* Re: Is this 32-bit NCM?y
@ 2014-12-04 10:10 Midge Shaojun Tan
[not found] ` <AMSPR06MB6011E001029C251790CB923EE780-MyG0ARRHH/drF+2gGhmTpL9PrO6axcR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Midge Shaojun Tan @ 2014-12-04 10:10 UTC (permalink / raw)
To: Enrico Mioso, Bjørn Mork
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, youtux, linux-usb, netdev
[-- Attachment #1: Type: text/plain, Size: 2748 bytes --]
Hi all,
I test OK with kervel 3.16.4
Need disable other Ethernet network, just like eth1. (Then the DNS and route is OK)
And also need disable arp, (ifconfig wwan0 -arp up), because China UNICOM don't respond the ARP message.
With new mode switch string: /etc/usb_modeswitch.d/12d1:14fe
Please see the patch and check whether it is correct?
-----邮件原件-----
发件人: Enrico Mioso [mailto:mrkiko.rs@gmail.com]
发送时间: 2014年12月4日 17:54
收件人: Bjørn Mork
抄送: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org
主题: Re: Is this 32-bit NCM?y
Guys!
Don't forget I can test it - since I have a remote machine with 3.16 kernel and the device, at least for now.
So - Bjorn: do I need just to disable padding or do I need also to perform some other changes? I am sorry if I ask this a little bit stupidly, but I was alittle bit busy here.
On Thu, 4 Dec 2014, Bjørn Mork wrote:
> Date: Thu, 4 Dec 2014 10:19:11
> From: Bjørn Mork <bjorn@mork.no>
> To: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> Cc: Enrico Mioso <mrkiko.rs@gmail.com>,
> Eli Britstein <Eli.Britstein@audiocodes.com>,
> Alex Strizhevsky <alexxst@gmail.com>,
> Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
> "youtux@gmail.com" <youtux@gmail.com>,
> "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
> "netdev@vger.kernel.org" <netdev@vger.kernel.org>
> Subject: Re: Is this 32-bit NCM?y
>
> Kevin Zhu <Mingying.Zhu@audiocodes.com> writes:
>
>> Guys,
>>
>> After rearranging the padding, putting NCM0 right after NTH, and
>> disable ARP (FLAG_NOARP) and handling the offset alignment issue, it
>> seems it begins to work, though there's still problem with DHCP.
>
> Great! But it would be good to know if _one_ of these changes is
> enough to make it work.
>
>> The DHCP packet's size becomes a large one after the TX function,
>> which is 16384, the maximum.
>
> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
> Something like this should do for a simple test:
>
> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
>
>
> Bjørn
>
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
[-- Attachment #2: cdc_ncm.tgz --]
[-- Type: application/x-compressed, Size: 25607 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <AMSPR06MB6011E001029C251790CB923EE780-MyG0ARRHH/drF+2gGhmTpL9PrO6axcR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>]
* Re: Is this 32-bit NCM?y [not found] ` <AMSPR06MB6011E001029C251790CB923EE780-MyG0ARRHH/drF+2gGhmTpL9PrO6axcR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org> @ 2014-12-04 10:24 ` Enrico Mioso 0 siblings, 0 replies; 21+ messages in thread From: Enrico Mioso @ 2014-12-04 10:24 UTC (permalink / raw) To: Midge Shaojun Tan Cc: Bjørn Mork, Kevin Zhu, Eli Britstein, Alex Strizhevsky, youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: TEXT/PLAIN, Size: 4283 bytes --] Congratulations! Your modification to the driver work; the disable of padding itself alone did not. With the modified file version I am able to use the device with no problems. Congratulations guys. On Thu, 4 Dec 2014, Midge Shaojun Tan wrote: > Date: Thu, 4 Dec 2014 11:10:16 > From: Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> > To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> > Cc: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, > "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> > Subject: Re: Is this 32-bit NCM?y > > Hi all, > > I test OK with kervel 3.16.4 > Need disable other Ethernet network, just like eth1. (Then the DNS and route is OK) > And also need disable arp, (ifconfig wwan0 -arp up), because China UNICOM don't respond the ARP message. > With new mode switch string: /etc/usb_modeswitch.d/12d1:14fe > Please see the patch and check whether it is correct? > > > -----邮件原件----- > 发件人: Enrico Mioso [mailto:mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] > 发送时间: 2014年12月4日 17:54 > 收件人: Bjørn Mork > 抄送: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > 主题: Re: Is this 32-bit NCM?y > > Guys! > Don't forget I can test it - since I have a remote machine with 3.16 kernel and the device, at least for now. > So - Bjorn: do I need just to disable padding or do I need also to perform some other changes? I am sorry if I ask this a little bit stupidly, but I was alittle bit busy here. > > > > > > On Thu, 4 Dec 2014, Bjørn Mork wrote: > >> Date: Thu, 4 Dec 2014 10:19:11 >> From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> >> To: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> >> Cc: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, >> Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, >> Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, >> Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, >> "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, >> "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, >> "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> >> Subject: Re: Is this 32-bit NCM?y >> >> Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> writes: >> >>> Guys, >>> >>> After rearranging the padding, putting NCM0 right after NTH, and >>> disable ARP (FLAG_NOARP) and handling the offset alignment issue, it >>> seems it begins to work, though there's still problem with DHCP. >> >> Great! But it would be good to know if _one_ of these changes is >> enough to make it work. >> >>> The DHCP packet's size becomes a large one after the TX function, >>> which is 16384, the maximum. >> >> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max. >> Something like this should do for a simple test: >> >> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt >> >> >> Bjørn >> > This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. > > If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM?y 2014-12-04 10:10 Is this 32-bit NCM?y Midge Shaojun Tan [not found] ` <AMSPR06MB6011E001029C251790CB923EE780-MyG0ARRHH/drF+2gGhmTpL9PrO6axcR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org> @ 2014-12-04 10:33 ` Enrico Mioso 2014-12-04 11:44 ` Bjørn Mork 2 siblings, 0 replies; 21+ messages in thread From: Enrico Mioso @ 2014-12-04 10:33 UTC (permalink / raw) To: Midge Shaojun Tan Cc: Bjørn Mork, Kevin Zhu, Eli Britstein, Alex Strizhevsky, youtux, linux-usb, netdev ... it works only applying cdc_ncm_modify.c; nothing else change. ARP works. Modesiwtch message not changed. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM?y 2014-12-04 10:10 Is this 32-bit NCM?y Midge Shaojun Tan [not found] ` <AMSPR06MB6011E001029C251790CB923EE780-MyG0ARRHH/drF+2gGhmTpL9PrO6axcR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org> 2014-12-04 10:33 ` Enrico Mioso @ 2014-12-04 11:44 ` Bjørn Mork 2014-12-04 12:17 ` Enrico Mioso [not found] ` <877fy7myfb.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org> 2 siblings, 2 replies; 21+ messages in thread From: Bjørn Mork @ 2014-12-04 11:44 UTC (permalink / raw) To: Midge Shaojun Tan Cc: Enrico Mioso, Kevin Zhu, Eli Britstein, Alex Strizhevsky, youtux, linux-usb, netdev "Midge Shaojun Tan" <ShaojunMidge.Tan@audiocodes.com> writes: > Hi all, > > I test OK with kervel 3.16.4 > Need disable other Ethernet network, just like eth1. (Then the DNS and route is OK) > And also need disable arp, (ifconfig wwan0 -arp up), because China UNICOM don't respond the ARP message. The ARP functionality is independent of operator. It is handled internally by the modem firmware. There are no MAC addresses or ethernet headers transmitted over the radio link. That's all faked by the modem. All MAC addresses and ethernet headers are local to the modem<->host USB link. > With new mode switch string: /etc/usb_modeswitch.d/12d1:14fe > Please see the patch and check whether it is correct? I see that you have two changes there: 1) the ETH_HLEN adjustment of ctx->tx_remainder is dropped 2) the NDP is placed after the first frame. I haven't verified the effect of the tx_remainder change, but I assume it fixes an alignment problem for this device. I'd like to look more at the effect of this for different values of wNdpOutPayloadRemainder and wNdpOutDivisor. We can choose to put the NDP at the end of the NTB if we find that this fixes some problem, but doing so by default for every NCM and MBIM device is a bit risky. If we accept that some devices are so buggy that the NDP cannot be placed anywhere (as required by the spec), then we have to assume that this goes both ways. Which means that moving the NDP to the end of the NTB might break some other device. We just don't know that since we haven't ever tried it. And your fix doesn't really move it to the end either. It just places the NDP after the first ethernet packet. Which happens to be the end if there is only one packet in the NTB. But if we aggregate more packets into this NTB then the result will look like this: NTH eth packet 1 NDP eth packet 2 .. eth packet N I'm not convinced this modem will handle that if it cannot handle the NDP being before the first packet... This needs to be tested. Try increasing /sys/class/net/wwan0/cdc_ncm/tx_timer_usecs to force the driver to aggregate packets and see if everything still works. Preferably while looking at the resulting NTB to verify that it does contain more than one ethernet packet. I realize I sound a bit negative now. This is absolutely not my intention. This is great work, providing some real progress wrt figuring out what goes on here. Thanks a lot! I am sure we can sort out the remaining issues, which are really minor compared to what you have found so far. Bjørn ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM?y 2014-12-04 11:44 ` Bjørn Mork @ 2014-12-04 12:17 ` Enrico Mioso [not found] ` <877fy7myfb.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org> 1 sibling, 0 replies; 21+ messages in thread From: Enrico Mioso @ 2014-12-04 12:17 UTC (permalink / raw) To: Bjørn Mork Cc: Midge Shaojun Tan, Kevin Zhu, Eli Britstein, Alex Strizhevsky, youtux, linux-usb, netdev [-- Attachment #1: Type: TEXT/PLAIN, Size: 3995 bytes --] On Thu, 4 Dec 2014, Bjørn Mork wrote: > "Midge Shaojun Tan" <ShaojunMidge.Tan@audiocodes.com> writes: > >> Hi all, >> >> I test OK with kervel 3.16.4 >> Need disable other Ethernet network, just like eth1. (Then the DNS and route is OK) >> And also need disable arp, (ifconfig wwan0 -arp up), because China UNICOM don't respond the ARP message. > > The ARP functionality is independent of operator. It is handled > internally by the modem firmware. There are no MAC addresses or > ethernet headers transmitted over the radio link. That's all faked by > the modem. All MAC addresses and ethernet headers are local to the > modem<->host USB link. > >> With new mode switch string: /etc/usb_modeswitch.d/12d1:14fe >> Please see the patch and check whether it is correct? > > I see that you have two changes there: > > 1) the ETH_HLEN adjustment of ctx->tx_remainder is dropped > 2) the NDP is placed after the first frame. > > I haven't verified the effect of the tx_remainder change, but I assume > it fixes an alignment problem for this device. I'd like to look more at > the effect of this for different values of wNdpOutPayloadRemainder and > wNdpOutDivisor. > > We can choose to put the NDP at the end of the NTB if we find that this > fixes some problem, but doing so by default for every NCM and MBIM > device is a bit risky. If we accept that some devices are so buggy that > the NDP cannot be placed anywhere (as required by the spec), then we > have to assume that this goes both ways. Which means that moving the > NDP to the end of the NTB might break some other device. We just don't > know that since we haven't ever tried it. Guys - this is a little hard moment for my life, so sorry if I sound negative too, really. No humor here. Bjorn, I am starting to think that we might need to (sadly) differentiate how we threat "standard" NCM devices in respect to Huawei ones, a little bit more. As you said - changing the handling in any way would be too risky - and definitely, I am starting to think that different firmware versions have different bugs in this regard (might be not in NCM handling itself, but in respect to other areas, like ARP handling / faking ). At the end we might come out with a good enough solution - but we would start to complicate things more and more, and definitely we might end up complicating more and more the driver itself. At some point, we might also end up finding out that we need a different workarounds for different firmwares, not even compatible one another. so - my idea, that is hypotetical: 1 - Factorize out cdc_ncm more 2 - Creating new {tx,rx}_fixup routines applying different workarounds. then, when the need to apply different workarounds for difference device (or firmware versions) arise, we might also think of a way to communicate to the driver the firmware version, allowing it to select some quirks to apply. What do you all think about it? > And your fix doesn't really move it to the end either. It just places > the NDP after the first ethernet packet. Which happens to be the end if > there is only one packet in the NTB. But if we aggregate more packets > into this NTB then the result will look like this: > > NTH > eth packet 1 > NDP > eth packet 2 > .. > eth packet N > > I'm not convinced this modem will handle that if it cannot handle the > NDP being before the first packet... This needs to be tested. Try > increasing /sys/class/net/wwan0/cdc_ncm/tx_timer_usecs to force the > driver to aggregate packets and see if everything still works. > Preferably while looking at the resulting NTB to verify that it does > contain more than one ethernet packet. > > I realize I sound a bit negative now. This is absolutely not my > intention. This is great work, providing some real progress wrt figuring > out what goes on here. Thanks a lot! I am sure we can sort out the > remaining issues, which are really minor compared to what you have found > so far. > > > > Bjørn > > I'll test this now. ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <877fy7myfb.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>]
* Re: Is this 32-bit NCM?y [not found] ` <877fy7myfb.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org> @ 2014-12-04 12:28 ` Enrico Mioso [not found] ` <alpine.LNX.2.03.1412041326160.9926-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 21+ messages in thread From: Enrico Mioso @ 2014-12-04 12:28 UTC (permalink / raw) To: Bjørn Mork Cc: Midge Shaojun Tan, Kevin Zhu, Eli Britstein, Alex Strizhevsky, youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: TEXT/PLAIN, Size: 3917 bytes --] ... DHCP will work with some DHCPNACKS in the meanwhile, but ping stops working at all. Otherwise, it works with the standard value: --- 8.8.8.8 ping statistics --- 48 packets transmitted, 48 received, 0% packet loss, time 47004ms rtt min/avg/max/mdev = 362.084/392.878/523.132/33.636 ms And I was expecting effectively to see some lost packets, but instead... no. On Thu, 4 Dec 2014, Bjørn Mork wrote: > Date: Thu, 4 Dec 2014 12:44:56 > From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> > To: Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> > Cc: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, > "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> > Subject: Re: Is this 32-bit NCM?y > > "Midge Shaojun Tan" <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> writes: > >> Hi all, >> >> I test OK with kervel 3.16.4 >> Need disable other Ethernet network, just like eth1. (Then the DNS and route is OK) >> And also need disable arp, (ifconfig wwan0 -arp up), because China UNICOM don't respond the ARP message. > > The ARP functionality is independent of operator. It is handled > internally by the modem firmware. There are no MAC addresses or > ethernet headers transmitted over the radio link. That's all faked by > the modem. All MAC addresses and ethernet headers are local to the > modem<->host USB link. > >> With new mode switch string: /etc/usb_modeswitch.d/12d1:14fe >> Please see the patch and check whether it is correct? > > I see that you have two changes there: > > 1) the ETH_HLEN adjustment of ctx->tx_remainder is dropped > 2) the NDP is placed after the first frame. > > I haven't verified the effect of the tx_remainder change, but I assume > it fixes an alignment problem for this device. I'd like to look more at > the effect of this for different values of wNdpOutPayloadRemainder and > wNdpOutDivisor. > > We can choose to put the NDP at the end of the NTB if we find that this > fixes some problem, but doing so by default for every NCM and MBIM > device is a bit risky. If we accept that some devices are so buggy that > the NDP cannot be placed anywhere (as required by the spec), then we > have to assume that this goes both ways. Which means that moving the > NDP to the end of the NTB might break some other device. We just don't > know that since we haven't ever tried it. > > And your fix doesn't really move it to the end either. It just places > the NDP after the first ethernet packet. Which happens to be the end if > there is only one packet in the NTB. But if we aggregate more packets > into this NTB then the result will look like this: > > NTH > eth packet 1 > NDP > eth packet 2 > .. > eth packet N > > I'm not convinced this modem will handle that if it cannot handle the > NDP being before the first packet... This needs to be tested. Try > increasing /sys/class/net/wwan0/cdc_ncm/tx_timer_usecs to force the > driver to aggregate packets and see if everything still works. > Preferably while looking at the resulting NTB to verify that it does > contain more than one ethernet packet. > > I realize I sound a bit negative now. This is absolutely not my > intention. This is great work, providing some real progress wrt figuring > out what goes on here. Thanks a lot! I am sure we can sort out the > remaining issues, which are really minor compared to what you have found > so far. > > > > Bjørn > > ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <alpine.LNX.2.03.1412041326160.9926-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: Is this 32-bit NCM?y [not found] ` <alpine.LNX.2.03.1412041326160.9926-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2014-12-05 2:20 ` Kevin Zhu [not found] ` <54811670.5030703-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> 0 siblings, 1 reply; 21+ messages in thread From: Kevin Zhu @ 2014-12-05 2:20 UTC (permalink / raw) To: Enrico Mioso, Bjørn Mork Cc: Midge Shaojun Tan, Eli Britstein, Alex Strizhevsky, youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4821 bytes --] Regarding the location of NDP, it should be easy to fix. It can be added to the end of the NTB only after it's ready to send. Regarding the concern to other devices, as there's a particular driver for Huawei devices in kernel, which is huawei_cdc_ncm, maybe we can just fix the TX function there to avoid breaking other devices. Regards, Kevin On 12/04/2014 08:28 PM, Enrico Mioso wrote: > ... DHCP will work with some DHCPNACKS in the meanwhile, but ping > stops working at all. > Otherwise, it works with the standard value: > > --- 8.8.8.8 ping statistics --- > 48 packets transmitted, 48 received, 0% packet loss, time 47004ms > rtt min/avg/max/mdev = 362.084/392.878/523.132/33.636 ms > > And I was expecting effectively to see some lost packets, but > instead... no. > > > On Thu, 4 Dec 2014, Bjørn Mork wrote: > >> Date: Thu, 4 Dec 2014 12:44:56 >> From: Bjørn Mork <bjorn@mork.no> >> To: Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com> >> Cc: Enrico Mioso <mrkiko.rs@gmail.com>, >> Kevin Zhu <Mingying.Zhu@audiocodes.com>, >> Eli Britstein <Eli.Britstein@audiocodes.com>, >> Alex Strizhevsky <alexxst@gmail.com>, >> "youtux@gmail.com" <youtux@gmail.com>, >> "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, >> "netdev@vger.kernel.org" <netdev@vger.kernel.org> >> Subject: Re: Is this 32-bit NCM?y >> >> "Midge Shaojun Tan" <ShaojunMidge.Tan@audiocodes.com> writes: >> >>> Hi all, >>> >>> I test OK with kervel 3.16.4 >>> Need disable other Ethernet network, just like eth1. (Then the DNS >>> and route is OK) >>> And also need disable arp, (ifconfig wwan0 -arp up), because China >>> UNICOM don't respond the ARP message. >> >> The ARP functionality is independent of operator. It is handled >> internally by the modem firmware. There are no MAC addresses or >> ethernet headers transmitted over the radio link. That's all faked by >> the modem. All MAC addresses and ethernet headers are local to the >> modem<->host USB link. >> >>> With new mode switch string: /etc/usb_modeswitch.d/12d1:14fe >>> Please see the patch and check whether it is correct? >> >> I see that you have two changes there: >> >> 1) the ETH_HLEN adjustment of ctx->tx_remainder is dropped >> 2) the NDP is placed after the first frame. >> >> I haven't verified the effect of the tx_remainder change, but I assume >> it fixes an alignment problem for this device. I'd like to look more at >> the effect of this for different values of wNdpOutPayloadRemainder and >> wNdpOutDivisor. >> >> We can choose to put the NDP at the end of the NTB if we find that this >> fixes some problem, but doing so by default for every NCM and MBIM >> device is a bit risky. If we accept that some devices are so buggy that >> the NDP cannot be placed anywhere (as required by the spec), then we >> have to assume that this goes both ways. Which means that moving the >> NDP to the end of the NTB might break some other device. We just don't >> know that since we haven't ever tried it. >> >> And your fix doesn't really move it to the end either. It just places >> the NDP after the first ethernet packet. Which happens to be the end if >> there is only one packet in the NTB. But if we aggregate more packets >> into this NTB then the result will look like this: >> >> NTH >> eth packet 1 >> NDP >> eth packet 2 >> .. >> eth packet N >> >> I'm not convinced this modem will handle that if it cannot handle the >> NDP being before the first packet... This needs to be tested. Try >> increasing /sys/class/net/wwan0/cdc_ncm/tx_timer_usecs to force the >> driver to aggregate packets and see if everything still works. >> Preferably while looking at the resulting NTB to verify that it does >> contain more than one ethernet packet. >> >> I realize I sound a bit negative now. This is absolutely not my >> intention. This is great work, providing some real progress wrt figuring >> out what goes on here. Thanks a lot! I am sure we can sort out the >> remaining issues, which are really minor compared to what you have found >> so far. >> >> >> >> Bjørn >> >> This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±ºÆâØ^nr¡ö¦zË\x1aëh¨èÚ&¢îý»\x05ËÛÔØï¦v¬Îf\x1dp)¹¹br ê+Ê+zf£¢·h§~Ûiÿûàz¹\x1e®w¥¢¸?¨èÚ&¢)ߢ^[f ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <54811670.5030703-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>]
* Re: Is this 32-bit NCM?y [not found] ` <54811670.5030703-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> @ 2014-12-05 9:42 ` Bjørn Mork [not found] ` <8761dqjuuh.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org> ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Bjørn Mork @ 2014-12-05 9:42 UTC (permalink / raw) To: Kevin Zhu Cc: Enrico Mioso, Midge Shaojun Tan, Eli Britstein, Alex Strizhevsky, youtux@gmail.com, linux-usb@vger.kernel.org, netdev@vger.kernel.org Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> writes: > Regarding the location of NDP, it should be easy to fix. It can be added > to the end of the NTB only after it's ready to send. Yes, but this will require a bit of redesign. Note that this code is shared with cdc_mbim, which might have to add multiple NDPs for multiplexed sessions. In theory up to 512 different, but that is so unlinkely that we can ignore it. We could set a fixed limit significantly lower than that if necessary. I'd really like to refactor this code to simply queue the skbs, creating the linear NTB only when the queue is flushed. Then we'll have all the info we need and can order the contents any way we want without adding unnecessary padding. > Regarding the > concern to other devices, as there's a particular driver for Huawei > devices in kernel, which is huawei_cdc_ncm, maybe we can just fix the TX > function there to avoid breaking other devices. Sure. That is definitely an alternative if we don't want to touch the generic driver. But making the generic driver flexible enough to accommodate any device would be preferable. I do hope we can do that. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <8761dqjuuh.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>]
* Re: Is this 32-bit NCM?y [not found] ` <8761dqjuuh.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org> @ 2014-12-05 9:59 ` Enrico Mioso 0 siblings, 0 replies; 21+ messages in thread From: Enrico Mioso @ 2014-12-05 9:59 UTC (permalink / raw) To: Bjørn Mork Cc: Kevin Zhu, Midge Shaojun Tan, Eli Britstein, Alex Strizhevsky, youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA Yes Bjorn: I should say that's true. and - in general, touching the device driver to make it flexible is surely important, especially to make it more easy to fix / "expand" in the future. I was referring to modifying the huawei_cdc_ncm.c driver only for specific huawei workarounds / firmware misbehaviours. thank to everyone, Enrico -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 21+ messages in thread
* refactoring cdc_ncm 2014-12-05 9:42 ` Bjørn Mork [not found] ` <8761dqjuuh.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org> @ 2014-12-28 14:53 ` Enrico Mioso 2015-01-19 16:51 ` [discuss] [cdc_ncm] Refactoring cdc_ncm Enrico Mioso 2 siblings, 0 replies; 21+ messages in thread From: Enrico Mioso @ 2014-12-28 14:53 UTC (permalink / raw) To: Bjørn Mork; +Cc: linux-usb, netdev Hello everyone, hello Bjorn. Sorry for my prevous private mail, didn't think about it. So I was wondering how it could be possible to refactor the cdc_ncm.c driver to queue frames and only when enough data was collected, generate a full NCM packet. so I am trying to get clear what's the way to go. My idea was to try to not change the layout of the code so much: I would like not breaking cdc_mbim.c and other code sharing some of these functions, so all of the work would be done in the cdc_ncm_fill_tx_frame function. Before starting with code, I would like to organize ideas: - when an SKB comes in, if the queue isn't empty, I would queue it Somethink like if (skb_queue_empty(ctx->skb_tx_queue)){ skb_insert(skb); } else { ready2send=1; } - at this point, performs some check to see if we have enough data:how can I do so? What should I check? Sizes of nth16 + ntb16 + ... ? - if not enough data is present, exit the function returning NULL else - invoke some functions to prepare the NCM packet I plan to move / rewrite the needed code to isolate it completely from the queue logic: making it also a little bit more clear. I would like to have separate functions for any parts of the NCM packet construction. This would allow better flexibility and probably less maintenance burden in the long run, and might open the road to extending the driver to support 32-bit NCM and different signness handling. In the current code, we are carrying around the "sign" variable in the cdc_ncm_fill_tx_frame: why? Can different NCM packets have different sign settings? Thank you guys, waiting for your replies, Enrico ^ permalink raw reply [flat|nested] 21+ messages in thread
* [discuss] [cdc_ncm] Refactoring cdc_ncm 2014-12-05 9:42 ` Bjørn Mork [not found] ` <8761dqjuuh.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org> 2014-12-28 14:53 ` refactoring cdc_ncm Enrico Mioso @ 2015-01-19 16:51 ` Enrico Mioso 2 siblings, 0 replies; 21+ messages in thread From: Enrico Mioso @ 2015-01-19 16:51 UTC (permalink / raw) To: Bjørn Mork Cc: Kevin Zhu, Midge Shaojun Tan, Eli Britstein, Alex Strizhevsky, youtux, linux-usb, netdev Hi guys. I am noticing that in kernel 3.19rc4, the driver from huawei, hw_cdc_driver is not able to perform the call to netif_msg_ifup anymore (receives error -13). This to say that it would be very important to continue the work on refactoring cdc_ncm.c driver to let it work with newer huawei devices such as the E3372 even at full rates. I received some acks regarding the patches I sent last time - and I am grateful to you all maintainers / reviewers. I have actually not received acks for all the patches so I preferred waiting and not continously re-sending again. This also happened due to me getting very busy lately with studying. So the situation is getting complicated. I sent this mail to everyone just to keep you up-to-date. Don't worry. Any help from any developer interested would be very apreciated. I would need some mentoring or help in general with coding. Thank you all very much. Sincerely. Enrico ^ permalink raw reply [flat|nested] 21+ messages in thread
* Is this 32-bit NCM? @ 2014-11-26 21:51 Enrico Mioso 2014-11-27 18:34 ` Enrico Mioso 0 siblings, 1 reply; 21+ messages in thread From: Enrico Mioso @ 2014-11-26 21:51 UTC (permalink / raw) To: Bjòrn Mork; +Cc: youtux, linux-usb, netdev [-- Attachment #1: Type: TEXT/PLAIN, Size: 338 bytes --] I am sorry for the indecent capture - but I didn't manage to get a better one till now. We modified the driver: but I wanted to be sure ... is this 32-bit NCM? If so, we might proceed testing with the non-working device to see if this was the problem and then decide what to do next. Thank you. Please CC us - we are nt in mailing list. [-- Attachment #2: Type: APPLICATION/x-xz, Size: 859768 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? @ 2014-11-27 18:34 ` Enrico Mioso 2014-11-28 9:29 ` Bjørn Mork 0 siblings, 1 reply; 21+ messages in thread From: Enrico Mioso @ 2014-11-27 18:34 UTC (permalink / raw) To: Alex Strizhevsky Cc: Bjørn Mork, ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg, Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg, youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg [-- Attachment #1: Type: TEXT/PLAIN, Size: 3996 bytes --] What I suspect, is that all this mess started when Huawei introduce new firmware releases that changed something in the IPV6 support. Bjorn - do you remember when a guy called Thomas reported us a problem about an LTE huawei modem that wasn't working with huawei_cdc_ncm? And you then discovered the problem was originated from some changes in the ordering of cdc_ncm actions; what happened then? Did Thomas get his modem back to working state? Sorry Thomas - you wilol read this message but I don't remember your surname, and might get confused with other people called Thomas. On Thu, 27 Nov 2014, Alex Strizhevsky wrote: ==Date: Thu, 27 Nov 2014 13:36:37 ==From: Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ==To: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org, == Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org ==Cc: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, == linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, == Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org ==Subject: Re: Is this 32-bit NCM? == ==Adding my colleagues - Eli, Kevin & Midge. == ==Any ideas are welcome ;) == == ==On Thu, Nov 27, 2014 at 12:03 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote: == Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes: == == > Ok - we can arrive to some ocnclusions regarding the E3272. == > First of all - the modem seems buggy enough to not be able to == handle requests == > for different formats. You need to unplug and re-plug it, but == this is onlyan == > impression and is reasonable. == > == > Then - the modem will accept to ndisdup the connection with == > at^ndisdup=1,1,"internet" == > but - if we use huawei_cdc_ncm + cdc_ncm we have no flow == handling messages and == > the modem stops here. == > If we use the cdc_ncm 32-bit driver (modified) we get lotfs of == > ^dsflorpt == > that's how it should be. == > So I think we can say that something is changing. == > Then there's the alignment problem you mentioned in your == previous reply. And == > this is hard to solve. == > could you try to help me understand where the problem is? == > I feel like we are very close to the solution but something == isn't working. == > Or might be just try to change the 16 bit driver? == ==If you use a recent version of the driver as a basis, then you get the ==CDC NCM NTB parameters in sysfs (if not, then you need to enable ==debugging and look in the log for these values). For example: == ==bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/* ==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001 ==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360 ==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360 ==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824 ==/sys/class/net/wwan0/cdc_ncm/rx_max:15360 ==/sys/class/net/wwan0/cdc_ncm/tx_max:15360 ==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400 ==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4 ==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1 ==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0 ==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4 ==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32 ==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0 ==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32 == == ==The possible problem I am thinking of is proper handling of the ==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet Frame ==Alignment" in the spec. Which is confusing as hell, but if I ==understand ==it correctly then we are supposed to align the start of the IP packets ==(the "payload", _not_ the ethernet frame) to a whole wNdp*Divisor ==number ==as long as the wNdp*PayloadRemainder is 0. == == ==Bjørn == == == == ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? 2014-11-27 18:34 ` Enrico Mioso @ 2014-11-28 9:29 ` Bjørn Mork 2014-12-01 21:11 ` Enrico Mioso 0 siblings, 1 reply; 21+ messages in thread From: Bjørn Mork @ 2014-11-28 9:29 UTC (permalink / raw) To: Enrico Mioso Cc: Alex Strizhevsky, ShaojunMidge.Tan, Mingying.Zhu, youtux, linux-usb, netdev, Eli.Britstein Enrico Mioso <mrkiko.rs@gmail.com> writes: > What I suspect, is that all this mess started when Huawei introduce new > firmware releases that changed something in the IPV6 support. > Bjorn - do you remember when a guy called Thomas reported us a problem about an > LTE huawei modem that wasn't working with huawei_cdc_ncm? > And you then discovered the problem was originated from some changes in the > ordering of cdc_ncm actions; what happened then? > Did Thomas get his modem back to working state? yes, that bug was fixed by commit ff0992e9036e9810e7cd45234fa32ca1e79750e2 Author: Bjørn Mork <bjorn@mork.no> Date: Mon Mar 17 16:25:18 2014 +0100 net: cdc_ncm: fix control message ordering This is a context modified revert of commit 6a9612e2cb22 ("net: cdc_ncm: remove ncm_parm field") which introduced a NCM specification violation, causing setup errors for some devices. These errors resulted in the device and host disagreeing about shared settings, with complete failure to communicate as the end result. The NCM specification require that many of the NCM specific control reuests are sent only while the NCM Data Interface is in alternate setting 0. Reverting the commit ensures that we follow this requirement. Fixes: 6a9612e2cb22 ("net: cdc_ncm: remove ncm_parm field") Reported-and-tested-by: Pasi Kärkkäinen <pasik@iki.fi> Reported-by: Thomas Schäfer <tschaefer@t-online.de> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net> Bjørn ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? 2014-11-28 9:29 ` Bjørn Mork @ 2014-12-01 21:11 ` Enrico Mioso 2014-12-01 22:02 ` Eli Britstein 0 siblings, 1 reply; 21+ messages in thread From: Enrico Mioso @ 2014-12-01 21:11 UTC (permalink / raw) To: Mingying.Zhu Cc: Bjørn Mork, Alex Strizhevsky, ShaojunMidge.Tan, youtux, linux-usb, netdev, Eli.Britstein So ... I have two ideas left for now. We know for sure the problem is in the way we TX frames, not the way we RX them (the way we send, generate them, not the way we receive them). Si I have two ideas, and I ask for help from the Linux-usb mailing list for this first one. 1 - Does a wayexist to "replay" traffic crom a usb capture? We might try to take the usb frames generated by Windows, and send them to the device to see if there is any reaction. It should not be science fiction, I saw them do that in the eciadsl old project. 2 - The huawei ndis driver: does it work with these devices? It should be a little bit out-dated now (at least in terms of dates, it might work as well): the code is A LOT but, just in case, to see if there is any chances it'll work. It remains to be seen in which kernels it can actually compile again. If this works we might analyse what's happening and try to debug this out. But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm. Thank you. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? @ 2014-12-01 22:02 ` Eli Britstein 2014-12-02 3:53 ` Kevin Zhu 0 siblings, 1 reply; 21+ messages in thread From: Eli Britstein @ 2014-12-01 22:02 UTC (permalink / raw) To: Enrico Mioso Cc: Kevin Zhu, Bjørn Mork, Alex Strizhevsky, Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA Hi Enrico and all, Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)? Maybe we can trace to compare them? Sent from my iPhone > On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote: > > So ... I have two ideas left for now. > We know for sure the problem is in the way we TX frames, not the way we RX them > (the way we send, generate them, not the way we receive them). > Si I have two ideas, and I ask for help from the Linux-usb mailing list for > this first one. > > 1 - Does a wayexist to "replay" traffic crom a usb capture? > We might try to take the usb frames generated by Windows, and send them to the > device to see if there is any reaction. It should not be science fiction, I saw > them do that in the eciadsl old project. > 2 - The huawei ndis driver: does it work with these devices? > It should be a little bit out-dated now (at least in terms of dates, it might > work as well): the code is A LOT but, just in case, to see if there is any > chances it'll work. It remains to be seen in which kernels it can actually > compile again. > > If this works we might analyse what's happening and try to debug this out. > But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm. > Thank you. ________________________________ This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? 2014-12-01 22:02 ` Eli Britstein @ 2014-12-02 3:53 ` Kevin Zhu 2014-12-02 6:32 ` Enrico Mioso 0 siblings, 1 reply; 21+ messages in thread From: Kevin Zhu @ 2014-12-02 3:53 UTC (permalink / raw) To: Eli Britstein, Enrico Mioso Cc: Bjørn Mork, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev Hi, The DHCP packets have the maximum size of dwNtbOutMaxSize=16384, while the other packets are less than that. However, the DHCP queries are not replied in time either, there's always some delay. By the way, though the device claims to support GET_MAX_DATAGRAM_SIZE, but it returns error when the host sends this command to it. I disabled this command in NCM driver and tried, but it's the same result. Regards, Kevin On 12/02/2014 06:02 AM, Eli Britstein wrote: > Hi Enrico and all, > > Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)? > Maybe we can trace to compare them? > > Sent from my iPhone > >> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote: >> >> So ... I have two ideas left for now. >> We know for sure the problem is in the way we TX frames, not the way we RX them >> (the way we send, generate them, not the way we receive them). >> Si I have two ideas, and I ask for help from the Linux-usb mailing list for >> this first one. >> >> 1 - Does a wayexist to "replay" traffic crom a usb capture? >> We might try to take the usb frames generated by Windows, and send them to the >> device to see if there is any reaction. It should not be science fiction, I saw >> them do that in the eciadsl old project. >> 2 - The huawei ndis driver: does it work with these devices? >> It should be a little bit out-dated now (at least in terms of dates, it might >> work as well): the code is A LOT but, just in case, to see if there is any >> chances it'll work. It remains to be seen in which kernels it can actually >> compile again. >> >> If this works we might analyse what's happening and try to debug this out. >> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm. >> Thank you. This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? @ 2014-12-02 6:32 ` Enrico Mioso 2014-12-02 6:43 ` Kevin Zhu 0 siblings, 1 reply; 21+ messages in thread From: Enrico Mioso @ 2014-12-02 6:32 UTC (permalink / raw) To: Kevin Zhu Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky, Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: TEXT/PLAIN, Size: 4009 bytes --] Hi again Eli, Hi Kevin, Hi everyone... As I understand it anyway - the distinction here tends not to be between different types of packets. It tends to be between received and sent packet. We are not able to generate packets that the device retains valid. If you manually configure the IP the device would have assigned you via DHCP, your system will start answering ARP request, saying that the host with IP aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle). However, the other host (gateway) will never know that. Indeed, it'll continue asking who-is at aa.bb.cc.dd ? At least, this is the situation I observed in the test system. On Tue, 2 Dec 2014, Kevin Zhu wrote: ==Date: Tue, 2 Dec 2014 04:53:53 ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> ==To: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, == Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> ==Subject: Re: Is this 32-bit NCM? == ==Hi, == ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384, while ==the other packets are less than that. However, the DHCP queries are not ==replied in time either, there's always some delay. == ==By the way, though the device claims to support GET_MAX_DATAGRAM_SIZE, ==but it returns error when the host sends this command to it. I disabled ==this command in NCM driver and tried, but it's the same result. == ==Regards, ==Kevin == ==On 12/02/2014 06:02 AM, Eli Britstein wrote: ==> Hi Enrico and all, ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)? ==> Maybe we can trace to compare them? ==> ==> Sent from my iPhone ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: ==>> ==>> So ... I have two ideas left for now. ==>> We know for sure the problem is in the way we TX frames, not the way we RX them ==>> (the way we send, generate them, not the way we receive them). ==>> Si I have two ideas, and I ask for help from the Linux-usb mailing list for ==>> this first one. ==>> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture? ==>> We might try to take the usb frames generated by Windows, and send them to the ==>> device to see if there is any reaction. It should not be science fiction, I saw ==>> them do that in the eciadsl old project. ==>> 2 - The huawei ndis driver: does it work with these devices? ==>> It should be a little bit out-dated now (at least in terms of dates, it might ==>> work as well): the code is A LOT but, just in case, to see if there is any ==>> chances it'll work. It remains to be seen in which kernels it can actually ==>> compile again. ==>> ==>> If this works we might analyse what's happening and try to debug this out. ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm. ==>> Thank you. ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. == ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message == ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? 2014-12-02 6:32 ` Enrico Mioso @ 2014-12-02 6:43 ` Kevin Zhu 2014-12-02 6:49 ` Enrico Mioso 0 siblings, 1 reply; 21+ messages in thread From: Kevin Zhu @ 2014-12-02 6:43 UTC (permalink / raw) To: Enrico Mioso Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate the paddings, but it did not work either, not even DHCP. Regards, Kevin On 12/02/2014 02:32 PM, Enrico Mioso wrote: > Hi again Eli, > Hi Kevin, > Hi everyone... > > As I understand it anyway - the distinction here tends not to be between > different types of packets. > It tends to be between received and sent packet. > We are not able to generate packets that the device retains valid. > If you manually configure the IP the device would have assigned you via DHCP, > your system will start answering ARP request, saying that the host with IP > aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle). > However, the other host (gateway) will never know that. Indeed, it'll continue > asking who-is at aa.bb.cc.dd ? > At least, this is the situation I observed in the test system. > > > On Tue, 2 Dec 2014, Kevin Zhu wrote: > > ==Date: Tue, 2 Dec 2014 04:53:53 > ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> > ==To: Eli Britstein <Eli.Britstein@audiocodes.com>, > == Enrico Mioso <mrkiko.rs@gmail.com> > ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>, > == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, > == "youtux@gmail.com" <youtux@gmail.com>, > == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, > == "netdev@vger.kernel.org" <netdev@vger.kernel.org> > ==Subject: Re: Is this 32-bit NCM? > == > ==Hi, > == > ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384, while > ==the other packets are less than that. However, the DHCP queries are not > ==replied in time either, there's always some delay. > == > ==By the way, though the device claims to support GET_MAX_DATAGRAM_SIZE, > ==but it returns error when the host sends this command to it. I disabled > ==this command in NCM driver and tried, but it's the same result. > == > ==Regards, > ==Kevin > == > ==On 12/02/2014 06:02 AM, Eli Britstein wrote: > ==> Hi Enrico and all, > ==> > ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)? > ==> Maybe we can trace to compare them? > ==> > ==> Sent from my iPhone > ==> > ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote: > ==>> > ==>> So ... I have two ideas left for now. > ==>> We know for sure the problem is in the way we TX frames, not the way we RX them > ==>> (the way we send, generate them, not the way we receive them). > ==>> Si I have two ideas, and I ask for help from the Linux-usb mailing list for > ==>> this first one. > ==>> > ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture? > ==>> We might try to take the usb frames generated by Windows, and send them to the > ==>> device to see if there is any reaction. It should not be science fiction, I saw > ==>> them do that in the eciadsl old project. > ==>> 2 - The huawei ndis driver: does it work with these devices? > ==>> It should be a little bit out-dated now (at least in terms of dates, it might > ==>> work as well): the code is A LOT but, just in case, to see if there is any > ==>> chances it'll work. It remains to be seen in which kernels it can actually > ==>> compile again. > ==>> > ==>> If this works we might analyse what's happening and try to debug this out. > ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm. > ==>> Thank you. > ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. > == > ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message > == This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? 2014-12-02 6:43 ` Kevin Zhu @ 2014-12-02 6:49 ` Enrico Mioso 2014-12-02 7:44 ` Kevin Zhu 0 siblings, 1 reply; 21+ messages in thread From: Enrico Mioso @ 2014-12-02 6:49 UTC (permalink / raw) To: Kevin Zhu Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev [-- Attachment #1: Type: TEXT/PLAIN, Size: 5571 bytes --] Can you try to look at Windows registry keys based on the INF file as suggested or would this be a problem for you? And... if you have any Huawei manutal talking about it: even device's ^DSFLOWRPT might be useful to some extent, but ... this is only just a note in case we don't find anything else. Regards ... and good day to all of you, Enrico On Tue, 2 Dec 2014, Kevin Zhu wrote: ==Date: Tue, 2 Dec 2014 07:43:24 ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> ==To: Enrico Mioso <mrkiko.rs@gmail.com> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, Bjørn Mork <bjorn@mork.no>, == Alex Strizhevsky <alexxst@gmail.com>, == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, == "youtux@gmail.com" <youtux@gmail.com>, == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, == "netdev@vger.kernel.org" <netdev@vger.kernel.org> ==Subject: Re: Is this 32-bit NCM? == ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate the ==paddings, but it did not work either, not even DHCP. == ==Regards, ==Kevin == ==On 12/02/2014 02:32 PM, Enrico Mioso wrote: ==> Hi again Eli, ==> Hi Kevin, ==> Hi everyone... ==> ==> As I understand it anyway - the distinction here tends not to be between ==> different types of packets. ==> It tends to be between received and sent packet. ==> We are not able to generate packets that the device retains valid. ==> If you manually configure the IP the device would have assigned you via DHCP, ==> your system will start answering ARP request, saying that the host with IP ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle). ==> However, the other host (gateway) will never know that. Indeed, it'll continue ==> asking who-is at aa.bb.cc.dd ? ==> At least, this is the situation I observed in the test system. ==> ==> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: ==> ==> ==Date: Tue, 2 Dec 2014 04:53:53 ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> ==> ==To: Eli Britstein <Eli.Britstein@audiocodes.com>, ==> == Enrico Mioso <mrkiko.rs@gmail.com> ==> ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>, ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, ==> == "youtux@gmail.com" <youtux@gmail.com>, ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org> ==> ==Subject: Re: Is this 32-bit NCM? ==> == ==> ==Hi, ==> == ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384, while ==> ==the other packets are less than that. However, the DHCP queries are not ==> ==replied in time either, there's always some delay. ==> == ==> ==By the way, though the device claims to support GET_MAX_DATAGRAM_SIZE, ==> ==but it returns error when the host sends this command to it. I disabled ==> ==this command in NCM driver and tried, but it's the same result. ==> == ==> ==Regards, ==> ==Kevin ==> == ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote: ==> ==> Hi Enrico and all, ==> ==> ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)? ==> ==> Maybe we can trace to compare them? ==> ==> ==> ==> Sent from my iPhone ==> ==> ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote: ==> ==>> ==> ==>> So ... I have two ideas left for now. ==> ==>> We know for sure the problem is in the way we TX frames, not the way we RX them ==> ==>> (the way we send, generate them, not the way we receive them). ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb mailing list for ==> ==>> this first one. ==> ==>> ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture? ==> ==>> We might try to take the usb frames generated by Windows, and send them to the ==> ==>> device to see if there is any reaction. It should not be science fiction, I saw ==> ==>> them do that in the eciadsl old project. ==> ==>> 2 - The huawei ndis driver: does it work with these devices? ==> ==>> It should be a little bit out-dated now (at least in terms of dates, it might ==> ==>> work as well): the code is A LOT but, just in case, to see if there is any ==> ==>> chances it'll work. It remains to be seen in which kernels it can actually ==> ==>> compile again. ==> ==>> ==> ==>> If this works we might analyse what's happening and try to debug this out. ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm. ==> ==>> Thank you. ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. ==> == ==> ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message ==> == ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. == ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message == ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? @ 2014-12-02 7:44 ` Kevin Zhu 2014-12-02 7:45 ` Eli Britstein 0 siblings, 1 reply; 21+ messages in thread From: Kevin Zhu @ 2014-12-02 7:44 UTC (permalink / raw) To: Enrico Mioso Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky, Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 6732 bytes --] Hi all, Here's the registry from windows 7. Attached. One parameter that might be interesting is MaxNumOfDatagramInNTB, which is 64. I wonder if it has something to do with MaxDatagramSize. Can someone also check the registry, in case I missed something? Regards, Kevin On 12/02/2014 02:49 PM, Enrico Mioso wrote: > Can you try to look at Windows registry keys based on the INF file as suggested > or would this be a problem for you? > And... if you have any Huawei manutal talking about it: even device's > ^DSFLOWRPT > might be useful to some extent, but ... this is only just a note in case we > don't find anything else. > Regards ... and good day to all of you, > Enrico > > > On Tue, 2 Dec 2014, Kevin Zhu wrote: > > ==Date: Tue, 2 Dec 2014 07:43:24 > ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> > ==To: Enrico Mioso <mrkiko.rs@gmail.com> > ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, Bjørn Mork <bjorn@mork.no>, > == Alex Strizhevsky <alexxst@gmail.com>, > == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, > == "youtux@gmail.com" <youtux@gmail.com>, > == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, > == "netdev@vger.kernel.org" <netdev@vger.kernel.org> > ==Subject: Re: Is this 32-bit NCM? > == > ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate the > ==paddings, but it did not work either, not even DHCP. > == > ==Regards, > ==Kevin > == > ==On 12/02/2014 02:32 PM, Enrico Mioso wrote: > ==> Hi again Eli, > ==> Hi Kevin, > ==> Hi everyone... > ==> > ==> As I understand it anyway - the distinction here tends not to be between > ==> different types of packets. > ==> It tends to be between received and sent packet. > ==> We are not able to generate packets that the device retains valid. > ==> If you manually configure the IP the device would have assigned you via DHCP, > ==> your system will start answering ARP request, saying that the host with IP > ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle). > ==> However, the other host (gateway) will never know that. Indeed, it'll continue > ==> asking who-is at aa.bb.cc.dd ? > ==> At least, this is the situation I observed in the test system. > ==> > ==> > ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: > ==> > ==> ==Date: Tue, 2 Dec 2014 04:53:53 > ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> > ==> ==To: Eli Britstein <Eli.Britstein@audiocodes.com>, > ==> == Enrico Mioso <mrkiko.rs@gmail.com> > ==> ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>, > ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, > ==> == "youtux@gmail.com" <youtux@gmail.com>, > ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, > ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org> > ==> ==Subject: Re: Is this 32-bit NCM? > ==> == > ==> ==Hi, > ==> == > ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384, while > ==> ==the other packets are less than that. However, the DHCP queries are not > ==> ==replied in time either, there's always some delay. > ==> == > ==> ==By the way, though the device claims to support GET_MAX_DATAGRAM_SIZE, > ==> ==but it returns error when the host sends this command to it. I disabled > ==> ==this command in NCM driver and tried, but it's the same result. > ==> == > ==> ==Regards, > ==> ==Kevin > ==> == > ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote: > ==> ==> Hi Enrico and all, > ==> ==> > ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)? > ==> ==> Maybe we can trace to compare them? > ==> ==> > ==> ==> Sent from my iPhone > ==> ==> > ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote: > ==> ==>> > ==> ==>> So ... I have two ideas left for now. > ==> ==>> We know for sure the problem is in the way we TX frames, not the way we RX them > ==> ==>> (the way we send, generate them, not the way we receive them). > ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb mailing list for > ==> ==>> this first one. > ==> ==>> > ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture? > ==> ==>> We might try to take the usb frames generated by Windows, and send them to the > ==> ==>> device to see if there is any reaction. It should not be science fiction, I saw > ==> ==>> them do that in the eciadsl old project. > ==> ==>> 2 - The huawei ndis driver: does it work with these devices? > ==> ==>> It should be a little bit out-dated now (at least in terms of dates, it might > ==> ==>> work as well): the code is A LOT but, just in case, to see if there is any > ==> ==>> chances it'll work. It remains to be seen in which kernels it can actually > ==> ==>> compile again. > ==> ==>> > ==> ==>> If this works we might analyse what's happening and try to debug this out. > ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm. > ==> ==>> Thank you. > ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. > ==> == > ==> ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message > ==> == > ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. > == > ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message > == This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: e3372.reg --] [-- Type: text/x-ms-regedit; name="e3372.reg", Size: 10292 bytes --] ÿþW\0i\0n\0d\0o\0w\0s\0 \0R\0e\0g\0i\0s\0t\0r\0y\0 \0E\0d\0i\0t\0o\0r\0 \0V\0e\0r\0s\0i\0o\0n\0 \05\0.\00\00\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0]\0\r\0 \0"\0N\0e\0w\0D\0e\0v\0i\0c\0e\0I\0n\0s\0t\0a\0l\0l\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\00\01\0\r\0 \0"\0N\0e\0t\0C\0f\0g\0I\0n\0s\0t\0a\0n\0c\0e\0I\0d\0"\0=\0"\0{\02\04\04\04\03\00\0E\05\0-\0F\06\0B\01\0-\04\0E\09\0C\0-\09\00\01\01\0-\04\01\03\0B\07\0E\02\04\05\09\08\0C\0}\0"\0\r\0 \0"\0*\0I\0f\0T\0y\0p\0e\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\0f\03\0\r\0 \0"\0C\0h\0a\0r\0a\0c\0t\0e\0r\0i\0s\0t\0i\0c\0s\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\08\04\0\r\0 \0"\0*\0M\0e\0d\0i\0a\0T\0y\0p\0e\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\00\09\0\r\0 \0"\0*\0P\0h\0y\0s\0i\0c\0a\0l\0M\0e\0d\0i\0a\0T\0y\0p\0e\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\00\08\0\r\0 \0"\0N\0e\0t\0L\0u\0i\0d\0I\0n\0d\0e\0x\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\00\00\0\r\0 \0"\0D\0e\0v\0i\0c\0e\0I\0n\0s\0t\0a\0n\0c\0e\0I\0D\0"\0=\0"\0U\0S\0B\0\\0\\0V\0I\0D\0_\01\02\0D\01\0&\0S\0U\0B\0C\0L\0A\0S\0S\0_\00\03\0&\0P\0R\0O\0T\0_\01\06\0\\0\\07\0&\04\06\0B\06\05\0F\01\0&\00\0&\00\00\00\02\0"\0\r\0 \0"\0I\0n\0s\0t\0a\0l\0l\0T\0i\0m\0e\0S\0t\0a\0m\0p\0"\0=\0h\0e\0x\0:\0d\0e\0,\00\07\0,\00\0a\0,\00\00\0,\00\03\0,\00\00\0,\00\08\0,\00\00\0,\00\01\0,\00\00\0,\03\01\0,\00\00\0,\01\0d\0,\00\00\0,\0c\0f\0,\00\00\0\r\0 \0"\0B\0u\0s\0N\0u\0m\0b\0e\0r\0"\0=\0"\00\0"\0\r\0 \0"\0M\0P\0R\0a\0d\0i\0o\0S\0t\0a\0t\0e\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\00\01\0\r\0 \0"\0B\0u\0s\0T\0y\0p\0e\0"\0=\0"\01\05\0"\0\r\0 \0"\0C\0o\0m\0p\0o\0n\0e\0n\0t\0I\0d\0"\0=\0"\0u\0s\0b\0\\0\\0v\0i\0d\0_\01\02\0d\01\0&\0s\0u\0b\0c\0l\0a\0s\0s\0_\00\03\0&\0p\0r\0o\0t\0_\01\06\0"\0\r\0 \0"\0d\0i\0s\0a\0b\0l\0e\0_\0a\0c\0c\0u\0m\0u\0l\0a\0t\0i\0o\0n\0_\0u\0p\0d\0a\0t\0e\0"\0=\0"\00\0"\0\r\0 \0"\0F\0l\0o\0w\0C\0o\0n\0t\0r\0o\0l\0T\0i\0m\0e\0O\0u\0t\0"\0=\0"\02\08\00\00\0"\0\r\0 \0"\0F\0r\0a\0m\0e\0T\0y\0p\0e\0"\0=\0"\00\0"\0\r\0 \0"\0I\0s\0N\0t\0b\03\02\0"\0=\0"\01\0"\0\r\0 \0"\0M\0a\0x\0N\0u\0m\0O\0f\0D\0a\0t\0a\0g\0r\0a\0m\0s\0I\0n\0N\0T\0B\0"\0=\0"\06\04\0"\0\r\0 \0"\0N\0c\0m\0R\0e\0i\0n\0i\0t\0i\0a\0l\0i\0z\0e\0E\0n\0a\0b\0l\0e\0"\0=\0"\01\0"\0\r\0 \0"\0N\0T\0B\0I\0n\0p\0u\0t\0S\0i\0z\0e\0"\0=\0"\00\0"\0\r\0 \0"\0P\0a\0c\0k\0e\0t\0s\0A\0c\0c\0u\0m\0u\0l\0a\0t\0i\0o\0n\0T\0i\0m\0e\0o\0u\0t\0"\0=\0"\02\00\0"\0\r\0 \0"\0P\0r\0o\0m\0i\0s\0c\0u\0o\0u\0s\0"\0=\0"\00\0"\0\r\0 \0"\0W\0w\0a\0n\0M\0b\0i\0m\0E\0n\0a\0b\0l\0e\0"\0=\0"\00\0"\0\r\0 \0"\0I\0n\0f\0P\0a\0t\0h\0"\0=\0"\0o\0e\0m\05\04\0.\0i\0n\0f\0"\0\r\0 \0"\0I\0n\0f\0S\0e\0c\0t\0i\0o\0n\0"\0=\0"\0e\0w\0_\0w\0w\0a\0n\0e\0c\0m\0.\0n\0d\0i\0"\0\r\0 \0"\0P\0r\0o\0v\0i\0d\0e\0r\0N\0a\0m\0e\0"\0=\0"\0H\0U\0A\0W\0E\0I\0"\0\r\0 \0"\0D\0r\0i\0v\0e\0r\0D\0a\0t\0e\0D\0a\0t\0a\0"\0=\0h\0e\0x\0:\00\00\0,\00\00\0,\07\0f\0,\07\0a\0,\07\04\0,\05\07\0,\0c\0f\0,\00\01\0\r\0 \0"\0D\0r\0i\0v\0e\0r\0D\0a\0t\0e\0"\0=\0"\04\0-\01\04\0-\02\00\01\04\0"\0\r\0 \0"\0D\0r\0i\0v\0e\0r\0V\0e\0r\0s\0i\0o\0n\0"\0=\0"\01\0.\00\0.\01\03\0.\00\0"\0\r\0 \0"\0M\0a\0t\0c\0h\0i\0n\0g\0D\0e\0v\0i\0c\0e\0I\0d\0"\0=\0"\0u\0s\0b\0\\0\\0v\0i\0d\0_\01\02\0d\01\0&\0s\0u\0b\0c\0l\0a\0s\0s\0_\00\03\0&\0p\0r\0o\0t\0_\01\06\0"\0\r\0 \0"\0D\0r\0i\0v\0e\0r\0D\0e\0s\0c\0"\0=\0"\0H\0U\0A\0W\0E\0I\0 \0M\0o\0b\0i\0l\0e\0 \0C\0o\0n\0n\0e\0c\0t\0 \0-\0 \0N\0e\0t\0w\0o\0r\0k\0 \0C\0a\0r\0d\0"\0\r\0 \0"\0E\0n\0a\0b\0l\0e\0D\0h\0c\0p\0"\0=\0d\0w\0o\0r\0d\0:\00\00\00\00\00\00\00\00\0\r\0 \0"\0h\0w\0_\0n\0d\0i\0s\0_\0c\0o\0n\0t\0r\0o\0l\0_\0f\0i\0l\0e\0"\0=\0"\0\\0\\0D\0o\0s\0D\0e\0v\0i\0c\0e\0s\0\\0\\0H\0w\0U\0s\0b\0N\0d\0i\0s\00\0"\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0L\0i\0n\0k\0a\0g\0e\0]\0\r\0 \0"\0R\0o\0o\0t\0D\0e\0v\0i\0c\0e\0"\0=\0h\0e\0x\0(\07\0)\0:\07\0b\0,\00\00\0,\03\02\0,\00\00\0,\03\04\0,\00\00\0,\03\04\0,\00\00\0,\03\04\0,\00\00\0,\03\03\0,\00\00\0,\03\00\0,\00\00\0,\04\05\0,\00\00\0,\03\05\0,\00\00\0,\02\0d\0,\0\\0\r\0 \0 \0 \00\00\0,\04\06\0,\00\00\0,\03\06\0,\00\00\0,\04\02\0,\00\00\0,\03\01\0,\00\00\0,\02\0d\0,\00\00\0,\03\04\0,\00\00\0,\04\05\0,\00\00\0,\03\09\0,\00\00\0,\04\03\0,\00\00\0,\02\0d\0,\00\00\0,\03\09\0,\00\00\0,\03\00\0,\00\00\0,\0\\0\r\0 \0 \0 \03\01\0,\00\00\0,\03\01\0,\00\00\0,\02\0d\0,\00\00\0,\03\04\0,\00\00\0,\03\01\0,\00\00\0,\03\03\0,\00\00\0,\04\02\0,\00\00\0,\03\07\0,\00\00\0,\04\05\0,\00\00\0,\03\02\0,\00\00\0,\03\04\0,\00\00\0,\03\05\0,\00\00\0,\03\09\0,\0\\0\r\0 \0 \0 \00\00\0,\03\08\0,\00\00\0,\04\03\0,\00\00\0,\07\0d\0,\00\00\0,\00\00\0,\00\00\0,\00\00\0,\00\00\0\r\0 \0"\0U\0p\0p\0e\0r\0B\0i\0n\0d\0"\0=\0h\0e\0x\0(\07\0)\0:\04\0e\0,\00\00\0,\06\04\0,\00\00\0,\06\09\0,\00\00\0,\07\03\0,\00\00\0,\07\05\0,\00\00\0,\06\09\0,\00\00\0,\06\0f\0,\00\00\0,\00\00\0,\00\00\0,\05\04\0,\00\00\0,\06\03\0,\00\00\0,\0\\0\r\0 \0 \0 \07\00\0,\00\00\0,\06\09\0,\00\00\0,\07\00\0,\00\00\0,\00\00\0,\00\00\0,\05\04\0,\00\00\0,\06\03\0,\00\00\0,\07\00\0,\00\00\0,\06\09\0,\00\00\0,\07\00\0,\00\00\0,\03\06\0,\00\00\0,\00\00\0,\00\00\0,\00\00\0,\00\00\0\r\0 \0"\0E\0x\0p\0o\0r\0t\0"\0=\0h\0e\0x\0(\07\0)\0:\05\0c\0,\00\00\0,\04\04\0,\00\00\0,\06\05\0,\00\00\0,\07\06\0,\00\00\0,\06\09\0,\00\00\0,\06\03\0,\00\00\0,\06\05\0,\00\00\0,\05\0c\0,\00\00\0,\07\0b\0,\00\00\0,\03\02\0,\00\00\0,\03\04\0,\0\\0\r\0 \0 \0 \00\00\0,\03\04\0,\00\00\0,\03\04\0,\00\00\0,\03\03\0,\00\00\0,\03\00\0,\00\00\0,\04\05\0,\00\00\0,\03\05\0,\00\00\0,\02\0d\0,\00\00\0,\04\06\0,\00\00\0,\03\06\0,\00\00\0,\04\02\0,\00\00\0,\03\01\0,\00\00\0,\02\0d\0,\00\00\0,\0\\0\r\0 \0 \0 \03\04\0,\00\00\0,\04\05\0,\00\00\0,\03\09\0,\00\00\0,\04\03\0,\00\00\0,\02\0d\0,\00\00\0,\03\09\0,\00\00\0,\03\00\0,\00\00\0,\03\01\0,\00\00\0,\03\01\0,\00\00\0,\02\0d\0,\00\00\0,\03\04\0,\00\00\0,\03\01\0,\00\00\0,\03\03\0,\0\\0\r\0 \0 \0 \00\00\0,\04\02\0,\00\00\0,\03\07\0,\00\00\0,\04\05\0,\00\00\0,\03\02\0,\00\00\0,\03\04\0,\00\00\0,\03\05\0,\00\00\0,\03\09\0,\00\00\0,\03\08\0,\00\00\0,\04\03\0,\00\00\0,\07\0d\0,\00\00\0,\00\00\0,\00\00\0,\00\00\0,\00\00\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0]\0\r\0 \0"\0S\0e\0r\0v\0i\0c\0e\0"\0=\0"\0h\0w\0u\0s\0b\0_\0w\0w\0a\0n\0e\0c\0m\0"\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0I\0n\0t\0e\0r\0f\0a\0c\0e\0s\0]\0\r\0 \0"\0U\0p\0p\0e\0r\0R\0a\0n\0g\0e\0"\0=\0"\0f\0l\0p\0p\04\0 \0a\0n\0d\0 \0f\0l\0p\0p\06\0"\0\r\0 \0"\0L\0o\0w\0e\0r\0R\0a\0n\0g\0e\0"\0=\0"\0p\0p\0i\0p\0"\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0]\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0d\0i\0s\0a\0b\0l\0e\0_\0a\0c\0c\0u\0m\0u\0l\0a\0t\0i\0o\0n\0_\0u\0p\0d\0a\0t\0e\0]\0\r\0 \0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0F\0l\0a\0g\0 \0t\0o\0 \0d\0i\0s\0a\0b\0l\0e\0 \0N\0C\0M\0 \0a\0c\0c\0u\0m\0u\0l\0a\0t\0i\0o\0n\0 \0a\0u\0t\0o\0 \0u\0p\0d\0a\0t\0i\0o\0n\0"\0\r\0 \0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\00\0"\0\r\0 \0"\0t\0y\0p\0e\0"\0=\0"\0d\0w\0o\0r\0d\0"\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0F\0l\0o\0w\0C\0o\0n\0t\0r\0o\0l\0T\0i\0m\0e\0O\0u\0t\0]\0\r\0 \0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0F\0l\0o\0w\0 \0C\0o\0n\0t\0r\0o\0l\0 \0t\0i\0m\0e\0o\0u\0t\0 \0i\0n\0t\0e\0r\0v\0a\0l\0 \0i\0n\0 \0m\0s\0"\0\r\0 \0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\02\08\00\00\0"\0\r\0 \0"\0t\0y\0p\0e\0"\0=\0"\0d\0w\0o\0r\0d\0"\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0F\0r\0a\0m\0e\0T\0y\0p\0e\0]\0\r\0 \0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0F\0r\0a\0m\0e\0 \0T\0y\0p\0e\0 \0i\0n\0 \0d\0r\0i\0v\0e\0r\0-\0d\0e\0v\0i\0c\0e\0 \0c\0o\0m\0m\0u\0n\0i\0c\0a\0t\0i\0o\0n\0s\0"\0\r\0 \0"\0t\0y\0p\0e\0"\0=\0"\0e\0n\0u\0m\0"\0\r\0 \0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\00\0"\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0F\0r\0a\0m\0e\0T\0y\0p\0e\0\\0e\0n\0u\0m\0]\0\r\0 \0"\01\0"\0=\0"\0I\0P\0"\0\r\0 \0"\00\0"\0=\0"\0E\0t\0h\0e\0r\0n\0e\0t\0"\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0I\0s\0N\0t\0b\03\02\0]\0\r\0 \0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\03\02\0b\0i\0t\0 \0m\0o\0d\0e\0"\0\r\0 \0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\01\0"\0\r\0 \0"\0t\0y\0p\0e\0"\0=\0"\0e\0n\0u\0m\0"\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0I\0s\0N\0t\0b\03\02\0\\0e\0n\0u\0m\0]\0\r\0 \0"\01\0"\0=\0"\0Y\0e\0s\0"\0\r\0 \0"\00\0"\0=\0"\0N\0o\0"\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0M\0a\0x\0N\0u\0m\0O\0f\0D\0a\0t\0a\0g\0r\0a\0m\0s\0I\0n\0N\0T\0B\0]\0\r\0 \0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0M\0a\0x\0i\0m\0u\0m\0 \0n\0u\0m\0b\0e\0r\0 \0o\0f\0 \0d\0a\0t\0a\0g\0r\0a\0m\0s\0 \0i\0n\0 \0N\0T\0B\0"\0\r\0 \0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\06\04\0"\0\r\0 \0"\0t\0y\0p\0e\0"\0=\0"\0d\0w\0o\0r\0d\0"\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0N\0c\0m\0R\0e\0i\0n\0i\0t\0i\0a\0l\0i\0z\0e\0E\0n\0a\0b\0l\0e\0]\0\r\0 \0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0F\0l\0a\0g\0 \0t\0o\0 \0e\0n\0a\0b\0l\0e\0 \0N\0C\0M\0 \0r\0e\0i\0n\0i\0t\0i\0a\0l\0i\0z\0e\0 \0a\0f\0t\0e\0r\0 \0r\0e\0s\0u\0m\0e\0"\0\r\0 \0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\01\0"\0\r\0 \0"\0t\0y\0p\0e\0"\0=\0"\0d\0w\0o\0r\0d\0"\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0N\0T\0B\0I\0n\0p\0u\0t\0S\0i\0z\0e\0]\0\r\0 \0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0N\0T\0B\0 \0i\0n\0p\0u\0t\0 \0s\0i\0z\0e\0"\0\r\0 \0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\00\0"\0\r\0 \0"\0t\0y\0p\0e\0"\0=\0"\0d\0w\0o\0r\0d\0"\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0P\0a\0c\0k\0e\0t\0s\0A\0c\0c\0u\0m\0u\0l\0a\0t\0i\0o\0n\0T\0i\0m\0e\0o\0u\0t\0]\0\r\0 \0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0P\0a\0c\0k\0e\0t\0s\0 \0A\0c\0c\0u\0m\0u\0l\0a\0t\0i\0o\0n\0 \0T\0i\0m\0e\0o\0u\0t\0 \0[\0u\0s\0e\0c\0]\0"\0\r\0 \0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\02\00\0"\0\r\0 \0"\0t\0y\0p\0e\0"\0=\0"\0d\0w\0o\0r\0d\0"\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0P\0r\0o\0m\0i\0s\0c\0u\0o\0u\0s\0]\0\r\0 \0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0S\0e\0t\0 \0t\0h\0e\0 \0p\0h\0y\0s\0i\0c\0a\0l\0 \0N\0I\0C\0 \0t\0o\0 \0p\0r\0o\0m\0i\0s\0c\0u\0o\0u\0s\0 \0m\0o\0d\0e\0"\0\r\0 \0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\00\0"\0\r\0 \0"\0t\0y\0p\0e\0"\0=\0"\0e\0n\0u\0m\0"\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0P\0r\0o\0m\0i\0s\0c\0u\0o\0u\0s\0\\0e\0n\0u\0m\0]\0\r\0 \0"\01\0"\0=\0"\0E\0n\0a\0b\0l\0e\0"\0\r\0 \0"\00\0"\0=\0"\0D\0i\0s\0a\0b\0l\0e\0"\0\r\0 \0\r\0 \0[\0H\0K\0E\0Y\0_\0L\0O\0C\0A\0L\0_\0M\0A\0C\0H\0I\0N\0E\0\\0S\0Y\0S\0T\0E\0M\0\\0C\0o\0n\0t\0r\0o\0l\0S\0e\0t\00\00\01\0\\0C\0o\0n\0t\0r\0o\0l\0\\0C\0l\0a\0s\0s\0\\0{\04\0D\03\06\0E\09\07\02\0-\0E\03\02\05\0-\01\01\0C\0E\0-\0B\0F\0C\01\0-\00\08\00\00\02\0B\0E\01\00\03\01\08\0}\0\\00\00\02\08\0\\0N\0d\0i\0\\0P\0a\0r\0a\0m\0s\0\\0W\0w\0a\0n\0M\0b\0i\0m\0E\0n\0a\0b\0l\0e\0]\0\r\0 \0"\0P\0a\0r\0a\0m\0D\0e\0s\0c\0"\0=\0"\0F\0l\0a\0g\0 \0t\0o\0 \0e\0n\0a\0b\0l\0e\0 \0W\0W\0A\0N\0 \0M\0B\0I\0M\0 \0f\0u\0n\0c\0t\0i\0o\0n\0"\0\r\0 \0"\0D\0e\0f\0a\0u\0l\0t\0"\0=\0"\00\0"\0\r\0 \0"\0t\0y\0p\0e\0"\0=\0"\0d\0w\0o\0r\0d\0"\0\r\0 \0\r\0 \0 ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: Is this 32-bit NCM? @ 2014-12-02 7:45 ` Eli Britstein 2014-12-02 8:03 ` Kevin Zhu 0 siblings, 1 reply; 21+ messages in thread From: Eli Britstein @ 2014-12-02 7:45 UTC (permalink / raw) To: Kevin Zhu, Enrico Mioso Cc: Bjørn Mork, Alex Strizhevsky, Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA Outlook blocked the attachment. Please zip it and resend. Thanks, Best regards, Eli Britstein SW Team Leader and Project Manager MP2xx Residential Gateways Tel: +972-3-9764148 Mobile: +972-54-2312677 Fax: +972-3-9764040 Email: Eli.Britstein@audiocodes.com Web: www.audiocodes.com -----Original Message----- From: Kevin Zhu Sent: Tuesday, December 02, 2014 9:44 To: Enrico Mioso Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org Subject: Re: Is this 32-bit NCM? Hi all, Here's the registry from windows 7. Attached. One parameter that might be interesting is MaxNumOfDatagramInNTB, which is 64. I wonder if it has something to do with MaxDatagramSize. Can someone also check the registry, in case I missed something? Regards, Kevin On 12/02/2014 02:49 PM, Enrico Mioso wrote: > Can you try to look at Windows registry keys based on the INF file as > suggested or would this be a problem for you? > And... if you have any Huawei manutal talking about it: even device's > ^DSFLOWRPT might be useful to some extent, but ... this is only just a > note in case we don't find anything else. > Regards ... and good day to all of you, Enrico > > > On Tue, 2 Dec 2014, Kevin Zhu wrote: > > ==Date: Tue, 2 Dec 2014 07:43:24 > ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> > ==To: Enrico Mioso <mrkiko.rs@gmail.com> > ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, Bjørn Mork <bjorn@mork.no>, > == Alex Strizhevsky <alexxst@gmail.com>, > == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, > == "youtux@gmail.com" <youtux@gmail.com>, > == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, > == "netdev@vger.kernel.org" <netdev@vger.kernel.org> > ==Subject: Re: Is this 32-bit NCM? > == > ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate > the ==paddings, but it did not work either, not even DHCP. > == > ==Regards, > ==Kevin > == > ==On 12/02/2014 02:32 PM, Enrico Mioso wrote: > ==> Hi again Eli, > ==> Hi Kevin, > ==> Hi everyone... > ==> > ==> As I understand it anyway - the distinction here tends not to be > between ==> different types of packets. > ==> It tends to be between received and sent packet. > ==> We are not able to generate packets that the device retains valid. > ==> If you manually configure the IP the device would have assigned > you via DHCP, ==> your system will start answering ARP request, saying > that the host with IP ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle). > ==> However, the other host (gateway) will never know that. Indeed, > it'll continue ==> asking who-is at aa.bb.cc.dd ? > ==> At least, this is the situation I observed in the test system. > ==> > ==> > ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: > ==> > ==> ==Date: Tue, 2 Dec 2014 04:53:53 > ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> ==> ==To: Eli > Britstein <Eli.Britstein@audiocodes.com>, > ==> == Enrico Mioso <mrkiko.rs@gmail.com> > ==> ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>, > ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, > ==> == "youtux@gmail.com" <youtux@gmail.com>, > ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, > ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org> > ==> ==Subject: Re: Is this 32-bit NCM? > ==> == > ==> ==Hi, > ==> == > ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384, > while ==> ==the other packets are less than that. However, the DHCP > queries are not ==> ==replied in time either, there's always some delay. > ==> == > ==> ==By the way, though the device claims to support > GET_MAX_DATAGRAM_SIZE, ==> ==but it returns error when the host sends > this command to it. I disabled ==> ==this command in NCM driver and tried, but it's the same result. > ==> == > ==> ==Regards, > ==> ==Kevin > ==> == > ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote: > ==> ==> Hi Enrico and all, > ==> ==> > ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)? > ==> ==> Maybe we can trace to compare them? > ==> ==> > ==> ==> Sent from my iPhone > ==> ==> > ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote: > ==> ==>> > ==> ==>> So ... I have two ideas left for now. > ==> ==>> We know for sure the problem is in the way we TX frames, not > the way we RX them ==> ==>> (the way we send, generate them, not the way we receive them). > ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb > mailing list for ==> ==>> this first one. > ==> ==>> > ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture? > ==> ==>> We might try to take the usb frames generated by Windows, and > send them to the ==> ==>> device to see if there is any reaction. It > should not be science fiction, I saw ==> ==>> them do that in the eciadsl old project. > ==> ==>> 2 - The huawei ndis driver: does it work with these devices? > ==> ==>> It should be a little bit out-dated now (at least in terms of > dates, it might ==> ==>> work as well): the code is A LOT but, just in > case, to see if there is any ==> ==>> chances it'll work. It remains > to be seen in which kernels it can actually ==> ==>> compile again. > ==> ==>> > ==> ==>> If this works we might analyse what's happening and try to debug this out. > ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm. > ==> ==>> Thank you. > ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. > ==> == > ==> ==If you have received this email in error please immediately > notify the sender and delete or destroy any copy of this message ==> > == ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. > == > ==If you have received this email in error please immediately notify > the sender and delete or destroy any copy of this message == ________________________________ This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? 2014-12-02 7:45 ` Eli Britstein @ 2014-12-02 8:03 ` Kevin Zhu 2014-12-02 10:32 ` Enrico Mioso 0 siblings, 1 reply; 21+ messages in thread From: Kevin Zhu @ 2014-12-02 8:03 UTC (permalink / raw) To: Eli Britstein, Enrico Mioso Cc: Bjørn Mork, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev Below is the content of the INF file oem54.inf. ; Copyright (c) 2010,2011 Huawei Incorporated ; Manufacturer: Huawei Incorporated ; ; CDC ECM & NCM driver ; [Version] Signature="$WINDOWS NT$" Class=Net ClassGUID={4d36e972-e325-11ce-bfc1-08002be10318} Provider=%Mfg% DriverVer=04/14/2014,1.0.13.0 CatalogFile=ew_wwanecm.cat [Manufacturer] %Mfg% = DeviceList,NTx86,NTamd64 [SourceDisksNames] 1 = %ew_wwanecm.DiskName%,,,"" [SourceDisksFiles] ew_wwanecm.sys = 1,, ; For Win2K [DeviceList] %PNP21_HW_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_16 %PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_46 %PNP21_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_76 %PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_07 %PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_37 %PNP21_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_67 %PNP21_HW_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_11 ; for logo test %HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00 ; For WinXP and later [DeviceList.NTx86] %PNP21_HW_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_16 %PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_46 %PNP21_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_76 %PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_07 %PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_37 %PNP21_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_67 %PNP21_HW_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_11 ; for logo test %HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00 ; For XP and later x64 [DeviceList.NTamd64] %PNP21_HW_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_16 %PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_46 %PNP21_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_76 %PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_07 %PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_37 %PNP21_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_67 %PNP21_HW_NetworkDesc% = ew_wwanecm.ndi, USB\VID_12D1&Subclass_03&Prot_11 ; for logo test %HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00 ;------------------------------------------------------------------------------- ; Virtual Ethernet Adapter ; [ew_wwanecm.ndi] *IfType = 243 ; IF_TYPE_WWANPP *MediaType = 9; NdisMediumWirelessWan *PhysicalMediaType = 8 ; NdisPhysicalMediumWirelessWan EnableDhcp = 0 ; DHCP Disabled Characteristics = 0x84 ; NCF_HAS_UI | NCF_PHYSICAL BusType = 15 ; if you specify NCF_PHYSICAL, you must specify bustype AddReg = ew_wwanecm.Reg, ParamsPromiscuous, ParamsFrameType, ParamsIsNtb32, ParamsNTBInputSize, ParamsPacketsAccumulationTimeout, ParamsMaxNumOfDatagramsInNTB, FlowControlTimeOut, DisableAccumulationUpdate, WwanMbimEnable, NcmReinitializeEnable CopyFiles = ew_wwanecm.CopyFiles [WWAN_AddReg] HKR,, Platform,0x00010001,0x3 HKR,, WWAN,0x00010001,0x1 HKR,, "SelectiveSuspendIdleTime", 0x00010001, 0x05 [ew_wwanecm.ndi.Services] AddService = %ServiceName%, 2, ew_wwanecm.Service, ew_wwanecm.EventLog [ew_wwanecm.ndi.HW] AddReg = WWAN_AddReg ;----------------------------------------------------------------------------- ; [ew_wwanecm.Reg] HKR, , BusNumber, 0, "0" HKR, , MPRadioState, 0x00010001, 0x00000001 ;RadioState HKR, Ndi, Service, 0, "hwusb_wwanecm" HKR, Ndi\Interfaces, UpperRange, 0, "flpp4" and "flpp6" HKR, Ndi\Interfaces, LowerRange, 0, "ppip" [ParamsPromiscuous] ; ; Should the physical NIC be set to Promiscuous mode ; HKR, Ndi\Params\Promiscuous, ParamDesc, , %Promiscuous% HKR, Ndi\Params\Promiscuous, Default, ,"0" HKR, Ndi\Params\Promiscuous, type, , enum HKR, Ndi\Params\Promiscuous\enum,"1", , %Promiscuous_Enable% HKR, Ndi\Params\Promiscuous\enum,"0", , %Promiscuous_Disable% [ParamsFrameType] HKR, Ndi\Params\FrameType, ParamDesc, 0, %FrameType% HKR, Ndi\Params\FrameType, type, 0, enum HKR, Ndi\Params\FrameType, Default, 0, "0" HKR, Ndi\Params\FrameType\enum,"1", 0, %FrameType_IP% HKR, Ndi\Params\FrameType\enum,"0", 0, %FrameType_Ethernet% [ParamsIsNtb32] HKR, Ndi\Params\IsNtb32, ParamDesc, , %IsNtb32% HKR, Ndi\Params\IsNtb32, Default, , "1" HKR, Ndi\Params\IsNtb32, type, , enum HKR, Ndi\Params\IsNtb32\enum, "1", , "Yes" HKR, Ndi\Params\IsNtb32\enum, "0", , "No" [ParamsNTBInputSize] HKR, Ndi\Params\NTBInputSize, ParamDesc, , %NTBInputSize% ; If the following size is larger than the maximum allowed by the device, the ; maximum value is used. 0 means to use the maximum allowed value of the device. HKR, Ndi\Params\NTBInputSize, Default, , "0" HKR, Ndi\Params\NTBInputSize, type, , dword [ParamsPacketsAccumulationTimeout] HKR, Ndi\Params\PacketsAccumulationTimeout, ParamDesc, , %PacketsAccumulationTimeout% ; Unit of PacketsAccumulationTimeout is usecs. Default value is 20 us. HKR, Ndi\Params\PacketsAccumulationTimeout, Default, , "20" HKR, Ndi\Params\PacketsAccumulationTimeout, type, , dword [ParamsMaxNumOfDatagramsInNTB] HKR, Ndi\Params\MaxNumOfDatagramsInNTB, ParamDesc, , %MaxNumOfDatagramsInNTB% HKR, Ndi\Params\MaxNumOfDatagramsInNTB, Default, , "64" HKR, Ndi\Params\MaxNumOfDatagramsInNTB, type, , dword [FlowControlTimeOut] HKR, Ndi\Params\FlowControlTimeOut, ParamDesc, , %FlowControlTimeout% HKR, Ndi\Params\FlowControlTimeOut, Default, , "2800" HKR, Ndi\Params\FlowControlTimeOut, type, , dword [DisableAccumulationUpdate] HKR, Ndi\Params\disable_accumulation_update, ParamDesc, , %DisableAccumulationUpdate% HKR, Ndi\Params\disable_accumulation_update, Default, , "0" HKR, Ndi\Params\disable_accumulation_update, type, , dword [WwanMbimEnable] HKR, Ndi\Params\WwanMbimEnable, ParamDesc, , %WwanMbimEnable% HKR, Ndi\Params\WwanMbimEnable, Default, , "0" HKR, Ndi\Params\WwanMbimEnable, type, , dword [NcmReinitializeEnable] HKR, Ndi\Params\NcmReinitializeEnable, ParamDesc, , %NcmReinitializeEnable% HKR, Ndi\Params\NcmReinitializeEnable, Default, , "1" HKR, Ndi\Params\NcmReinitializeEnable, type, , dword ;----------------------------------------------------------------------------- ; DestinationDirs ; [DestinationDirs] ew_wwanecm.CopyFiles = 12 [ew_wwanecm.CopyFiles] ew_wwanecm.sys,,,0x6 ;COPYFLG_NOSKIP | COPYFLG_NOVERSIONCHECK ;----------------------------------------------------------------------------- ; Driver and Service Section ; [ew_wwanecm.Service] ServiceType = 1 ;%SERVICE_KERNEL_DRIVER% StartType = 3 ;%SERVICE_DEMAND_START% ErrorControl = 1 ;%SERVICE_ERROR_NORMAL% ServiceBinary = %12%\ew_wwanecm.sys LoadOrderGroup = NDIS AddReg = ew_wwanecm.Service.Reg [ew_wwanecm.Service.Reg] HKR, , TextModeFlags, 0x00010001, 0x0001 HKR, Parameters, DebugLevel, 0x00010001, 1 HKR, Parameters, WwanLogoTestOn, 0x00010001, 0 [ew_wwanecm.EventLog] AddReg = ew_wwanecm.AddEventLog.Reg [ew_wwanecm.AddEventLog.Reg] HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll" HKR, , TypesSupported, 0x00010001, 7 ;----------------------------------------------------------------------------- ; Localizable Strings ; [Strings] Mfg = "HUAWEI" HUAWEI_NDISDeviceDesc = "HUAWEI Mobile Connect - Network Adapter" ;PNP2.1 Device descriptor PNP21_HW_3G_NetworkDesc = "HUAWEI Mobile Connect - 3G Network Card" PNP21_HW_NetworkDesc = "HUAWEI Mobile Connect - Network Card" PNP21_NetworkDesc = "Mobile Connect - Network Card" PNP21_VDF_NetworkDesc = "Vodafone Mobile Broadband Network Adapter (Huawei)" ew_wwanecm.DiskName = "DriverCore Installation Disk" Promiscuous = "Set the physical NIC to promiscuous mode" Promiscuous_Disable = "Disable" ServiceName = "hwusb_wwanecm" Promiscuous_Enable = "Enable" FrameType = "Frame Type in driver-device communications" FrameType_Ethernet = "Ethernet" FrameType_IP = "IP" IsNtb32 = "32bit mode" NTBInputSize = "NTB input size" PacketsAccumulationTimeout = "Packets Accumulation Timeout [usec]" MaxNumOfDatagramsInNTB = "Maximum number of datagrams in NTB" FlowControlTimeout = "Flow Control timeout interval in ms" DisableAccumulationUpdate = "Flag to disable NCM accumulation auto updation" WwanMbimEnable = "Flag to enable WWAN MBIM function" NcmReinitializeEnable = "Flag to enable NCM reinitialize after resume" Regards, Kevin On 12/02/2014 03:45 PM, Eli Britstein wrote: > Outlook blocked the attachment. Please zip it and resend. > > Thanks, > Best regards, > > Eli Britstein > SW Team Leader and Project Manager > MP2xx Residential Gateways > > Tel: +972-3-9764148 > Mobile: +972-54-2312677 > Fax: +972-3-9764040 > Email: Eli.Britstein@audiocodes.com > Web: www.audiocodes.com > > > > -----Original Message----- > From: Kevin Zhu > Sent: Tuesday, December 02, 2014 9:44 > To: Enrico Mioso > Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org > Subject: Re: Is this 32-bit NCM? > > Hi all, > > Here's the registry from windows 7. Attached. One parameter that might be interesting is MaxNumOfDatagramInNTB, which is 64. I wonder if it has something to do with MaxDatagramSize. Can someone also check the registry, in case I missed something? > > Regards, > Kevin > > On 12/02/2014 02:49 PM, Enrico Mioso wrote: >> Can you try to look at Windows registry keys based on the INF file as >> suggested or would this be a problem for you? >> And... if you have any Huawei manutal talking about it: even device's >> ^DSFLOWRPT might be useful to some extent, but ... this is only just a >> note in case we don't find anything else. >> Regards ... and good day to all of you, Enrico >> >> >> On Tue, 2 Dec 2014, Kevin Zhu wrote: >> >> ==Date: Tue, 2 Dec 2014 07:43:24 >> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> >> ==To: Enrico Mioso <mrkiko.rs@gmail.com> >> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, Bjørn Mork <bjorn@mork.no>, >> == Alex Strizhevsky <alexxst@gmail.com>, >> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, >> == "youtux@gmail.com" <youtux@gmail.com>, >> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, >> == "netdev@vger.kernel.org" <netdev@vger.kernel.org> >> ==Subject: Re: Is this 32-bit NCM? >> == >> ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate >> the ==paddings, but it did not work either, not even DHCP. >> == >> ==Regards, >> ==Kevin >> == >> ==On 12/02/2014 02:32 PM, Enrico Mioso wrote: >> ==> Hi again Eli, >> ==> Hi Kevin, >> ==> Hi everyone... >> ==> >> ==> As I understand it anyway - the distinction here tends not to be >> between ==> different types of packets. >> ==> It tends to be between received and sent packet. >> ==> We are not able to generate packets that the device retains valid. >> ==> If you manually configure the IP the device would have assigned >> you via DHCP, ==> your system will start answering ARP request, saying >> that the host with IP ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle). >> ==> However, the other host (gateway) will never know that. Indeed, >> it'll continue ==> asking who-is at aa.bb.cc.dd ? >> ==> At least, this is the situation I observed in the test system. >> ==> >> ==> >> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: >> ==> >> ==> ==Date: Tue, 2 Dec 2014 04:53:53 >> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> ==> ==To: Eli >> Britstein <Eli.Britstein@audiocodes.com>, >> ==> == Enrico Mioso <mrkiko.rs@gmail.com> >> ==> ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>, >> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, >> ==> == "youtux@gmail.com" <youtux@gmail.com>, >> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, >> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org> >> ==> ==Subject: Re: Is this 32-bit NCM? >> ==> == >> ==> ==Hi, >> ==> == >> ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384, >> while ==> ==the other packets are less than that. However, the DHCP >> queries are not ==> ==replied in time either, there's always some delay. >> ==> == >> ==> ==By the way, though the device claims to support >> GET_MAX_DATAGRAM_SIZE, ==> ==but it returns error when the host sends >> this command to it. I disabled ==> ==this command in NCM driver and tried, but it's the same result. >> ==> == >> ==> ==Regards, >> ==> ==Kevin >> ==> == >> ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote: >> ==> ==> Hi Enrico and all, >> ==> ==> >> ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)? >> ==> ==> Maybe we can trace to compare them? >> ==> ==> >> ==> ==> Sent from my iPhone >> ==> ==> >> ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote: >> ==> ==>> >> ==> ==>> So ... I have two ideas left for now. >> ==> ==>> We know for sure the problem is in the way we TX frames, not >> the way we RX them ==> ==>> (the way we send, generate them, not the way we receive them). >> ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb >> mailing list for ==> ==>> this first one. >> ==> ==>> >> ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture? >> ==> ==>> We might try to take the usb frames generated by Windows, and >> send them to the ==> ==>> device to see if there is any reaction. It >> should not be science fiction, I saw ==> ==>> them do that in the eciadsl old project. >> ==> ==>> 2 - The huawei ndis driver: does it work with these devices? >> ==> ==>> It should be a little bit out-dated now (at least in terms of >> dates, it might ==> ==>> work as well): the code is A LOT but, just in >> case, to see if there is any ==> ==>> chances it'll work. It remains >> to be seen in which kernels it can actually ==> ==>> compile again. >> ==> ==>> >> ==> ==>> If this works we might analyse what's happening and try to debug this out. >> ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm. >> ==> ==>> Thank you. >> ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. >> ==> == >> ==> ==If you have received this email in error please immediately >> notify the sender and delete or destroy any copy of this message ==> >> == ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. >> == >> ==If you have received this email in error please immediately notify >> the sender and delete or destroy any copy of this message == > This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? 2014-12-02 8:03 ` Kevin Zhu @ 2014-12-02 10:32 ` Enrico Mioso 2014-12-02 11:21 ` Bjørn Mork 0 siblings, 1 reply; 21+ messages in thread From: Enrico Mioso @ 2014-12-02 10:32 UTC (permalink / raw) To: Kevin Zhu Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev [-- Attachment #1: Type: TEXT/PLAIN, Size: 18265 bytes --] Kevin - it works! the key seems to be in the tx_fixup function; there is a special handling for frames effectively. Please ... help me backport those changes to the standard Linux driver - it will be a gain for us all, and in general you'll have a more probable maintenance than you would with the driver from huawei. Sorry huawei guys - I respect you, but there is a reason if drivers needs some modifications to get merged. Hoping not to sound arrogant, my intent was only to be clear. On Tue, 2 Dec 2014, Kevin Zhu wrote: ==Date: Tue, 2 Dec 2014 09:03:21 ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> ==To: Eli Britstein <Eli.Britstein@audiocodes.com>, == Enrico Mioso <mrkiko.rs@gmail.com> ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>, == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, == "youtux@gmail.com" <youtux@gmail.com>, == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, == "netdev@vger.kernel.org" <netdev@vger.kernel.org> ==Subject: Re: Is this 32-bit NCM? == ==Below is the content of the INF file oem54.inf. == ==; Copyright (c) 2010,2011 Huawei Incorporated ==; Manufacturer: Huawei Incorporated ==; ==; CDC ECM & NCM driver ==; == ==[Version] ==Signature="$WINDOWS NT$" ==Class=Net ==ClassGUID={4d36e972-e325-11ce-bfc1-08002be10318} ==Provider=%Mfg% ==DriverVer=04/14/2014,1.0.13.0 ==CatalogFile=ew_wwanecm.cat == ==[Manufacturer] ==%Mfg% = DeviceList,NTx86,NTamd64 == ==[SourceDisksNames] ==1 = %ew_wwanecm.DiskName%,,,"" == ==[SourceDisksFiles] ==ew_wwanecm.sys = 1,, == ==; For Win2K ==[DeviceList] ==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_16 ==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_46 ==%PNP21_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_76 == ==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_07 ==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_37 ==%PNP21_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_67 == ==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_11 == ==; for logo test ==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00 == ==; For WinXP and later ==[DeviceList.NTx86] ==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_16 ==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_46 ==%PNP21_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_76 == ==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_07 ==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_37 ==%PNP21_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_67 == ==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_11 == ==; for logo test ==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00 == ==; For XP and later x64 ==[DeviceList.NTamd64] ==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_16 ==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_46 ==%PNP21_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_76 == ==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_07 ==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_37 ==%PNP21_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_67 == ==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi, ==USB\VID_12D1&Subclass_03&Prot_11 == ==; for logo test ==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00 == ==;------------------------------------------------------------------------------- == ==; Virtual Ethernet Adapter ==; ==[ew_wwanecm.ndi] ==*IfType = 243 ; IF_TYPE_WWANPP ==*MediaType = 9; NdisMediumWirelessWan ==*PhysicalMediaType = 8 ; NdisPhysicalMediumWirelessWan ==EnableDhcp = 0 ; DHCP Disabled ==Characteristics = 0x84 ; NCF_HAS_UI | NCF_PHYSICAL ==BusType = 15 ; if you specify NCF_PHYSICAL, you must specify ==bustype ==AddReg = ew_wwanecm.Reg, ParamsPromiscuous, ParamsFrameType, ==ParamsIsNtb32, ParamsNTBInputSize, ParamsPacketsAccumulationTimeout, ==ParamsMaxNumOfDatagramsInNTB, FlowControlTimeOut, ==DisableAccumulationUpdate, WwanMbimEnable, NcmReinitializeEnable ==CopyFiles = ew_wwanecm.CopyFiles == == ==[WWAN_AddReg] ==HKR,, Platform,0x00010001,0x3 ==HKR,, WWAN,0x00010001,0x1 ==HKR,, "SelectiveSuspendIdleTime", 0x00010001, 0x05 ==[ew_wwanecm.ndi.Services] ==AddService = %ServiceName%, 2, ew_wwanecm.Service, ew_wwanecm.EventLog == ==[ew_wwanecm.ndi.HW] ==AddReg = WWAN_AddReg == ==;----------------------------------------------------------------------------- == ==; ==[ew_wwanecm.Reg] ==HKR, , BusNumber, 0, "0" ==HKR, , MPRadioState, 0x00010001, ==0x00000001 ;RadioState ==HKR, Ndi, Service, 0, "hwusb_wwanecm" ==HKR, Ndi\Interfaces, UpperRange, 0, "flpp4" and =="flpp6" ==HKR, Ndi\Interfaces, LowerRange, 0, "ppip" == ==[ParamsPromiscuous] ==; ==; Should the physical NIC be set to Promiscuous mode ==; ==HKR, Ndi\Params\Promiscuous, ParamDesc, , %Promiscuous% ==HKR, Ndi\Params\Promiscuous, Default, ,"0" ==HKR, Ndi\Params\Promiscuous, type, , enum ==HKR, Ndi\Params\Promiscuous\enum,"1", , %Promiscuous_Enable% ==HKR, Ndi\Params\Promiscuous\enum,"0", , %Promiscuous_Disable% == ==[ParamsFrameType] ==HKR, Ndi\Params\FrameType, ParamDesc, 0, %FrameType% ==HKR, Ndi\Params\FrameType, type, 0, enum ==HKR, Ndi\Params\FrameType, Default, 0, "0" ==HKR, Ndi\Params\FrameType\enum,"1", 0, %FrameType_IP% ==HKR, Ndi\Params\FrameType\enum,"0", 0, %FrameType_Ethernet% == ==[ParamsIsNtb32] ==HKR, Ndi\Params\IsNtb32, ParamDesc, , %IsNtb32% ==HKR, Ndi\Params\IsNtb32, Default, , "1" ==HKR, Ndi\Params\IsNtb32, type, , enum ==HKR, Ndi\Params\IsNtb32\enum, "1", , "Yes" ==HKR, Ndi\Params\IsNtb32\enum, "0", , "No" == ==[ParamsNTBInputSize] ==HKR, Ndi\Params\NTBInputSize, ParamDesc, , %NTBInputSize% ==; If the following size is larger than the maximum allowed by the ==device, the ==; maximum value is used. 0 means to use the maximum allowed value of the ==device. ==HKR, Ndi\Params\NTBInputSize, Default, , "0" ==HKR, Ndi\Params\NTBInputSize, type, , dword == ==[ParamsPacketsAccumulationTimeout] ==HKR, Ndi\Params\PacketsAccumulationTimeout, ParamDesc, , ==%PacketsAccumulationTimeout% ==; Unit of PacketsAccumulationTimeout is usecs. Default value is 20 us. ==HKR, Ndi\Params\PacketsAccumulationTimeout, Default, , "20" ==HKR, Ndi\Params\PacketsAccumulationTimeout, type, , dword == ==[ParamsMaxNumOfDatagramsInNTB] ==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, ParamDesc, , ==%MaxNumOfDatagramsInNTB% ==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, Default, , "64" ==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, type, , dword == ==[FlowControlTimeOut] ==HKR, Ndi\Params\FlowControlTimeOut, ParamDesc, , %FlowControlTimeout% ==HKR, Ndi\Params\FlowControlTimeOut, Default, , "2800" ==HKR, Ndi\Params\FlowControlTimeOut, type, , dword == ==[DisableAccumulationUpdate] ==HKR, Ndi\Params\disable_accumulation_update, ParamDesc, , ==%DisableAccumulationUpdate% ==HKR, Ndi\Params\disable_accumulation_update, Default, , "0" ==HKR, Ndi\Params\disable_accumulation_update, type, , dword == ==[WwanMbimEnable] ==HKR, Ndi\Params\WwanMbimEnable, ParamDesc, , %WwanMbimEnable% ==HKR, Ndi\Params\WwanMbimEnable, Default, , "0" ==HKR, Ndi\Params\WwanMbimEnable, type, , dword == ==[NcmReinitializeEnable] ==HKR, Ndi\Params\NcmReinitializeEnable, ParamDesc, , %NcmReinitializeEnable% ==HKR, Ndi\Params\NcmReinitializeEnable, Default, , "1" ==HKR, Ndi\Params\NcmReinitializeEnable, type, , dword == ==;----------------------------------------------------------------------------- == ==; DestinationDirs ==; ==[DestinationDirs] ==ew_wwanecm.CopyFiles = 12 == ==[ew_wwanecm.CopyFiles] ==ew_wwanecm.sys,,,0x6 ;COPYFLG_NOSKIP | COPYFLG_NOVERSIONCHECK ==;----------------------------------------------------------------------------- == ==; Driver and Service Section ==; == ==[ew_wwanecm.Service] ==ServiceType = 1 ;%SERVICE_KERNEL_DRIVER% ==StartType = 3 ;%SERVICE_DEMAND_START% ==ErrorControl = 1 ;%SERVICE_ERROR_NORMAL% ==ServiceBinary = %12%\ew_wwanecm.sys ==LoadOrderGroup = NDIS ==AddReg = ew_wwanecm.Service.Reg == ==[ew_wwanecm.Service.Reg] ==HKR, , TextModeFlags, 0x00010001, 0x0001 ==HKR, Parameters, DebugLevel, 0x00010001, 1 ==HKR, Parameters, WwanLogoTestOn, 0x00010001, 0 == ==[ew_wwanecm.EventLog] ==AddReg = ew_wwanecm.AddEventLog.Reg == ==[ew_wwanecm.AddEventLog.Reg] ==HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll" ==HKR, , TypesSupported, 0x00010001, 7 == ==;----------------------------------------------------------------------------- == ==; Localizable Strings ==; ==[Strings] ==Mfg = "HUAWEI" == ==HUAWEI_NDISDeviceDesc = "HUAWEI Mobile Connect - Network Adapter" == ==;PNP2.1 Device descriptor ==PNP21_HW_3G_NetworkDesc = "HUAWEI Mobile Connect - 3G Network Card" ==PNP21_HW_NetworkDesc = "HUAWEI Mobile Connect - Network Card" ==PNP21_NetworkDesc = "Mobile Connect - Network Card" ==PNP21_VDF_NetworkDesc = "Vodafone Mobile Broadband Network Adapter ==(Huawei)" == ==ew_wwanecm.DiskName = "DriverCore Installation Disk" ==Promiscuous = "Set the physical NIC to promiscuous mode" ==Promiscuous_Disable = "Disable" ==ServiceName = "hwusb_wwanecm" ==Promiscuous_Enable = "Enable" ==FrameType = "Frame Type in driver-device communications" ==FrameType_Ethernet = "Ethernet" ==FrameType_IP = "IP" == ==IsNtb32 = "32bit mode" ==NTBInputSize = "NTB input size" ==PacketsAccumulationTimeout = "Packets Accumulation Timeout [usec]" ==MaxNumOfDatagramsInNTB = "Maximum number of datagrams in NTB" ==FlowControlTimeout = "Flow Control timeout interval in ms" ==DisableAccumulationUpdate = "Flag to disable NCM accumulation auto ==updation" ==WwanMbimEnable = "Flag to enable WWAN MBIM function" ==NcmReinitializeEnable = "Flag to enable NCM reinitialize after resume" == ==Regards, ==Kevin == ==On 12/02/2014 03:45 PM, Eli Britstein wrote: ==> Outlook blocked the attachment. Please zip it and resend. ==> ==> Thanks, ==> Best regards, ==> ==> Eli Britstein ==> SW Team Leader and Project Manager ==> MP2xx Residential Gateways ==> ==> Tel: +972-3-9764148 ==> Mobile: +972-54-2312677 ==> Fax: +972-3-9764040 ==> Email: Eli.Britstein@audiocodes.com ==> Web: www.audiocodes.com ==> ==> ==> ==> -----Original Message----- ==> From: Kevin Zhu ==> Sent: Tuesday, December 02, 2014 9:44 ==> To: Enrico Mioso ==> Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org ==> Subject: Re: Is this 32-bit NCM? ==> ==> Hi all, ==> ==> Here's the registry from windows 7. Attached. One parameter that might be interesting is MaxNumOfDatagramInNTB, which is 64. I wonder if it has something to do with MaxDatagramSize. Can someone also check the registry, in case I missed something? ==> ==> Regards, ==> Kevin ==> ==> On 12/02/2014 02:49 PM, Enrico Mioso wrote: ==>> Can you try to look at Windows registry keys based on the INF file as ==>> suggested or would this be a problem for you? ==>> And... if you have any Huawei manutal talking about it: even device's ==>> ^DSFLOWRPT might be useful to some extent, but ... this is only just a ==>> note in case we don't find anything else. ==>> Regards ... and good day to all of you, Enrico ==>> ==>> ==>> On Tue, 2 Dec 2014, Kevin Zhu wrote: ==>> ==>> ==Date: Tue, 2 Dec 2014 07:43:24 ==>> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> ==>> ==To: Enrico Mioso <mrkiko.rs@gmail.com> ==>> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, Bjørn Mork <bjorn@mork.no>, ==>> == Alex Strizhevsky <alexxst@gmail.com>, ==>> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, ==>> == "youtux@gmail.com" <youtux@gmail.com>, ==>> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, ==>> == "netdev@vger.kernel.org" <netdev@vger.kernel.org> ==>> ==Subject: Re: Is this 32-bit NCM? ==>> == ==>> ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate ==>> the ==paddings, but it did not work either, not even DHCP. ==>> == ==>> ==Regards, ==>> ==Kevin ==>> == ==>> ==On 12/02/2014 02:32 PM, Enrico Mioso wrote: ==>> ==> Hi again Eli, ==>> ==> Hi Kevin, ==>> ==> Hi everyone... ==>> ==> ==>> ==> As I understand it anyway - the distinction here tends not to be ==>> between ==> different types of packets. ==>> ==> It tends to be between received and sent packet. ==>> ==> We are not able to generate packets that the device retains valid. ==>> ==> If you manually configure the IP the device would have assigned ==>> you via DHCP, ==> your system will start answering ARP request, saying ==>> that the host with IP ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle). ==>> ==> However, the other host (gateway) will never know that. Indeed, ==>> it'll continue ==> asking who-is at aa.bb.cc.dd ? ==>> ==> At least, this is the situation I observed in the test system. ==>> ==> ==>> ==> ==>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: ==>> ==> ==>> ==> ==Date: Tue, 2 Dec 2014 04:53:53 ==>> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> ==> ==To: Eli ==>> Britstein <Eli.Britstein@audiocodes.com>, ==>> ==> == Enrico Mioso <mrkiko.rs@gmail.com> ==>> ==> ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>, ==>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, ==>> ==> == "youtux@gmail.com" <youtux@gmail.com>, ==>> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, ==>> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org> ==>> ==> ==Subject: Re: Is this 32-bit NCM? ==>> ==> == ==>> ==> ==Hi, ==>> ==> == ==>> ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384, ==>> while ==> ==the other packets are less than that. However, the DHCP ==>> queries are not ==> ==replied in time either, there's always some delay. ==>> ==> == ==>> ==> ==By the way, though the device claims to support ==>> GET_MAX_DATAGRAM_SIZE, ==> ==but it returns error when the host sends ==>> this command to it. I disabled ==> ==this command in NCM driver and tried, but it's the same result. ==>> ==> == ==>> ==> ==Regards, ==>> ==> ==Kevin ==>> ==> == ==>> ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote: ==>> ==> ==> Hi Enrico and all, ==>> ==> ==> ==>> ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)? ==>> ==> ==> Maybe we can trace to compare them? ==>> ==> ==> ==>> ==> ==> Sent from my iPhone ==>> ==> ==> ==>> ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote: ==>> ==> ==>> ==>> ==> ==>> So ... I have two ideas left for now. ==>> ==> ==>> We know for sure the problem is in the way we TX frames, not ==>> the way we RX them ==> ==>> (the way we send, generate them, not the way we receive them). ==>> ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb ==>> mailing list for ==> ==>> this first one. ==>> ==> ==>> ==>> ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture? ==>> ==> ==>> We might try to take the usb frames generated by Windows, and ==>> send them to the ==> ==>> device to see if there is any reaction. It ==>> should not be science fiction, I saw ==> ==>> them do that in the eciadsl old project. ==>> ==> ==>> 2 - The huawei ndis driver: does it work with these devices? ==>> ==> ==>> It should be a little bit out-dated now (at least in terms of ==>> dates, it might ==> ==>> work as well): the code is A LOT but, just in ==>> case, to see if there is any ==> ==>> chances it'll work. It remains ==>> to be seen in which kernels it can actually ==> ==>> compile again. ==>> ==> ==>> ==>> ==> ==>> If this works we might analyse what's happening and try to debug this out. ==>> ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm. ==>> ==> ==>> Thank you. ==>> ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. ==>> ==> == ==>> ==> ==If you have received this email in error please immediately ==>> notify the sender and delete or destroy any copy of this message ==> ==>> == ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. ==>> == ==>> ==If you have received this email in error please immediately notify ==>> the sender and delete or destroy any copy of this message == ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. == ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message == ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? 2014-12-02 10:32 ` Enrico Mioso @ 2014-12-02 11:21 ` Bjørn Mork 2014-12-02 13:11 ` Enrico Mioso 0 siblings, 1 reply; 21+ messages in thread From: Bjørn Mork @ 2014-12-02 11:21 UTC (permalink / raw) To: Enrico Mioso Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev Enrico Mioso <mrkiko.rs@gmail.com> writes: > Kevin - it works! the key seems to be in the tx_fixup function; there is a > special handling for frames effectively. > Please ... help me backport those changes to the standard Linux driver - it > will be a gain for us all, and in general you'll have a more probable > maintenance than you would with the driver from huawei. Very interesting. The NCM code in the huawei driver has a different origin, so it is quite different and not too easy to merge into the existing Linux cdc_ncm driver. But this does pinpoint differences we should explore. One is the placement of the NDP: The Huawei driver puts it at the end. Another, which is much easier to test out quickly, is the sequence numbering: The Huawei driver doesn't use it. So I wonder if this makes any difference: diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c index 80a844e0ae03..37f11770acb6 100644 --- a/drivers/net/usb/cdc_ncm.c +++ b/drivers/net/usb/cdc_ncm.c @@ -1049,7 +1049,7 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) nth16 = (struct usb_cdc_ncm_nth16 *)memset(skb_put(skb_out, sizeof(struct usb_cdc_ncm_nth16)), 0, sizeof(struct usb_cdc_ncm_nth16)); nth16->dwSignature = cpu_to_le32(USB_CDC_NCM_NTH16_SIGN); nth16->wHeaderLength = cpu_to_le16(sizeof(struct usb_cdc_ncm_nth16)); - nth16->wSequence = cpu_to_le16(ctx->tx_seq++); +// nth16->wSequence = cpu_to_le16(ctx->tx_seq++); /* count total number of frames in this NTB */ ctx->tx_curr_frame_num = 0; Bjørn ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? 2014-12-02 11:21 ` Bjørn Mork @ 2014-12-02 13:11 ` Enrico Mioso 2014-12-02 13:37 ` Bjørn Mork 0 siblings, 1 reply; 21+ messages in thread From: Enrico Mioso @ 2014-12-02 13:11 UTC (permalink / raw) To: Bjørn Mork Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev [-- Attachment #1: Type: TEXT/PLAIN, Size: 2429 bytes --] ... but out of curiosity: are NCM specs allowing to change order of things in the package or not? This is not to start philosofical falames or something, but to understand better how things work. And, if they do: how much arbitrarily? On Tue, 2 Dec 2014, Bjørn Mork wrote: ==Date: Tue, 2 Dec 2014 12:21:18 ==From: Bjørn Mork <bjorn@mork.no> ==To: Enrico Mioso <mrkiko.rs@gmail.com> ==Cc: Kevin Zhu <Mingying.Zhu@audiocodes.com>, == Eli Britstein <Eli.Britstein@audiocodes.com>, == Alex Strizhevsky <alexxst@gmail.com>, == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, == "youtux@gmail.com" <youtux@gmail.com>, == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, == "netdev@vger.kernel.org" <netdev@vger.kernel.org> ==Subject: Re: Is this 32-bit NCM? == ==Enrico Mioso <mrkiko.rs@gmail.com> writes: == ==> Kevin - it works! the key seems to be in the tx_fixup function; there is a ==> special handling for frames effectively. ==> Please ... help me backport those changes to the standard Linux driver - it ==> will be a gain for us all, and in general you'll have a more probable ==> maintenance than you would with the driver from huawei. == ==Very interesting. The NCM code in the huawei driver has a different ==origin, so it is quite different and not too easy to merge into the ==existing Linux cdc_ncm driver. == ==But this does pinpoint differences we should explore. One is the ==placement of the NDP: The Huawei driver puts it at the end. Another, ==which is much easier to test out quickly, is the sequence numbering: The ==Huawei driver doesn't use it. == ==So I wonder if this makes any difference: == ==diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c ==index 80a844e0ae03..37f11770acb6 100644 ==--- a/drivers/net/usb/cdc_ncm.c ==+++ b/drivers/net/usb/cdc_ncm.c ==@@ -1049,7 +1049,7 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) == nth16 = (struct usb_cdc_ncm_nth16 *)memset(skb_put(skb_out, sizeof(struct usb_cdc_ncm_nth16)), 0, sizeof(struct usb_cdc_ncm_nth16)); == nth16->dwSignature = cpu_to_le32(USB_CDC_NCM_NTH16_SIGN); == nth16->wHeaderLength = cpu_to_le16(sizeof(struct usb_cdc_ncm_nth16)); ==- nth16->wSequence = cpu_to_le16(ctx->tx_seq++); ==+// nth16->wSequence = cpu_to_le16(ctx->tx_seq++); == == /* count total number of frames in this NTB */ == ctx->tx_curr_frame_num = 0; == == == ==Bjørn == ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? @ 2014-12-02 13:37 ` Bjørn Mork 2014-12-02 13:53 ` Enrico Mioso 0 siblings, 1 reply; 21+ messages in thread From: Bjørn Mork @ 2014-12-02 13:37 UTC (permalink / raw) To: Enrico Mioso Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux@gmail.com, linux-usb@vger.kernel.org, netdev@vger.kernel.org Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes: > ... but out of curiosity: are NCM specs allowing to change order of things in > the package or not? > This is not to start philosofical falames or something, but to understand > better how things work. And, if they do: how much arbitrarily? Only the NTB header has a fixed location. The rest can be anywhere and in any order. Quoting from section 3 Data Transport: "Within any given NTB, the NTH always must be first; but the other items may occur in arbitrary order." Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? @ 2014-12-02 13:53 ` Enrico Mioso 2014-12-02 15:04 ` Kevin Zhu 0 siblings, 1 reply; 21+ messages in thread From: Enrico Mioso @ 2014-12-02 13:53 UTC (permalink / raw) To: Bjørn Mork Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: TEXT/PLAIN, Size: 1490 bytes --] Thank you very much Bjorn. On Tue, 2 Dec 2014, Bjørn Mork wrote: ==Date: Tue, 2 Dec 2014 14:37:03 ==From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ==Cc: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, == Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> ==Subject: Re: Is this 32-bit NCM? == ==Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes: == ==> ... but out of curiosity: are NCM specs allowing to change order of things in ==> the package or not? ==> This is not to start philosofical falames or something, but to understand ==> better how things work. And, if they do: how much arbitrarily? == ==Only the NTB header has a fixed location. The rest can be anywhere and ==in any order. Quoting from section 3 Data Transport: == == "Within any given NTB, the NTH always must be first; but the other == items may occur in arbitrary order." == == ==Bjørn == ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? @ 2014-12-02 15:04 ` Kevin Zhu 2014-12-02 15:28 ` Enrico Mioso 0 siblings, 1 reply; 21+ messages in thread From: Kevin Zhu @ 2014-12-02 15:04 UTC (permalink / raw) To: Enrico Mioso, Bjørn Mork Cc: Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA I do not understand why the wSequence matters. By the way, I think I see some NDPs are right after NTH headers in the windows capture. ________________________________________ From: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Sent: Tuesday, December 2, 2014 21:53 To: Bjørn Mork Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: Is this 32-bit NCM? Thank you very much Bjorn. On Tue, 2 Dec 2014, Bjørn Mork wrote: ==Date: Tue, 2 Dec 2014 14:37:03 ==From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ==Cc: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, == Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> ==Subject: Re: Is this 32-bit NCM? == ==Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes: == ==> ... but out of curiosity: are NCM specs allowing to change order of things in ==> the package or not? ==> This is not to start philosofical falames or something, but to understand ==> better how things work. And, if they do: how much arbitrarily? == ==Only the NTB header has a fixed location. The rest can be anywhere and ==in any order. Quoting from section 3 Data Transport: == == "Within any given NTB, the NTH always must be first; but the other == items may occur in arbitrary order." == == ==Bjørn == This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? 2014-12-02 15:04 ` Kevin Zhu @ 2014-12-02 15:28 ` Enrico Mioso 2014-12-03 5:38 ` Kevin Zhu 0 siblings, 1 reply; 21+ messages in thread From: Enrico Mioso @ 2014-12-02 15:28 UTC (permalink / raw) To: Kevin Zhu Cc: Bjørn Mork, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev [-- Attachment #1: Type: TEXT/PLAIN, Size: 2923 bytes --] ... And what do you think about the source code of their ndis driver? We at least know now the device work with it, so we have something to mimic :D thank you for your work and patience Kevin. On Tue, 2 Dec 2014, Kevin Zhu wrote: ==Date: Tue, 2 Dec 2014 16:04:25 ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> ==To: Enrico Mioso <mrkiko.rs@gmail.com>, Bjørn Mork <bjorn@mork.no> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, == Alex Strizhevsky <alexxst@gmail.com>, == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, == "youtux@gmail.com" <youtux@gmail.com>, == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, == "netdev@vger.kernel.org" <netdev@vger.kernel.org> ==Subject: Re: Is this 32-bit NCM? == ==I do not understand why the wSequence matters. By the way, I think I see some NDPs are right after NTH headers in the windows capture. == ==________________________________________ ==From: Enrico Mioso <mrkiko.rs@gmail.com> ==Sent: Tuesday, December 2, 2014 21:53 ==To: Bjørn Mork ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org ==Subject: Re: Is this 32-bit NCM? == ==Thank you very much Bjorn. == == ==On Tue, 2 Dec 2014, Bjørn Mork wrote: == ====Date: Tue, 2 Dec 2014 14:37:03 ====From: Bjørn Mork <bjorn@mork.no> ====To: Enrico Mioso <mrkiko.rs@gmail.com> ====Cc: Kevin Zhu <Mingying.Zhu@audiocodes.com>, ==== Eli Britstein <Eli.Britstein@audiocodes.com>, ==== Alex Strizhevsky <alexxst@gmail.com>, ==== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, ==== "youtux@gmail.com" <youtux@gmail.com>, ==== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, ==== "netdev@vger.kernel.org" <netdev@vger.kernel.org> ====Subject: Re: Is this 32-bit NCM? ==== ====Enrico Mioso <mrkiko.rs@gmail.com> writes: ==== ====> ... but out of curiosity: are NCM specs allowing to change order of things in ====> the package or not? ====> This is not to start philosofical falames or something, but to understand ====> better how things work. And, if they do: how much arbitrarily? ==== ====Only the NTB header has a fixed location. The rest can be anywhere and ====in any order. Quoting from section 3 Data Transport: ==== ==== "Within any given NTB, the NTH always must be first; but the other ==== items may occur in arbitrary order." ==== ==== ====Bjørn ==== ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. == ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message == ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? @ 2014-12-03 5:38 ` Kevin Zhu 2014-12-03 6:00 ` Enrico Mioso 0 siblings, 1 reply; 21+ messages in thread From: Kevin Zhu @ 2014-12-03 5:38 UTC (permalink / raw) To: Enrico Mioso Cc: Bjørn Mork, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA My dongle also works with the huawei driver. I think only the 32bit format and NDP location matter. We may modify the TX function to put NTH and NDP at the beginning of a NTB and see if it will work with the driver cdc_ncm. Regards, Kevin On 12/02/2014 11:28 PM, Enrico Mioso wrote: > ... And what do you think about the source code of their ndis driver? > We at least know now the device work with it, so we have something to mimic :D > thank you for your work and patience Kevin. > > On Tue, 2 Dec 2014, Kevin Zhu wrote: > > ==Date: Tue, 2 Dec 2014 16:04:25 > ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> > ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Bjørn Mork <bjorn@mork.no> > ==Cc: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, > == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> > ==Subject: Re: Is this 32-bit NCM? > == > ==I do not understand why the wSequence matters. By the way, I think I see some NDPs are right after NTH headers in the windows capture. > == > ==________________________________________ > ==From: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > ==Sent: Tuesday, December 2, 2014 21:53 > ==To: Bjørn Mork > ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TaqPxH82wqD4g@public.gmane.orgg > ==Subject: Re: Is this 32-bit NCM? > == > ==Thank you very much Bjorn. > == > == > ==On Tue, 2 Dec 2014, Bjørn Mork wrote: > == > ====Date: Tue, 2 Dec 2014 14:37:03 > ====From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> > ====To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > ====Cc: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > ==== Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > ==== Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > ==== Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > ==== "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > ==== "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TaqPxH82wqD4g@public.gmane.orgg>, > ==== "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> > ====Subject: Re: Is this 32-bit NCM? > ==== > ====Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes: > ==== > ====> ... but out of curiosity: are NCM specs allowing to change order of things in > ====> the package or not? > ====> This is not to start philosofical falames or something, but to understand > ====> better how things work. And, if they do: how much arbitrarily? > ==== > ====Only the NTB header has a fixed location. The rest can be anywhere and > ====in any order. Quoting from section 3 Data Transport: > ==== > ==== "Within any given NTB, the NTH always must be first; but the other > ==== items may occur in arbitrary order." > ==== > ==== > ====Bjørn > ==== > ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. > == > ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message > == This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? 2014-12-03 5:38 ` Kevin Zhu @ 2014-12-03 6:00 ` Enrico Mioso 2014-12-03 6:05 ` Kevin Zhu 0 siblings, 1 reply; 21+ messages in thread From: Enrico Mioso @ 2014-12-03 6:00 UTC (permalink / raw) To: Kevin Zhu Cc: Bjørn Mork, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev [-- Attachment #1: Type: TEXT/PLAIN, Size: 4718 bytes --] Yes - I think this would be ok. You might try this with the 16-bit river first, and then with the 32-bit one to see how things work. I hope for the best. Let us all know, Enrico On Wed, 3 Dec 2014, Kevin Zhu wrote: ==Date: Wed, 3 Dec 2014 06:38:27 ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> ==To: Enrico Mioso <mrkiko.rs@gmail.com> ==Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein <Eli.Britstein@audiocodes.com>, == Alex Strizhevsky <alexxst@gmail.com>, == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, == "youtux@gmail.com" <youtux@gmail.com>, == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, == "netdev@vger.kernel.org" <netdev@vger.kernel.org> ==Subject: Re: Is this 32-bit NCM? == ==My dongle also works with the huawei driver. I think only the 32bit ==format and NDP location matter. We may modify the TX function to put NTH ==and NDP at the beginning of a NTB and see if it will work with the ==driver cdc_ncm. == ==Regards, ==Kevin == ==On 12/02/2014 11:28 PM, Enrico Mioso wrote: ==> ... And what do you think about the source code of their ndis driver? ==> We at least know now the device work with it, so we have something to mimic :D ==> thank you for your work and patience Kevin. ==> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: ==> ==> ==Date: Tue, 2 Dec 2014 16:04:25 ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> ==> ==To: Enrico Mioso <mrkiko.rs@gmail.com>, Bjørn Mork <bjorn@mork.no> ==> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, ==> == Alex Strizhevsky <alexxst@gmail.com>, ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, ==> == "youtux@gmail.com" <youtux@gmail.com>, ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org> ==> ==Subject: Re: Is this 32-bit NCM? ==> == ==> ==I do not understand why the wSequence matters. By the way, I think I see some NDPs are right after NTH headers in the windows capture. ==> == ==> ==________________________________________ ==> ==From: Enrico Mioso <mrkiko.rs@gmail.com> ==> ==Sent: Tuesday, December 2, 2014 21:53 ==> ==To: Bjørn Mork ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org ==> ==Subject: Re: Is this 32-bit NCM? ==> == ==> ==Thank you very much Bjorn. ==> == ==> == ==> ==On Tue, 2 Dec 2014, Bjørn Mork wrote: ==> == ==> ====Date: Tue, 2 Dec 2014 14:37:03 ==> ====From: Bjørn Mork <bjorn@mork.no> ==> ====To: Enrico Mioso <mrkiko.rs@gmail.com> ==> ====Cc: Kevin Zhu <Mingying.Zhu@audiocodes.com>, ==> ==== Eli Britstein <Eli.Britstein@audiocodes.com>, ==> ==== Alex Strizhevsky <alexxst@gmail.com>, ==> ==== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, ==> ==== "youtux@gmail.com" <youtux@gmail.com>, ==> ==== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, ==> ==== "netdev@vger.kernel.org" <netdev@vger.kernel.org> ==> ====Subject: Re: Is this 32-bit NCM? ==> ==== ==> ====Enrico Mioso <mrkiko.rs@gmail.com> writes: ==> ==== ==> ====> ... but out of curiosity: are NCM specs allowing to change order of things in ==> ====> the package or not? ==> ====> This is not to start philosofical falames or something, but to understand ==> ====> better how things work. And, if they do: how much arbitrarily? ==> ==== ==> ====Only the NTB header has a fixed location. The rest can be anywhere and ==> ====in any order. Quoting from section 3 Data Transport: ==> ==== ==> ==== "Within any given NTB, the NTH always must be first; but the other ==> ==== items may occur in arbitrary order." ==> ==== ==> ==== ==> ====Bjørn ==> ==== ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. ==> == ==> ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message ==> == ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. == ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message == ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM? @ 2014-12-03 6:05 ` Kevin Zhu 2014-12-04 6:31 ` Is this 32-bit NCM?y Enrico Mioso 0 siblings, 1 reply; 21+ messages in thread From: Kevin Zhu @ 2014-12-03 6:05 UTC (permalink / raw) To: Enrico Mioso Cc: Bjørn Mork, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA OK. I will. Thank you for everything! Regards, Kevin On 12/03/2014 02:00 PM, Enrico Mioso wrote: > Yes - I think this would be ok. You might try this with the 16-bit river first, > and then with the 32-bit one to see how things work. > I hope for the best. > Let us all know, > Enrico > > > On Wed, 3 Dec 2014, Kevin Zhu wrote: > > ==Date: Wed, 3 Dec 2014 06:38:27 > ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> > ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > ==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Eli Britstein <Eli.Britstein@audiocodes.com>, > == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, > == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> > ==Subject: Re: Is this 32-bit NCM? > == > ==My dongle also works with the huawei driver. I think only the 32bit > ==format and NDP location matter. We may modify the TX function to put NTH > ==and NDP at the beginning of a NTB and see if it will work with the > ==driver cdc_ncm. > == > ==Regards, > ==Kevin > == > ==On 12/02/2014 11:28 PM, Enrico Mioso wrote: > ==> ... And what do you think about the source code of their ndis driver? > ==> We at least know now the device work with it, so we have something to mimic :D > ==> thank you for your work and patience Kevin. > ==> > ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: > ==> > ==> ==Date: Tue, 2 Dec 2014 16:04:25 > ==> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> > ==> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> > ==> ==Cc: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > ==> == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > ==> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > ==> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > ==> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TasMV2rI37PzA@public.gmane.orgorg>, > ==> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> > ==> ==Subject: Re: Is this 32-bit NCM? > ==> == > ==> ==I do not understand why the wSequence matters. By the way, I think I see some NDPs are right after NTH headers in the windows capture. > ==> == > ==> ==________________________________________ > ==> ==From: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > ==> ==Sent: Tuesday, December 2, 2014 21:53 > ==> ==To: Bjørn Mork > ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev@vger.kernel.org > ==> ==Subject: Re: Is this 32-bit NCM? > ==> == > ==> ==Thank you very much Bjorn. > ==> == > ==> == > ==> ==On Tue, 2 Dec 2014, Bjørn Mork wrote: > ==> == > ==> ====Date: Tue, 2 Dec 2014 14:37:03 > ==> ====From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> > ==> ====To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > ==> ====Cc: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > ==> ==== Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > ==> ==== Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > ==> ==== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, > ==> ==== "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > ==> ==== "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb@vger.kernel.org>, > ==> ==== "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TasMV2rI37PzA@public.gmane.orgorg> > ==> ====Subject: Re: Is this 32-bit NCM? > ==> ==== > ==> ====Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes: > ==> ==== > ==> ====> ... but out of curiosity: are NCM specs allowing to change order of things in > ==> ====> the package or not? > ==> ====> This is not to start philosofical falames or something, but to understand > ==> ====> better how things work. And, if they do: how much arbitrarily? > ==> ==== > ==> ====Only the NTB header has a fixed location. The rest can be anywhere and > ==> ====in any order. Quoting from section 3 Data Transport: > ==> ==== > ==> ==== "Within any given NTB, the NTH always must be first; but the other > ==> ==== items may occur in arbitrary order." > ==> ==== > ==> ==== > ==> ====Bjørn > ==> ==== > ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. > ==> == > ==> ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message > ==> == > ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. > == > ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message > == This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM?y 2014-12-03 6:05 ` Kevin Zhu @ 2014-12-04 6:31 ` Enrico Mioso 2014-12-04 8:52 ` Kevin Zhu 0 siblings, 1 reply; 21+ messages in thread From: Enrico Mioso @ 2014-12-04 6:31 UTC (permalink / raw) To: Kevin Zhu Cc: Bjørn Mork, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev [-- Attachment #1: Type: TEXT/PLAIN, Size: 6251 bytes --] Hello guys! I am writing this message to hear if there is any progress, Enrico On Wed, 3 Dec 2014, Kevin Zhu wrote: > Date: Wed, 3 Dec 2014 07:05:37 > From: Kevin Zhu <Mingying.Zhu@audiocodes.com> > To: Enrico Mioso <mrkiko.rs@gmail.com> > Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein <Eli.Britstein@audiocodes.com>, > Alex Strizhevsky <alexxst@gmail.com>, > Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, > "youtux@gmail.com" <youtux@gmail.com>, > "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, > "netdev@vger.kernel.org" <netdev@vger.kernel.org> > Subject: Re: Is this 32-bit NCM? > > OK. I will. Thank you for everything! > > Regards, > Kevin > > On 12/03/2014 02:00 PM, Enrico Mioso wrote: >> Yes - I think this would be ok. You might try this with the 16-bit river first, >> and then with the 32-bit one to see how things work. >> I hope for the best. >> Let us all know, >> Enrico >> >> >> On Wed, 3 Dec 2014, Kevin Zhu wrote: >> >> ==Date: Wed, 3 Dec 2014 06:38:27 >> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> >> ==To: Enrico Mioso <mrkiko.rs@gmail.com> >> ==Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein <Eli.Britstein@audiocodes.com>, >> == Alex Strizhevsky <alexxst@gmail.com>, >> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, >> == "youtux@gmail.com" <youtux@gmail.com>, >> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, >> == "netdev@vger.kernel.org" <netdev@vger.kernel.org> >> ==Subject: Re: Is this 32-bit NCM? >> == >> ==My dongle also works with the huawei driver. I think only the 32bit >> ==format and NDP location matter. We may modify the TX function to put NTH >> ==and NDP at the beginning of a NTB and see if it will work with the >> ==driver cdc_ncm. >> == >> ==Regards, >> ==Kevin >> == >> ==On 12/02/2014 11:28 PM, Enrico Mioso wrote: >> ==> ... And what do you think about the source code of their ndis driver? >> ==> We at least know now the device work with it, so we have something to mimic :D >> ==> thank you for your work and patience Kevin. >> ==> >> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: >> ==> >> ==> ==Date: Tue, 2 Dec 2014 16:04:25 >> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> >> ==> ==To: Enrico Mioso <mrkiko.rs@gmail.com>, Bjørn Mork <bjorn@mork.no> >> ==> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, >> ==> == Alex Strizhevsky <alexxst@gmail.com>, >> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, >> ==> == "youtux@gmail.com" <youtux@gmail.com>, >> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, >> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org> >> ==> ==Subject: Re: Is this 32-bit NCM? >> ==> == >> ==> ==I do not understand why the wSequence matters. By the way, I think I see some NDPs are right after NTH headers in the windows capture. >> ==> == >> ==> ==________________________________________ >> ==> ==From: Enrico Mioso <mrkiko.rs@gmail.com> >> ==> ==Sent: Tuesday, December 2, 2014 21:53 >> ==> ==To: Bjørn Mork >> ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org >> ==> ==Subject: Re: Is this 32-bit NCM? >> ==> == >> ==> ==Thank you very much Bjorn. >> ==> == >> ==> == >> ==> ==On Tue, 2 Dec 2014, Bjørn Mork wrote: >> ==> == >> ==> ====Date: Tue, 2 Dec 2014 14:37:03 >> ==> ====From: Bjørn Mork <bjorn@mork.no> >> ==> ====To: Enrico Mioso <mrkiko.rs@gmail.com> >> ==> ====Cc: Kevin Zhu <Mingying.Zhu@audiocodes.com>, >> ==> ==== Eli Britstein <Eli.Britstein@audiocodes.com>, >> ==> ==== Alex Strizhevsky <alexxst@gmail.com>, >> ==> ==== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, >> ==> ==== "youtux@gmail.com" <youtux@gmail.com>, >> ==> ==== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, >> ==> ==== "netdev@vger.kernel.org" <netdev@vger.kernel.org> >> ==> ====Subject: Re: Is this 32-bit NCM? >> ==> ==== >> ==> ====Enrico Mioso <mrkiko.rs@gmail.com> writes: >> ==> ==== >> ==> ====> ... but out of curiosity: are NCM specs allowing to change order of things in >> ==> ====> the package or not? >> ==> ====> This is not to start philosofical falames or something, but to understand >> ==> ====> better how things work. And, if they do: how much arbitrarily? >> ==> ==== >> ==> ====Only the NTB header has a fixed location. The rest can be anywhere and >> ==> ====in any order. Quoting from section 3 Data Transport: >> ==> ==== >> ==> ==== "Within any given NTB, the NTH always must be first; but the other >> ==> ==== items may occur in arbitrary order." >> ==> ==== >> ==> ==== >> ==> ====Bjørn >> ==> ==== >> ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. >> ==> == >> ==> ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message >> ==> == >> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. >> == >> ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message >> == > This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. > > If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM?y 2014-12-04 6:31 ` Is this 32-bit NCM?y Enrico Mioso @ 2014-12-04 8:52 ` Kevin Zhu 2014-12-04 8:56 ` Enrico Mioso 2014-12-04 9:19 ` Bjørn Mork 0 siblings, 2 replies; 21+ messages in thread From: Kevin Zhu @ 2014-12-04 8:52 UTC (permalink / raw) To: Enrico Mioso Cc: Bjørn Mork, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev Guys, After rearranging the padding, putting NCM0 right after NTH, and disable ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it begins to work, though there's still problem with DHCP. It's able to ping, though my Ubuntu network manage does not notice this network interface. So no DNS. I have to specify the network interface and IP in the ping command. The DHCP packet's size becomes a large one after the TX function, which is 16384, the maximum. And the dongle does not reply it in time. For now, I just simple rearrange the code to meet Huawei's alignment requirement. I think other devices may be different, regarding the 'offset' definition. We may need to handle it. And also need to double check if the code has bugs. Regards, Kevin On 12/04/2014 02:31 PM, Enrico Mioso wrote: > Hello guys! > I am writing this message to hear if there is any progress, > Enrico > > > On Wed, 3 Dec 2014, Kevin Zhu wrote: > >> Date: Wed, 3 Dec 2014 07:05:37 >> From: Kevin Zhu <Mingying.Zhu@audiocodes.com> >> To: Enrico Mioso <mrkiko.rs@gmail.com> >> Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein >> <Eli.Britstein@audiocodes.com>, >> Alex Strizhevsky <alexxst@gmail.com>, >> Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, >> "youtux@gmail.com" <youtux@gmail.com>, >> "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, >> "netdev@vger.kernel.org" <netdev@vger.kernel.org> >> Subject: Re: Is this 32-bit NCM? >> >> OK. I will. Thank you for everything! >> >> Regards, >> Kevin >> >> On 12/03/2014 02:00 PM, Enrico Mioso wrote: >>> Yes - I think this would be ok. You might try this with the 16-bit >>> river first, >>> and then with the 32-bit one to see how things work. >>> I hope for the best. >>> Let us all know, >>> Enrico >>> >>> >>> On Wed, 3 Dec 2014, Kevin Zhu wrote: >>> >>> ==Date: Wed, 3 Dec 2014 06:38:27 >>> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> >>> ==To: Enrico Mioso <mrkiko.rs@gmail.com> >>> ==Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein >>> <Eli.Britstein@audiocodes.com>, >>> == Alex Strizhevsky <alexxst@gmail.com>, >>> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, >>> == "youtux@gmail.com" <youtux@gmail.com>, >>> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, >>> == "netdev@vger.kernel.org" <netdev@vger.kernel.org> >>> ==Subject: Re: Is this 32-bit NCM? >>> == >>> ==My dongle also works with the huawei driver. I think only the 32bit >>> ==format and NDP location matter. We may modify the TX function to >>> put NTH >>> ==and NDP at the beginning of a NTB and see if it will work with the >>> ==driver cdc_ncm. >>> == >>> ==Regards, >>> ==Kevin >>> == >>> ==On 12/02/2014 11:28 PM, Enrico Mioso wrote: >>> ==> ... And what do you think about the source code of their ndis >>> driver? >>> ==> We at least know now the device work with it, so we have >>> something to mimic :D >>> ==> thank you for your work and patience Kevin. >>> ==> >>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: >>> ==> >>> ==> ==Date: Tue, 2 Dec 2014 16:04:25 >>> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> >>> ==> ==To: Enrico Mioso <mrkiko.rs@gmail.com>, Bjørn Mork >>> <bjorn@mork.no> >>> ==> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, >>> ==> == Alex Strizhevsky <alexxst@gmail.com>, >>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, >>> ==> == "youtux@gmail.com" <youtux@gmail.com>, >>> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, >>> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org> >>> ==> ==Subject: Re: Is this 32-bit NCM? >>> ==> == >>> ==> ==I do not understand why the wSequence matters. By the way, I >>> think I see some NDPs are right after NTH headers in the windows >>> capture. >>> ==> == >>> ==> ==________________________________________ >>> ==> ==From: Enrico Mioso <mrkiko.rs@gmail.com> >>> ==> ==Sent: Tuesday, December 2, 2014 21:53 >>> ==> ==To: Bjørn Mork >>> ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun >>> Tan; youtux@gmail.com; linux-usb@vger.kernel.org; >>> netdev@vger.kernel.org >>> ==> ==Subject: Re: Is this 32-bit NCM? >>> ==> == >>> ==> ==Thank you very much Bjorn. >>> ==> == >>> ==> == >>> ==> ==On Tue, 2 Dec 2014, Bjørn Mork wrote: >>> ==> == >>> ==> ====Date: Tue, 2 Dec 2014 14:37:03 >>> ==> ====From: Bjørn Mork <bjorn@mork.no> >>> ==> ====To: Enrico Mioso <mrkiko.rs@gmail.com> >>> ==> ====Cc: Kevin Zhu <Mingying.Zhu@audiocodes.com>, >>> ==> ==== Eli Britstein <Eli.Britstein@audiocodes.com>, >>> ==> ==== Alex Strizhevsky <alexxst@gmail.com>, >>> ==> ==== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, >>> ==> ==== "youtux@gmail.com" <youtux@gmail.com>, >>> ==> ==== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, >>> ==> ==== "netdev@vger.kernel.org" <netdev@vger.kernel.org> >>> ==> ====Subject: Re: Is this 32-bit NCM? >>> ==> ==== >>> ==> ====Enrico Mioso <mrkiko.rs@gmail.com> writes: >>> ==> ==== >>> ==> ====> ... but out of curiosity: are NCM specs allowing to change >>> order of things in >>> ==> ====> the package or not? >>> ==> ====> This is not to start philosofical falames or something, >>> but to understand >>> ==> ====> better how things work. And, if they do: how much >>> arbitrarily? >>> ==> ==== >>> ==> ====Only the NTB header has a fixed location. The rest can be >>> anywhere and >>> ==> ====in any order. Quoting from section 3 Data Transport: >>> ==> ==== >>> ==> ==== "Within any given NTB, the NTH always must be first; but >>> the other >>> ==> ==== items may occur in arbitrary order." >>> ==> ==== >>> ==> ==== >>> ==> ====Bjørn >>> ==> ==== >>> ==> ==This email and any files transmitted with it are confidential >>> material. They are intended solely for the use of the designated >>> individual or entity to whom they are addressed. If the reader of >>> this message is not the intended recipient, you are hereby notified >>> that any dissemination, use, distribution or copying of this >>> communication is strictly prohibited and may be unlawful. >>> ==> == >>> ==> ==If you have received this email in error please immediately >>> notify the sender and delete or destroy any copy of this message >>> ==> == >>> ==This email and any files transmitted with it are confidential >>> material. They are intended solely for the use of the designated >>> individual or entity to whom they are addressed. If the reader of >>> this message is not the intended recipient, you are hereby notified >>> that any dissemination, use, distribution or copying of this >>> communication is strictly prohibited and may be unlawful. >>> == >>> ==If you have received this email in error please immediately notify >>> the sender and delete or destroy any copy of this message >>> == >> This email and any files transmitted with it are confidential >> material. They are intended solely for the use of the designated >> individual or entity to whom they are addressed. If the reader of >> this message is not the intended recipient, you are hereby notified >> that any dissemination, use, distribution or copying of this >> communication is strictly prohibited and may be unlawful. >> >> If you have received this email in error please immediately notify >> the sender and delete or destroy any copy of this message >> This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM?y 2014-12-04 8:52 ` Kevin Zhu @ 2014-12-04 8:56 ` Enrico Mioso [not found] ` <alpine.LNX.2.03.1412040955140.3516-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2014-12-04 9:19 ` Bjørn Mork 1 sibling, 1 reply; 21+ messages in thread From: Enrico Mioso @ 2014-12-04 8:56 UTC (permalink / raw) To: Kevin Zhu Cc: Bjørn Mork, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev [-- Attachment #1: Type: TEXT/PLAIN, Size: 8746 bytes --] Hi Kevin. Thank you for your hints and work. Only a note - why disabling ARP? I think it could be a good iea... or does the hw_cdc_driver do that? thank you again, Enrico On Thu, 4 Dec 2014, Kevin Zhu wrote: > Date: Thu, 4 Dec 2014 09:52:49 > From: Kevin Zhu <Mingying.Zhu@audiocodes.com> > To: Enrico Mioso <mrkiko.rs@gmail.com> > Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein <Eli.Britstein@audiocodes.com>, > Alex Strizhevsky <alexxst@gmail.com>, > Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, > "youtux@gmail.com" <youtux@gmail.com>, > "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, > "netdev@vger.kernel.org" <netdev@vger.kernel.org> > Subject: Re: Is this 32-bit NCM?y > > Guys, > > After rearranging the padding, putting NCM0 right after NTH, and disable > ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it > begins to work, though there's still problem with DHCP. It's able to > ping, though my Ubuntu network manage does not notice this network > interface. So no DNS. > > I have to specify the network interface and IP in the ping command. > > The DHCP packet's size becomes a large one after the TX function, which > is 16384, the maximum. And the dongle does not reply it in time. For > now, I just simple rearrange the code to meet Huawei's alignment > requirement. I think other devices may be different, regarding the > 'offset' definition. We may need to handle it. And also need to double > check if the code has bugs. > > Regards, > Kevin > > On 12/04/2014 02:31 PM, Enrico Mioso wrote: >> Hello guys! >> I am writing this message to hear if there is any progress, >> Enrico >> >> >> On Wed, 3 Dec 2014, Kevin Zhu wrote: >> >>> Date: Wed, 3 Dec 2014 07:05:37 >>> From: Kevin Zhu <Mingying.Zhu@audiocodes.com> >>> To: Enrico Mioso <mrkiko.rs@gmail.com> >>> Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein >>> <Eli.Britstein@audiocodes.com>, >>> Alex Strizhevsky <alexxst@gmail.com>, >>> Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, >>> "youtux@gmail.com" <youtux@gmail.com>, >>> "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, >>> "netdev@vger.kernel.org" <netdev@vger.kernel.org> >>> Subject: Re: Is this 32-bit NCM? >>> >>> OK. I will. Thank you for everything! >>> >>> Regards, >>> Kevin >>> >>> On 12/03/2014 02:00 PM, Enrico Mioso wrote: >>>> Yes - I think this would be ok. You might try this with the 16-bit >>>> river first, >>>> and then with the 32-bit one to see how things work. >>>> I hope for the best. >>>> Let us all know, >>>> Enrico >>>> >>>> >>>> On Wed, 3 Dec 2014, Kevin Zhu wrote: >>>> >>>> ==Date: Wed, 3 Dec 2014 06:38:27 >>>> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> >>>> ==To: Enrico Mioso <mrkiko.rs@gmail.com> >>>> ==Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein >>>> <Eli.Britstein@audiocodes.com>, >>>> == Alex Strizhevsky <alexxst@gmail.com>, >>>> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, >>>> == "youtux@gmail.com" <youtux@gmail.com>, >>>> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, >>>> == "netdev@vger.kernel.org" <netdev@vger.kernel.org> >>>> ==Subject: Re: Is this 32-bit NCM? >>>> == >>>> ==My dongle also works with the huawei driver. I think only the 32bit >>>> ==format and NDP location matter. We may modify the TX function to >>>> put NTH >>>> ==and NDP at the beginning of a NTB and see if it will work with the >>>> ==driver cdc_ncm. >>>> == >>>> ==Regards, >>>> ==Kevin >>>> == >>>> ==On 12/02/2014 11:28 PM, Enrico Mioso wrote: >>>> ==> ... And what do you think about the source code of their ndis >>>> driver? >>>> ==> We at least know now the device work with it, so we have >>>> something to mimic :D >>>> ==> thank you for your work and patience Kevin. >>>> ==> >>>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: >>>> ==> >>>> ==> ==Date: Tue, 2 Dec 2014 16:04:25 >>>> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> >>>> ==> ==To: Enrico Mioso <mrkiko.rs@gmail.com>, Bjørn Mork >>>> <bjorn@mork.no> >>>> ==> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, >>>> ==> == Alex Strizhevsky <alexxst@gmail.com>, >>>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, >>>> ==> == "youtux@gmail.com" <youtux@gmail.com>, >>>> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, >>>> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org> >>>> ==> ==Subject: Re: Is this 32-bit NCM? >>>> ==> == >>>> ==> ==I do not understand why the wSequence matters. By the way, I >>>> think I see some NDPs are right after NTH headers in the windows >>>> capture. >>>> ==> == >>>> ==> ==________________________________________ >>>> ==> ==From: Enrico Mioso <mrkiko.rs@gmail.com> >>>> ==> ==Sent: Tuesday, December 2, 2014 21:53 >>>> ==> ==To: Bjørn Mork >>>> ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun >>>> Tan; youtux@gmail.com; linux-usb@vger.kernel.org; >>>> netdev@vger.kernel.org >>>> ==> ==Subject: Re: Is this 32-bit NCM? >>>> ==> == >>>> ==> ==Thank you very much Bjorn. >>>> ==> == >>>> ==> == >>>> ==> ==On Tue, 2 Dec 2014, Bjørn Mork wrote: >>>> ==> == >>>> ==> ====Date: Tue, 2 Dec 2014 14:37:03 >>>> ==> ====From: Bjørn Mork <bjorn@mork.no> >>>> ==> ====To: Enrico Mioso <mrkiko.rs@gmail.com> >>>> ==> ====Cc: Kevin Zhu <Mingying.Zhu@audiocodes.com>, >>>> ==> ==== Eli Britstein <Eli.Britstein@audiocodes.com>, >>>> ==> ==== Alex Strizhevsky <alexxst@gmail.com>, >>>> ==> ==== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, >>>> ==> ==== "youtux@gmail.com" <youtux@gmail.com>, >>>> ==> ==== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, >>>> ==> ==== "netdev@vger.kernel.org" <netdev@vger.kernel.org> >>>> ==> ====Subject: Re: Is this 32-bit NCM? >>>> ==> ==== >>>> ==> ====Enrico Mioso <mrkiko.rs@gmail.com> writes: >>>> ==> ==== >>>> ==> ====> ... but out of curiosity: are NCM specs allowing to change >>>> order of things in >>>> ==> ====> the package or not? >>>> ==> ====> This is not to start philosofical falames or something, >>>> but to understand >>>> ==> ====> better how things work. And, if they do: how much >>>> arbitrarily? >>>> ==> ==== >>>> ==> ====Only the NTB header has a fixed location. The rest can be >>>> anywhere and >>>> ==> ====in any order. Quoting from section 3 Data Transport: >>>> ==> ==== >>>> ==> ==== "Within any given NTB, the NTH always must be first; but >>>> the other >>>> ==> ==== items may occur in arbitrary order." >>>> ==> ==== >>>> ==> ==== >>>> ==> ====Bjørn >>>> ==> ==== >>>> ==> ==This email and any files transmitted with it are confidential >>>> material. They are intended solely for the use of the designated >>>> individual or entity to whom they are addressed. If the reader of >>>> this message is not the intended recipient, you are hereby notified >>>> that any dissemination, use, distribution or copying of this >>>> communication is strictly prohibited and may be unlawful. >>>> ==> == >>>> ==> ==If you have received this email in error please immediately >>>> notify the sender and delete or destroy any copy of this message >>>> ==> == >>>> ==This email and any files transmitted with it are confidential >>>> material. They are intended solely for the use of the designated >>>> individual or entity to whom they are addressed. If the reader of >>>> this message is not the intended recipient, you are hereby notified >>>> that any dissemination, use, distribution or copying of this >>>> communication is strictly prohibited and may be unlawful. >>>> == >>>> ==If you have received this email in error please immediately notify >>>> the sender and delete or destroy any copy of this message >>>> == >>> This email and any files transmitted with it are confidential >>> material. They are intended solely for the use of the designated >>> individual or entity to whom they are addressed. If the reader of >>> this message is not the intended recipient, you are hereby notified >>> that any dissemination, use, distribution or copying of this >>> communication is strictly prohibited and may be unlawful. >>> >>> If you have received this email in error please immediately notify >>> the sender and delete or destroy any copy of this message >>> > This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. > > If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message > ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <alpine.LNX.2.03.1412040955140.3516-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: Is this 32-bit NCM?y [not found] ` <alpine.LNX.2.03.1412040955140.3516-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2014-12-04 9:01 ` Kevin Zhu 0 siblings, 0 replies; 21+ messages in thread From: Kevin Zhu @ 2014-12-04 9:01 UTC (permalink / raw) To: Enrico Mioso Cc: Bjørn Mork, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA It looks windows disable it, so I just follow it. Maybe enabling it will be also OK. I have not tried. I do not find it in hw_cdc_driver. Regards, Kevin On 12/04/2014 04:56 PM, Enrico Mioso wrote: > Hi Kevin. > Thank you for your hints and work. > Only a note - why disabling ARP? I think it could be a good iea... or > does the hw_cdc_driver do that? > thank you again, > Enrico > > > > On Thu, 4 Dec 2014, Kevin Zhu wrote: > >> Date: Thu, 4 Dec 2014 09:52:49 >> From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> >> To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >> Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Eli Britstein >> <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, >> Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, >> Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, >> "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, >> "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, >> "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> >> Subject: Re: Is this 32-bit NCM?y >> >> Guys, >> >> After rearranging the padding, putting NCM0 right after NTH, and disable >> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it >> begins to work, though there's still problem with DHCP. It's able to >> ping, though my Ubuntu network manage does not notice this network >> interface. So no DNS. >> >> I have to specify the network interface and IP in the ping command. >> >> The DHCP packet's size becomes a large one after the TX function, which >> is 16384, the maximum. And the dongle does not reply it in time. For >> now, I just simple rearrange the code to meet Huawei's alignment >> requirement. I think other devices may be different, regarding the >> 'offset' definition. We may need to handle it. And also need to double >> check if the code has bugs. >> >> Regards, >> Kevin >> >> On 12/04/2014 02:31 PM, Enrico Mioso wrote: >>> Hello guys! >>> I am writing this message to hear if there is any progress, >>> Enrico >>> >>> >>> On Wed, 3 Dec 2014, Kevin Zhu wrote: >>> >>>> Date: Wed, 3 Dec 2014 07:05:37 >>>> From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> >>>> To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >>>> Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Eli Britstein >>>> <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, >>>> Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, >>>> Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, >>>> "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, >>>> "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, >>>> "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> >>>> Subject: Re: Is this 32-bit NCM? >>>> >>>> OK. I will. Thank you for everything! >>>> >>>> Regards, >>>> Kevin >>>> >>>> On 12/03/2014 02:00 PM, Enrico Mioso wrote: >>>>> Yes - I think this would be ok. You might try this with the 16-bit >>>>> river first, >>>>> and then with the 32-bit one to see how things work. >>>>> I hope for the best. >>>>> Let us all know, >>>>> Enrico >>>>> >>>>> >>>>> On Wed, 3 Dec 2014, Kevin Zhu wrote: >>>>> >>>>> ==Date: Wed, 3 Dec 2014 06:38:27 >>>>> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> >>>>> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >>>>> ==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Eli Britstein >>>>> <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, >>>>> == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, >>>>> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, >>>>> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, >>>>> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, >>>>> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> >>>>> ==Subject: Re: Is this 32-bit NCM? >>>>> == >>>>> ==My dongle also works with the huawei driver. I think only the 32bit >>>>> ==format and NDP location matter. We may modify the TX function to >>>>> put NTH >>>>> ==and NDP at the beginning of a NTB and see if it will work with the >>>>> ==driver cdc_ncm. >>>>> == >>>>> ==Regards, >>>>> ==Kevin >>>>> == >>>>> ==On 12/02/2014 11:28 PM, Enrico Mioso wrote: >>>>> ==> ... And what do you think about the source code of their ndis >>>>> driver? >>>>> ==> We at least know now the device work with it, so we have >>>>> something to mimic :D >>>>> ==> thank you for your work and patience Kevin. >>>>> ==> >>>>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: >>>>> ==> >>>>> ==> ==Date: Tue, 2 Dec 2014 16:04:25 >>>>> ==> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> >>>>> ==> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Bjørn Mork >>>>> <bjorn-yOkvZcmFvRU@public.gmane.org> >>>>> ==> ==Cc: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, >>>>> ==> == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, >>>>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, >>>>> ==> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, >>>>> ==> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY@public.gmane.orgnel.org>, >>>>> ==> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TaqPxH82wqD4g@public.gmane.orgg> >>>>> ==> ==Subject: Re: Is this 32-bit NCM? >>>>> ==> == >>>>> ==> ==I do not understand why the wSequence matters. By the way, I >>>>> think I see some NDPs are right after NTH headers in the windows >>>>> capture. >>>>> ==> == >>>>> ==> ==________________________________________ >>>>> ==> ==From: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >>>>> ==> ==Sent: Tuesday, December 2, 2014 21:53 >>>>> ==> ==To: Bjørn Mork >>>>> ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun >>>>> Tan; youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; >>>>> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org >>>>> ==> ==Subject: Re: Is this 32-bit NCM? >>>>> ==> == >>>>> ==> ==Thank you very much Bjorn. >>>>> ==> == >>>>> ==> == >>>>> ==> ==On Tue, 2 Dec 2014, Bjørn Mork wrote: >>>>> ==> == >>>>> ==> ====Date: Tue, 2 Dec 2014 14:37:03 >>>>> ==> ====From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> >>>>> ==> ====To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >>>>> ==> ====Cc: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, >>>>> ==> ==== Eli Britstein <Eli.Britstein@audiocodes.com>, >>>>> ==> ==== Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, >>>>> ==> ==== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, >>>>> ==> ==== "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, >>>>> ==> ==== "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb@vger.kernel.org>, >>>>> ==> ==== "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY@public.gmane.orgnel.org> >>>>> ==> ====Subject: Re: Is this 32-bit NCM? >>>>> ==> ==== >>>>> ==> ====Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes: >>>>> ==> ==== >>>>> ==> ====> ... but out of curiosity: are NCM specs allowing to change >>>>> order of things in >>>>> ==> ====> the package or not? >>>>> ==> ====> This is not to start philosofical falames or something, >>>>> but to understand >>>>> ==> ====> better how things work. And, if they do: how much >>>>> arbitrarily? >>>>> ==> ==== >>>>> ==> ====Only the NTB header has a fixed location. The rest can be >>>>> anywhere and >>>>> ==> ====in any order. Quoting from section 3 Data Transport: >>>>> ==> ==== >>>>> ==> ==== "Within any given NTB, the NTH always must be first; but >>>>> the other >>>>> ==> ==== items may occur in arbitrary order." >>>>> ==> ==== >>>>> ==> ==== >>>>> ==> ====Bjørn >>>>> ==> ==== >>>>> ==> ==This email and any files transmitted with it are confidential >>>>> material. They are intended solely for the use of the designated >>>>> individual or entity to whom they are addressed. If the reader of >>>>> this message is not the intended recipient, you are hereby notified >>>>> that any dissemination, use, distribution or copying of this >>>>> communication is strictly prohibited and may be unlawful. >>>>> ==> == >>>>> ==> ==If you have received this email in error please immediately >>>>> notify the sender and delete or destroy any copy of this message >>>>> ==> == >>>>> ==This email and any files transmitted with it are confidential >>>>> material. They are intended solely for the use of the designated >>>>> individual or entity to whom they are addressed. If the reader of >>>>> this message is not the intended recipient, you are hereby notified >>>>> that any dissemination, use, distribution or copying of this >>>>> communication is strictly prohibited and may be unlawful. >>>>> == >>>>> ==If you have received this email in error please immediately notify >>>>> the sender and delete or destroy any copy of this message >>>>> == >>>> This email and any files transmitted with it are confidential >>>> material. They are intended solely for the use of the designated >>>> individual or entity to whom they are addressed. If the reader of >>>> this message is not the intended recipient, you are hereby notified >>>> that any dissemination, use, distribution or copying of this >>>> communication is strictly prohibited and may be unlawful. >>>> >>>> If you have received this email in error please immediately notify >>>> the sender and delete or destroy any copy of this message >>>> >> This email and any files transmitted with it are confidential >> material. They are intended solely for the use of the designated >> individual or entity to whom they are addressed. If the reader of >> this message is not the intended recipient, you are hereby notified >> that any dissemination, use, distribution or copying of this >> communication is strictly prohibited and may be unlawful. >> >> If you have received this email in error please immediately notify >> the sender and delete or destroy any copy of this message >> This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM?y 2014-12-04 8:52 ` Kevin Zhu 2014-12-04 8:56 ` Enrico Mioso @ 2014-12-04 9:19 ` Bjørn Mork 2014-12-04 9:26 ` Kevin Zhu 2014-12-04 9:53 ` Enrico Mioso 1 sibling, 2 replies; 21+ messages in thread From: Bjørn Mork @ 2014-12-04 9:19 UTC (permalink / raw) To: Kevin Zhu Cc: Enrico Mioso, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev Kevin Zhu <Mingying.Zhu@audiocodes.com> writes: > Guys, > > After rearranging the padding, putting NCM0 right after NTH, and disable > ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it > begins to work, though there's still problem with DHCP. Great! But it would be good to know if _one_ of these changes is enough to make it work. > The DHCP packet's size becomes a large one after the TX function, which > is 16384, the maximum. You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max. Something like this should do for a simple test: echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt Bjørn ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM?y 2014-12-04 9:19 ` Bjørn Mork @ 2014-12-04 9:26 ` Kevin Zhu [not found] ` <548028A0.5000909-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> 2014-12-04 9:55 ` Bjørn Mork 2014-12-04 9:53 ` Enrico Mioso 1 sibling, 2 replies; 21+ messages in thread From: Kevin Zhu @ 2014-12-04 9:26 UTC (permalink / raw) To: Bjørn Mork Cc: Enrico Mioso, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev I will find it out. And I don't have v3.16 and I'm not going to upgrade my OS to that. Sorry. So I would just stick to v3.13. Anyway, that size is wrong, it should be fixed. Regards, Kevin On 12/04/2014 05:19 PM, Bjørn Mork wrote: > Kevin Zhu <Mingying.Zhu@audiocodes.com> writes: > >> Guys, >> >> After rearranging the padding, putting NCM0 right after NTH, and disable >> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it >> begins to work, though there's still problem with DHCP. > Great! But it would be good to know if _one_ of these changes is enough > to make it work. > >> The DHCP packet's size becomes a large one after the TX function, which >> is 16384, the maximum. > You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max. > Something like this should do for a simple test: > > echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt > > > Bjørn This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <548028A0.5000909-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>]
* Re: Is this 32-bit NCM?y [not found] ` <548028A0.5000909-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> @ 2014-12-04 9:28 ` Enrico Mioso 0 siblings, 0 replies; 21+ messages in thread From: Enrico Mioso @ 2014-12-04 9:28 UTC (permalink / raw) To: Kevin Zhu Cc: Bjørn Mork, Enrico Mioso, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: TEXT/PLAIN, Size: 2567 bytes --] Ok - but... you can upgrade your OS to that without any effort - simply apt-get-installing the required linux-image-3.16 package plus the -extra package. It's nothing more in case. thank you kevin, thank you Bjorn. Enrico On Thu, 4 Dec 2014, Kevin Zhu wrote: > Date: Thu, 4 Dec 2014 10:26:20 > From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> > To: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> > Cc: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, > "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, > "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, > "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> > Subject: Re: Is this 32-bit NCM?y > > I will find it out. And I don't have v3.16 and I'm not going to upgrade > my OS to that. Sorry. So I would just stick to v3.13. Anyway, that size > is wrong, it should be fixed. > > Regards, > Kevin > > On 12/04/2014 05:19 PM, Bjørn Mork wrote: >> Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> writes: >> >>> Guys, >>> >>> After rearranging the padding, putting NCM0 right after NTH, and disable >>> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it >>> begins to work, though there's still problem with DHCP. >> Great! But it would be good to know if _one_ of these changes is enough >> to make it work. >> >>> The DHCP packet's size becomes a large one after the TX function, which >>> is 16384, the maximum. >> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max. >> Something like this should do for a simple test: >> >> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt >> >> >> Bjørn > This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. > > If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM?y 2014-12-04 9:26 ` Kevin Zhu [not found] ` <548028A0.5000909-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> @ 2014-12-04 9:55 ` Bjørn Mork 1 sibling, 0 replies; 21+ messages in thread From: Bjørn Mork @ 2014-12-04 9:55 UTC (permalink / raw) To: Kevin Zhu Cc: Enrico Mioso, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev Kevin Zhu <Mingying.Zhu@audiocodes.com> writes: > I will find it out. And I don't have v3.16 and I'm not going to upgrade > my OS to that. Sorry. So I would just stick to v3.13. Ouch. well, OK. I certainly hope you are at v3.13.10 or newer at least. Otherwise we know very well what the problem is... One of the reasons for the series that went into v3.16 was making this sort of debugging easier, enabling on-the-fly NCM aggregation parameter tuning. I'd certainly recommend taking advantage of it instead of rebulding the driver every time you want to test the effect of some minor change to the aggregation scheme. And do feel free to add more knobs if you need them. Bjørn ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM?y 2014-12-04 9:19 ` Bjørn Mork 2014-12-04 9:26 ` Kevin Zhu @ 2014-12-04 9:53 ` Enrico Mioso 2014-12-04 10:02 ` Bjørn Mork 1 sibling, 1 reply; 21+ messages in thread From: Enrico Mioso @ 2014-12-04 9:53 UTC (permalink / raw) To: Bjørn Mork Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev [-- Attachment #1: Type: TEXT/PLAIN, Size: 1529 bytes --] Guys! Don't forget I can test it - since I have a remote machine with 3.16 kernel and the device, at least for now. So - Bjorn: do I need just to disable padding or do I need also to perform some other changes? I am sorry if I ask this a little bit stupidly, but I was alittle bit busy here. On Thu, 4 Dec 2014, Bjørn Mork wrote: > Date: Thu, 4 Dec 2014 10:19:11 > From: Bjørn Mork <bjorn@mork.no> > To: Kevin Zhu <Mingying.Zhu@audiocodes.com> > Cc: Enrico Mioso <mrkiko.rs@gmail.com>, > Eli Britstein <Eli.Britstein@audiocodes.com>, > Alex Strizhevsky <alexxst@gmail.com>, > Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>, > "youtux@gmail.com" <youtux@gmail.com>, > "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, > "netdev@vger.kernel.org" <netdev@vger.kernel.org> > Subject: Re: Is this 32-bit NCM?y > > Kevin Zhu <Mingying.Zhu@audiocodes.com> writes: > >> Guys, >> >> After rearranging the padding, putting NCM0 right after NTH, and disable >> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it >> begins to work, though there's still problem with DHCP. > > Great! But it would be good to know if _one_ of these changes is enough > to make it work. > >> The DHCP packet's size becomes a large one after the TX function, which >> is 16384, the maximum. > > You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max. > Something like this should do for a simple test: > > echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt > > > Bjørn > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Is this 32-bit NCM?y 2014-12-04 9:53 ` Enrico Mioso @ 2014-12-04 10:02 ` Bjørn Mork 0 siblings, 0 replies; 21+ messages in thread From: Bjørn Mork @ 2014-12-04 10:02 UTC (permalink / raw) To: Enrico Mioso Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan, youtux, linux-usb, netdev Enrico Mioso <mrkiko.rs@gmail.com> writes: > Guys! > Don't forget I can test it - since I have a remote machine with 3.16 > kernel and the device, at least for now. > So - Bjorn: do I need just to disable padding or do I need also to > perform some other changes? I am sorry if I ask this a little bit > stupidly, but I was alittle bit busy here. I don't know. I just mentioned it because it is easy to test, although the method isn't too obvious. Someone should document this somewhere. Hey, wait... Someone did :-) https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net-cdc_ncm Bjørn ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2015-01-19 16:51 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-12-04 10:10 Is this 32-bit NCM?y Midge Shaojun Tan [not found] ` <AMSPR06MB6011E001029C251790CB923EE780-MyG0ARRHH/drF+2gGhmTpL9PrO6axcR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org> 2014-12-04 10:24 ` Enrico Mioso 2014-12-04 10:33 ` Enrico Mioso 2014-12-04 11:44 ` Bjørn Mork 2014-12-04 12:17 ` Enrico Mioso [not found] ` <877fy7myfb.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org> 2014-12-04 12:28 ` Enrico Mioso [not found] ` <alpine.LNX.2.03.1412041326160.9926-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2014-12-05 2:20 ` Kevin Zhu [not found] ` <54811670.5030703-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> 2014-12-05 9:42 ` Bjørn Mork [not found] ` <8761dqjuuh.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org> 2014-12-05 9:59 ` Enrico Mioso 2014-12-28 14:53 ` refactoring cdc_ncm Enrico Mioso 2015-01-19 16:51 ` [discuss] [cdc_ncm] Refactoring cdc_ncm Enrico Mioso -- strict thread matches above, loose matches on Subject: below -- 2014-11-26 21:51 Is this 32-bit NCM? Enrico Mioso 2014-11-27 18:34 ` Enrico Mioso 2014-11-28 9:29 ` Bjørn Mork 2014-12-01 21:11 ` Enrico Mioso 2014-12-01 22:02 ` Eli Britstein 2014-12-02 3:53 ` Kevin Zhu 2014-12-02 6:32 ` Enrico Mioso 2014-12-02 6:43 ` Kevin Zhu 2014-12-02 6:49 ` Enrico Mioso 2014-12-02 7:44 ` Kevin Zhu 2014-12-02 7:45 ` Eli Britstein 2014-12-02 8:03 ` Kevin Zhu 2014-12-02 10:32 ` Enrico Mioso 2014-12-02 11:21 ` Bjørn Mork 2014-12-02 13:11 ` Enrico Mioso 2014-12-02 13:37 ` Bjørn Mork 2014-12-02 13:53 ` Enrico Mioso 2014-12-02 15:04 ` Kevin Zhu 2014-12-02 15:28 ` Enrico Mioso 2014-12-03 5:38 ` Kevin Zhu 2014-12-03 6:00 ` Enrico Mioso 2014-12-03 6:05 ` Kevin Zhu 2014-12-04 6:31 ` Is this 32-bit NCM?y Enrico Mioso 2014-12-04 8:52 ` Kevin Zhu 2014-12-04 8:56 ` Enrico Mioso [not found] ` <alpine.LNX.2.03.1412040955140.3516-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2014-12-04 9:01 ` Kevin Zhu 2014-12-04 9:19 ` Bjørn Mork 2014-12-04 9:26 ` Kevin Zhu [not found] ` <548028A0.5000909-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> 2014-12-04 9:28 ` Enrico Mioso 2014-12-04 9:55 ` Bjørn Mork 2014-12-04 9:53 ` Enrico Mioso 2014-12-04 10:02 ` Bjørn Mork
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.