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 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.

Last 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() 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 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() opertation 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, 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 sockets 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. Unfortunately, this problem doesn't seem to have a solution.