Re: Patch to nm-modem-probe

[Valmantas Palikša <walmis gmail com>]

patching file callouts/nm-modem-probe.c
Hunk #1 succeeded at 311 with fuzz 2 (offset -2 lines).
Hunk #2 succeeded at 321 (offset -2 lines).
Hunk #3 succeeded at 348 (offset -2 lines).
Hunk #4 succeeded at 395 (offset -7 lines).
Hunk #5 FAILED at 414.
Hunk #6 succeeded at 429 (offset -10 lines).
Hunk #7 succeeded at 448 (offset -10 lines).
Hunk #8 succeeded at 465 (offset -10 lines).
Hunk #9 succeeded at 485 (offset -10 lines).
Hunk #10 succeeded at 597 (offset -10 lines).
Hunk #11 succeeded at 614 (offset -10 lines).
1 out of 11 hunks FAILED -- saving rejects to file
callouts/nm-modem-probe.c.rej

That's on vanilla nm 0.7.1. Which version are you using?

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'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 
> 
> 
> 
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list