** Changed in: network-manager (Ubuntu)
Assignee: Tony Espy (awe) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1407928
Title:
[phone] Does not auto-switch to available, kn
I've confirmed with the original customer that this indeed *is* working
as expected. As such, I'm updating the status on both tasks to
'Invalid'.
** Changed in: rsyslog (Ubuntu)
Status: Incomplete => Invalid
** Changed in: snappy
Status: Incomplete => Invalid
--
You received
** Changed in: rsyslog (Ubuntu)
Status: New => Incomplete
** Changed in: snappy
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1875493
Title:
[core] log
I just updated the status to Incomplete for both bug tasks, as I may
have been too confident in the original bug description given to me by
the customer.
The logrotate script as written is not meant to "restart" rsyslogd.
Looking at the man page, the HUP signal (as sent by the /usr/lib/rsyslog
This bug no longer exists in Ubuntu 16.04, as the rsyslog rotate script
(inherited from the Debian package) handles both systemd and sysvinit
based systems:
$ more /usr/lib/rsyslog/rsyslog-rotate
#!/bin/sh
if [ -d /run/systemd/system ]; then
systemctl kill -s HUP rsyslog.service
else
@ogra If the component in question was removed and/or deprecated and no
longer used in the current development release, then the policy
shouldn't apply. In this case I don't think it would be much of a
stretch to get a waiver for this. That said, as I'm pretty sure this bug
is specific to Core, so
@ogra This is a bug in the core[16] snap. I'm not sure why we'd even
consider SRU'ing to UC18 or UC20. On both of the those systems, core
wouldn't be the booting snap, so any fix would be a no-op.
Possible ways to fix include:
- releasing an rsyslog SRU for 16.04, but as Michael points out this
Public bug reported:
A customer recently reported that 'sudo docker run hello-world' fails on
a pi3 or pi4 running UC18. Looking at the journal, the failure appears
to be caused by an apparmor denial related docker's overlay2 storage
driver. I've tried both the unified and the Pi3 specific UC18
snappy-hwe-snaps is a project used to track work related to system stack
snaps published by Canonical. Your bug most likely has to do with the
bluez (or related) Debian package from the Ubuntu archive.
** Project changed: snappy-hwe-snaps => bluez
** Project changed: bluez => bluez (Ubuntu)
--
This project is meant for tracking bugs and source code related to
system stack snaps (bluez, modem-manager, ... ) published by Canonical.
Please use a bug tracker for Peppermint Linux.
** Project changed: snappy-hwe-snaps => ubuntu
** Changed in: ubuntu
Status: New => Invalid
--
You
@Alfonso
What's the use case for calling 'netplan apply' in this scenario? Is NM
the configured as the netplan renderer?
Is there ever a case where "systemd-networkd-resolvconf-update.service"
can call resolvconf even though NM is the renderer from the start (i.e.
there's no transition from
I just ran an additional five cycles of the testing described in my
previous comment with no failures.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1762672
Title:
TPM intermittently fails after
Tested the latest OEM kernel from -proposed on a Dell Edge Gateway 3000
running Ubuntu Server 18.04 LTS:
# rmadison linux-image-oem | grep bionic-proposed
linux-image-oem | 4.15.0.1035.40 | bionic-proposed | amd64
# dpkg -l | grep linux-image-oem
ii linux-image-oem
@Tyler
So it looks like we landed this just in time for the new SRU cycle,
which means we're looking at a tentative release to proposed on Mar 25.
Does that sound right? If so, I may check with Anthony to see if there's
a possibility that linux-oem could possibly re-spin and release
earlier...
@Khaled
Just curious as to why this is now FixCommitted? Has Tyler's back-port
landed in git for the next OEM and/or mainline kernel SRU release?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1762672
** Description changed:
- [0.801334] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 4)
- [0.812132] tpm tpm0: A TPM error (2314) occurred continue selftest
- [0.843629] tpm tpm0: A TPM error (2314) occurred continue selftest
- [0.895424] tpm tpm0: A TPM error (2314)
** Summary changed:
- TPM on Dell XPS 13 stopped working after upgrade to 18.04
+ TPM intermittently fails after cold-boot
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1762672
Title:
TPM
I've run 10 cold boots on the gateway mentioned in my previous comment,
and in each case after issuing a tpm2_startup clear command, I've been
able to query the NVLIST of the TPM. So the back-ported patch appears to
be working as advertised.
--
You received this bug notification because you are
@Tyler I've tested your kernel on a Dell Edge Gateway 3000 which was
showing the same TPM selftest log messages as originally described in
this bug. When cold-booted with your kernel I only see the following
messages now:
14:57:44 [0.00] ACPI: TPM2 0x76D537C8 34 (v03 Tpm2Tabl
Note it's possible to use grub2 configuration directives to lock down
privileged operations (such as access to the shell). The 'superusers'
and 'password*' directives can be used to require user auth before
certain operations. It even looks like it's possible to completely
disable these privileged
** Changed in: network-manager (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1781597
Title:
[SRU] WoWLAN settings are not supported
To manage notifications
And after reverting core back to 2.34.1, it's reported as:
{
"snap": "core",
"slot": "optical-drive",
"interface": "optical-drive",
"label": ""
},
So yes, this looks like a valid bug. Also looks like "label:" was
dropped?
--
You received this bug notification
I *think* (I don't have a pre-2.35 core snap at hand) the issue is that
the 'snap' attribute of the core interfaces as reported by snapd's
/v2/interfaces endpoint used to be set to "core", whereas with 2.35 it's
reported as "system". Here's a fragment of the JSON returned by this
endpoint for the
Sorry, the version of core that I reverted back to was 16-2.34.3 (5145),
not 2.34.1.
** Summary changed:
- The core snap was renamed to system in the 2.35 release
+ [2.35.1] /v2/interfaces returns "system" instead of "core" as owning snap of
core interface slots
--
You received this bug
The bug was accidentally reported against the wrong project.
** Changed in: ubuntu
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1771463
Title:
[18.04 Server]
I just changed the status of this bug to Incomplete, and will follow up
with the bug reporter as there's insufficient detail in the description,
and most likely a misunderstanding of how Ubuntu dependencies work.
** Changed in: ubuntu
Status: New => Incomplete
--
You received this bug
Re-opened, as there's some interest from OEMs in seeing NM teaming
support land in 18.04.
** Description changed:
Availability:
The package is available in universe, built on all architectures.
Rationale:
- The package is a new (Build-)Depends for network-manager, for network device
The description needs some more detail.
>From what I've read, the bug is:
1) Install a new kernel snap from candidate channel which has known bugs
2) Verify that the bugs are reproducible
3) Revert the kernel snap back to the stable version
4) Re-test to ensure known bugs are not reproducible
My point is that we shouldn't release these patches as an SRU without
being able to reproduce the bugs that the patches claim to fix first.
Otherwise we risk introducing additional regressions.
So if we want to consider an SRU for NM with one or more of Aaron's
patches, then yes we need to go
There's no evidence (ie. syslogs, package versions, output of wpa_cli)
provided which is a basis for re-opening the bug.
Also, please point us to the *exact* patch that is supposed to fix the
problem.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
This bug was marked FixReleased based on the upload of network-manager
1.2.6-0ubuntu0.16.04.1 to xenial updates and the comments from a many
people that the issue was resolved.
Recently there were two comments (#96 and #97) that claim that the bug
still exists. Comment #96 doesn't even list
@Kevin
NetworkManager already has code to monitor system signals related to
suspend/resume, so no adding additional scripts to /usr/lib/systemd
/system-sleep isn't the answer.
@Dan
Different bug... this bug is caused by NetworkManager's WiFi scanning
logic stalling due to a race condition.
Updated the Status to "FixReleased" as it's not possible to do this
anymore on the latest 16.04 LTS release with NetworkManager 1.2.x, as
guest users no longer have sufficient permission to add new connections.
Retrofitting this to the version of NM in 14.04 might be a challenging as the
** Changed in: network-manager (Ubuntu)
Status: Triaged => Won't Fix
** Changed in: network-manager (Ubuntu)
Status: Won't Fix => Fix Released
** Changed in: network-manager (Ubuntu)
Status: Fix Released => Incomplete
--
You received this bug notification because you are a
Ugh, and then I wake my Thinkpad 410s just now, and I hit the bug on the
201st cycle. ;(-
Guess I'll go back to dropping the patch again from 1.2.6 and see how
many cycles I can run on it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
@taiebot65
Thanks. I'll take a look.
Regarding this bug, it turns out that when I was testing my version of
NM with the dropped 'ScanDone' patch (wifi-Signal-on-the-wifi-
device...), I'd been doing so on top of the newly re-based 1.2.6, and it
turns out there was an actual fix in 1.2.6 which
** Changed in: oem-priority/xenial
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1585863
Title:
WiFi malfunction after suspend & resume stress - sudo wpa_cli scan
I've reproduced this on a Thinkpad 410s running 16.04 LTS. The version
of network-manager I used is the latest from xenial-updates:
1.2.2-0ubuntu0.16.04.3.
A few comments:
1) The fwts s3 test uses a low-level API to exercise suspend/resume.
I've been working with the fwts maintainer on an
Just moved this to Incomplete, as it's been posited that the fix for bug
#1104476 resolves the issue.
If anyone can confirm that this is still broken, we can investigate
further.
** Changed in: network-manager (Ubuntu)
Status: Triaged => Incomplete
--
You received this bug notification
As this has been fixed in netplan, I'm changing the status of the HWE
task to Invalid. If this is incorrect, or there's something else we
need to do in the NM snap, then feel free to re-open.
** Changed in: snappy-hwe-snaps
Status: New => Invalid
--
You received this bug notification
@Alfonso
Let's put this on the agenda for this weeks' net/telephony meeting.
I'm not sure I'm comfortable with releasing your workaround just yet as
it introduces latency when the APs are properly configured for roaming.
--
You received this bug notification because you are a member of Ubuntu
Public bug reported:
Configuring a static IP address for an ethernet device on an Ubuntu Core
16 system generates a netplan file without a gateway specified, thus the
console-conf WaitDefaultRouteTask eventually times out. Here's the
netplan file generated:
network:
ethernets:
eth0:
Ah, thanks for the clarification.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/688286
Title:
[MIR] ofono
To manage notifications about this bug go to:
@Michael
Didn't quite catch that last bit about ofono-scripts. Care to
elaborate? Is this something we should fix in our next landing?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/688286
Title:
** Changed in: ofono (Ubuntu)
Importance: Undecided => Critical
** Changed in: ofono (Ubuntu)
Status: Incomplete => In Progress
** Description changed:
- Binary package hint: ofono
+ [Availability]
+ * Available in universe
- I have reviewed the package and it meets the
** Changed in: network-manager (Ubuntu)
Assignee: Tony Espy (awe) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1551823
Title:
PPTP connection does not work and dies afte
This certainly makes sense, but given our current plans, this isn't a
high-priority interface in the short term.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1616048
Title:
Create interface for
ollaborate with Jolla as the code is stable, and hasn't
been touched since the package was created.
>From the initial bzr revision:
revno: 1
committer: Tony Espy <e...@canonical.com>
branch nick: trunk
timestamp: Wed 2014-07-30 15:
Public bug reported:
[Availability]
* Available in universe
[Rationale]
* This package is required by unity8
[Security]
* No known security issues at this time. It has been reviewed by security in
the past for use on the phone.
[Quality assurance]
* This package has no unit tests or
Installing the proposed packages worked for me, albeit with an extra
hoop of running a snap app as sudo first to get around the permission
problem.
After the installing, I did:
% sudo snap install hello
% hello
mkdir: cannot create directory ‘/home/espy/snap/hello’: Permission denied
% sudo
Fix Committed
** Changed in: network-manager (Ubuntu)
Status: Fix Committed => Confirmed
** Changed in: network-manager (Ubuntu RTM)
Importance: Undecided => High
** Changed in: network-manager (Ubuntu RTM)
Assignee: (unassigned) => Tony Espy (awe)
** Changed in: network-man
The fix is currently in silo 005, and was just marked 'Lander Approved'.
The version containing the fix will be 1.2.2-0ubuntu1~xenial3, and
should hopefully land in the next few days.
** Changed in: network-manager (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug
** Changed in: network-manager (Ubuntu)
Status: Confirmed => In Progress
** Changed in: indicator-network (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
So... a long time ago, when Ubuntu Touch was first being developed, we
hit a bug with certain rild implementations that would configure the
routing table when a data call was established, and this caused problems
with NM's routing logic.
The workaround was the creation of a NM dispatcher script
)
Status: New => In Progress
** Changed in: network-manager (Ubuntu)
Status: In Progress => Invalid
** Changed in: lxc-android-config (Ubuntu)
Assignee: (unassigned) => Tony Espy (awe)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which i
** Also affects: network-manager (Ubuntu)
Importance: Undecided
Status: New
** Changed in: network-manager (Ubuntu)
Assignee: (unassigned) => Tony Espy (awe)
** Changed in: phablet-tools (Ubuntu)
Status: Confirmed => Invalid
** Changed in: network-manager (
A quick look at the list-modems output shows the following for the
NetworkRegistration interface for SIM1:
[ org.ofono.NetworkRegistration ]
Mode = auto
Strength = 100
Name =
Technology = umts
Status = registered
LocationAreaCode = 20498
@Dave
Did you ever confirm my results per my last request in comment #11?
It's looking more and more like I was mistaken, and that NM 1.2 may
indeed be the culprit.
I re-tested the emulator with the latest rc ( #27 ), and dropped a
"manual" network-manager.override file in /etc/init. When I
@Pat Is there a new rc available then?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1587808
Title:
Ubuntu-emulator no network on latest image
To manage notifications about this bug go to:
By default, ubuntu-emulator creates an /etc/network/interfaces file with
the following contents:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.0.2.15
netmask 255.255.255.0
gateway 10.0.2.2
dns-nameservers 10.0.2.3
iface eth1 inet manual
iface eth2
** Changed in: network-manager (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1597681
Title:
[CTA] Enable WAPI support
To manage notifications about
** Description changed:
I dialed a number that happened to call me at the exact same moment - I
received the call and completed it, but the outgoing call remains in a
zombie state, can't be hung up and I can't make any other calls:
$ /usr/share/ofono/scripts/hangup-call
I just updated bug #1593686 ( WPA-PSK limit introduced in OTA11 ) with
the root cause which confirms Pete's theory about timeouts.
That said, *if* a user had successfully connected to an AP prior to the
update to OTA11. This *shouldn't* have caused issues, as the psk would
already have been
I just confirmed that this is a regression is caused by the final
deprecation of dbus-glib in NM 1.2x, and it's replacement by gdbus. As
part of this work, the code which requests secrets from a secret-agent,
now uses code generated from the introspection XML to make the actual
DBus method call.
** Changed in: ubuntu-system-settings (Ubuntu)
Status: Confirmed => Invalid
** Changed in: canonical-devices-system-image
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@Andrea
Can you provide the info requested on comment #25 too?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580146
Title:
[touch] Internet connection stops working while WiFi is still
@Andrea
There are two tests I'd like you to run for me.
First, let's verify the baseline by flashing OTA10 ( pre-NM 1.1.93
landing ) on a spare krillin, and then set the WiFi connection to the
opposite as earlier suggested, this time setting ipv4.method to ignore.
This will validate that IPv6
** Changed in: ofono (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1588127
Title:
Phone abandons incoming call
To manage notifications about this bug go
** Changed in: network-manager (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1565717
Title:
No connection after returning from area without
** Changed in: network-manager (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1579098
Title:
[touch] Mobile data connection drops, and doesn't
Public bug reported:
Although the hotspot logic was vastly improved in OTA11, there are still
intermittent issues with enabling hotspot on arale.
On a freshly flashed phone running rc-proposed / 356, when I first
attempt to setup a hotspot, when I click the "Start" button, the spinner
shows up
** Attachment added: "indicator-network log file from arale after start failed"
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1594938/+attachment/4688158/+files/indicator-network.log
** Also affects: canonical-devices-system-image
Importance: Undecided
Status: New
** Attachment added: "Screenshot of Hotspot setup dialog"
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1594938/+attachment/4688157/+files/hotspot-spinning.png
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@Simon
Pretty sure my results reported in comment #11 were using the silo, so
5.37 doesn't resolve the problem.
I just re-tested on arale ( rc-proposed, 350 ) and still see the same
behavior on the initial connect of the headset. Unfortunately, I can't
seem to get the headset to work at all now
I created an emulator instance using revision 19. I verified indeed
that it's running NM , per comment #8. The indicator shows that
airplane mode is active, although urfill isn't running (
/usr/share/urfkill/scripts/flight-mode throws an error ). When I run
'nmcli d', I see that ril_0 ( the
** Changed in: network-manager (Ubuntu)
Status: Confirmed => In Progress
** Changed in: canonical-devices-system-image
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Any chance you can fire up an old emulator image and prove this?
Again, although there is a modem emulation included in the emulator
image ( it's part of qemu ), it's not sufficient for us to run a full
ofono/rilmodem against.
AFAIK, there's no special trigger to configure ofono phonesim on the
We've never really had any kind of working mobile data support in the
emulator. There was an effort a long time ago to try and make this work
for CI testing of ofono, but as it was estimated to be a major under-
taking, we abandoned it.
It should be possible to use the ofono phonesim package to
** Changed in: phablet-tools (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1587808
Title:
Ubuntu-emulator no network on latest image
To manage
** Changed in: network-manager (Ubuntu)
Status: Incomplete => In Progress
** Changed in: network-manager (Ubuntu)
Assignee: (unassigned) => Tony Espy (awe)
** Changed in: network-manager (Ubuntu)
Importance: Undecided => High
--
You received this bug notification be
OK, so there are two low-level problems:
1. InProgress error returned by SetProperty('Active',true) call to ofono
for a gprs-context.
Alfonso's first syslog shows that this can happen, but I'm not sure
exactly how to reproduce. NM would've had to start activation, then
Attached bounced down and
@Pat
The reason I asked was that two of the three scenarios listed by Alfonso
in the bug involved a crash or restart of NetworkManager, and the
resulting state was that the mobile data connection gets stuck trying to
activate an already active ( or activating ) connection.
I wasn't sure if he
@Andrea
Can you try adding the following setting to the NetworkManager
connection file for "Canonical-2.4GHz-g" in /etc/NetworkManager/system-
connections:
[ipv6]
method=ignore
"[ipv6]" should already be there, so just add "method=ignore", and
remove any other settings under "ipv6".
Restart
So from @Andrea's latest pastebin:
- NM shows both modem and wlan0 as connected
- syslog shows one DHCP renewal period
- a do-add-ip4-address error is logged, however the IP address is still
configured ( ip addr show confirms this ); need to investigate whether
the error log message is
@Alfsonso
One more note, although comment #2 isn't a valid scenario, it does
trigger the same behavior.
The root cause of the bug is that the current NM wwan plugin doesn't
properly handle already activated contexts.
** Changed in: network-manager (Ubuntu)
Status: Confirmed => In
@Alfonso
The scenario in comment #2 isn't valid. That said, I am able to
reproduce by killing NetworkManager, so I agree this is a valid bug that
needs to be fixed.
@Pat
As Alfonso pointed out, your problem is different, as there's no active
context, nor does NetworkManager appear stuck.
** Changed in: network-manager (Ubuntu)
Assignee: (unassigned) => Tony Espy (awe)
** Changed in: network-manager (Ubuntu)
Importance: Undecided => Critical
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@Andrea
Let's try and work together to get the description of the bug (
including steps to reproduce ) accurate.
The initial description was network "stops working" when WiFi is "still
connected". This implies the network was actually connected and working
before the bug occurred, true? It'd
@Andrea
Re: comment #3, please review bug #1533508, to see if your hitting the
same. If not, please file a new bug and include output from
/usr/share/ofono/scripts/list-modems and list-contexts.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
@Andrea
One last thing... did you check for crash files?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580146
Title:
Internet connection stops working while WiFi is still connected
To manage
@Andrea
Finally, you might also want to consider "forgetting" some of the saved
access points on your device. NetworkManager shows a seriously long
list of WiFi connections.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@Andrea
Let's keep this bug specific to the original problem described.
Does this problem only occur at the office?
Can you reproduce it reliably? If so, how long after you initially
connect does it take to manifest itself?
>From what you provided in your initial pastebin, both the indicator
** Changed in: network-manager (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580146
Title:
Internet connection stops working while WiFi is still connected
** Changed in: network-manager (Ubuntu)
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1579915
Title:
network-manager 1.2 uses more power
To manage
Two things I noticed while testing the powersave fix from silo-77:
1) On mako ( rc-proposed / 434 ), iwconfig doesn't report anything at
all for powersave. This may be a driver limitation.
2) On frieza ( rc-proposed / 101 ), the powersave period is set to 0,
which may be a less than ideal
I've confirmed that the default powersave patch included in xenial is
wrong, as it patches libnm-util which is deprecated, as opposed to
patching the new libnm0.
I've update the version of NM in the silo for VPN with an updated patch
which restores WiFi powersave by default.
Note, it looks like the problem is that the original patch fixes up the
libnm-util version of nm-settings-wireless.c which has been deprecated.
Instead the libnm-core version of nm-settings-wireless.c needs to be
updated. I'm testing this now for a touch build and will report back
here if it
To be clear from discussions with Andrea, the network is accessible, but
it appears that DNS isn't working correctly. He's able to ping an IPv4
address, but trying to ping a hostname results in an immediate'unknown
host' being displayed.
--
You received this bug notification because you are a
@Amr
Thanks for the pointer. I just added a comment to bug #1557026
regarding the xenial powersave regression, and it applies to Touch as
well.
I'm working on an updated patch for Touch, and then will see about
SRU'ing for xenial as soon as possible.
--
You received this bug notification
So NM 1.1.93-0ubuntu1 includes the patch default_powersave_on.patch,
which is pretty simple, it just modifies the NMSettingWireless code to
default powersave to 1:
===
--- a/libnm-util/nm-setting-wireless.c
+++
1 - 100 of 2316 matches
Mail list logo
