On 6/25/24 00:28, Tim Harvey wrote:
On Sat, Jun 22, 2024 at 1:09 AM Maxim Uvarov muvarov@gmail.com wrote:
пт, 21 июн. 2024 г. в 21:42, Fabio Estevam festevam@gmail.com:
Hi Tim and Jerome,
On Fri, Jun 21, 2024 at 1:08 PM Tim Harvey tharvey@gateworks.com wrote:
I tried your to-upstream/v5-wip branch (042bea36eb9731079a3d7afffe3774d79e06ac5d) and it behaves the same. Do you have something else to try/test?
Yes, when I tested older versions from Maxim I could never get lwIP to work with i.MX.
Jerome,
Please try to run the lwIP series on any i.MX board, if possible.
Thanks
Packet not for us means that incoming packet DST MAC does not match to the MAC address inside lwip. I.e. to MAC address set into lwip when lwip_init was done. Original U-Boot network stack does not compare MACs but lwip does. There is something specific on this board, in general lwip with debug should print out MAC used during initialization. This MAC should match to the MAC from the incoming packet.
It seems 'packet not for us' can mean a lot of things.
Yeah :-/ in this case I believe the traces are caused by unrelated traffic (UDP port 138 is used by NetBIOS).
I added a bit of debugging around 'DHCP packet accepted' and found I'm not receiving any packets from my DHCP server. So I connected directly to another board (isolated network) where I ran my own server and tcpdump and I don't see packets coming from lwip:
Ha! That's interesting.
without lwip my server shows: # tcpdump -i eth1 tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 22:18:01.043992 IP (tos 0x0, ttl 255, id 23, offset 0, flags [DF], proto UDP (17), length 328) 22:18:01.044391 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 22:18:01.044454 IP (tos 0x0, ttl 255, id 24, offset 0, flags [DF], proto UDP (17), length 328) 22:18:01.044752 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
# tcpdump -i eth1 tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 22:22:41.602178 [|llc] 22:22:41.709978 [|llc] 22:22:41.867947 [|llc] 22:22:42.105202 [|llc] 22:22:42.502091 [|llc] 22:22:43.219079 [|llc] 22:22:44.497979 [|llc] 22:22:45.776884 [|llc] 22:22:47.054773 [|llc] 22:22:48.333667 [|llc] 22:22:49.611559 [|llc] 22:22:50.890469 [|llc]
What actual hardware has this been tested with? I think Tom mentioned he tested with an rpi of some sort.
Yes, I believe he tested on RPi 3B and me too. Ilias has tested on NVIDIA Jetson Nano.
I don't know what the meaning of the llc msg is above but you can see there is no DHCP request.
Some more tracing is needed. Can you try enabling all traces in lib/lwip/u-boot/lwipopts.h? i.e., replace all LWIP_DBG_OFF with LWIP_DBG_ON in the #if defined(CONFIG_LWIP_DEBUG) section. And of course enabled CONFIG_LWIP_DEBUG. I do have a i.MX8M Plus EVK board but will not be able to use it before tomorrow.
Thanks,