Bug#829257: RFP: ndctl -- NVDIMM management utility

[Dan Williams]

On Tue, Nov 21, 2017 at 11:11 AM, Breno Leitao  wrote:
> Hi Dan,
>
>> Hi Breno,
>>
>> That link has gone dead, can you repost the package?
>
> The package is now on the NEW queue.
>
> https://ftp-master.debian.org/new/ndctl_58.2-1.html

Ah, wonderful, thanks for that.

>
> Are we able to get it from there?
> Let me know if not, and I can re-upload to mentors.
>

I think we're good to go, thanks for taking the initiative on this.

Bug#829257: RFP: ndctl -- NVDIMM management utility

[Dan Williams]

On Fri, Feb 17, 2017 at 8:18 AM, Breno Leitao  wrote:
>> I can work on it if Nish is not planning to submit his package to Debian.
>
> I just created the package and it is at mentors.
>
> https://mentors.debian.net/package/ndctl
>
> Any review is appreciated. If no problems are found, I am willing to upload 
> it.

Hi Breno,

That link has gone dead, can you repost the package?

Bug#829257: RFP: ndctl -- NVDIMM management utility

[Dan Williams]

On Tue, Feb 7, 2017 at 10:55 AM, Breno Leitao  wrote:
> Is there anyone working on packaging ndctl? If not, I have interest in
> working on it.
>

No, I don't think there is.

Nish had put together a snap package here:

https://launchpad.net/~nacc/+archive/ubuntu/nvdimm

...but I don't think he's working on a Debian package. I'd love to see
it integrated, let me know if I can help.

Bug#773525: Randomly excludes available connections [when there are too many?]

[Dan Williams]

On Fri, 2015-07-17 at 00:35 +0100, Simon McVittie wrote:
> On 17/07/15 00:13, Dan Williams wrote:
> > eg, think of it as each contact in Telepathy being an object



> > The solution here is likely to transition the libnm implementation over
> > to the ObjectManager interface's GetManagedObjects() method for the
> > initial setup, to get everything in one call.  A lot of data, but likely
> > faster than doing it piece-by-piece.
> 
> That's what I'd recommend; ObjectManager is precisely for situations
> where clients are interested in "most" children of a parent object.

That's the path I'd like to pursue, I did an initial implementation of
the OM interface for NM git master (what will become 1.2) based on our
gdbus conversion (which is now merged! hurrah!!!) and filed a bug to
track its ongoing work:

https://bugzilla.gnome.org/show_bug.cgi?id=753566

> > Any
> > chance we could get dbus-glib to implement GetManagedObjects()?
> 
> It is entirely possible to "roll your own" GetManagedObjects; indeed,
> Telepathy reimplements the entire service-side Properties interface
> (because dbus-glib was historically even worse than it is now).
> 
> I'm a little reluctant to add features to dbus-glib, because it's a dead
> end; but if it helps NM, I'd make an exception for reviewing
> ObjectManager support.

Since we've just merged our gdbus conversion, there is less need for
dbus-glib changes now.  Unless of course somebody tries to use kdbus
with NM <= 1.0.x, since the ObjectManager work isn't trivially
backportable because it depends on gdbus.  But if it comes to that,
we'll either say "upgrade" or we'll have to investigate solutions for
dbus-glib-based 1.0.x.  We will not be touching NM 0.9.10 for any of
these issues though.

Dan

Bug#773525: Randomly excludes available connections [when there are too many?]

[Dan Williams]

On Thu, 2015-07-16 at 23:56 +0100, Simon McVittie wrote:
> On 16/07/15 19:56, Dan Williams wrote:
> > There really isn't any solution that I can think of, except serializing
> > the requests in the client libraries.  Unfortunately, that's not a great
> > way to go about it and it simply complicates the code on the client
> > side.
> 
> In the medium to long term I think the only way is to have some sort of
> queue of requests, or improve NM's D-Bus API so that things can be
> batched (for instance getting properties of more than one AP per
> round-trip, which would also make it faster).
> 
> > It's quite easy to run over 128 pending replies.
> 
> How many do you need? Is the answer in fact "arbitrarily many"?
> 
> With some appropriate benchmarks we might be able to increase the limit
> by an order of magnitude or two, but I'm concerned that going back to
> the 1K that NetworkManager historically used might be too many.
> 
> The problem is that if you have an unbounded number of requests
> in-flight, the system dbus-daemon uses an unbounded amount of memory to
> track them; and the system dbus-daemon is a shared resource acting on
> behalf of various trusted and untrusted processes, so that would be bad.
> The reasons it tracks them at all are so that unsolicited "replies" can
> be rejected; so that if a client can call a method on a service, the
> service allowed to reply; and so that if a service falls off the bus
> without replying to all method calls it should have handled, dbus-daemon
> can synthesize error replies immediately, rather than leaving the
> clients to time out.
> 
> At the moment dbus-daemon also doesn't use clever enough data
> structures, resulting in a CPU-consumption denial of service attack:
> with a lot of pending replies and a lot of connections allowed, an
> attacker can make dbus-daemon use a lot of CPU time. We dropped the
> pending reply limit from 8K to 128 because there was a practical
> denial-of-service attack with 8K (CVE-2014-3638,
> https://bugs.freedesktop.org/show_bug.cgi?id=81053): simple method calls
> could be made to take more than 25 seconds (the default timeout).
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=83938 has some attempts at
> better data structures, but it's significant code churn, so we're
> unlikely to land anything like that in a dbus stable-branch. I'd be
> happy to review a cleaned up implementation, but that isn't going to
> help for distributions that aren't tracking bleeding-edge dbus.
> 
> kdbus' hard-coded limit was also 128 pending replies per sender, last
> time I looked (although I think it was just coincidence that Alban
> suggested the same number after experimenting with denial of service
> attacks). It needs to track requested replies for basically the same
> reasons as dbus-daemon, and also has to be fairly conservative with its
> limits because it's allocating kernel memory. So moving to kdbus is
> probably not going to save us from this.
> 
> > We do have the 'libnm' library with NM 1.0+ that uses GDBus all the way
> > through, so if GDBus somehow manages to avoid this problem then great.
> > Otherwise, we'll have the same problem in libnm too...
> 
> It sounds as though this is really an issue with the high-level design
> of NM's D-Bus API, rather than the specifics of how the client library
> is implemented, so I don't think GDBus is going to help.

I'd take issue with that assertion actually.  The object model of NM is
such that the number of objects can be determined by either (a)
configuration, eg number of saved network connections or (b) external
network properties like number of access points, etc.  I don't think
that's really unreasonable, especially given how D-Bus wants objects +
properties + interfaces.  I'd rather not go all libpurple-style and
stuff all properties into one interface so we can save 2 GetAll() calls
per object.

eg, think of it as each contact in Telepathy being an object, and I can
easily see somebody having 100+ contacts/friends etc.  Each of those
contacts has properties to be retrieved too.  So would a client just try
to get 50 of those at a time, wait for the reply, then get the next 50?
And then fire off GetAll() on each of those in 50-item batches?  And
then for multiple interfaces?

Also, how is a client supposed to know how big the limit is?  Or is a
client just supposed to use a sufficiently low number that it is known
to work in all cases?

The solution here is likely to transition the libnm implementation over
to the ObjectManager interface's GetManagedObjects() method for the
initial setup, to get everything in one call.  A lot of data, but likely
fas

Bug#773525: [Pkg-utopia-maintainers] Bug#773525: Randomly excludes available connections [when there are too many?]

[Dan Williams]

On Thu, 2015-07-16 at 19:16 +0200, Michael Biebl wrote:
> Am 19.12.2014 um 15:32 schrieb Pietro Battiston:
> > Package: network-manager
> > Version: 0.9.10.0-4
> > Severity: grave
> > 
> > Copypasted from a shell:
> > 
> > pietro@debiousci:~$ for i in `seq 1 10`; do nmcli c | wc; done
> > 127 637   12827
> > 127 637   12827
> > 127 627   12827
> > 126 628   12726
> > 127 629   12573
> > 127 634   12828
> > 127 629   12827
> > 127 630   12319
> > 127 631   12827
> > 127 627   12827
> > 
> > 
> > I am clearly not changing my list of available connections (so quick!). So 
> > what
> > is happening is that network-manager is dropping some of my registered
> > connections, in a random way. Initially I though "it is unable to handle 
> > more
> > than 127", but then I saw that sometimes it only lists 126. The output of
> > "nmcli c" is otherwise almost sane (see below).
> 
> Seeing the latest upstream release, it noticed the following commit [1]:
> 
> > dbus: increase 'max_replies_per_connection' limit in D-Bus configuration
> > D-Bus default limit of replies per connection has been lowered to 128 due to
> > CVE-2014-3638, see:
> > http://cgit.freedesktop.org/dbus/dbus/commit/?id=5bc7f9519ebc6117ba300c704794b36b87c2194b
> > https://bugs.freedesktop.org/show_bug.cgi?id=81053
> > 
> > The limit seems to be too low and causes problems in libnm-glib, that will 
> > not
> > return all NetworkManager connection profiles if there are too many of them
> > (roughly more than the limit). As a consequence, libnm-glib based clients 
> > will
> > not work properly.
> 
> This looks like it could be the reason for the problem you are seeing.
> 
> That said, I'm not sure if individual daemon packages overriding the
> dbus policy in that regard is a good idea (and a proper fix).
> 
> I've CCed the upstream maintainers of NM and dbus. Maybe we can find a
> solution for this.

There really isn't any solution that I can think of, except serializing
the requests in the client libraries.  Unfortunately, that's not a great
way to go about it and it simply complicates the code on the client
side.  For example, say you have perhaps 40 saved connections and you're
in a large city and so can see 30 or 40 access points.  When some client
starts up, it may request all of these initially, and also request
properties on the objects when some of the initial replies come back.
Obviously all of this happens asynchronously because blocking in a UI is
bad.  It's quite easy to run over 128 pending replies.

Attempting to serialize these in libnm-glib (or libnm for that matter)
would likely result in a bunch of code that's just a wrapper over
dbus-glib and one more layer of suck-itude.

We do have the 'libnm' library with NM 1.0+ that uses GDBus all the way
through, so if GDBus somehow manages to avoid this problem then great.
Otherwise, we'll have the same problem in libnm too...

Simon, any thoughts here?

Dan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#789457: [Pkg-utopia-maintainers] Bug#789457: Bug#789457: network-manager cannot create hotspot

[Dan Williams]

On Mon, 2015-06-22 at 00:38 +0200, Michael Biebl wrote:
> Am 21.06.2015 um 23:20 schrieb Pirate Praveen:
> > [connection]
> > id=Hotspot
> > uuid=a989fc8c-43e6-4f67-bc20-7bbca21938bf
> > type=802-11-wireless
> > autoconnect=false
> > 
> > [802-11-wireless]
> > ssid=savannah
> > mode=adhoc
> 
> One noticable difference I see is, that g-c-c creates a Hotspot
> connection here which has
> mode=infrastructure. Yours has mode=adhoc.
> 
> 
> Dan, are there any known issues with hotspot mode in ad-hoc mode?

Nothing known, no, but it's pretty dependent on the driver not being
stupid.  That said, best thing to get for debugging is the
wpa_supplicant debug logs to see what's going on in the supplicant.

dan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#784587: [Pkg-utopia-maintainers] Bug#784587: Bug#784587: network-manager: does not set up resolv.conf

[Dan Williams]

On Thu, 2015-05-07 at 19:08 +0200, Michael Biebl wrote:
> Hi Dan!
> 
> Am 07.05.2015 um 18:09 schrieb Dan Williams:
> > On Thu, 2015-05-07 at 13:15 +0900, Norbert Preining wrote:
> >> On Thu, 07 May 2015, Michael Biebl wrote:
> >>> The attached patch should fix the issue. Will poke upstream for a review
> >>> and upload tomorrow.
> >>
> >> Thanks for the quick fix!
> > 
> > Got found and fixed yesterday in nm-1-0...
> 
> Hm, I don't do any changes in the nm-1-0 related to that. Where those
> fixes not pushed?

Yeah, that was it.  Pushed now.

> > In git master there is no longer fallback if resolvconf fails for some
> > reason; but the resolv.conf manager is now a config option.  So we'd
> > expect distros to ship a sub-package that drops a config snippet
> > into /etc/NetworkManager/conf.d/ enabling resolvconf which also requires
> > the resolvconf package itself, so that when the config option is set,
> > resolvconf is always installed.  We may need some tweaking of the
> > default handling here, but the idea is that if the user specifically
> > chose resolvconf and it fails, that should be a hard failure and NM
> > shouldn't be touching resolv.conf since the user told NM not to...
> 
> I kind of liked the if-resolvconf-found-use-it behaviour.
> The new behaviour will be a bit icky if I go the subpackage route due to
> how conffiles are handled.
> conffiles (config files in /etc/) are not automatically removed by dpkg
> if the package is removed (they are only removed on purge).
> So if the user uninstalles (but doesn't purge) the sub-package, the
> conf.d snippet will stay around and he'll get resolv.conf failures
> because it's no longer guaranteed the resolvconf package is installed.

Hmm, ok.  I guess we'll have to allow fallback to writing resolvconf if
the executable doesn't exist.

dan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#784587: [Pkg-utopia-maintainers] Bug#784587: network-manager: does not set up resolv.conf

[Dan Williams]

On Thu, 2015-05-07 at 13:15 +0900, Norbert Preining wrote:
> On Thu, 07 May 2015, Michael Biebl wrote:
> > The attached patch should fix the issue. Will poke upstream for a review
> > and upload tomorrow.
> 
> Thanks for the quick fix!

Got found and fixed yesterday in nm-1-0...

In git master there is no longer fallback if resolvconf fails for some
reason; but the resolv.conf manager is now a config option.  So we'd
expect distros to ship a sub-package that drops a config snippet
into /etc/NetworkManager/conf.d/ enabling resolvconf which also requires
the resolvconf package itself, so that when the config option is set,
resolvconf is always installed.  We may need some tweaking of the
default handling here, but the idea is that if the user specifically
chose resolvconf and it fails, that should be a hard failure and NM
shouldn't be touching resolv.conf since the user told NM not to...

Dan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#782455: [Pkg-utopia-maintainers] Bug#782455: Bug#782455: network-manager-gnome: autostarted but not needed by gnome-shell ?

[Dan Williams]

On Wed, 2015-04-29 at 07:09 +0200, Michael Biebl wrote:
> Hi Dan!
> 
> Am 27.04.2015 um 22:00 schrieb Dan Williams:
> > On Mon, 2015-04-27 at 18:35 +0200, Michael Biebl wrote:
> >> Am 12.04.2015 um 15:15 schrieb Jérémy Lal:
> >> Afair, nm-applet was still autostarted for by gnome-shell to provide the
> >> VPN auth dialogs/secrets. I don't think this is the case anymore today,
> >> but I'm not totally sure. [1] indicates that it is no longer necessary.
> > 
> > GNOME autostart was disabled by d6ffe34dc092926fb949449c182e8f27722b6b8b
> > (2013-07-29) and then the shell watcher code was reworked and autostart
> > was re-enabled by e192e83c1aa136512a9d4f026f81677799af8127 (2013-10-10).
> > 
> > So yeah, it's re-autostarted now, and I guess that should be disabled.
> > GNOME Shell has handled VPN auth dialogs since version 3.4 or something
> > like that (almost 3 years old).  I've committed a change to the applet's
> > git master to disable autostart again.
> 
> I see, that you added GNOME to NotShowIn=
> I wonder if using
> AutostartCondition=GNOME3 unless-session gnome
> would be better, so it would still be run e.g. in GNOME flashback?

Do you mean the 'fallback' session?  If so, that still runs the GNOME
Shell network indicator.

> > On the subject of splitting nm-connection-manager from nm-applet in
> > packages, yes, I'd recommend that.  I would have 3 packages generated
> > from the network-manager-applet git repo:
> > 
> > nm-applet
> 
> That's currently called network-manager-gnome in Debian/Ubuntu
> 
> > nm-connection-editor
> 
> We don't split of nm-connection-editor (yet) in Debian. Is there a good
> reason to do so? Is the nm-connection-editor binary called from within a
> GNOME Shell session?

It does get called from the gnome-control-center binary for some
specific configuration cases still.

Dan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#782455: [Pkg-utopia-maintainers] Bug#782455: network-manager-gnome: autostarted but not needed by gnome-shell ?

[Dan Williams]

On Mon, 2015-04-27 at 18:35 +0200, Michael Biebl wrote:
> Am 12.04.2015 um 15:15 schrieb Jérémy Lal:
> > Package: network-manager-gnome
> > Version: 0.9.10.0-2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > In a gnome-shell session, i see that "nm-applet" is automatically
> > started, indeed by the fact network-manager-gnome installs
> > /etc/xdg/autostart/nm-applet.desktop.
> > However, this program is apparently not used at all by gnome-shell,
> > and not even accessible when started.
> > 
> > So i question two things here:
> > 
> > * why it is a dependency of gnome though it is not needed in the
> >   default gnome-shell session ?
> > * shouldn't network-connection-editor be in a separate package,
> >   allowing one to install it without autostarting nm-applet ?
> 
> Afair, nm-applet was still autostarted for by gnome-shell to provide the
> VPN auth dialogs/secrets. I don't think this is the case anymore today,
> but I'm not totally sure. [1] indicates that it is no longer necessary.

GNOME autostart was disabled by d6ffe34dc092926fb949449c182e8f27722b6b8b
(2013-07-29) and then the shell watcher code was reworked and autostart
was re-enabled by e192e83c1aa136512a9d4f026f81677799af8127 (2013-10-10).

So yeah, it's re-autostarted now, and I guess that should be disabled.
GNOME Shell has handled VPN auth dialogs since version 3.4 or something
like that (almost 3 years old).  I've committed a change to the applet's
git master to disable autostart again.

On the subject of splitting nm-connection-manager from nm-applet in
packages, yes, I'd recommend that.  I would have 3 packages generated
from the network-manager-applet git repo:

nm-applet
nm-connection-editor
libnm-gtk
libnma (replacement for libnm-gtk for NM 1.1+, no dbus-glib deps)

Dan

> The commit message also says, that nm-applet is no longer autostarted
> under GNOME Shell, which apparently is false.
> 
> So maybe this an oversight by upstream.
> 
> CCing Dan and Pavel for their input.
> 
> Michael
> 
> [1]
> https://git.gnome.org/browse/network-manager-applet/commit/?id=4473e6a48fcfda1d87d4a4bc9f5c0589235dcfe0


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#760998: [Pkg-utopia-maintainers] Bug#760998: Acknowledgement (network-manager: auto restarts)

[Dan Williams]

On Mon, 2015-03-09 at 09:13 +0100, Michael Biebl wrote:
> Am 19.02.2015 um 07:35 schrieb Kurt Roeckx:
> > severity 760998 serious
> > thanks
> > 
> > At this point I'm unable to stop network manager and keep it
> > stopped.  Now I have 0.9.10.0-6.
> > 
> > The log file shows:
> > NetworkManager[15359]:  exiting (success)
> > systemd[1]: Stopped Network Manager.
> > dbus[658]: [system] Activating via systemd: service 
> > name='org.freedesktop.NetworkManager' 
> > unit='dbus-org.freedesktop.NetworkManager.service'
> > systemd[1]: Starting Network Manager...
> > dbus[658]: [system] Successfully activated service 
> > 'org.freedesktop.nm_dispatcher'
> > systemd[1]: Started Network Manager Script Dispatcher Service.
> > NetworkManager[20467]:  NetworkManager (version 0.9.10.0) is 
> > starting...
> > 
> > I assume something else restarts it, but I have no idea what.  Is
> > there some way to debug this so I can reassign it?
> 
> It's most likely D-Bus activated, e.g. by nm-applet.
> 
> Atm, you need to run "systemctl disable NetworkManager.service;
> systemctl stop NetworkManager.service; ; systemctl start
> NetworkManager.service; systemctl enable NetworkManager.service".
> 
> Dan, is dropping the D-Bus autoactivation safe, i.e. removing
> /usr/share/dbus-1/system-services/org.freedesktop.NetworkManager.service?

Yeah, it's safe, though it might slightly slow your bootup for some
reason I don't remember.  Something about not being able to parallelize
bootup, because if something calls NM methods via D-Bus, systemd won't
be able to activate NM and block the receiving process until NM starts,
so the receiving process will just get an error instead of waiting.  But
I guess that's supposed to be the current situation too with our
Exec=/bin/false hack that hasn't worked in a while.

It's worth a try to remove that file, and change the systemd unit file's
[install] section to remove the Alias.  Let me know if that breaks
bootup horribly or something?

Dan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#767002: [Pkg-utopia-maintainers] Bug#767002: Bug#767002: network-manager breaks ptp tun interfaces

[Dan Williams]

After reviewing the logs I think:

cb94fe0a9e985647d0feb3637dabdeab56a650a1
core: don't override external route metrics (bgo #738268)

should fix this issue as well, since it actually doesn't just apply to
route metrics but also to addresses.  The issue was that merging the
generated setting back into the config lost some information which
caused NM to think the existing address/routes were not correct, and NM
overwrote them.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745029: [Pkg-utopia-maintainers] Bug#745029: network-manager: automatically kills scripts that take longer than 3 seconds

[Dan Williams]

On Mon, 2014-05-19 at 17:05 +0200, Michael Biebl wrote:
> Am 17.04.2014 13:13, schrieb MAG4 Piemonte:
> > Package: network-manager
> > Version: 0.9.8.8-5
> > Severity: normal
> > 
> > Dear Maintainer,
> > after upgrading in a Testing machine with systemd to 0.9.8.8-5 version we 
> > get
> > nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/01ifupdown' 
> > took
> > too long; killing it.
> > with no mount of nfs partitions.
> > Investigating we found
> > https://wiki.archlinux.org/index.php/NetworkManager#Avoiding_the_three_seconds_timeout
> > so we replace the symlink /etc/systemd/system/dbus-org.freedesktop.nm-
> > dispatcher.service creating the script file /etc/systemd/system/dbus-
> > org.freedesktop.nm-dispatcher.service with the following content:
> >   .include /lib/systemd/system/NetworkManager-dispatcher.service
> >   [Service]
> >   RemainAfterExit=yes
> > and enable the script file with permissions rwxr-xr-x.
> > Doing so we workaroud the problem ...
> > Regards!
> > 
> 
> 
> That is intended behaviour. Scripts are not supposed to start long
> running tasks. Please fix your scripts to not do that.
> 
> Afaics there is nothing to fix on the NM side, right Dan?

At the moment it's intended behavior.  NM 0.9.9+ have bumped the timeout
to 20 seconds, and for 0.9.10 we're planning to make NetworkManager
block on dispatcher scripts for up/down.  Obviously, that makes your
network connections take longer to connect or disconnect if the
dispatcher scripts are stupid, but then the stupid scripts need to get
fixed to not take so long.

Note that for NFS especially, network connections can drop without
warning, especially on WWAN/WiFi/Bluetooth, and at that point the
connection is completely gone, and NFS just has to handle that without
blocking.

Dan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#744845: [Pkg-utopia-maintainers] Bug#744845: Allow simultanious VPN connections

[Dan Williams]

On Tue, 2014-04-15 at 13:14 +0200, Michael Biebl wrote:
> Am 15.04.2014 11:34, schrieb Martin Zobel-Helas:
> > Package: network-manager-openvpn
> > Version: 0.9.8.4-2
> > Severity: wishlist
> > 
> > Hi,
> > 
> > at work i sometimes need two simultanoius VPN connections to access all
> > the hosts i need to work with.
> > 
> > When i try to connect to a second OpenVPN connection via Network
> > Manager OpenVPN, i get disconnected from the first connection, that is
> > already active.
> > 
> > The VPNs run painless at the same time when started from command line.
> > 
> > Idea: Add a checkbox to the dialog "Allow simultanious VPN connections"
> > so i can at least choose when setting up the VPN connection to run more
> > than one VPN at the same time using network manager.
> 
> This is most likely a core network-manager issue, and not specific to
> network-manager-openvpn.
> 
> Dan, is that correct?
> Or would it be possible to activate multiple VPN connections and is this
> simply a UI issue to expose that functionality?

At the moment, only one VPN of each type can be active at the same time.
Eg, you *should* be able to have an OpenVPN and a vpnc at the same time
already, though I haven't tried that.  But you cannot yet have two VPN
connections of the same type simultaneously.  That's a limitation in the
core NM (which I hope to remove quite soon) as well as a UI decision in
nm-applet to make the NM limitation clearer.

Dan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#664767: Brcmsmac driver woes, possible regression?

[Dan Williams]

On Tue, 2013-03-19 at 22:55 +0100, Arend van Spriel wrote:
> On 03/19/2013 05:21 PM, Camaleón wrote:
> > Mar 19 17:05:28 stt300 kernel: [26034.188562] wlan0: authenticated
> > Mar 19 17:05:28 stt300 kernel: [26034.192108] wlan0: associate with 
> > 00:1a:2b:97:7a:97 (try 1/3)
> > Mar 19 17:05:28 stt300 NetworkManager[30971]:  (wlan0): supplicant 
> > interface state: authenticating -> associating
> > Mar 19 17:05:30 stt300 kernel: [26036.586947] wlan0: RX AssocResp from 
> > 00:1a:2b:97:7a:97 (capab=0x411 status=0 aid=1)
> > Mar 19 17:05:30 stt300 kernel: [26036.587560] brcmsmac bcma0:0: brcmsmac: 
> > brcms_ops_bss_info_changed: associated
> > Mar 19 17:05:30 stt300 kernel: [26036.587576] brcmsmac bcma0:0: 
> > brcms_ops_bss_info_changed: qos enabled: true (implement)
> > Mar 19 17:05:30 stt300 kernel: [26036.587603] wlan0: associated
> > Mar 19 17:05:30 stt300 kernel: [26036.587698] IPv6: 
> > ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> > Mar 19 17:05:30 stt300 wpa_supplicant[2855]: wlan0: Associated with 
> > 00:1a:2b:97:7a:97
> 
> Seems to be heading in the right direction, but
> 
> > Mar 19 17:05:30 stt300 NetworkManager[30971]:  (wlan0): supplicant 
> > interface state: associating -> associated
> > Mar 19 17:05:30 stt300 NetworkManager[30971]:  (wlan0): supplicant 
> > interface state: associated -> 4-way handshake
> > Mar 19 17:05:32 stt300 avahi-daemon[2630]: Joining mDNS multicast group on 
> > interface wlan0.IPv6 with address fe80::ae81:12ff:fe34:6963.
> > Mar 19 17:05:32 stt300 avahi-daemon[2630]: New relevant interface 
> > wlan0.IPv6 for mDNS.
> > Mar 19 17:05:32 stt300 avahi-daemon[2630]: Registering new address record 
> > for fe80::ae81:12ff:fe34:6963 on wlan0.*.
> > Mar 19 17:05:32 stt300 NetworkManager[30971]:  Activation 
> > (wlan0/wireless): association took too long.
> 
> Here it seem to go bad again...
> 
> > Mar 19 17:05:32 stt300 NetworkManager[30971]:  (wlan0): device state 
> > change: config -> need-auth (reason 'none') [50 60 0]
> > Mar 19 17:05:32 stt300 NetworkManager[30971]:  Activation 
> > (wlan0/wireless): asking for new secrets
> > Mar 19 17:05:32 stt300 kernel: [26039.005158] wlan0: deauthenticating from 
> > 00:1a:2b:97:7a:97 by local choice (reason=3)
> 
> And we get a deauth request with WLAN_REASON_DEAUTH_LEAVING.

That local choice (reason=3) is NetworkManager terminating the
association attempt because it already took 25 seconds, which is way too
long for a simple association.  The cause is long before that.

NM tells the supplicant to start associating here:

Mar 19 17:05:07 stt300 NetworkManager[30971]:  Config: set
interface ap_scan to 1

and finally kills the attempt here:

Mar 19 17:05:32 stt300 NetworkManager[30971]:  Activation
(wlan0/wireless): association took too long.

So the supplicant gets a total of 25 seconds to associate to the AP,
which, if you're not associated within that time, you're definitely not
going to get associated if you're given more time.  But between 17:05:07
and 17:05:32, NM is just waiting for the association to succeed.

It really does look like the supplicant or driver tries to associate but
then fails, eg:

Mar 19 17:05:08 stt300 kernel: [26014.833011] wlan0: send auth to
00:1a:2b:97:7a:97 (try 1/3)
Mar 19 17:05:13 stt300 kernel: [26019.834259] wlan0: deauthenticating
from 00:1a:2b:97:7a:97 by local choice (reason=3)

There's a whole lot of authentication/association failures in that log,
which do appear to indicate that the STA can see the AP, but the AP
can't hear the STA.

Then we also have stuff like:

Mar 19 17:05:24 stt300 wpa_supplicant[2855]: wlan0: SME: Authentication
request to the driver failed

where it would be nice to know why the request failed.

Dan

> > Mar 19 17:05:33 stt300 kernel: [26040.004150] brcmsmac bcma0:0: brcmsmac: 
> > brcms_ops_bss_info_changed: disassociated
> > Mar 19 17:05:33 stt300 kernel: [26040.004172] brcmsmac bcma0:0: 
> > brcms_ops_bss_info_changed: qos enabled: false (implement)
> > Mar 19 17:05:34 stt300 kernel: [26040.504402] cfg80211: Calling CRDA to 
> > update world regulatory domain
> > Mar 19 17:05:34 stt300 ntpd[2611]: Listen normally on 16 wlan0 
> > fe80::ae81:12ff:fe34:6963 UDP 123
> > Mar 19 17:05:34 stt300 ntpd[2611]: peers refreshed
> > Mar 19 17:05:34 stt300 wpa_supplicant[2855]: wlan0: CTRL-EVENT-DISCONNECTED 
> > bssid=00:00:00:00:00:00 reason=3
> > Mar 19 17:05:34 stt300 NetworkManager[30971]:  (wlan0): supplicant 
> > interface state: 4-way handshake -> disconnected
> > Mar 19 17:05:34 stt300 NetworkManager[30971]:  Couldn't disconnect 
> > supplicant interface: This interface is not connected.
> 
> I am trying to make sense of it, but it is getting late over here. Have 
> a fresh look tomorrow.
> 
> Regards,
> Arend
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
To UNSUBSCRIBE, email to deb

Bug#664767: Brcmsmac driver woes, possible regression?

[Dan Williams]

On Tue, 2013-03-19 at 19:11 +0100, Camaleón wrote:
> El 2013-03-19 a las 12:59 -0500, Dan Williams escribió:
> 
> > On Tue, 2013-03-19 at 18:30 +0100, Camaleón wrote:
> > > El 2013-03-19 a las 11:53 -0500, Dan Williams escribió:
> > > > 
> > > > Note that NM 0.9.8 won't ask for a password when just anything fails,
> > > > but will ask for a password if the 4-way handshake fails, because if
> > > > that fails, it's probably your password.  We're contemplating getting
> > > > rid of that too, and just notifying the user that their password may be
> > > > wrong and that they should go update it in the network configuration
> > > > panel so we don't interrupt.  But if you're 100% sure your PSK is
> > > > correct, then it is, most likely, a driver bug.
> > > 
> > > Password is correct. I have a second wireless card (external, using 
> > > rt2800usb driver) that connects without a glitch to the same AP.
> > > 
> > > Moreover, unless I type the right password, N-M dialog does not allow 
> > > me to click on the "Connect" button.
> > 
> > NM minimally verifies the PSK, which by 802.11 standards is between 8
> > and 63 ASCII characters inclusive.  So you should be able to type
> > anything you want within those constraints, but clearly only one is your
> > real PSK.
> 
> Oops! Okay, so what user inputs is not "bullet-proof".
> 
> Anyway, this does not seem to be a problem of bad password. I was 
> finally able to get connected to the AP as soon as I carry the nebook 
> and put it next to the AP which is the problem I've always have had 
> with this driver (brcmsmac).

Yeah, that's a symptom of bad power control or bad gain or who knows
what in the driver.  But also, make sure your antennas are connected
correctly :)

> As soon as I back to another room, N-M asks me again for the pass-key 
> and disconnects.

NM 0.9.8 shouldn't do that; I bet you're not even getting to the point
where the 4-way handshake and password verification are done.  NM 0.9.8
will retry a few times, notify you and fail, then wait a couple minutes
and try again.  It shouldn't ask for a password anymore in situations
like this.

Dan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#664767: Brcmsmac driver woes, possible regression?

[Dan Williams]

On Tue, 2013-03-19 at 18:30 +0100, Camaleón wrote:
> El 2013-03-19 a las 11:53 -0500, Dan Williams escribió:
> 
> > On Tue, 2013-03-19 at 17:21 +0100, Camaleón wrote:
> > > 2013/3/19 Camaleón :
> > > > 2013/3/18 Jonathan Nieder :
> > > >> Camaleón wrote:
> > > >>> El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió:
> > > >>
> > > >>>> Sorry to hear. Reading back the bug report I noticed you are having a
> > > >>>> bcm4313 and we recently had a regression on it. Could you provide
> > > >>>> debugfs information from /brcmsmac/bcma0:0/hardware
> > > >>>
> > > >>> I see. My "/sys/kernel/debug/*" directory is empty
> > > >>
> > > >> mount -t debugfs debugfs /sys/kernel/debug
> > > >
> > > > Perfect, thanks.
> > > >
> > > > root@stt300:~# cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware
> > > > board vendor: 103c
> > > > board type: 145c
> > > > board revision: 2209
> > > > board flags: 8002a00
> > > > board flags2: 800
> > > > firmware revision: 262032b
> > > >
> > > > Now let's see how reverting the patch makes any difference as soon as
> > > > I can compile the module. I will keep you updated
> > > 
> > > Update: applied the patch to revert the "other" patch but I still
> > > cannot get the driver to work (see attached syslog). N-M still asks
> > > for password until desists :-(
> > 
> > Note that NM 0.9.8 won't ask for a password when just anything fails,
> > but will ask for a password if the 4-way handshake fails, because if
> > that fails, it's probably your password.  We're contemplating getting
> > rid of that too, and just notifying the user that their password may be
> > wrong and that they should go update it in the network configuration
> > panel so we don't interrupt.  But if you're 100% sure your PSK is
> > correct, then it is, most likely, a driver bug.
> 
> Password is correct. I have a second wireless card (external, using 
> rt2800usb driver) that connects without a glitch to the same AP.
> 
> Moreover, unless I type the right password, N-M dialog does not allow 
> me to click on the "Connect" button.

NM minimally verifies the PSK, which by 802.11 standards is between 8
and 63 ASCII characters inclusive.  So you should be able to type
anything you want within those constraints, but clearly only one is your
real PSK.

Dan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#664767: Brcmsmac driver woes, possible regression?

[Dan Williams]

On Tue, 2013-03-19 at 17:21 +0100, Camaleón wrote:
> 2013/3/19 Camaleón :
> > 2013/3/18 Jonathan Nieder :
> >> Camaleón wrote:
> >>> El 2013-03-18 a las 20:38 +0100, Arend van Spriel escribió:
> >>
>  Sorry to hear. Reading back the bug report I noticed you are having a
>  bcm4313 and we recently had a regression on it. Could you provide
>  debugfs information from /brcmsmac/bcma0:0/hardware
> >>>
> >>> I see. My "/sys/kernel/debug/*" directory is empty
> >>
> >> mount -t debugfs debugfs /sys/kernel/debug
> >
> > Perfect, thanks.
> >
> > root@stt300:~# cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware
> > board vendor: 103c
> > board type: 145c
> > board revision: 2209
> > board flags: 8002a00
> > board flags2: 800
> > firmware revision: 262032b
> >
> > Now let's see how reverting the patch makes any difference as soon as
> > I can compile the module. I will keep you updated
> 
> Update: applied the patch to revert the "other" patch but I still
> cannot get the driver to work (see attached syslog). N-M still asks
> for password until desists :-(

Note that NM 0.9.8 won't ask for a password when just anything fails,
but will ask for a password if the 4-way handshake fails, because if
that fails, it's probably your password.  We're contemplating getting
rid of that too, and just notifying the user that their password may be
wrong and that they should go update it in the network configuration
panel so we don't interrupt.  But if you're 100% sure your PSK is
correct, then it is, most likely, a driver bug.

Dan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#673705: [Pkg-utopia-maintainers] Bug#673705: Bug#673705: Bug#673705: network-manager: Network Manager doesn't connect to wifi (greyed out) when device cannot report signal strength

[Dan Williams]

On Mon, 2012-05-21 at 23:28 +0200, Michael Biebl wrote:
> tags 673705 + patch
> severity 673705 important
> thanks
> 
> On 21.05.2012 18:34, Dan Williams wrote:
> > On Mon, 2012-05-21 at 11:07 +0200, Gennady N. Uraltsev wrote:
> >> Sorry for the ambiguity. I filed a bug against the kernel in Debian
> >> about this problem. Here it is:
> >>
> >> 673703: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673703
> >>
> >> Anyhow they said it was a hardware/firmware issue and that they wouldn't
> >> fix it themselves. They forwarded the issue upstream, to
> >> linux-wireless.
> > 
> > Two bugs here: first the ipw2x00 kernel issues that got fixed recently;
> > one is the encryption capabilities issue that causes the grayed out menu
> > items.  The other bug is an NM bug, fixed by:
> > 
> > http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=50435e1d5deff17233f1de73ee030a5982e9fd05
> > 
> > which should be a safe backport.  The NM fix is really the correct fix
> > until the ipw2x00 driver gets ported to cfg80211 in the kernel.  It's
> > 10%  of the way there, which is what was confusing NM.
> 
> Thanks a lot Dan for this very helpful reply.
> So if I understood you correctly, simply cherry-picking 50435e1d should
> be enough to make NM work for Gennady, i.e. it doesn't require the
> kernel fix (because we would continue to use wext for ipw2x00). And the
> kernel patch is about making ipw2x00 work correctly via nl80211?

Correct on the NM part; incorrect on the ipw2x00 part.  The kernel fix
is necessary, but that still doesn't make ipw2x00 work with nl80211.
Turns out that ipw2x00 only advertises it's capabilities via nl80211,
but it doesn't actually support anything in nl80211, like signal
strength, associated channel and AP, connect, disconnect, etc.  So until
somebody does some major nl80211 work on ipw2x00, we have to keep using
WEXT to ask for that stuff.

Dan




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#673705: [Pkg-utopia-maintainers] Bug#673705: Bug#673705: network-manager: Network Manager doesn't connect to wifi (greyed out) when device cannot report signal strength

[Dan Williams]

On Mon, 2012-05-21 at 11:07 +0200, Gennady N. Uraltsev wrote:
> Sorry for the ambiguity. I filed a bug against the kernel in Debian
> about this problem. Here it is:
> 
> 673703: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673703
> 
> Anyhow they said it was a hardware/firmware issue and that they wouldn't
> fix it themselves. They forwarded the issue upstream, to
> linux-wireless.

Two bugs here: first the ipw2x00 kernel issues that got fixed recently;
one is the encryption capabilities issue that causes the grayed out menu
items.  The other bug is an NM bug, fixed by:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=50435e1d5deff17233f1de73ee030a5982e9fd05

which should be a safe backport.  The NM fix is really the correct fix
until the ipw2x00 driver gets ported to cfg80211 in the kernel.  It's
10%  of the way there, which is what was confusing NM.

Dan



> 
> 
> On 05/20/2012 11:43 PM, Michael Biebl wrote:
> > On 20.05.2012 23:36, Gennady N. Uraltsev wrote:
> >> 02:02.0 Network controller: Intel Corporation PRO/Wireless LAN 2100 3B
> >> Mini PCI Adapter (rev 04)
> >>
> >> and the driver is the kernel module  ipw2100
> >>
> >> I already told them about this and they say it is a hardware/firmware
> >  ^
> >  who is them?
> > 
> >> limitation and they aren't sure it is fixable.
> > 
> > I thought this was kernel/driver issue and affected drivers were
> > ipw2100/ipw2200
> > 
> > CCing Dan, maybe he can his insight on this issue.
> > 
> >> On 05/20/2012 11:06 PM, Michael Biebl wrote:
> >>> On 20.05.2012 22:55, Gennady N. Uraltsev wrote:
> >>
> 
>  There are many cards that have this problem, and I do not see any reason 
>  to
> >>
> >>> Which card and driver do you use?
> > 
> > 





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605275: EeePC 1005HAG still freezes when probing the builtin 3G modem

[Dan Williams]

On Tue, 2012-02-28 at 11:14 +0100, Maik Zumstrull wrote:
> On Tue, Feb 28, 2012 at 06:09, Dan Williams  wrote:
> 
> > Notes I'd seen from another driver indicate that it's got a modem/PPP
> > port (intf 0), a DIAG/DM port (intf 1 or 2) and the PCUI port (intf 1 or
> > 2).  At least the PCUI port should be able to respond to AT commands
> > too.  Can you talk on ttyUSB1 or ttyUSB2 with AT commands?
> >
> > Try "AT^GETPORTMODE" on any port that takes AT commands and see what you
> > get.
> 
> ttyUSB0 acts like a modem. That it opens instantly holds with picocom
> as well, the other ones hang for a bit.
> ttyUSB1 doesn't seem to take AT commands (no response).
> ttyUSB2 takes AT commands.
> 
> Both AT-capable ports reply "COMMAND NOT SUPPORT" [sic] to AT^GETPORTMODE.

But ttyUSB2 still has the close() blocking problem while ttyUSB0 does
not?

Dan




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605275: EeePC 1005HAG still freezes when probing the builtin 3G modem

[Dan Williams]

On Mon, 2012-02-27 at 17:28 +0100, Maik Zumstrull wrote:
> On Mon, Feb 27, 2012 at 17:19, Dan Williams  wrote:
> 
> > Any chance you can get the Windows driver installer for this device?
> 
> Weirdly, ASUS doesn't offer it for download. I wiped the included
> Windows first thing.
> 
> > Looking at the INF files gives us clues as to what the ports are used
> > for.  Also, I'd expect at least *two* AT capable ports on a GSM/UMTS
> > device, but perhaps only one on a CDMA/EVDO device.  Is this an EM770
> > (CDMA/EVDO) or a GSM/UMTS device?
> 
> GSM/UMTS
> 
> >  Also, again is there any way you can
> > get the device model name and firmware version from ATI/AT+GMM/AT+GMR ?
> 
> Manufacturer: huawei
> Model: EM770
> Revision: 11.108.04.01.40
> IMEI: [Removed]
> +GCAP: +CGSM,+DS,+ES
> 
> OK
> 
> EM770
> 
> OK
> 
> 11.108.04.01.40

Notes I'd seen from another driver indicate that it's got a modem/PPP
port (intf 0), a DIAG/DM port (intf 1 or 2) and the PCUI port (intf 1 or
2).  At least the PCUI port should be able to respond to AT commands
too.  Can you talk on ttyUSB1 or ttyUSB2 with AT commands?

Try "AT^GETPORTMODE" on any port that takes AT commands and see what you
get.

Dan




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605275: EeePC 1005HAG still freezes when probing the builtin 3G modem

[Dan Williams]

On Sun, 2012-02-26 at 19:48 +0100, Maik Zumstrull wrote:
> On Sun, Feb 26, 2012 at 18:57, Greg KH  wrote:
> > On Sun, Feb 26, 2012 at 06:35:43PM +0100, Maik Zumstrull wrote:
> 
> >> > Is the device stuck doing something?
> >>
> >> Not as far as I know.
> >
> > Are two userspace programs trying to access the device at the same time?
> 
> The device exports three virtual serial ports. ModemManager accesses
> more than one. On the other hand, we were able to reproduce the freeze
> accessing only one port from one process, see Bugzilla.
> 
> I've attached a fresh strace of opening the device on 3.2.6. The
> open() takes 10s, the close takes 5s. Nothing else was accessing any
> ttyUSB*; I killed ModemManager and double checked with lsof.
> 
> > Yes.  Please try loading the module with:
> >modprobe option debug=1
> > and seeing what happens in the kernel log when you open the device.
> 
> Output attached. I think it's three "option_send_setup" for one
> open()/close(). At least, that's what happens with the C snippet.

Ah, yeah, that would make sense.  Does this happen for *all* ports on
the modem, or only a few ports?  I'd expect option_send_setup() to work
for any AT-capable ports, but possibly fail for others that aren't full
serial ports, like DIAG/DM ports or other protocols.  There's a
blacklist in option specifically for sendsetup that we can use to ensure
that ports that don't like sendsetup don't use it.  But we need to
figure out which ports those are, since it's very unlikely to be all of
them.

Dan




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605275: EeePC 1005HAG still freezes when probing the builtin 3G modem

[Dan Williams]

On Mon, 2012-02-27 at 16:44 +0100, Maik Zumstrull wrote:
> On Mon, Feb 27, 2012 at 16:33, Dan Williams  wrote:
> 
> > Ah, yeah, that would make sense.  Does this happen for *all* ports on
> > the modem, or only a few ports?
> 
> Patched the C snippet to open/close all three. Looks like ttyUSB0 is
> fine, 1 and 2 hang.

Any chance you can get the Windows driver installer for this device?
Looking at the INF files gives us clues as to what the ports are used
for.  Also, I'd expect at least *two* AT capable ports on a GSM/UMTS
device, but perhaps only one on a CDMA/EVDO device.  Is this an EM770
(CDMA/EVDO) or a GSM/UMTS device?  Also, again is there any way you can
get the device model name and firmware version from ATI/AT+GMM/AT+GMR ?

Here's the problem we have.  12d1:1001 is an ID used by a *lot* of
Huawei devices.  Most of them don't have this problem.  Yours does.
Because Huawei use the same VID/PID for many devices, we can't identify
your device specifically and quirk it without quirking all of them.

Dan





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605275: EeePC 1005HAG still freezes when probing the builtin 3G modem

[Dan Williams]

On Sun, 2012-02-26 at 19:48 +0100, Maik Zumstrull wrote:
> On Sun, Feb 26, 2012 at 18:57, Greg KH  wrote:
> > On Sun, Feb 26, 2012 at 06:35:43PM +0100, Maik Zumstrull wrote:
> 
> >> > Is the device stuck doing something?
> >>
> >> Not as far as I know.
> >
> > Are two userspace programs trying to access the device at the same time?
> 
> The device exports three virtual serial ports. ModemManager accesses
> more than one. On the other hand, we were able to reproduce the freeze
> accessing only one port from one process, see Bugzilla.
> 
> I've attached a fresh strace of opening the device on 3.2.6. The
> open() takes 10s, the close takes 5s. Nothing else was accessing any
> ttyUSB*; I killed ModemManager and double checked with lsof.
> 
> > Yes.  Please try loading the module with:
> >modprobe option debug=1
> > and seeing what happens in the kernel log when you open the device.
> 
> Output attached. I think it's three "option_send_setup" for one
> open()/close(). At least, that's what happens with the C snippet.

There's a few issues going on here that I've seen before.  First is the
SENDSETUP quirk in option.ko that is required for some devices where the
interface is claimed by option but really isn't supposed to be, because
it's not actually speaking USB serial.  Thus it doesn't respond to the
sendsetup command and the option driver just blocks for a bit.

Second is "closing_wait", which ModemManager sets to
ASYNC_CLOSING_WAIT_NONE to prevent a 5 or 10 second freeze on close()
where if the port has not responded to any request, the buffer is still
full, and close() blocks (even if O_NONBLOCK) until the buffer is
flushed.  Setting ASYNC_CLOSING_WAIT_NONE appeared to fix that.

What device is this?

Dan




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#626822: [Pkg-utopia-maintainers] Bug#626822: network-manager: can fallback to using 4.2.2.1 DNS server?

[Dan Williams]

On Sun, 2011-05-15 at 18:28 +0200, Michael Biebl wrote:
> Hi
> 
> Am 15.05.2011 18:20, schrieb Timo Juhani Lindfors:
> > Package: network-manager
> > Version: 0.8.999-1
> > Severity: normal
> > 
> > On a Finnish free software IRC channel I heard that sometimes when
> > people use a 3G stick of their Finnish ISP (Saunalahti) their DNS
> > requests are sent to 4.2.2.1 which according to traceroute is
> > somewhere in the UK.
> 
> Do you possibly have more references regarding this issue?

4.2.2.1 and 4.2.2.2 are GTE/Verizon nameservers in the US.  These values
are hardcoded by NetworkManager when PPP returns invalid nameservers.
pppd used to have some bugs in versions 2.4.4 and earlier where it could
not detect nameservers after negotiating configuration with the modem.
Then it would return a bogus nameserver, which NM detects and tries to
at least use a known-working nameserver instead.

Again, if you see 4.2.2.1 getting used, that's due to a bug between pppd
and the modem, and if NM didn't substitute 4.2.2.1, you wouldn't get any
DNS at all.  The problem could be debugged by starting NM like so:

NM_PPP_DEBUG=1 NetworkManager --no-daemon

You'll get all sorts of PPP debug spew which is useful to figure out
what's going on.

Dan

> > 
> > I have not hit this bug myself but I started investigating and found the
> > below function in the source code. Does this mean that gtei.net can
> > profile what websites people visit when they use a Finnish ISP?
> > 
> 
> > ppp_ip4_config (NMPPPManager *ppp_manager,
> >  * providers to return 10.11.12.13 and 10.11.12.14 for the DNS servers.
> >  * Apparently fixed in ppp-2.4.5 but we've had some reports that this is
> >  * not the case.
> >  *
> >  * 
> > http://git.ozlabs.org/?p=ppp.git;a=commitdiff_plain;h=2e09ef6886bbf00bc5a9a641110f801e372ffde6
> >  * 
> > http://git.ozlabs.org/?p=ppp.git;a=commitdiff_plain;h=f8191bf07df374f119a07910a79217c7618f113e
> >  */
> > 
> 
> I'm brining Dan in the loop here.
> 
> 





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#626822: [Pkg-utopia-maintainers] Bug#626822: network-manager: can fallback to using 4.2.2.1 DNS server?

[Dan Williams]

On Thu, 2011-05-19 at 21:43 +0300, Timo Juhani Lindfors wrote:
> Dan Williams  writes:
> > Again, if you see 4.2.2.1 getting used, that's due to a bug between pppd
> > and the modem, and if NM didn't substitute 4.2.2.1, you wouldn't get any
> > DNS at all.
> >
> > The problem could be debugged by starting NM like so:
> 
> I understand but you are describing a different problem. I'm reporting

I believe this is the same problem that we were talking about.  The
problem is that pppd and the modem are not able to negotiate the correct
DNS servers for your provider.  Thus you are stuck with 4.2.2.1.

> this bug about the fact that NM can fallback to these servers and in
> doing so make it possible for GTE to spy and hijack DNS requests of
> users that are completely unrelated to GTE without even warning the
> users about it.

You have no control over the DNS servers that you are given anyway, and
the provider can change them at will.  If you're concerned about this,
you can change your mobile broadband IP configuration from "Automatic
(PPP)" to "Automatic (PPP) addresses only" and enter custom nameservers
that you trust and control.  You do get a warning in syslog:

nm_log_warn (LOGD_PPP, "compensating for invalid PPP-provided
nameservers");

The nameservers are also clearly displayed in the connection information
dialog.

We're not going to show a popup notification or anything like; instead
we should fix the real problem in pppd.  This hack in NM was introduced
because we had a flood of bug reports about networking not working at
all due to bad nameservers, and this at least allows users to get
online.

Dan





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#615082: [Pkg-utopia-maintainers] Bug#615082: Bug#615082: Acknowledgement (network-manager: dnsmasq exited with error: Configuration problem)

[Dan Williams]

On Fri, 2011-02-25 at 20:25 +, Simon Kelley wrote:
> On 25/02/11 20:03, Michael Biebl wrote:
> > Am 25.02.2011 20:45, schrieb Simon Kelley:
> >> On 25/02/11 19:29, Michael Biebl wrote:
> >>> Am 25.02.2011 18:58, schrieb Simon Kelley:
> >
> >>> Is there maybe a nicer way to tell dnsmasq to *not* read the global
> >>> configuration file?
> >>
> >> Ah, I hadn't read up in the source code to that part.
> >>
> >> It's completely unnecessary:
> >>
> >> dnsmasq --conf-file
> >>
> >> suppresses reading the default configuration file. Just stop adding the
> >> junk filename (which never did anything, anyway) and dnsmasq will no
> >> longer complain.
> >
> > Perfect, thanks for your input. Seems like the way to go then.
> >
> > Just to be sure: Can I rely on dnsmasq --conf-file to work on versions<  
> > 2.57?
> 
> You can.
> 
> > Is there a minimum version when this behaviour was introduced?
> 
> There must be and I'm not sure exactly which it is, but I just checked 
> 2.39 which is four years old, and this behaviour was in then.
> 
> > I can only assume Dan added this hack (back then) for a reason.
> 
> My guess is that it arises from unclear documentation rather than lack 
> of functionality.

I just added it because I ran into a problem at one point (and somebody
else did too) where a package installed global dnsmasq config file had
some conflicting options with what NM spawns dnsmasq with.  Since NM
sends all the arguments on the command-line, because they change
depending on your IP connection and because we can't guarantee what's in
the global config file, I did this hack.  I was not aware of leaving off
the config file name.

We can and should fix it though.  Just one question: does the
"--conf-file" have to be at the end of the arg list, or is dnsmasq smart
enough to know that something that comes after it that starts with "--"
is an argument?  I'd expect this to be the case, but just checking.

Dan





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#574270: Functionality overlap between udev's modem-modeswitch and usb-modeswitch about 19d2:2000

[Dan Williams]

On Thu, 2010-03-18 at 18:16 +0100, Kay Sievers wrote:
> On Thu, Mar 18, 2010 at 17:48, Didier 'OdyX' Raboud  wrote:
> > Hi udev upstreams !
> >
> > (please keep me and the Debian bug CC'ed).
> >
> > I am the Debian maintainer for usb-modeswitch and I got a user reporting 
> > that
> > his 3G dongle was not "switched" anymore [0]. After some investigation, I
> > strongly suspect that udev's modem-modeswitch and usb-modeswitch have a
> > conflicting functionality overlap.
> >
> > From /lib/udev/rules.d/61-mobile-action.rules :
> >
> >> # modem-modeswitch does not work with these devices, the fake CD-ROM needs 
> >> to
> > be ejected
> >>
> >> # ZTE MF6xx
> >> ACTION=="add", ENV{ID_CDROM}=="1", ENV{ID_VENDOR_ID}=="19d2",
> > ENV{ID_MODEL_ID}=="2000", RUN+="/usr/bin/eject %k"
> >
> > From /lib/udev/rules.d/40-usb_modeswitch.rules :
> >
> >> # ZTE devices
> >> ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="2000", RUN+="usb_modeswitch
> > '%b/%k'"
> >
> > It seems (to me) that those lines should be removed from udev (as 
> > usb-modeswitch
> > provides a generic switching facility for more than "just" 19d2:2000.
> >
> > What is your opinion thereabout ?

People seem to have a hard time understanding that "Mobile Action" and
"Option" are not the companies as ZTE and Huawei, unfortunately.  I
don't really understand that.

However, some of that confusion comes from having duplicate mode
switching tools.

> If Dan has no objections, we are ready to delete modem-modeswitch from
> the udev tree.

usb_modeswitch still doesn't do the Mobile Action cable stuff.  So I'll
spin modem-modeswitch into a standalone tool that *only* switches the
mobile action cables.  Then we can remove the confusion and just use
usb_modeswitch.

Dan





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org