Re: LwIP and multiple network interfaces

[Jerome Forissier <jerome.forissier@linaro.org>]

On 1/3/25 02:52, E Shattow wrote:
> 
> 
> On 1/2/25 17:40, Tom Rini wrote:
>> On Thu, Jan 02, 2025 at 05:34:57PM -0800, E Shattow wrote:
>>
>>> Tom sorry about sending this reply twice, struggle here is with Thunderbird
>>> mail UI sometimes hiding "Reply All" and it missed the mail list first time
>>> around.
>>
>> No problem.
>>
>>> On 1/2/25 14:47, Tom Rini wrote:
>>>> On Thu, Jan 02, 2025 at 02:26:06PM -0800, E Shattow wrote:
>>>>> Problem: 'dhcp' must be ran twice when the network cable is plugged into a
>>>>> port other than the first network port.
>>>>>
>>>>> Network cable plugged into bottom (first) Ethernet port:
>>>>> 1. Power on
>>>>> 2. StarFive # dhcp
>>>>>
>>>>> ethernet@16030000 Waiting for PHY auto negotiation to complete....... done
>>>>> DHCP client bound to address 192.168.2.51 (3678 ms)
>>>>>
>>>>>
>>>>> Network cable plugged into top (second) Ethernet port:
>>>>> 1. Power on
>>>>> 2. StarFive # dhcp
>>>>> ethernet@16030000 Waiting for PHY auto negotiation to complete.........
>>>>> TIMEOUT !
>>>>> phy_startup() failed: -110
>>>>> FAILED: -110
>>>>> ethernet@16040000 Waiting for PHY auto negotiation to complete...... done
>>>>> ethernet@16030000 Waiting for PHY auto negotiation to complete.........
>>>>> TIMEOUT !
>>>>> phy_startup() failed: -110
>>>>> FAILED: -110
>>>>> Could not start ethernet@16030000
>>>>> 3. StarFive # dhcp
>>>>> DHCP client bound to address 192.168.2.77 (31 ms)
>>>>
>>>> What happens when you set ethact to 1 first?
>>>>
>>>
>>>
>>> '1' literal does not seem to do something so I guess it is meant the id of
>>> the first ethernet interface:
>>
>> Yes, I misspoke sorry.
>>
>>>  From power-on:
>>>
>>> ...
>>> starfive_7110_pcie pcie@2b000000: Starfive PCIe bus probed.
>>> starfive_7110_pcie pcie@2c000000: Starfive PCIe bus probed.
>>> In:    serial@10000000
>>> Out:   serial@10000000
>>> Err:   serial@10000000
>>> Net:   eth0: ethernet@16030000, eth1: ethernet@16040000
>>> starting USB...
>>> No USB controllers found
>>> Working FDT set to ff700a10
>>> StarFive # env print ethact
>>> ## Error: "ethact" not defined
>>> StarFive # env set ethact 1
>>> StarFive # dhcp
>>> ethernet@16030000 Waiting for PHY auto negotiation to complete.........
>>> TIMEOUT !
>>> phy_startup() failed: -110
>>> FAILED: -110
>>> ethernet@16040000 Waiting for PHY auto negotiation to complete...... done
>>> EQOS_DMA_MODE_SWR stuck
>>> FAILED: -110
>>> Could not start ethernet@16030000
>>>
>>> Again, from power-on:
>>>
>>> starfive_7110_pcie pcie@2b000000: Starfive PCIe bus probed.
>>> starfive_7110_pcie pcie@2c000000: Starfive PCIe bus probed.
>>> In:    serial@10000000
>>> Out:   serial@10000000
>>> Err:   serial@10000000
>>> Net:   eth0: ethernet@16030000, eth1: ethernet@16040000
>>> starting USB...
>>> No USB controllers found
>>> Working FDT set to ff700a10
>>> StarFive # env print ethact
>>> ## Error: "ethact" not defined
>>> StarFive # env set ethact ethernet@16040000
>>> StarFive # dhcp
>>> ethernet@16040000 Waiting for PHY auto negotiation to complete...... done
>>> DHCP client bound to address 192.168.2.77 (149 ms)
>>
>> So then yes, the second interface works when ethact is set to use that
>> directly. This is the same behavior as the legacy stack I believe.
>>
> 
> Legacy stack does actually rotate and complete successfully when ethact environment variable does not exist and (eventually) configure the second interface though. Here with LwIP the procedure fails.
> 
> Notice that here it starts with ethernet@16030000, then rotates to ethernet@16040000 unsuccessfully, and back again to ethernet@16030000 before (again) failing and giving up. There is a network cable plugged into 'ethernet@16040000' port and if we try the command again the environment variable ethact retained 'ethact=ethernet@16040000' from the failed procedure so you're right it works as it should... except that it totally failed to do what was expected the first time.

That's unexpected indeed.

> Is this exposing a problem with this board network driver and behavior or is it something with LwIP ?
Hard to tell at this point. One thing I know for sure is that lwIP expects
eth_set_current() (called from do_dhcp()) to actually pick a valid
interface if there is one. So it should definitely select ethernet@16040000
in your scenario. Adding debug prints to eth_set_current(),
eth_current_changed() etc. should help.

Thanks,
-- 
Jerome