[lwip-devel] Changes in lwip to make it work in the Hurd

[Joan Lledó]

Hello,

The port of lwip to the Hurd is finished and I'd like to share with
you some changes I had to make to the stack in order to make it work
in our environment. We're working with lwip 2.0.1 and would like to
update to new versions applying as few patches as possible. That's why
I'd like to know your opinion about the items of the list,
particularly, whether you think it's worth to try to find a acceptable
solution for upstreaming for any item, in which case I would create a
new thread for that issue.

1.- We're using an external DHCP client that needs to send UDP packets
from 0.0.0.0 to 255.255.255.255 for DHCPDISCOVER messages. I made two
changes:
1.- ip4.c: Don't forward broadcast messages to the loopback
interface[1]. We need this because the interface has INADDR_NONE
assigned at this point. Since INADDR_NONE==INADDR_BROADCAST, the stack
thinks the packet is for itself.
2.- udp.c: Don't use the outgoing interface IP as source address when
that IP is INADDR_NONE[2].

2.- We use two different sys_arch_sem_wait() functions in our
sys_arch.c. One is the default for Unix ports and the other one is
specific for the Hurd. Our function[3] calls a non-portable pthread
function that allows us to awake a waiting RPC thread from Glibc in
the user-side. We need this in lwip_select() because it's called as a
RPC with no timeout, so we need a way to unblock it from the client
side.

3.- The inet server may be reconfigured in runtime, that means
removing and adding new interfaces while the tcpip thread is running.
In my tests, this is a problem where there are some opened TCP
connections at the moment its interface is gone, which eventually
leads to some assert fail. In my tests, placing a check in
lwip_selscan()[4] seems to solve all these problems, but I guess this
can be done better.

4.- We received a patch[5] that implements lwip_poll() in sockets.c.
I've tested it and is working fine for us. This doesn't solve the
problem with the number of sockets, but it could be interesting to
adapt it for new releases.

5.- Nothing important, but in my Ethernet driver I had to change the
exit condition in output and input loops, because the default
example[6] exits when q->next == 0, and should be when q->tot_len ==
q->len.


---------------------------
[1] 
https://github.com/jlledom/liblwip-hurd/blob/bfb72544fe21ac7e73acba2835a8c81a67493e33/dist/core/ipv4/ip4.c#L934
[2] 
https://github.com/jlledom/liblwip-hurd/blob/bfb72544fe21ac7e73acba2835a8c81a67493e33/dist/core/udp.c#L636
[3] 
https://github.com/jlledom/liblwip-hurd/blob/bfb72544fe21ac7e73acba2835a8c81a67493e33/port/sys_arch.c#L487
[4] 
https://github.com/jlledom/liblwip-hurd/blob/bfb72544fe21ac7e73acba2835a8c81a67493e33/dist/api/sockets.c#L1470
[5] http://lists.gnu.org/archive/html/bug-hurd/2017-08/msg00013.html
[6] 
https://github.com/yarrick/lwip/blob/339ec17cf0aaf57525cecc2468089e2ffe12b1ac/src/netif/ethernetif.c#L210