netdev - Re: [PATCH 1/1] net: usb: cdc_mbim: add flag FLAG_SEND

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]

Message-ID: <CAGRyCJFMh9j64UO7a8Lk7dc8YRk9CxC7xXE3ZuzHY5p_kYLgWQ@mail.gmail.com>
Date:   Thu, 31 May 2018 13:52:06 +0200
From:   Daniele Palmas <dnlplm@...il.com>
To:     Bjørn Mork <bjorn@...k.no>
Cc:     Oliver Neukum <oliver@...kum.org>, netdev@...r.kernel.org,
        linux-usb <linux-usb@...r.kernel.org>
Subject: Re: [PATCH 1/1] net: usb: cdc_mbim: add flag FLAG_SEND_ZLP

2018-05-31 11:56 GMT+02:00 Bjørn Mork <bjorn@...k.no>:
> Daniele Palmas <dnlplm@...il.com> writes:
>
>> Testing Telit LM940 with ICMP packets > 14552 bytes revealed that
>> the modem needs FLAG_SEND_ZLP to properly work, otherwise the cdc
>> mbim data interface won't be anymore responsive.
>>
>> Signed-off-by: Daniele Palmas <dnlplm@...il.com>
>
> Acked-by: Bjørn Mork <bjorn@...k.no>
>
> Should have thought of this... I noticed your discussion, but couldn't
> reproduce the issues myself.  This explains why.
>
> Do you happen to know if the device announces larger buffers than the
> driver wants to use, or if this happens with the max sized buffers too?
>
> You can easily check these values by comparing dwNtbInMaxSize and
> dwNtbOutMaxSize (device maximum values) with rx_max and tx_max
> (neogtiated values) using e.g
>
>  grep . /sys/class/net/wwan0/cdc_ncm/*
>

This seems to happen with the max sized buffers according to the output:

daniele@...22:/home/daniele$ grep . /sys/class/net/wwp0s20u6i2/cdc_ncm/*

/sys/class/net/wwp0s20u6i2/cdc_ncm/bmNtbFormatsSupported:0x0001
/sys/class/net/wwp0s20u6i2/cdc_ncm/dwNtbInMaxSize:16384
/sys/class/net/wwp0s20u6i2/cdc_ncm/dwNtbOutMaxSize:16384
/sys/class/net/wwp0s20u6i2/cdc_ncm/min_tx_pkt:13312
/sys/class/net/wwp0s20u6i2/cdc_ncm/ndp_to_end:N
/sys/class/net/wwp0s20u6i2/cdc_ncm/rx_max:16384
/sys/class/net/wwp0s20u6i2/cdc_ncm/tx_max:16384
/sys/class/net/wwp0s20u6i2/cdc_ncm/tx_timer_usecs:400
/sys/class/net/wwp0s20u6i2/cdc_ncm/wNdpInAlignment:4
/sys/class/net/wwp0s20u6i2/cdc_ncm/wNdpInDivisor:1
/sys/class/net/wwp0s20u6i2/cdc_ncm/wNdpInPayloadRemainder:0
/sys/class/net/wwp0s20u6i2/cdc_ncm/wNdpOutAlignment:4
/sys/class/net/wwp0s20u6i2/cdc_ncm/wNdpOutDivisor:4
/sys/class/net/wwp0s20u6i2/cdc_ncm/wNdpOutPayloadRemainder:0
/sys/class/net/wwp0s20u6i2/cdc_ncm/wNtbOutMaxDatagrams:16

Thanks,
Daniele

>
> It has never been 100% clear to me whether we should send the ZLP by
> default if we've negotiated a smaller than max buffer. But the ZLP ought
> to be redundant in any case, since the device knows the negotiated
> buffer size. So I do believe our current interpretation makes sense.
>
> Not that it matters.  There are obviously more than enough device
> implementations violating this requirement to make it completely
> pointless.
>
>
> Bjørn