netdev - Re: RMNET QMAP data aggregation with size greater than 16384

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: <77b850933d9af8ddbc21f5908ca0764d@codeaurora.org>
Date:   Thu, 05 Aug 2021 16:57:00 -0600
From:   subashab@...eaurora.org
To:     Aleksander Morgado <aleksander@...ksander.es>
Cc:     Bjørn Mork <bjorn@...k.no>,
        Daniele Palmas <dnlplm@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        stranche@...eaurora.org
Subject: Re: RMNET QMAP data aggregation with size greater than 16384

> I may be mistaken then in how this should be setup when using rmnet.
> For the qmi_wwan case using add_mux/del_mux (Daniele correct me if
> wrong!), we do need to configure the MTU of the master interface to be
> equal to the aggregation data size reported via QMI WDA before
> creating any mux link; see
> http://paldan.altervista.org/linux-qmap-qmi_wwan-multiple-pdn-setup/
> 
> I ended up doing the same here for the rmnet case; but if it's not
> needed I can definitely change that. I do recall that I originally had
> left the master MTU untouched in the rmnet case and users had issues,
> and increasing it to the aggregation size solved that; I assume that's
> because the MTU should have been increased to accommodate the extra
> MAP header as you said. How much more size does it need on top of the
> 1500 bytes?

You need to use an additional 4 bytes for MAPv1 and 8 bytes for 
MAPv4/v5.

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,
a Linux Foundation Collaborative Project