Re: Patch to nm-modem-probe

[Dan Williams <dcbw redhat com>]

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 
> 
> 
>