@TimoRoth It would be interesting whether your ESP Gateway is working with these bug fixes as expected.

With this applied I can now ping the gateway itself with a ping size of up to 1434 bytes(which is a packet size of exactly 1500).
And I can ping a client behind the gateway with a ping size of up to 200 bytes, which translates to an ESP-NOW package of exactly 250 bytes.
If I try to ping with 201 bytes I can see one single 246 byte sized ESP-NOW package coming in on the client, but never the second fragment. Same behaviour when pinging from the RIOT shell. Which is weird, because that already worked when I tested it yesterday.
Not an issue with this PR though, the lack of fragmentation support is a different issue entirely.

With this applied I can now ping the gateway itself with a ping size of up to 1434 bytes(which is a packet size of exactly 1500).

Not really clear why 1434. ICMPv6 Echo request header has 8 byte and IPv6 header without extensions has 40 bytes. Therefore, I would expect 1452 byte as maximum or missed I something?

Since your output interface has a MTU of 1280, your ICMPv6 Echo requests should be forwarded only for a data size of 1232 byte if fragmentation is not supported or not allowed.

If I try to ping with 201 bytes I can see one single 246 byte sized ESP-NOW package coming in on the client, but never the second fragment. Same behaviour when pinging from the RIOT shell. Which is weird, because that already worked when I tested it yesterday.

I checked out your last commit, it works for me as expected. I can ping using ESP-NOW with a data size of up to 1232 byte.

Not really clear why 1434

Is there a link layer header as well in there?

Is there a link layer header as well in there?

I don't know, @TimoRoth?.

If Ethernet II frame formatting is used, IPv6 should be directly the payload and should be able to use the whole MTU. If he uses a Linux PC to ping, I would guess this should be the case.

I'm using Windows ping, I'm not exactly sure what it does, but when I do "ping -6 -l 1434" the package reaching the esp-eth interface has a size of exactly 1500 bytes. Didn't investigate any further why it's exactly that size.

@TimoRoth I see, you are using windows. Hm, does it work to make and flash ESP32 with Windows or are you using Linux/macOS for that?

Anyway, It would be quite interesting how the packets looks like. May I ask you to snap such one ICMPv6 Echo packet with data size of 1434 bytes by wireshark?

I'm using a VM with Linux. But it does not have access to the Wifi where the router is on, so I need to do that from the Windows host.

Looks like this on Wireshark. Not sure there the extra 4 Byte on the esp-eth end come from.

@TimoRoth Thanks. This is what I supposed, Ethernet II formatted MAC frame with 40 bytes IPv6 header and 8 bytes ICMPv6 echo reply header as payload. The frame size of 1496 on wire includes the 14 bytes Ethernet II header. But, Ethernet II MTU size is always the limit for the payload of the Ethernet frame. That is, usually it should be possible to have 1514 bytes on wire.

If you ping any IPv4 host, you will see these 1514 bytes on wire with ping <IPv4 address> -s 1472.

@miri64 May I ask you to review this fix for esp_eth netdev driver? It would be great to get it merged as soon as possible.

I don't have the hardware to test, but I will give it a code review.

Maybe @TimoRoth could it retest even though he already tried the changes #10604 (comment).

@PeterKietzmann should also have access to the hardware - and is experienced with the netdev interface.

Just tested it again on top of current master.
Pinging the board works great up until the packet size exceeds the MTU, which is to be expected.

Then, once my change request is addressed I think we can merge.

@miri64 Changed

@miri64 Could you give your ACK for the requested change?

Untested ACK.

Thanks. Was tested again by @TimoRoth #10604 (comment)