Re: Is this 32-bit NCM?y

Re: Is this 32-bit NCM?y

[Midge Shaojun Tan]

[-- 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 --]

Re: Is this 32-bit NCM?y

[Enrico Mioso]

[-- 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
>

Re: Is this 32-bit NCM?y

[Enrico Mioso]

... it works only applying cdc_ncm_modify.c; nothing else change. ARP works. Modesiwtch message not changed.

Re: Is this 32-bit NCM?y

[Bjørn Mork]

"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

Re: Is this 32-bit NCM?y

[Enrico Mioso]

[-- 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.

Re: Is this 32-bit NCM?y

[Enrico Mioso]

[-- 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
>
>

Re: Is this 32-bit NCM?y

[Kevin Zhu]

[-- 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Ç+‰·¥Š{±ºÆâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&¢îý»\x05ËÛÔØï¦v¬Îf\x1dp)¹¹br	šê+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹\x1e®w¥¢¸?™¨è­Ú&¢)ߢ^[f

Re: Is this 32-bit NCM?y

[Bjørn Mork]

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

Re: Is this 32-bit NCM?y

[Enrico Mioso]

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

refactoring cdc_ncm

[Enrico Mioso]

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

[discuss] [cdc_ncm] Refactoring cdc_ncm

[Enrico Mioso]

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

Re: Is this 32-bit NCM?y

[Bjørn Mork]

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

Re: Is this 32-bit NCM?y

[Bjørn Mork]

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

Re: Is this 32-bit NCM?y

[Enrico Mioso]

[-- 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
>

Re: Is this 32-bit NCM?y

[Enrico Mioso]

[-- 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
>

Re: Is this 32-bit NCM?y

[Kevin Zhu]

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

Re: Is this 32-bit NCM?y

[Bjørn Mork]

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

Re: Is this 32-bit NCM?y

[Kevin Zhu]

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

Re: Is this 32-bit NCM?y

[Enrico Mioso]

[-- 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
>

Re: Is this 32-bit NCM?y

[Kevin Zhu]

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

Re: Is this 32-bit NCM?y

[Enrico Mioso]

[-- 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
>