[GSoC 2017] ioctl operations

[Joan Lledó]

One of the pending tasks in my TODO since the beginning of the project
was implementing the operations of the iioctl interface and other
interfaces if needed. The iioctl interface is the responsible for
servicing the ioctl requests[1] that have a socket as first parameter.
Besides, pfinet also implements another interface called "pfinet" that
responds to SIOCGIFCONF requests. With these interfaces , we can
programatically configure the translator from a user program if it has
the proper credentials, also, all users can read the configuration of
the stack.

Las week I started writing some iioctl operations and SIOCGIFADDR,
SIOCGIFDSTADDR, SIOCGIFBRDADDR, SIOCGIFNETMASK, SIOCSIFADDR,
SIOCSIFDSTADDR, SIOCSIFBRDADDR, SIOCSIFNETMASK, SIOCGIFFLAGS and
SIOCSIFFLAGS are supported so far. Next I'll share some problems I
found while writing them.

In the first place, I was surprised to see how all SIOCS* requests,
that is, the ones for configuring the stack, were executed without
problems when called from a plain user program when they should be
allowed only for the root user. When I tried to do the same over
pfinet, an EPERM error was returned. Finally, I discovered the point
was in the socket_create()[2] operation. In this operation the user is
considered root if s/he is the owner of the file the translator is
installed on. Thus, pfinet was returning EPERM because it was
installed on /servers/socket/2, where my user wasn't the owner, while
lwip was installed on a file in my home.

Another problem I had was related to the SIOCSIFBRDADDR request, for
changing the broadcast address of a network. At the beginning I didn't
know how to do it, and soon discovered that this operation is just not
supported by LwIP. However, I was left with the question: Why would
anybody need to change the default broadcast address of her/his
network? In which scenario would that be useful? I asked the question
at SuperUser[3] and, for the moment, nobody answered me...

Finally, I found a problem with the device flags. This is the problem:
if I set the flags with the SIOCSIFFLAGS operation, everything works
fine and the effects are noticed immediately. However, when I issue
the SIOCGIFFLAGS request I don't get the flags I've just set, instead,
I get 0x00000041. In fact, it doesn't matter which flags are set in
the device, the device_get_status()[4] operation called with the
NET_STATUS parameter always returns 0x00000041 in the flags field of
the ifreq. This problem can be fixed by using the NET_FLAGS parameter,
with this one, I've checked the values are always the correct ones,
but the call fails if we're working over a multiplexed device with the
eth-multiplexer translator. At the end, I used the first option with
NET_STATUS, but I'll have to find out if this is the best option.

In addition to the iioctl interface, I've spent part of these last
days fixing bugs. Once, while making tests the stack raised an error
claiming there where no more available sockets. That was surprising,
is there a max number of sockets? So yes, there is, LwIP has a limit.
In LwIP, sockets stored in an static global array[5], thus, all the
needed memory is allocated in the heap all the time and the amount of
sockets is limited by the amount of available memory of the system.
Since LwIP is aimed for embedded systems where the memory use to be
very limited, the amount of sockets by default is... four. I increased
the value to the amazing amount of 32, I hope the Hurd can cope with
it :P. This made me wonder if there's a max number of sockets in other
systems. As expected, what I found on the Internet is that there's not
a fixed limit in most systems, it depends on the configuration and the
available memory. But probably in other systems sockets are stored in
dynamic memory that increases on demand. The problem with LwIP is that
it uses static memory and, whatever amount of sockets we choose, we'll
be wasting memory for most of cases and don't have enough socket for
special cases. In addition, this is not the only case where this
happens, the same problem is present with the amount of TCP
connections, UDP "connections", IPv6 addresses per interface, etc[6].
Unfortunately, this problem doesn't seem to have a solution.


-------------------------------------------------------------
[1] https://linux.die.net/man/7/netdevice
[2] https://github.com/jlledom/lwip-hurd/blob/master/socket-ops.c#L74
[3] 
https://superuser.com/questions/1230098/why-change-the-ipv4-default-broadcast-address
[4] https://github.com/jlledom/lwip-hurd/blob/master/iioctl-ops.c#L220
[5] 
https://github.com/yarrick/lwip/blob/328134fdbaaea2ff80193ec0453a12132ef0d2ab/src/api/sockets.c#L262
[6] 
https://github.com/yarrick/lwip/blob/328134fdbaaea2ff80193ec0453a12132ef0d2ab/src/include/lwip/opt.h#L352