[PATCH v4 00/14] Introduce the lwIP network stack
Jerome Forissier
jerome.forissier at linaro.org
Tue Jun 25 10:02:47 CEST 2024
On 6/25/24 00:28, Tim Harvey wrote:
> On Sat, Jun 22, 2024 at 1:09 AM Maxim Uvarov <muvarov at gmail.com> wrote:
>>
>> пт, 21 июн. 2024 г. в 21:42, Fabio Estevam <festevam at gmail.com>:
>>>
>>> Hi Tim and Jerome,
>>>
>>> On Fri, Jun 21, 2024 at 1:08 PM Tim Harvey <tharvey at 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
More information about the U-Boot
mailing list