GNOME Bugzilla – Bug 637140
Linktop HSPADataCard: use secondary port for data
Last modified: 2014-10-14 10:17:12 UTC
I think there is some issue with unsolicited message handling. ModemManager fails to handle +CIEV messages enabled with +CMER if +CIND is supported by the device. See my comment (https://bugzilla.gnome.org/show_bug.cgi?id=636040#c6). It also prevent +CIND to function properly. I tried with removing CMER/CIEV feature then +CIND signal reporting works perfect. I don't this as device issue because this works fine with OFONO. I think unsolicited message handling should be improved or modem-manager should provide a way to disable unsolicited message handling via plugin.
Could you attach full --debug output from modem-manager so I can take a look and see if there's something else going wrong? I'd like to see what happens after connect with both ports.
Created attachment 176515 [details] modem-manager --debug You can see after connection is established the +CIND responses are missing and +CIEV messages are blocked but when I disconnect the device those +CIEV messages are printed.
Created attachment 176516 [details] modem-manager --debug (CIEV disabled) And here is the debug output of modem-manager where I disabled the CIEV messages (removed that code from the source). You can see now the +CIND responses are properly handled. I have also tested with latest build of oFono that successfully handles both +CIND & +CIEV responses without such issue. So I don't think it's a device issue.
I think, the issue is, +CMER is issued to the primary port which is then used for data connection. The primary port can't be used for AT commands once connection is established. So in my opinion, unsolicited message handlers should be registered with secondary port.
Created attachment 176958 [details] [review] Use secondary port if available I am not sure whether this is the right approach but it has solved the issue and now +CIEV messages are handled properly.
Created attachment 176996 [details] [review] Use secondary port if available Consider +CREG and +CGREG as well.
Hi Dan, Would you please review this patch? It's working perfect with my device. Please also have a look at bug #637934 which is another major issue with these devices. Regards -- Amit
So I think we should do it a bit differently, since we can't always trust modems to do the right thing, especially with secondary ports. Some modems will say they support enabling on the secondary port, but they actually use a minimal command parser on those ports and don't send the unsolicited codes (like some Sierra modems). So instead, I pushed: 476cc44bc1c991b9ad940d1de9cb42baf93555ab to fix that. Can you test it out and see if that fixes the issue for you with this modem?
Created attachment 179136 [details] modem-manager --debug Unfortunately the fix doesn't work with my device. I have observed that it works only if exclusively registered to the secondary port. If there is no standard way, I think, plugins should be allowed to select proper ports otherwise there will be lots of duplication in plugin code.
Created attachment 179174 [details] wvdial.conf After reverse engineering the binary (32bit only) package that comes with the device and sniffing the usb ports. I found some interesting facts about this device. It has two ports with same capabilities. Either of the port can be used for AT commands (as a control port) or for communication (as data port). After sniffing the ports, I found that the /dev/ttyACM1 is used for almost every AT commands including switching the preferred mode to register the network to check the signal quality. And /dev/ttyACM0 is used to send only two AT commands: 1. AT OK 2. ATDT*99# +DR: NONE CONNECT .. .. Clearly, this is a dial command to start communication. So decided to test it manually using wvdial and it worked. Here the wvdial.conf that I have used to test the device. So, I think, if there is any way to use the secondary port to dial the number, there is no need to make these changes. I tried with custom `do_connect` function in mm-modem-linktop.c which is then attached to the modem class in `modem_init` but that doesn't work. Would you suggest me a proper way to ensure that the secondary port will be used to dial the number?
Created attachment 179991 [details] ofono log I have implemented ofono plugin for this modem and it's working exactly as it should (not integrated yet). Here I am attaching ofono log. You can see that the control port is used for most of the AT commands while modem port is used just for making connection. Also, the CIEV messages are received on control port only.
Created attachment 188825 [details] windows-modem-log Here I am attaching the log of the windows modem application that comes with this device.
What was should probably do here is tag this specific device like we tag ZTE and other devices, to specify which port should be data and which port should be primary.
So this modem should use the secondary port as Data port. Is this something applicable to all Linktop modems, or just to this specific model?
It's not applicable to all devices; none of mine care which port gets used.
Moving bugreport to the new ModemManager bugzilla in fd.o; summarized the issue there as well. Please subscribe to the new bugreport to get new updates. https://bugs.freedesktop.org/show_bug.cgi?id=84980 Closing this report as NOTGNOME.