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:   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

Powered by blists - more mailing lists