Re: Patch to nm-modem-probe

[Dan Williams <dcbw redhat com>]

On Thu, 2009-08-20 at 00:08 +0100, Rick Jones wrote:
> I'll check this out as soon as I can, but probably not before next
> week as I've got a lot on right now.
> 
> Re the echo and tty modes issues, I think this may be distro-specific
> (even hardware-specific?). The OS sets the initial modes when the USB
> port is created, and on my Asus Eee running Ubuntu the modes appear to
> be pretty random - like a termio struct is being allocated but not
> initialised. If this initial mode includes ECHO then it leads to

Hmm, you mean racing between port open and the tcsetattr?  The first
thing the prober does after opening the port is of course setting !ECHO
in the tcsetattr call.

>  problems. In my case the initial mode is normally a lot different
> from RAW. I guess RH is different. I don't see any benefit in the
> prober restoring the settings, since the only thing that's going to
> open the device subsequently is NM, which will set the modes itself
> (and presumably to the same as the prober left them anyway).

*Sometimes*.  The prober runs for a lot more ports than it actually
uses, and thus we may end up setting the the mode wrong on a port that's
not actually a mobile broadband device or something.  I'm still not
convinced that the prober shouldn't leave things in the state it found
them...

> I've had the ZTE go zombie too, but never been able to tie it down. It
> hasn't happened for a while now, and I get a lot of failed
> connections! I read a report (here? - can't remember) suggesting that
> the device dies if the UMs it outputs aren't consumed - on both
> ports. 

What I found was that after NM had opened the port (ie tried to connect)
then yes, it would die after a minute or two of the failed connect *or*
even a clean disconnect I think.  But oddly, it doesn't die a minute or
two after the prober runs.  That leads me to believe that there's
something special about the connection process (but not about probing)
that happens here; obviously the prober either (a) didn't do anything to
trigger the issue or (b) cleaned stuff up correctly, or (c) both.  But
apparently when NM closes the serial device it doesn't do something that
the prober did?  Or the firmware is just shitty.  Not sure which.

Dan

> I don't know if that's actually true or guesswork. I normally run a
> shell window that displays the monitor port output when I'm using the
> modem, so maybe doing that is preventing the problem. You could try
> the same and see if it makes any difference.
> 
> -- 
> Cheers
> Rick
> 
> --On Wednesday, August 19, 2009 11:50:59 -0500 Dan Williams
> <dcbw redhat com> wrote:
> 
> > On Wed, 2009-07-29 at 18:26 +0100, Rick Jones wrote:
> > > Dan
> > > 
> > > Here's another patch to nm-modem-probe, and to the .rules file
> that
> > > invokes it.
> > 
> > I spent some time on this yesterday and rolled most your changes
> into
> > the prober, if not verbatim at least in spirit.  Can you check out
> > latest git and make sure it works for you still?  It seems to
> reliably
> > detect my 3UK MF627 both with and without the SIM inserted.
> > 
> > I still don't quite understand the echo issues you were talking
> about
> > since I think the TCSANOW bits turn off echo by masking out ECHO and
> > ECHOE before setting the port attributes.  I also diffed port state
> > (using stty) before NM opened the port (ie, after the prober had
> reset
> > it) , after NM opened the port, and after setting 'raw' mode with
> stty.
> > They weren't significantly different that I could find (only ignbrk
> or
> > something like that).  Needs further investigation perhaps?
> > 
> > I couldn't trigger any kernel issues with Fedora's
> > 2.6.29.6-217.2.3.fc11.i686 on my test machine despite having
> > plugged/unplugged about 25 mobile broadband cards twice each (though
> not
> > while the port was in-use).
> > 
> > I did notice the ZTE device dropping off the bus and going zombie
> after
> > a failed NM connection attempt.  Not really sure what to do here;
> I'd
> > like a bit more investigation into whether there's something we can
> do
> > or some command to stop it from happening.  Perhaps the windows
> driver
> > does something different about it?
> > 
> > Thanks!
> > Dan
> > 
> > > I've taken on some of your suggestions, but used the .rules file
> to
> > > identify the ZTE vid and pass extra arguments to nm-modem-probe.
> I've
> > > made CPMS an option not the default.
> > > 
> > > Sending the init string to the ZTE after only a 1-sec wait doesn't
> > > cause any problems, it just keeps responding ERROR until it's
> woken up
> > > enough to deal with it. I'd thought it caused other issues, but
> looks
> > > like I was wrong.
> > > 
> > > The only effective change in behaviour from the original with
> non-ZTE
> > > devices is 1-sec rather than .5-sec initial delay, and sending
> ATE0
> > > initialisation, which should always be beneficial. The default
> timeout
> > > on that initialisation is only 2-secs so if the modem doesn't want
> to
> > > co-operate it won't hold things up.
> > > 
> > > Let me know if you're happy with this, or if you'd like me to do
> any
> > > more to it.
> > > 
> > > Cheers, Rick
> > > 
> > > --On Saturday, July 25, 2009 22:33:08 +0100 Rick Jones
> > > <rick activeservice co uk> wrote:
> > > 
> > > ¦ Dan
> > > ¦ 
> > > ¦ Thanks for the feedback - see below ...
> > > ¦ 
> > > ¦ --On Thursday, July 23, 2009 15:02:56 -0400 Dan Williams
> > > <dcbw redhat com> wrote:
> > > ¦ ¦ --delay was originally meant to be an overall timeout, but I
> > > optimized
> > > ¦ ¦ that later on to fast-path modems that responded to something
> > > before
> > > ¦ ¦ that 5 seconds was up.  Many modems (especially built-in
> devices
> > > that
> > > ¦ ¦ boot long before udev starts up) will respond immediately and
> the
> > > hard 3
> > > ¦ ¦ second timeout was really unecessary.  Other modems do require
> > > that
> > > ¦ ¦ timeout.
> > > ¦ 
> > > ¦ ¦ Your patch will actually make all modems wait timeout_ms
> before
> > > being
> > > ¦ ¦ probed, so it does increase the probe latency quite a
> > > bit.  Additional
> > > ¦ ¦ to that, it adds a 1s latency right before sending the init
> > > command.
> > > ¦ 
> > > ¦ I take the point on built-in modems, but given all the other
> delays
> > > and waits involved in opening a connection, is 2 or 3 seconds
> actually
> > > significant? If this is happening at boot-up, surely it will all
> be
> > > finished by the time the user logs in, even with a few extra
> seconds.
> > > ¦ 
> > > ¦ ¦ What I'd recommend is the following:
> > > ¦ ¦ 
> > > ¦ ¦ 1) get rid of --initwait, and just use --delay.  After the
> initial
> > > 500ms
> > > ¦ ¦ wait that the original code had, send the init string every
> second
> > > until
> > > ¦ ¦ you get some response, or until the timeout expires.  That
> > > preserves the
> > > ¦ ¦ fastpath that built-in modems can take to get recognized much
> more
> > > ¦ ¦ quickly, but rightfully penalizes the ZTE device for being,
> well,
> > > dumb.
> > > ¦ 
> > > ¦ One problem here is that if you start sending an init string to
> the
> > > ZTE sooner than about 3 secs, it seems to do some strange things.
> I
> > > can't remember exactly what was going on, but that was one reason
> I
> > > wanted to be able to have a longer initial delay. I can get some
> log
> > > output from nm-modem-probe next week if you'd like - I don't have
> the
> > > time right now, sorry.
> > > ¦ 
> > > ¦ ¦ 2) get rid of --nocpms.  Lets use the --vid option to
> special-case
> > > ZTE
> > > ¦ ¦ and automatically determine what init string to send.
> > > ¦ 
> > > ¦ Are you suggesting hard-coding recognition of the ZTE vid into
> > > nm-modem-probe? My preference would be to put that kind of thing
> into
> > > the .rules file if necessary, and keep compiled code more generic.
> If
> > > it turns out that some other device can benefit from the CPMS
> tweak,
> > > or there are versions of the ZTE that object to it, it's much
> easer to
> > > fix a .rules file, especially by a user as a "get out of trouble"
> fix.
> > > That's why I made it a command line option (it could easily of
> course
> > > be --cpms so the default is not to send it).
> > > ¦ 
> > > ¦ It would mean updating the .rules file to have two branches, one
> for
> > > ZTE and one not (assuming you prefer to send +CPMS only to ZTE
> > > devices), but two branches might be necessary anyway if ZTEs need
> a
> > > longer timeout.
> > > ¦ 
> > > ¦ ¦ "there is a short window where the buffered data can be echoed
> > > back to
> > > ¦ ¦ the modem before this happens."
> > > ¦ ¦ 
> > > ¦ ¦ Could you describe that issue in a bit more detail?  I don't
> quite
> > > ¦ ¦ understand what's going on there.
> > > ¦ 
> > > ¦ I've had to infer quite a few things here, but I'm pretty sure
> of
> > > what is happening.
> > > ¦ 
> > > ¦ When I was first trying to use the device I would quite often
> get
> > > complete system hangs, requiring hard re-boot. When this happened
> it
> > > was usually immediately on clicking in the applet menu to make a
> > > connection (and other users have reported this too). I then
> started
> > > looking at the ttyUSB port modes using stty, and they seemed to be
> > > pretty random. In particular, crashes could be linked with echo
> mode
> > > being enabled. If I ran "stty raw -F /dev/ttyUSB2" after the modem
> was
> > > plugged in but before connecting, I never got any crashes. By
> running
> > > "stty echo ..." I could almost guarantee to crash. My first
> thought
> > > was that NM wasn't initialising the port properly, but looking at
> the
> > > code it clearly does.
> > > ¦ 
> > > ¦ IIRC, a port doesn't echo its input unless it is open, so prior
> to a
> > > connection being made, nothing bad is happening. But the moment it
> is
> > > open it will echo, and if there is buffered input to the port then
> > > this will immediately echo back out. I believe this will happen in
> the
> > > window between NM opening the port and setting the termio modes.
> So
> > > the combination of a stack of UMs (which the ZTE by default spits
> out)
> > > queued up in a USB buffer somewhere, the ttyUSB port suddenly
> echoing
> > > them all back, and the modem echoing them back again, etc....
> creates
> > > a snarl up enough to hang the machine. I don't know if it's
> actually a
> > > crash/panic, or it simply does something like eat all the
> interrupts.
> > > ¦ 
> > > ¦ But the fact is that making sure the port is set to raw mode,
> and
> > > left that way, totally stops the problem. So the best thing is
> simply
> > > for nm-modem-probe not to reset the port after using it!
> > > ¦ 
> > > ¦ It doesn't serve any purpose anyway, because nothing is going to
> use
> > > the port in its original mode. I guess those kernel fixes might
> affect
> > > it, as it's clearly pretty marginal, as will turning of modem echo
> in
> > > nm-modem-probe, and stopping UMs. But I still think the port
> should be
> > > left in raw mode after nm-modem-probe has finished - belt &
> braces.
> > > ¦ 
> > > ¦ ¦ 
> > > ¦ ¦ Thanks for your work on ZTE devices!
> > > ¦ 
> > > ¦ No probs, I just want something that works. I'd probably have
> saved
> > > myself a lot of trouble if I'd gone with a carrier who supplies
> > > Icon :)
> > > ¦ 
> > > ¦ Cheers, Rick 
> > > 
> > > 
> > > 
> > 
> > 
> 
>