
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.
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:
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.
I don't know what the meaning of the llc msg is above but you can see there is no DHCP request.
Best Regards,
Tim