netdev - Re: Is this 32-bit NCM?y

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 4 Dec 2014 13:28:24 +0100 (CET)
From:	Enrico Mioso <mrkiko.rs@...il.com>
To:	Bjørn Mork <bjorn@...k.no>
cc:	Midge Shaojun Tan <ShaojunMidge.Tan@...iocodes.com>,
	Kevin Zhu <Mingying.Zhu@...iocodes.com>,
	Eli Britstein <Eli.Britstein@...iocodes.com>,
	Alex Strizhevsky <alexxst@...il.com>,
	"youtux@...il.com" <youtux@...il.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Is this 32-bit NCM?y

... 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@...k.no>
> To: Midge Shaojun Tan <ShaojunMidge.Tan@...iocodes.com>
> Cc: Enrico Mioso <mrkiko.rs@...il.com>,
>     Kevin Zhu <Mingying.Zhu@...iocodes.com>,
>     Eli Britstein <Eli.Britstein@...iocodes.com>,
>     Alex Strizhevsky <alexxst@...il.com>,
>     "youtux@...il.com" <youtux@...il.com>,
>     "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
>     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
> Subject: Re: Is this 32-bit NCM?y
> 
> "Midge Shaojun  Tan" <ShaojunMidge.Tan@...iocodes.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
>
>