summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorMatthias-Christian Ott <ott@mirix.org>2021-12-27 01:12:08 +0300
committerDavid S. Miller <davem@davemloft.net>2021-12-27 17:52:06 +0300
commitca506fca461b260ab32952b610c3d4aadc6c11fd (patch)
treefedfc3be53b74fb30c70463913e53663e5ba6af6 /include
parent5f50153288452e10b6edd69ec9112c49442b054a (diff)
downloadlinux-ca506fca461b260ab32952b610c3d4aadc6c11fd.tar.xz
net: usb: pegasus: Do not drop long Ethernet frames
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). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Matthias-Christian Ott <ott@mirix.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions