Re: Issue with Telit LE922 and cdc_mbim
2016-11-23 19:38 GMT+01:00 Bjørn Mork : > Daniele Palmas writes: >> 2016-11-23 15:49 GMT+01:00 Bjørn Mork : >>> Daniele Palmas writes: 2016-11-21 10:49 GMT+01:00 Bjørn Mork : > Daniele Palmas writes: > >> it turned out that resetting the interface in cdc_ncm_init after >> getting the NTB parameters removes the need for the sleep, making the >> modem to work fine. > > Sounds very good, although I must admit that it isn't perfectly clear to > me what kind of reset we're talking about here. But no worries, the > patch will make that clear :) > Sorry for the confusion, I meant resetting the MBIM function with RESET_FUNCTION request code. >>> >>> Yes, the patch did make that clear, as expected :) >>> >> I wonder if this is an acceptable solution and can be applied also for >> MC7455. > > Quite possible. I will definitely test it. If we can avoid an > arbitrary and pointless delay, then that's great. But I guess this also > requires testing with a wide range of other MBIM devices to find out if > we can apply it unconditionally without breaking anything. Avoiding > device-specific or vendor-specific code is important in a class driver, > if possible. > Ok, unfortunately I can test only with Telit modems, so I'm not sure if the change I did is harmless for all the other modems: RESET_FUNCTION should not cause issues, >>> >>> Agreed. Unfortunately, we cannot depend on sane firmware behaviour ;) >>> >>> I did a semi-quick test on a Sierra Wireless EM7455 and can confirm that >>> your patch makes it work without the delay. Very nice. >>> >> >> Cool! >> >>> Do you happen to know if the Windows MBIM driver use RESET_FUNCTION >>> during initialisation? That would make this feel much safer. >>> >> >> Yes, Windows driver seems to send RESET_FUNCTION two times: after >> getting NTB parameters and after setting NTB input size. But it seems >> that only the first one is mandatory. >> >> Windows USB traces taken with TotalPhase Datacenter are available at >> >> https://drive.google.com/drive/folders/0B1kPnH2g8ISIZWJiV05qeWN5dVE >> >> file LE922win10_2.tdc > > This is comforting. It means that the risk introducing the > RESET_FUNCTION call is close to zero. The only remaining issue is > whether we can safely remove the altsetting toggle. > >>> I see that your testing also included Intel based modems. That's good. >>> It would still be nice to have test results from a few more MBIM >>> implementations, in particular the more "difficult" ones. But I don't >> >> I agree, especially Huawei ones for which the alternate setting >> toggling was introduced. > > I'll see what I can do about that. Looks like I have to dig through my > mailbox. It seems I didn't add any Reported-by tags on the relevant > commits. Wonder why... Well, there you have the reason why you always > should. Now I got to do the work instead of just loading it on you :) > >>> know how much help I can promise here. At the moment I don't even know >>> which box my modems are in. Moved a month ago and am still living in a >>> box. Or more like a hundred boxes ;) >>> >>> The easiest way to get this thoroughly tested is of course to push it >>> now, and try to respond quickly in case it breaks something. Don't know >>> what others think about that? >>> but I also removed altsetting toggling for all MBIM modems and maybe this is not acceptable. >>> >>> I wonder about that. It was added specifically for modems which seemed >>> to need it. Don't remember if we ever tried RESET_FUNCTION as an >>> alternative. Removing workaorunds which have proven to be necessary at >>> some point in time is a bit risky. >>> >> >> I totally agree, but the other way would be to add another quirk at >> the cdc_mbim driver level, isn't it? > > Yes, so I'm definitely with you here - let's try without the quirk > first. I'm ready to say "commit it", if noone else objects. > >> If this is a preferred solution I can try to modify the patch >> according to this path. > > No, the patch is fine as is. Just one question: If keeping the > altsetting toggle proves necessary, will that break the Qualcomm > devices? Yes, I could test that myself, but I'm lazy and I guess you > already have tested it? Unfortunately, yes: for Telit LE922A6 altsetting toggle seems to be part of the problem. Regards, Daniele > > > Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with Telit LE922 and cdc_mbim
Bjørn Mork writes: > Daniele Palmas writes: >> 2016-11-23 15:49 GMT+01:00 Bjørn Mork : >> >>> I see that your testing also included Intel based modems. That's good. >>> It would still be nice to have test results from a few more MBIM >>> implementations, in particular the more "difficult" ones. But I don't >> >> I agree, especially Huawei ones for which the alternate setting >> toggling was introduced. > > I'll see what I can do about that. Looks like I have to dig through my > mailbox. It seems I didn't add any Reported-by tags on the relevant > commits. Wonder why... Well, there you have the reason why you always > should. Now I got to do the work instead of just loading it on you :) OK, I found the details I should have included with that commit. The bug was observed on a Huawei E3372: It didn't respect our request for 16bit headers until we added this altsetting toggle. Ref https://bugs.freedesktop.org/show_bug.cgi?id=94340 And thanks to Andrew I have one of those modems, so I should be able to test your alternative fix. If I can only figure out where my modems are... Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with Telit LE922 and cdc_mbim
Daniele Palmas writes: > 2016-11-23 15:49 GMT+01:00 Bjørn Mork : >> Daniele Palmas writes: >>> 2016-11-21 10:49 GMT+01:00 Bjørn Mork : Daniele Palmas writes: > it turned out that resetting the interface in cdc_ncm_init after > getting the NTB parameters removes the need for the sleep, making the > modem to work fine. Sounds very good, although I must admit that it isn't perfectly clear to me what kind of reset we're talking about here. But no worries, the patch will make that clear :) >>> >>> Sorry for the confusion, I meant resetting the MBIM function with >>> RESET_FUNCTION request code. >> >> Yes, the patch did make that clear, as expected :) >> > I wonder if this is an acceptable solution and can be applied also for > MC7455. Quite possible. I will definitely test it. If we can avoid an arbitrary and pointless delay, then that's great. But I guess this also requires testing with a wide range of other MBIM devices to find out if we can apply it unconditionally without breaking anything. Avoiding device-specific or vendor-specific code is important in a class driver, if possible. >>> >>> Ok, unfortunately I can test only with Telit modems, so I'm not sure >>> if the change I did is harmless for all the other modems: >>> RESET_FUNCTION should not cause issues, >> >> Agreed. Unfortunately, we cannot depend on sane firmware behaviour ;) >> >> I did a semi-quick test on a Sierra Wireless EM7455 and can confirm that >> your patch makes it work without the delay. Very nice. >> > > Cool! > >> Do you happen to know if the Windows MBIM driver use RESET_FUNCTION >> during initialisation? That would make this feel much safer. >> > > Yes, Windows driver seems to send RESET_FUNCTION two times: after > getting NTB parameters and after setting NTB input size. But it seems > that only the first one is mandatory. > > Windows USB traces taken with TotalPhase Datacenter are available at > > https://drive.google.com/drive/folders/0B1kPnH2g8ISIZWJiV05qeWN5dVE > > file LE922win10_2.tdc This is comforting. It means that the risk introducing the RESET_FUNCTION call is close to zero. The only remaining issue is whether we can safely remove the altsetting toggle. >> I see that your testing also included Intel based modems. That's good. >> It would still be nice to have test results from a few more MBIM >> implementations, in particular the more "difficult" ones. But I don't > > I agree, especially Huawei ones for which the alternate setting > toggling was introduced. I'll see what I can do about that. Looks like I have to dig through my mailbox. It seems I didn't add any Reported-by tags on the relevant commits. Wonder why... Well, there you have the reason why you always should. Now I got to do the work instead of just loading it on you :) >> know how much help I can promise here. At the moment I don't even know >> which box my modems are in. Moved a month ago and am still living in a >> box. Or more like a hundred boxes ;) >> >> The easiest way to get this thoroughly tested is of course to push it >> now, and try to respond quickly in case it breaks something. Don't know >> what others think about that? >> >>> but I also removed altsetting >>> toggling for all MBIM modems and maybe this is not acceptable. >> >> I wonder about that. It was added specifically for modems which seemed >> to need it. Don't remember if we ever tried RESET_FUNCTION as an >> alternative. Removing workaorunds which have proven to be necessary at >> some point in time is a bit risky. >> > > I totally agree, but the other way would be to add another quirk at > the cdc_mbim driver level, isn't it? Yes, so I'm definitely with you here - let's try without the quirk first. I'm ready to say "commit it", if noone else objects. > If this is a preferred solution I can try to modify the patch > according to this path. No, the patch is fine as is. Just one question: If keeping the altsetting toggle proves necessary, will that break the Qualcomm devices? Yes, I could test that myself, but I'm lazy and I guess you already have tested it? Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with Telit LE922 and cdc_mbim
Re-adding the list, sorry. 2016-11-23 15:49 GMT+01:00 Bjørn Mork : > Daniele Palmas writes: >> 2016-11-21 10:49 GMT+01:00 Bjørn Mork : >>> Daniele Palmas writes: >>> it turned out that resetting the interface in cdc_ncm_init after getting the NTB parameters removes the need for the sleep, making the modem to work fine. >>> >>> Sounds very good, although I must admit that it isn't perfectly clear to >>> me what kind of reset we're talking about here. But no worries, the >>> patch will make that clear :) >>> >> >> Sorry for the confusion, I meant resetting the MBIM function with >> RESET_FUNCTION request code. > > Yes, the patch did make that clear, as expected :) > I wonder if this is an acceptable solution and can be applied also for MC7455. >>> >>> Quite possible. I will definitely test it. If we can avoid an >>> arbitrary and pointless delay, then that's great. But I guess this also >>> requires testing with a wide range of other MBIM devices to find out if >>> we can apply it unconditionally without breaking anything. Avoiding >>> device-specific or vendor-specific code is important in a class driver, >>> if possible. >>> >> >> Ok, unfortunately I can test only with Telit modems, so I'm not sure >> if the change I did is harmless for all the other modems: >> RESET_FUNCTION should not cause issues, > > Agreed. Unfortunately, we cannot depend on sane firmware behaviour ;) > > I did a semi-quick test on a Sierra Wireless EM7455 and can confirm that > your patch makes it work without the delay. Very nice. > Cool! > Do you happen to know if the Windows MBIM driver use RESET_FUNCTION > during initialisation? That would make this feel much safer. > Yes, Windows driver seems to send RESET_FUNCTION two times: after getting NTB parameters and after setting NTB input size. But it seems that only the first one is mandatory. Windows USB traces taken with TotalPhase Datacenter are available at https://drive.google.com/drive/folders/0B1kPnH2g8ISIZWJiV05qeWN5dVE file LE922win10_2.tdc > I see that your testing also included Intel based modems. That's good. > It would still be nice to have test results from a few more MBIM > implementations, in particular the more "difficult" ones. But I don't I agree, especially Huawei ones for which the alternate setting toggling was introduced. > know how much help I can promise here. At the moment I don't even know > which box my modems are in. Moved a month ago and am still living in a > box. Or more like a hundred boxes ;) > > The easiest way to get this thoroughly tested is of course to push it > now, and try to respond quickly in case it breaks something. Don't know > what others think about that? > >> but I also removed altsetting >> toggling for all MBIM modems and maybe this is not acceptable. > > I wonder about that. It was added specifically for modems which seemed > to need it. Don't remember if we ever tried RESET_FUNCTION as an > alternative. Removing workaorunds which have proven to be necessary at > some point in time is a bit risky. > I totally agree, but the other way would be to add another quirk at the cdc_mbim driver level, isn't it? If this is a preferred solution I can try to modify the patch according to this path. Thanks, Daniele > > Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with Telit LE922 and cdc_mbim
Daniele Palmas writes: > 2016-11-21 10:49 GMT+01:00 Bjørn Mork : >> Daniele Palmas writes: >> >>> it turned out that resetting the interface in cdc_ncm_init after >>> getting the NTB parameters removes the need for the sleep, making the >>> modem to work fine. >> >> Sounds very good, although I must admit that it isn't perfectly clear to >> me what kind of reset we're talking about here. But no worries, the >> patch will make that clear :) >> > > Sorry for the confusion, I meant resetting the MBIM function with > RESET_FUNCTION request code. Yes, the patch did make that clear, as expected :) >>> I wonder if this is an acceptable solution and can be applied also for >>> MC7455. >> >> Quite possible. I will definitely test it. If we can avoid an >> arbitrary and pointless delay, then that's great. But I guess this also >> requires testing with a wide range of other MBIM devices to find out if >> we can apply it unconditionally without breaking anything. Avoiding >> device-specific or vendor-specific code is important in a class driver, >> if possible. >> > > Ok, unfortunately I can test only with Telit modems, so I'm not sure > if the change I did is harmless for all the other modems: > RESET_FUNCTION should not cause issues, Agreed. Unfortunately, we cannot depend on sane firmware behaviour ;) I did a semi-quick test on a Sierra Wireless EM7455 and can confirm that your patch makes it work without the delay. Very nice. Do you happen to know if the Windows MBIM driver use RESET_FUNCTION during initialisation? That would make this feel much safer. I see that your testing also included Intel based modems. That's good. It would still be nice to have test results from a few more MBIM implementations, in particular the more "difficult" ones. But I don't know how much help I can promise here. At the moment I don't even know which box my modems are in. Moved a month ago and am still living in a box. Or more like a hundred boxes ;) The easiest way to get this thoroughly tested is of course to push it now, and try to respond quickly in case it breaks something. Don't know what others think about that? > but I also removed altsetting > toggling for all MBIM modems and maybe this is not acceptable. I wonder about that. It was added specifically for modems which seemed to need it. Don't remember if we ever tried RESET_FUNCTION as an alternative. Removing workaorunds which have proven to be necessary at some point in time is a bit risky. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with Telit LE922 and cdc_mbim
Hi Bjørn, 2016-11-21 10:49 GMT+01:00 Bjørn Mork : > Daniele Palmas writes: > >> it turned out that resetting the interface in cdc_ncm_init after >> getting the NTB parameters removes the need for the sleep, making the >> modem to work fine. > > Sounds very good, although I must admit that it isn't perfectly clear to > me what kind of reset we're talking about here. But no worries, the > patch will make that clear :) > Sorry for the confusion, I meant resetting the MBIM function with RESET_FUNCTION request code. >> I wonder if this is an acceptable solution and can be applied also for >> MC7455. > > Quite possible. I will definitely test it. If we can avoid an > arbitrary and pointless delay, then that's great. But I guess this also > requires testing with a wide range of other MBIM devices to find out if > we can apply it unconditionally without breaking anything. Avoiding > device-specific or vendor-specific code is important in a class driver, > if possible. > Ok, unfortunately I can test only with Telit modems, so I'm not sure if the change I did is harmless for all the other modems: RESET_FUNCTION should not cause issues, but I also removed altsetting toggling for all MBIM modems and maybe this is not acceptable. Thanks, Daniele > > Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with Telit LE922 and cdc_mbim
Daniele Palmas writes: > it turned out that resetting the interface in cdc_ncm_init after > getting the NTB parameters removes the need for the sleep, making the > modem to work fine. Sounds very good, although I must admit that it isn't perfectly clear to me what kind of reset we're talking about here. But no worries, the patch will make that clear :) > I wonder if this is an acceptable solution and can be applied also for MC7455. Quite possible. I will definitely test it. If we can avoid an arbitrary and pointless delay, then that's great. But I guess this also requires testing with a wide range of other MBIM devices to find out if we can apply it unconditionally without breaking anything. Avoiding device-specific or vendor-specific code is important in a class driver, if possible. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with Telit LE922 and cdc_mbim
Hi Bjørn, 2016-11-16 9:50 GMT+01:00 Daniele Palmas : > Hi Bjørn, > > 2016-11-15 19:56 GMT+01:00 Bjørn Mork : >> Daniele Palmas writes: >> >>> The problem is in cdc_ncm, function cdc_ncm_bind_common, line >>> >>> usleep_range(1, 2); >>> >>> It seems that LE922 needs an higher timeout; changing the line to >>> >>> usleep_range(7, 8); >>> >>> makes the modem to work fine. >> >> Extremely interesting! As you probably noticed, that delay was recently >> added as a workaround for the same problem on Sierra Wireless EM7455 >> modems. I believe these are based on the Qualcomm MDM9230. Which >> chipset is the LE922 based on? Is it also one of the newer Qualcom >> chips? > > Yes, it is based on one of latest QC chipsets. > >> >> >>> I will submit a patch for this. >> >> Thanks. It would also be great if you could trigger some investigation >> into the actual firmware issue. It looks like the firmware returns >> control to the driver before it's actually ready at this point of >> initialisation. >> > > Yeah, for sure I will ask for some investigation also on the firmware > side, even though I don't have many expectations for this. > > It seems that, if the modem is attached to the host and then turned > on, the previous delay is not enough. And then there seems also to be > constraints on the application side (e.g. ModemManager). > > Currently I'm not going to submit a patch until things are more clear. it turned out that resetting the interface in cdc_ncm_init after getting the NTB parameters removes the need for the sleep, making the modem to work fine. I wonder if this is an acceptable solution and can be applied also for MC7455. Regards, Daniele > > Thanks for your help, > Daniele > >> >> >> >> Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with Telit LE922 and cdc_mbim
Hi Bjørn, 2016-11-15 19:56 GMT+01:00 Bjørn Mork : > Daniele Palmas writes: > >> The problem is in cdc_ncm, function cdc_ncm_bind_common, line >> >> usleep_range(1, 2); >> >> It seems that LE922 needs an higher timeout; changing the line to >> >> usleep_range(7, 8); >> >> makes the modem to work fine. > > Extremely interesting! As you probably noticed, that delay was recently > added as a workaround for the same problem on Sierra Wireless EM7455 > modems. I believe these are based on the Qualcomm MDM9230. Which > chipset is the LE922 based on? Is it also one of the newer Qualcom > chips? Yes, it is based on one of latest QC chipsets. > > >> I will submit a patch for this. > > Thanks. It would also be great if you could trigger some investigation > into the actual firmware issue. It looks like the firmware returns > control to the driver before it's actually ready at this point of > initialisation. > Yeah, for sure I will ask for some investigation also on the firmware side, even though I don't have many expectations for this. It seems that, if the modem is attached to the host and then turned on, the previous delay is not enough. And then there seems also to be constraints on the application side (e.g. ModemManager). Currently I'm not going to submit a patch until things are more clear. Thanks for your help, Daniele > > > > Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with Telit LE922 and cdc_mbim
Daniele Palmas writes: > The problem is in cdc_ncm, function cdc_ncm_bind_common, line > > usleep_range(1, 2); > > It seems that LE922 needs an higher timeout; changing the line to > > usleep_range(7, 8); > > makes the modem to work fine. Extremely interesting! As you probably noticed, that delay was recently added as a workaround for the same problem on Sierra Wireless EM7455 modems. I believe these are based on the Qualcomm MDM9230. Which chipset is the LE922 based on? Is it also one of the newer Qualcom chips? > I will submit a patch for this. Thanks. It would also be great if you could trigger some investigation into the actual firmware issue. It looks like the firmware returns control to the driver before it's actually ready at this point of initialisation. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with Telit LE922 and cdc_mbim
Hi, 2016-11-14 14:51 GMT+01:00 Daniele Palmas : > Hi, > > I'm struggling with Telit LE922 modem that presents an MBIM device. > The modem works fine in Windows, while in Linux (tested with 4.9 rc1) > data connection is not functional: using ifconfig I can see > > wwp0s20u8i2 Link encap:Ethernet HWaddr e6:c0:3b:97:80:de > inet addr:176.246.94.9 Bcast:176.246.94.11 Mask:255.255.255.252 > UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:1 errors:15 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:40 (40.0 B) > > so the issue seems to be in tx. > > I'm using an USB hw sniffer for trying to understand the problem; this > is an example of a NCM packet with Windows 10 driver: > > 4E 43 4D 48 0C 00 0B 02 48 00 38 00 45 00 00 28 > 78 E8 40 00 80 06 63 68 05 5C 7A E5 D8 3A C6 03 > E9 08 01 BB FB 36 F0 EA C6 8C D8 CB 50 10 80 00 > 9B 16 00 00 00 00 00 00 49 50 53 00 10 00 00 00 > 0C 00 28 00 00 00 00 00 > > 16 bit NTB, with NDP at the end. So I enabled CDC_NCM_FLAG_NDP_TO_END, > but still the device is not properly working. > > This is the first properly transmitted acked packet in Linux: > > 4E 43 4D 48 0C 00 00 00 80 00 34 00 46 C0 00 28 > 00 00 40 00 01 02 F4 F9 B0 F6 5E 09 E0 00 00 16 > 94 04 00 00 22 00 F9 02 00 00 00 01 04 00 00 00 > E0 00 00 FB 49 50 53 00 10 00 00 00 0C 00 28 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > that looks like quite similar than the Windows one (besides the final > padding). > > Then all the following out packets are nacked, e.g: > > 4E 43 4D 48 0C 00 01 00 D8 00 8C 00 45 00 00 3E > 05 71 40 00 40 11 0C E8 B0 F6 5E 09 0A 85 0E D2 > B3 30 00 35 00 2A D3 57 58 6A 01 00 00 01 00 00 > 00 00 00 00 05 64 61 69 73 79 06 75 62 75 6E 74 > 75 03 63 6F 6D 00 00 01 00 01 00 00 45 00 00 3E > 2A EC 40 00 40 11 91 8A B0 F6 5E 09 0A 84 64 B5 > B3 30 00 35 00 2A 7D 75 58 6A 01 00 00 01 00 00 > 00 00 00 00 05 64 61 69 73 79 06 75 62 75 6E 74 > 75 03 63 6F 6D 00 00 01 00 01 00 00 49 50 53 00 > 14 00 00 00 0C 00 3E 00 4C 00 3E 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 > > Those packets look good to me: the main difference with Windows is the > presence of more than one datagram, but, as far as I understand, this > should not be a problem since the modem reports: > > dwNtbInMaxSize=16384 dwNtbOutMaxSize=16384 wNdpOutPayloadRemainder=0 > wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=16 flags=0x20 > > while in Windows it seems that always only one datagram is sent. > > My thought is that the problem is in the modem firmware: in some way, > the first acked packet is breaking things inside the modem that is not > able to receive packets anymore, but maybe there is some other > problems in the tx packets created by the driver and I'm not able to > catch it. > I was wrong, the problem is not with the first packet. The problem is in cdc_ncm, function cdc_ncm_bind_common, line usleep_range(1, 2); It seems that LE922 needs an higher timeout; changing the line to usleep_range(7, 8); makes the modem to work fine. I will submit a patch for this. Regards, Daniele > Does someone have an hint about this? > > Is there a way to configure the cdc_mbim driver in order to have > exactly the same packet format sent in Windows? > > USB traces taken with TotalPhase Datacenter are available at > > https://drive.google.com/open?id=0B1kPnH2g8ISIZWJiV05qeWN5dVE > > Thanks, > Daniele -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Issue with Telit LE922 and cdc_mbim
Hi, I'm struggling with Telit LE922 modem that presents an MBIM device. The modem works fine in Windows, while in Linux (tested with 4.9 rc1) data connection is not functional: using ifconfig I can see wwp0s20u8i2 Link encap:Ethernet HWaddr e6:c0:3b:97:80:de inet addr:176.246.94.9 Bcast:176.246.94.11 Mask:255.255.255.252 UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:1 errors:15 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:40 (40.0 B) so the issue seems to be in tx. I'm using an USB hw sniffer for trying to understand the problem; this is an example of a NCM packet with Windows 10 driver: 4E 43 4D 48 0C 00 0B 02 48 00 38 00 45 00 00 28 78 E8 40 00 80 06 63 68 05 5C 7A E5 D8 3A C6 03 E9 08 01 BB FB 36 F0 EA C6 8C D8 CB 50 10 80 00 9B 16 00 00 00 00 00 00 49 50 53 00 10 00 00 00 0C 00 28 00 00 00 00 00 16 bit NTB, with NDP at the end. So I enabled CDC_NCM_FLAG_NDP_TO_END, but still the device is not properly working. This is the first properly transmitted acked packet in Linux: 4E 43 4D 48 0C 00 00 00 80 00 34 00 46 C0 00 28 00 00 40 00 01 02 F4 F9 B0 F6 5E 09 E0 00 00 16 94 04 00 00 22 00 F9 02 00 00 00 01 04 00 00 00 E0 00 00 FB 49 50 53 00 10 00 00 00 0C 00 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 that looks like quite similar than the Windows one (besides the final padding). Then all the following out packets are nacked, e.g: 4E 43 4D 48 0C 00 01 00 D8 00 8C 00 45 00 00 3E 05 71 40 00 40 11 0C E8 B0 F6 5E 09 0A 85 0E D2 B3 30 00 35 00 2A D3 57 58 6A 01 00 00 01 00 00 00 00 00 00 05 64 61 69 73 79 06 75 62 75 6E 74 75 03 63 6F 6D 00 00 01 00 01 00 00 45 00 00 3E 2A EC 40 00 40 11 91 8A B0 F6 5E 09 0A 84 64 B5 B3 30 00 35 00 2A 7D 75 58 6A 01 00 00 01 00 00 00 00 00 00 05 64 61 69 73 79 06 75 62 75 6E 74 75 03 63 6F 6D 00 00 01 00 01 00 00 49 50 53 00 14 00 00 00 0C 00 3E 00 4C 00 3E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Those packets look good to me: the main difference with Windows is the presence of more than one datagram, but, as far as I understand, this should not be a problem since the modem reports: dwNtbInMaxSize=16384 dwNtbOutMaxSize=16384 wNdpOutPayloadRemainder=0 wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=16 flags=0x20 while in Windows it seems that always only one datagram is sent. My thought is that the problem is in the modem firmware: in some way, the first acked packet is breaking things inside the modem that is not able to receive packets anymore, but maybe there is some other problems in the tx packets created by the driver and I'm not able to catch it. Does someone have an hint about this? Is there a way to configure the cdc_mbim driver in order to have exactly the same packet format sent in Windows? USB traces taken with TotalPhase Datacenter are available at https://drive.google.com/open?id=0B1kPnH2g8ISIZWJiV05qeWN5dVE Thanks, Daniele -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
