GNOME Bugzilla – Bug 637934
While disconnecting, mark state as disabled if port is closed.
Last modified: 2011-12-07 21:05:19 UTC
Created attachment 177002 [details] modem-manager --debug For some weired reasons, if modem is unable to connect. The modem-manager fails to mark the modem state accordingly. You can test this by using some invalid APN name. See these state change debug info form the attached log file: ** ... : state changed (connected -> disconnecting) ** ... : state changed (disconnecting -> connected) After debugging the issue, I found that the `disconnect_done` function of `mm-generic-gsm.c` restores the previous state if there is any error (in this case the error is MM_SERIAL_ERROR_NOT_OPEN).
Created attachment 177033 [details] [review] Mark state as disabled if port is closed. I observed that this happens in several cases like invalid APN or unstable network coverage. When the connection is dropped automatically due to network issue, it was not possible to reconnect without removing the device. This patch has fixed this issue.
In this case, does the port actually get destroyed by the kernel? When MM closes the port here: ** (modem-manager:7223): DEBUG: <1293184713.730061> (ttyACM0) device open count is 0 (close) ** (modem-manager:7223): DEBUG: <1293184713.730130> (ttyACM0) closing serial port... ** (modem-manager:7223): DEBUG: <1293184713.730164> (ttyACM0): port now disconnected ** (modem-manager:7223): DEBUG: <1293184713.745834> (ttyACM0) serial port closed we don't have quite enough information about why it's been closed. Would be nice to get more info here so we can figure out what to do. I've added more logging in git master to help debug this situation, can you reproduce it with the latest and hopefully we'll see better what's going on? Thanks!
Created attachment 179138 [details] modem-manager --debug Look at the line 220. The state has been changed to `connected`. BTW, I don't think the kernel is destroying the ports as I can see both /dev/ttyACM0 and /dev/ttyACM1 are there.
Reopening as I think the requested information has been provided.
Yeah, this device is pretty weird. It's not replying to requests for information on ttyUSB1 too, whiel ttyUSB0 is taken with data. I wonder if it really wants us to use ttyUSB1 for PPP instead?
I have also implemented ofono plugin for this device and it's working flawlessly with ofono. The device is using ttyACM1 for AT commands and ttyUACM0 for data exclusively (it can be swappable however). On ttyUSB0, we only need to send initialization commands: AT &F AT+CFUN=1 Other AT commands should be sent to ttyACM1 and should listen to it for unsolicited messages. The data port is not emitting anything once data connection is established. I have created a wvdial configuration to know the exact behavior. Here I am attaching the wvdial config...
Created attachment 187168 [details] wvdial.conf
Can the initialization commands be sent on ttyACM1?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!