net: Align interface numbering with POSIX/BSD/Linux

[pfalcon]

Currently, Zephyr uses natural 0-based numbering of networking interfaces (0 - first interface, 1 - next, etc.) However, the BSD networking API (which is the basis for POSIX, Linux, etc.) use a more adhoc numbering. E.g. quoting http://man7.org/linux/man-pages/man7/packet.7.html :

sll_ifindex is the interface index of the interface (see
netdevice(7)); 0 matches any interface (only permitted for bind‐
ing). sll_hatype is an ARP type as defined in the
<linux/if_arp.h> include file.

In other words, BSD numbering is 1-based, and 0 has a special meaning of "any"/"all" interfaces - and it's used consistently wherever an interface index appears, not just for packet sockets quoted above.

Based on the discussing in #12564 (comment) , the best way to deal with that would be to switch Zephyr to use the same numbering even on native level (vs for example trying to keep 0-based "native" index and convert it back and forth for Socket API level).

As we can't realistically do that change for 1.14, submitting this reminder ticket, and considering it's "ok" to use 0-based numbering in initial parts going into 1.14.

[pfalcon]

@jukkar, @tbursztyka, @rveerama1, @rlubos, @mike-scott : FYI.

[tbursztyka]

@pfalcon will you propose a patch for it? The fix sounds rather trivial, as only the socket interface handles the iface index that way, no need to change how iface are indexed in the core side.

[pfalcon]

as only the socket interface handles the iface index that way, no need to change how iface are indexed in the core side.

That's not what @jukkar said in the discussion linked above.

[tbursztyka]

well the net_if_get_by_index() etc.. doing the +1 and so on, is an easier solution actually

[tbursztyka]

However as 1.14 is going to be LTS, I would advise to fix that. It's a bug, so we have almost 2month of bug fix before the actual release.

[pfalcon]

However as 1.14 is going to be LTS, I would advise to fix that. It's a bug, so we have almost 2month of bug fix before the actual release.

Well, I can only +1 such approach. Anyway, it comes from @rveerama1's #12564, where he asked for response whether this issue is blocking for that PR, and the consensus was that we shouldn't dump that on him, he already does a great work of resolving other matters as required by packet socket.

So, this is made a separate issue, and I'm all for resolving it for 1.14 whenever possible.