Re: Patch to nm-modem-probe

[Rick Jones <rick activeservice co uk>]

--On Wednesday, July 29, 2009 11:57:39 +0300 ValmantasPalikša <walmis gmail com> wrote:

> Also if the buffer from ttyUSB1 is not flushed or read regularly the
> device crashes. I'm guessing that the modem buffers data internally and
> if that data is not read, the buffer overflows and the firmware crashes.
> If +ZUSIMR UMs are disabled it will take longer to crash because it
> still sends +ZPASR UMs which indicate network type.

That's both interesting and alarming! I've noticed that my modem will sometimes just shutdown and disconnect - as if unplugged - if left idle. It's usually after about 15 mins, and I was thinking that the device has perhaps got an idle timeout. But maybe it's the effect you describe.

I have some helper scripts I usually run while using the modem, one of which displays a slightly filtered output of the monitor port, so I guess this stops it crashing while connected.

How can we get NM to do that?

If NM could also keep the modem port flushed while disconnected this would help with another issue, which is that the device nearly always fails to connect first time. This is because when there are UMs waiting to be read, they block responses to valid AT commands. I.e. consider the initialisation sequence of:
        send ATinitstring - read response 
When there are buffered UMs, they come back in the response, but there is no response to the AT command itself. The sequence has to be:
        read output until idle - send ATinitstring - read response

The ideal is for NM to just act as a null sink for the port until it is ready to start the conversation. Maybe this will be possible with 0.8 and ModemManager.

Is this just another bizarre problem with ZTEs, or do UMs interfere with commands on other modems?

Any thoughts?

Rick