[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.03.1412041326160.9926@gmail.com>
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
>
>
Powered by blists - more mailing lists