netdev - Re: [PATCH net v2] net: usb: pegasus: Do not drop long Ethernet frames

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: <87aa9378-ac72-7221-6bf1-ee4d6ed2009d@mirix.org>
Date:   Sun, 2 Jan 2022 15:16:04 +0100
From:   Matthias-Christian Ott <ott@...ix.org>
To:     Petko Manolov <petkan@...leusys.com>
Cc:     linux-usb@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net v2] net: usb: pegasus: Do not drop long Ethernet
 frames

On 27/12/2021 12:11, Petko Manolov wrote:
> On 21-12-26 23:12:08, Matthias-Christian Ott wrote:
>> The D-Link DSB-650TX (2001:4002) is unable to receive Ethernet frames that are
>> longer than 1518 octets, for example, Ethernet frames that contain 802.1Q VLAN
>> tags.
>>
>> The frames are sent to the pegasus driver via USB but the driver discards them
>> because they have the Long_pkt field set to 1 in the received status report.
>> The function read_bulk_callback of the pegasus driver treats such received
>> "packets" (in the terminology of the hardware) as errors but the field simply
>> does just indicate that the Ethernet frame (MAC destination to FCS) is longer
>> than 1518 octets.
>>
>> It seems that in the 1990s there was a distinction between "giant" (> 1518)
>> and "runt" (< 64) frames and the hardware includes flags to indicate this
>> distinction. It seems that the purpose of the distinction "giant" frames was
>> to not allow infinitely long frames due to transmission errors and to allow
>> hardware to have an upper limit of the frame size. However, the hardware
>> already has such limit with its 2048 octet receive buffer and, therefore,
>> Long_pkt is merely a convention and should not be treated as a receive error.
>>
>> Actually, the hardware is even able to receive Ethernet frames with 2048
>> octets which exceeds the claimed limit frame size limit of the driver of 1536
>> octets (PEGASUS_MTU).
> 
> 2048 is not mentioned anywhere in both, adm8511 and adm8515 documents.  In the
> latter I found 1638 as max packet length, but that's not the default.  The
> default is 1528 and i don't feel like changing it without further investigation.

I can't remember where I found the number. I adapted the original bug
report that I wrote months ago for the commit message. I'm assuming that
the number comes from the size of the SRAM transmit buffer/TX FIFO. I
also remember that I did some experiments with the MTU to find out what
the hardware supports. However, I don't remember the results of these
experiments. So treat the 2048 as an unverified and perhaps wrong claim.
I will remove it a subsequent version of the patch.

The ADM8515/X datasheet states that the 2 KiB SRAM TX FIFO can hold 4
Ethernet frames which equals a MTU of 512 Octets and that the 24 KiB
SRAM RX FIFO can hold 16 Ethernet frames which equals a MTU of 1536
Octets. This somewhat contradicts the 1638 Octets from the same
datasheet. So it seems best to me find it out with an experiment.

> Thus, i assume it is safe to change PEGASUS_MTU to 1528 for the moment.  VLAN
> frames have 4 additional bytes so we aren't breaking neither pegasus I nor
> pegasus II devices.

Yes, this also not the subject or intent of the commit. I will remove
the sentence from the paragraph in a subsequent version of the patch.

Kind regards,
Matthias-Christian Ott