Re: [lwip-devel] netifapi limitations

[Jonathan Larmour]

Thanks for the reply Joel.

On 16/03/18 13:48, Joel Cunningham wrote:
> 
> On 03/15/2018 09:23 PM, Jonathan Larmour wrote:
>> I've noticed a limitation in the netifapi (not the netif API!) : [snip]
>
> This is definitely a limitation that has been discussed before on the list
> (see https://savannah.nongnu.org/task/index.php?14724). To me, the netif and
> netifapis are really only useful from code that manages a struct netif (owns
> the allocation/reference, so it can safely pass pointers). I think of this as
> link layer management code, which typically adds/removes the neift, applies
> configuration settings and not network application code that lives above the
> stack.

But it's not potentially just application code but higher layer protocol code.
Think of the requirements for

> I think for network application code, additional APIs are needed to get things
> like get address information, list of interfaces.  LwIP doesn't have any of
> the normal things like getifaddrs and in my projects, I've got custom code to
> do these lookups in a safe way.
> 
> We made some progress implementing ifnametoindex/ifindextoname, but
> encountered some implementation issues with if_nameindex (which enumerates all
> interfaces).  See 
> https://savannah.nongnu.org/task/?func=detailitem&item_id=14314
> 
>>
>> Perhaps it could be argued that keeping lwIP simple means making compromises,
>> and maybe this is a compromise to make. But overall IMHO, the netif API would
>> be better off removing all mentions of struct netif* entirely. Instead each
>> function should take an if index.
>>
>> That brings me to a second issue, netif_find() assumes that the netif name is
>> exactly three chars long, the third being the if number from 0-9. The number
>> is assigned in netif_add() by incrementing a local static variable each time.
>> The problem here is that this means you can only ever have added 10 
>> interfaces
>> before the API breaks, even if you have removed netifs in the meantime. Even
>> if we parsed the name argument as a normal NUL-terminated string, the index 
>> is
>> a u8_t. If there is a possibility that people can be adding/removing netif's
>> dynamically and repeatedly (think USB or PPP), this can't work long. The 
>> index
>> probably wants to be u32_t for safety given how long embedded devices can be
>> up for, and netif_find() needs to accept a normal NUL-terminated string and
>> use strtoul() on the number component.
>>
>> Next, if the numbers are part of the name, but are assigned by lwIP, how can
>> netif API users even find an interface except in the most simple static 
>> cases,
>> and making assumptions about interface initialisation order? It makes me 
>> think
>> we need an iterator function in netifapi to report the next used index (which
>> in practice just traverses the netif list). For example:
> Given how it's implemented on git master with the index, you're right the
> resulting name is non-deterministic. If we had something like
> getifaddrs/if_nameindex, we could enumerate the names, but I think having
> names which can be hardcoded into applications isn't a good practice.




-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine