From: Stephen Hemminger <stephen@networkplumber.org>
To: netdev@vger.kernel.org
Subject: Fw: [Bug 109471] New: Linux generating invalid Ethernet frames which get dropped (as over-size) by gateway
Date: Wed, 16 Dec 2015 07:57:05 -0800 [thread overview]
Message-ID: <20151216075705.3dcfafa7@xeon-e3> (raw)
User error, but someone could help them out.
Begin forwarded message:
Date: Wed, 16 Dec 2015 15:47:16 +0000
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "shemminger@linux-foundation.org" <shemminger@linux-foundation.org>
Subject: [Bug 109471] New: Linux generating invalid Ethernet frames which get dropped (as over-size) by gateway
https://bugzilla.kernel.org/show_bug.cgi?id=109471
Bug ID: 109471
Summary: Linux generating invalid Ethernet frames which get
dropped (as over-size) by gateway
Product: Networking
Version: 2.5
Kernel Version: 3.18.11-v7+ #781 SMP PREEMPT armv7l GNU/Linux
Hardware: ARM
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: shemminger@linux-foundation.org
Reporter: linuxbrad@gmail.com
Regression: No
Also described in detail here:
http://networkengineering.stackexchange.com/questions/25254/1522-byte-frames-from-access-point-being-dropped-by-gateway
I configured the Linux device in question (Raspberry Pi 2b) as a hostap WIFI
access point. Wifi clients connect and can sometimes transfer some data but as
soon as the packet flow reaches a frame size of 1522 the flow stops - the
gateway starts showing a spike in dropped frames (reflected in
/sys/class/net/eth0 /statistics/rx_length_errors) as the client retransmits
the dropped packets. A closer look shows that the gateway is dropping the
packets due to size.
The TCP/IP part of the packet is 1500 bytes and I expect framing to add a final
14 or 18 bytes before transmitting it onto the wire. However 22 bytes are being
added, and it seems to be too many.
I have packet captures available to send via email (I'd like to not attach them
for privacy reasons).
The following is a sample oversized packet as exported from Wireshark. Note
that I tweaked the MAC and IP addresses for privacy.
No. Time Source Destination Protocol
Length Info
35 21:55:21.644314 192.168.1.149 54.239.25.200 TCP
1522 [TCP Retransmission] 44053→443 [ACK] Seq=350 Ack=155 Win=88832 Len=1460
[ETHERNET FRAME CHECK SEQUENCE INCORRECT]
Frame 35: 1522 bytes on wire (12176 bits), 1522 bytes captured (12176 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Dec 15, 2015 21:55:21.644314000 EST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1450234521.644314000 seconds
[Time delta from previous captured frame: 0.150820000 seconds]
[Time delta from previous displayed frame: 3.683211000 seconds]
[Time since reference or first frame: 9.568260000 seconds]
Frame Number: 35
Frame Length: 1522 bytes (12176 bits)
Capture Length: 1522 bytes (12176 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:tcp]
[Coloring Rule Name: Bad TCP]
[Coloring Rule String: tcp.analysis.flags && !tcp.analysis.window_update]
Ethernet II, Src: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx), Dst: Raspberr_xx:xx:xx
(xx:xx:xx:xx:xx:xx)
Destination: Raspberr_xx:xx:xx (xx:xx:xx:xx:xx:xx)
Address: Raspberr_xx:xx:xx (xx:xx:xx:xx:xx:xx)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
Address: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IP (0x0800)
Trailer: 2f8e4de5
Frame check sequence: 0x29f37f68 [incorrect, should be 0x3b863a28]
[FCS Good: False]
[FCS Bad: True]
[Expert Info (Error/Checksum): Bad checksum]
[Bad checksum]
[Severity level: Error]
[Group: Checksum]
Internet Protocol Version 4, Src: 192.168.1.149 (192.168.1.149), Dst:
54.239.25.200 (54.239.25.200)
Version: 4
Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT
(Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable
Transport) (0x00)
Total Length: 1500
Identification: 0xaaf3 (43763)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: TCP (6)
Header checksum: 0x3234 [validation disabled]
[Good: False]
[Bad: False]
Source: 192.168.1.149 (192.168.1.149)
Destination: 54.239.25.200 (54.239.25.200)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Transmission Control Protocol, Src Port: 44053 (44053), Dst Port: 443 (443),
Seq: 350, Ack: 155, Len: 1460
Source Port: 44053 (44053)
Destination Port: 443 (443)
[Stream index: 1]
[TCP Segment Len: 1460]
Sequence number: 350 (relative sequence number)
[Next sequence number: 1810 (relative sequence number)]
Acknowledgment number: 155 (relative ack number)
Header Length: 20 bytes
.... 0000 0001 0000 = Flags: 0x010 (ACK)
000. .... .... = Reserved: Not set
...0 .... .... = Nonce: Not set
.... 0... .... = Congestion Window Reduced (CWR): Not set
.... .0.. .... = ECN-Echo: Not set
.... ..0. .... = Urgent: Not set
.... ...1 .... = Acknowledgment: Set
.... .... 0... = Push: Not set
.... .... .0.. = Reset: Not set
.... .... ..0. = Syn: Not set
.... .... ...0 = Fin: Not set
Window size value: 347
[Calculated window size: 88832]
[Window size scaling factor: 256]
Checksum: 0x1c58 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Urgent pointer: 0
[SEQ/ACK analysis]
[iRTT: 0.028704000 seconds]
[Bytes in flight: 2077]
[TCP Analysis Flags]
[Expert Info (Note/Sequence): This frame is a (suspected)
retransmission]
[This frame is a (suspected) retransmission]
[Severity level: Note]
[Group: Sequence]
[The RTO for this segment was: 7.247571000 seconds]
[RTO based on delta from frame: 12]
Retransmitted TCP segment data (1460 bytes)
--
You are receiving this mail because:
You are the assignee for the bug.
reply other threads:[~2015-12-16 15:56 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151216075705.3dcfafa7@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.