Despite getting home at 6am this morning after a night of clubbing, I’ve had a productive day hacking around with the troublesome modem.
I’ve produced a patch against 2.6.34-rc6 which blacklists the MF636 such that option_send_setup doesn’t send a the RTS and DTR states to the first three serial ports, ttyUSB[0-2].
Examining the contents of the Windows INF files in the files on the ZeroCD device, I’ve found the following nuggets:
- Interface 00 is a USB Diagnostic interface, which is probably why it doesn’t respond to AT commands
- Interface 01 is an NMEA interface, and interface 02 is an extended NMEA interface – I don’t know what this means
- Interface 03 is a Mass Storage device which appears when you first plug in the device
- Interface 04 is the modem itself
I’ve also made a breakthrough in the initialization string – this must be AT&F&D2&C1, which:
- &F: Revert to factory defaults
- &D2: Set the DTR behaviour to terminate the call gracefully upon a DTR on/off tranisition
- &C1: Sets the Received Line Signal Detect (RLSD – is this DCD/Carrier Detect?) on until all data is received from the remote modem
- S0=0: Do not automatically answer an incoming call
Another little gem I found – the moment you dial ATD*99#, you cannot terminate the connection unless you send a PPP LCP TermReq. You can’t send the usual escape sequence +++, then ATH, nor can you cause the modem to disconnect by sending ATH via another port. It appears it must be done via PPP. This seems a bit brain-damaged.
Finally, the best bit – if you don’t set the initialization string correctly, the modem will crash and disconnect itself from the USB bus. Very handy, and painfully difficult to debug. NetworkManager doesn’t send the correct initialization string, hence the modem crashes.
I’m hating this device less the more I learn about it. I could still do with something that ‘just works’ without all this faff – but I get a lovely warm feeling knowing I’m helping out other people who have had the MF636 imposed on them.