On 6/25/24 00:28, Tim Harvey wrote: > On Sat, Jun 22, 2024 at 1:09 AM Maxim Uvarov <muva...@gmail.com> wrote: >> >> пт, 21 июн. 2024 г. в 21:42, Fabio Estevam <feste...@gmail.com>: >>> >>> Hi Tim and Jerome, >>> >>> On Fri, Jun 21, 2024 at 1:08 PM Tim Harvey <thar...@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, -- Jerome
