Problem with Spanning Tree Protocol

[iosofter]

I'm running your RP2040 W5500 Ethernet code (7.12-64-g82916a1c), and am getting a lot of unwanted hex dumps on the console, even when using log level MG_LL_NONE.

Enabling MG_LL_DEBUG gives an indication of the source:

802    3 mongoose.c:5287:mg_tcpip_rx    Unknown eth type fe68
0000   01 80 c2 ef 03 fe 0c 8e 29 9c fe 7a fe 68 03 03   ........)..z.h..
0010   04 85 d0 1c 00 80 01 80 c2 ef 03 fe 0c 8e 29 9c   ..............).
813    3 mongoose.c:5287:mg_tcpip_rx    Unknown eth type fe68
0000   01 80 c2 ef 03 fe 0c 8e 29 9c fe 7a fe 68 03 03   ........)..z.h..
0010   04 85 d0 1c 00 80 01 80 c2 ef 03 fe 0c 8e 29 9c   ..............).
825    3 mongoose.c:5287:mg_tcpip_rx    Unknown eth type fe68
0000   01 80 c2 ef 03 fe 0c 8e 29 9c fe 7a fe 68 03 03   ........)..z.h..
0010   04 85 d0 1c 00 80 01 80 c2 ef 03 fe 0c 8e 29 9c   ..............).

Wireshark identifies this as Spanning Tree Protocol coming from the ADSL router, which is a BT home hub, by far the most popular device in England. Remarkably, every 3 seconds it sends out 14 STP messages, and there is no way of preventing this.

Looking at the end of the mg_tcpip_rx function, it would appear that when an unknown Ethernet type is received, the logfile message is qualified by the MG_DEBUG macro, but the mg_hexdump call isn't, so will always be printed. Given the large number of these messages, this is a significant workload for the CPU.

Would it be possible to add the option of silently discarding unknown Ethernet types?

[scaprile]

It would not just appear, we intentionally put it there.
mg_hexdump does not follow logging level, it is there or it is not; just comment it out if you don't want it
I'll see to minimize the impact #2525