Technically, the MTU should be 1496 of you use VLANs, or else it's > actually already a jumbo frame. The total size according to the ethernet > spec is really 1518. Larger are not allowed. VLAN information is > actually a part of the payload. > > Yes, 1518 is the size, true. But VLANS are not part of the payload. An untagged frame which enters a VLAN switch will have the 802.1Q tag inserted after the DA/SA. When that happens the CRC has to be recomputed so therefore *it is not* just part of the payload (e.g. like a UDP datagram). Larger are allowed, we typically use 2K sizes for additional link layer encapsulation (most of the switching hardware today does at least).
IEEE Std 802.3-2012 (Revision of IEEE Std 802.3-2008) 1.4.102 basic frame A MAC frame that carries a Length/Type field with the Length or type interpretation and has a maximum length of *1518* octets. The basic frame is not intended to allow inclusion of additional tags (i.e., untagged) or encapsulations required by higher layer protocols. (See IEEE Std 802.3, 3.2.7.) 3.2.7 MAC Client Data Field Ethernet implementations shall support at least one of three maximum MAC Client Data field sizes defined as follows: a) 1500 decimal—basic frames (see 1.4.102) b) 1504 decimal—Q-tagged frames (see 1.4.334) c) 1982 decimal—envelope frames (see 1.4.184) If layer management is implemented, frames with a MAC Client Data field larger than the supported maximum MAC Client Data field size are counted. Also, if we have a length field, then it's an 802.3 frame, while if you > have type information in there it is a Ethernet II frame. So IP commonly > use Ethernet II, and not 802.3. There is a standard for sending IP over > 802.3 as well, but it has been declared obsolete since many years now. > 3.2.6 Length/Type field This two-octet field takes one of two meanings, depending on its numeric value. For numerical evaluation, the first octet is the most significant octet of this field. a)If the value of this field is less than or equal to 1500 decimal (05DC hexadecimal), then the Length/Type field indicates the number of MAC client data octets contained in the subsequent MAC Client Data field of the basic frame (Length interpretation). b)If the value of this field is greater than or equal to 1536 decimal (0600 hexadecimal), then the Length/Type field indicates the Ethertype of the MAC client protocol (Type interpretation). The Length and Type interpretations of this field are mutually exclusive. > > Sorry, this was mostly silly trivia... > > We are running with STM32H7 chips, but I think we are actually using a > large enough packet size. So I don't have any direct feedback on this > problem. > > So what packet size do you use? We're running STM32F7 with some exotic radio hardware, probably will get to this later on in the year (Ethernet bridging). > Johnny > > On 2021-03-04 22:48, James Dougherty wrote: > > John, to answer your question on ethernet, 1500 is a very common MTU. For > > VLAN tagged frame support (802.1Q VLAN ID ), 1518 bytes (1522 bytes on > the > > wire with 4-byte / 32-bit ETH CRC32), for Jumbo frames (not IEEE) 9122 is > > common. Minimum frame size with CRC is 64-bytes and zero padding is > common, > > < 64 is considered a runt frame. And note if ethernet_len field is 0x800 > > you have an IP packet. Good luck on STM32H7 ethernet hardfault debug. > > > > On Thu, Mar 4, 2021 at 12:46 PM John Rippetoe < > jrippe...@roboticresearch.com> > > wrote: > > > >> Hello All, > >> > >> I've been playing around with networking on the STM32H7 and am seeing > >> hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log > >> below, the driver would appear to be dropping packets that are too large > >> to fit into the default packet size of 590. By increasing the packet > >> size to the max (1518), the problem seems to disappear, but I am a > >> little confused why the driver is able to catch the fact that the > >> received packet was too large and drop it appropriately, but then crash. > >> After poking around the ethernet driver, I think I understand the issue > >> to be that because the MAC DMA does not know that the buffer it is > >> writing into has a size limit, it is overflowing the buffer and writing > >> into adjacent memory. Am I understanding this correctly? > >> > >> My main concern here is that increasing NET_ETH_PKTSIZE to the limit > >> will only hide the issue for a time instead of solving it. A quick > >> google search does show that the maximum ethernet frame size is 1518 > >> bytes though, so I am working under the assumption that maxing it out in > >> my config will account for all possible frame sizes and eliminate this > >> issue. I have no experience with low level networking protocols and > >> standards, so I thought it would be prudent to seek out additional help > >> to make sure I am on the right track. > >> > >> Thanks in advance. > >> > >> - John > >> > >> stm32_receive: WARNING: DROPPED Too big: 684 > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> stm32_receive: WARNING: DROPPED Too big: 1332 > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> stm32_receive: WARNING: DROPPED Too big: 1264 > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> stm32_receive: WARNING: DROPPED Too big: 684 > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> stm32_receive: WARNING: DROPPED Too big: 1364 > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> stm32_receive: WARNING: DROPPED Too big: 1264 > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> stm32_receive: WARNING: DROPPED Too big: 1436 > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> stm32_receive: WARNING: DROPPED Too big: 1300 > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > >> up_hardfault: PANIC!!! Hard fault: 40000000 > >> up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148 > >> task: lpwork > >> up_registerdump: R0: 24012080 2401206e 0000024e 00000000 24012000 > >> 40029160 24011fc0 00008040 > >> up_registerdump: R8: 40029134 24011f00 24011fe0 240120b8 00000001 > >> 38002f88 080a26a7 080a2538 > >> up_registerdump: xPSR: 81000000 BASEPRI: 000000f0 CONTROL: 00000000 > >> up_registerdump: EXC_RETURN: ffffffe9 > >> up_dumpstate: sp: 24010bb0 > >> up_dumpstate: IRQ stack: > >> up_dumpstate: base: 24010c00 > >> up_dumpstate: size: 00000200 > >> up_dumpstate: used: 00000140 > >> up_stackdump: 24010ba0: 24010bb0 2400e830 0000064c 080a0fed 000000f0 > >> 00000000 240120b8 00000001 > >> up_stackdump: 24010bc0: 38002f88 080a26a7 080a2538 0816625a 00000000 > >> 080a129f 080a1271 080f754f > >> up_stackdump: 24010be0: 000000f0 080a2935 000000f0 38002eb4 40029160 > >> 24011fc0 00008040 080a1b8f > >> up_dumpstate: sp: 38002f88 > >> up_dumpstate: User stack: > >> up_dumpstate: base: 38003008 > >> up_dumpstate: size: 0000064c > >> up_dumpstate: used: 000003e0 > >> up_stackdump: 38002f80: 00000010 080a269b 24012050 24012000 00000000 > >> 24012010 2400b430 00000000 > >> up_stackdump: 38002fa0: 000000f0 00000080 00000000 00000000 00005ec8 > >> 0809d2e7 ffffffff ffffffff > >> up_stackdump: 38002fc0: 00005ec8 00000001 00000010 00020000 39276cac > >> 2400b430 00000000 00000000 > >> up_stackdump: 38002fe0: 00000000 00000000 00000000 00000000 00000000 > >> 0809c501 0809c4f1 0809bed5 > >> up_stackdump: 38003000: 00000000 00000000 deadbeef 38003014 00000000 > >> 6f77706c de006b72 7b93d153 > >> up_taskdump: Idle Task: PID=0 Stack Used=0 of 0 > >> up_taskdump: hpwork: PID=1 Stack Used=352 of 2028 > >> up_taskdump: lpwork: PID=2 Stack Used=992 of 1612 > >> up_taskdump: init: PID=3 Stack Used=1544 of 2980 > >> > >> > >> CONFIDENTIALITY NOTICE: This communication may contain private, > >> confidential and privileged material for the sole use of the intended > >> recipient. If you are not the intended recipient, please delete this > e-mail > >> and any attachments permanently. > >> > >> > > > > -- > Johnny Billquist || "I'm on a bus > || on a psychedelic trip > email: b...@softjar.se || Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol >
