Public bug reported:
Using 16.10
ethernet stopped working, network indicator & nmcli reports that my ethernet is
unmanaged.
ifconfig reports it has no ip address. I turn on wifi and it works fine.
Doing ifconfig up; dhclient works for
getting ip address
I did have network-manager snap
There can be many ways captive portals work and it is tricky being able
to support the different ways of detecting this.
I've seen some offer redirects, but others offer different status codes
to indicate the captive portal, and not all captive portals act properly
once things get returned.
I
awe is currently working on getting the update to 1.2 working. Work is
ongoing, and needs a few more improvements and patches ported.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
Is there any reason to keep both connections active at the same time?
Obviously it needs to be able to connect to mobile data when wifi is
connected for HERE/agps, but I think it just needs to download satellite
data once (I could be wrong it might need to keep downloading this data)
--
You
@Tony
1) requestUpdate() should be left in, as the backend needs to tell other parts
when the update request has been completed. I have tested this, so it does
compile. In further testing, it does not look like any clients are requesting
updates, so the increased power consumption is coming
fyi: requestUpdate is called by the qnetworkconfigurationmanager, when
updateConfigurations() gets called.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1480877
Title:
patch #6 fixes crash in system-settings (#1523975) and removes wifi
scanning updates, which could potentially drain the battery (#1524133)
** Patch added: "net-bearer-nm-disconnect-ap-signals6.patch"
@Tony I suppose that if statement in
QNetworkManagerEngine::requestUpdate() could also be removed, leaving
the last line only, since we do not do anything with uknown AP's
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager
@Tony, currently I am on stable/ubuntu-developer. Previously I was
testing on stable/ubuntu. I was on rc-proposed for quite a while, but it
seemed to have only a few scopes, and not the twitter scope which I
wanted to try out.
My updated patch removes actions on device added and removed calls.
@Tony
I noticed this on touch.
The problem was that the ConnectionActive was returning true for mobile data
ipv6 default route when wifi had the actual default route, so it would never
get updated when wifi became default.
--
You received this bug notification because you are a member of
I agree, since nothing controls the connections through QtBearer (and
the platform doesn't want that), and AP lists are not allowed in
contained apps, it makes sense to simply remove them.
I've fixed up that patch in regards to d'tor disconnects, removed some
redundant code.
And since it was a
hmmm... I just noticed/remembered that upstream Qt networkmanager plugin
has been updated, which should perform a bit better as it has had some
refactoring/rewriting done. It is slightly more sane.
--
You received this bug notification because you are a member of Desktop
Packages, which is
Actually, the only time Qt's QNetworkManagerInterfaceAccessPoint does a
GetAll is in the QNetworkManagerInterfaceAccessPoint c'tor. But that is
in the upstream version.
And the current ubuntu version (at least the one I am seeing) does not
do GetAll at all.
--
You received this bug notification
This patch fixes duplicate entries of access points. Which contributes
to but may not totally fix this bug.
** Patch added: "nmbearer-fix-duplicates.diff"
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1480877/+attachment/4521638/+files/nmbearer-fix-duplicates.diff
--
You
nmRegistered will only get called from the connection signal/slot when
networkmanager daemon if and when gets registered on the dbus. If it is
already registered, it will get called from that invokeMethod.
--
You received this bug notification because you are a member of Desktop
Packages, which
You are correct in that GetAll gets called twice for each accesspoint.
I can see that by adding qDebug's and disable/enable wifi
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
Sorry, thought I'd include more.
2nd patch that obsoletes my previous patch includes disconnecting from
system dbus when objects get deleted.
** Patch added: "nmbearer-fix-duplicates2.diff"
The generic bearer plugin is brain dead, especially when it comes to
knowing when it's actually connected or not.
Although connectivity-api also suffers from blocking dbus calls, I feel
the connectivity-api backend is the right way to go for bearer & QNAM
right now. In the least, it will lessen
That's right, any time QNAM is used it uses the Qt Bearer backend
(unless Qt is configure without bearer). In the case of the network-
manager backend, it calls the blocking dbus calls to get list of
services, and then for every service to get that services properties.
Even for local file://
You might be running into those dbus blocking calls in the network-manager
bearer backend.
The networkmanager bearer plugin currently is using a few blocking dbus calls
to get properties and such.
see this abandoned change here:
https://codereview.qt-project.org/#/c/98090/
This change was
Start InternetCheckercmd with wifi enabled, with the known wifi router
unpowered or out of range, while connected to mobile data. (will not
work like this when manually enabling/disabling wifi)
It will return something like this:
phablet@ubuntu-phablet:~$ InternetCheckercmd/InternetCheckercmd
Has that network-manager fix hit ubuntu-rtm/devel yet? Because without
these qtbearer/qnam patches, I'm still seeing images loading issues.
The problem is not manually disabling the AP, but when moving (roaming)
from one to another, i.e. moving from wlan coverage to 3g coverage, or
from 3g to
I did more testing of the generic plugin, and it's not as bad as I
thought, in that it does signal when interfaces become the default
route.
But my comment still stands that without these patches (in the least,
the patch to QNAM itself is especially needed) the defaultConfiguration
internal to
Here's a patch to skip some of the tests that are failing due to no
valid configurations on the test machines.
** Patch added: skip failing network tests
When I run that test on the phone, it does not crash and passes.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1357321
Title:
[TOPBLOCKER] QNetworkAccessManager doesn't
Updated upstream. https://codereview.qt-project.org/#/c/99818/
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1357321
Title:
[TOPBLOCKER] QNetworkAccessManager doesn't
When I use dbus-monitor on NetworkManager, I get this:
signal sender=:1.8 - dest=(null destination) serial=2845
path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager;
member=StateChanged
uint32 20
signal sender=:1.8 - dest=(null destination) serial=2852
Ok, I think I see the light now. This is an odd one.
There seems to be two connection settings (within networkmanager) for
the same connection context (even in mako), one being the nm settings
configuration that is actually connected (settings/2), and the other
that is not flagged as active
This fixes that last reconnection issue. There might be a better way,
but with this, the connection is stable again.
https://codereview.qt-project.org/#/c/99818/
But the question remains why NetworkManager has more than one
configuration for a context
--
You received this bug notification
Well, I did delete the contents of ~/.cache and reboot. But now I do not
have the apps grid.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1357321
Title:
[TOPBLOCKER]
According to dbus-monitor, the mode interface keeps failing:
signal sender=:1.8 - dest=(null destination) serial=1635
path=/org/freedesktop/NetworkManager/Devices/1;
interface=org.freedesktop.NetworkManager.Device; member=StateChanged
uint32 120
uint32 40
uint32 0
signal sender=:1.8 -
modem interface...
Is there anyway to edit comments?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1357321
Title:
[TOPBLOCKER] QNetworkAccessManager doesn't support roaming
syslog with networkmanager debug.
Starts with being connected. double spaced when it reached disconnection, and
ends with reconnection.
** Attachment added: nm debug syslog
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1357321/+attachment/4258799/+files/syslog.log
--
As for the original comment. If I delete the cache and reboot,
icons/images do not show up like normal if I start up with 3g
connection.
Looking at the syslog, I noticed the disconnection always starts with
the line:
NetworkManager[1439]: debug [1415764765.680476] [nm-modem.c:533]
weird. I just downloaded/installed the package again, and I can no
longer see that disconnect/reconnect loop.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1357321
Title:
Using only the generic plugin: rmnet_usb0 seems to be having issues.
(repeated ad-infinitum)
(NetworkConfig::configurationChanged:202) - default config
(NetworkConfig::configurationChanged:183) - Unknown 312537797 rmnet_usb0
UnknownPurpose Defined BearerUnknown InternetAccessPoint
@kgunn72 I think we certainly have moved on to a different bug.
Originally, QNAM was not considering mobile data connection at all,
because the QtBearer was only using generic plug (which does not know
the difference between mobile data and other network interfaces and is
not really usable
QNAM uses QtBearer, which means those are handled by the NetworkManager
backend, which I am currently trying to fix up.
There are two ways of diserning online status with QtNetwork.
1) QNetworkConfigurationManager has isOnline() method, this can be done
on the defaultConfiguration().
2)
38 matches
Mail list logo
