Student: Ambarisha Bhatlapenumarthi
Mentors: Tomas Hruby, Dirk Vogt
git repository: minix-lwipgsoc

The project aims to complete LwIP integration into MINIX 3. Basic support has already been added but it isn't complete and hasn't been tested properly yet. This project will be about completing that work and then adding new features like IP routing, forwarding, IPv6 support, NPF support. There are also some secondary goals like developing core LwIP for the benefit of both MINIX 3 and LwIP communities.

Imported LwIP-trunk codebase. LwIP is currently in 1.4.1rc1. LwIP-trunk contains alot of major IPv6 patches which will be coming out in 1.5.0.
After a few changes to the Makefiles everything compiles.
Noticed a couple of random glitches after installing LwIP-trunk. Otherwise lwip server runs fine.
Looked into DHCP client. Need to consider ISC's dhclient vs Roy Marvels' dhcpcd(being used by netbsd).

I worked on porting ISC's dhclient to MINIX. dhclient comes with bind which is a DNS software. Support for IPv6 is also available. So once it works, most of the basic functionality will be available. For now all the code compiles. I still need to fix a few things(mentioned below) and then test the client. I defined a couple of dummy functions to make the IPv6 code compile. Once IPv6 module is completed these dummy functions can be replaced.

bind maintains a journal file for IXFR zone transfers. It uses utimes() for timestamping each time it accesses this journal file. utimes() is not available in MINIX, so instead of using the utimes we maintain a timestamp variable for the journal file.

There are three Network API available. BPF, LPF and raw sockets. For raw sockets, they are trying to use a handcrafted IP header by setting the IP_HDRINCL socket option. But IP_HDRINCL isn't available in /usr/include. Also I am not sure why handcrafted IP header is necessary. For BPF, LPF it has to handcrafted anyway. So, probably this is so for reusing that code.

dhclient requires SO_BROADCAST which is a socket option for broadcasting. But SO_BROADCAST isn't available in MINIX.

This week I first fixed the problems from last week:

• Escaped IP_HDRINCL problem by defining a NO_IPHDRINCL macro for minix. When NO_IPHDRINCL is defined we let the kernel craft the ip header, but make sure that the network interface is initialized with 0.0.0.0 IP address. Then we use 255.255.255.255 with the sendto() call.
• LwIP defines a macro IP_SOF_BROADCAST for enabling broadcasting on a network interface. I modified MINIX's lwip/opt.h file to enable this. I modified setsockopt() to allow setting this socket option. Then modified lwip server to set this flag on the pcb.

I got the NetBSD's dhclient-script and modified it to work with MINIX as our ifconfig command is very restricted. Also typecasts between struct sockaddr_in and struct sockaddr aren't working as expected. Currently working on fixing this. (Edit: It was just because of a mistake, I was including the wrong file)

This week I worked DNS and IP forwarding.

• BIND included in dhclient only builds the export libraries required by dhclient. After some work, it now builds, successfully, the dns client daemon, nsupdate and couple of other binaries that come in the BIND package.
• I have also switched on IP forwarding, but I had some trouble configuring a second network interface and am still working on this.
• I also looked at the status of routing in lwip. After discussing with Tomas, decided that extensive routing work should be left out. For now, we can route between 'n' immediate networks on 'n' interfaces.

I have been working on integrating dhclient and bind into minix src tree. I also successfully tested IP forwarding.

• dhclient and bind tools available in netbsd are from an older version than the one I worked on.
• The newer version of dhcp supports IPv6, and hence there is quite a bit of difference in the code
• I am following netbsd's directory structure of dhclient and bind, so that I can use their makefiles (after modifications)

I laid out the makefiles and modified them for minix. I found out that bind has 2 sets of libraries BIND9 libraries and bind export libraries. Bind export libraries separate code which is closely tied to bind binaries (especially named). Since we are porting both dhclient and named, I figured we could merge both libraries. After building everything and running, I learnt that the libraries are not compatible with each other internally. I got this confirmed on bind-workers mailing list. So, now we have two sets of bind libraries which are somewhat different. I have placed the export libraries under libbindexport in src/lib. I am finally finished with integrating dhclient into minix src tree. Though there still seems to be a problem with broadcast receive messages. I am now working to fix this.

I have also setup IPv6 lan with my host for starting work on IPv6. I looked at liblwip, lwip server from IPv6 perspective. liblwip has a LWIP_IPV6 option which turns on IPv6 in lwip. We first turn that on, then modify lwip server to handle ioctls on ipv6 sockets. Perhaps this might become more clear after discussing with Tomas and Dirk today.

Last week I couldn't get much work done except implementing NWIOGIP6CONF ioctl and IPv6 changes at IP layer because I had problems with setting up a serial console and implemented NWIOSIP6CONF the wrong way(fixed now). Here are the changes from this week :

• Added IPv6 TCP & IPv6 UDP functionality to lwip server. (Still to test)
• Modified the userland libraries to recognize and work with IPv6 sockets (Still to test)
• Built libc with IPv6 support by enabling USE_INET6 in lib/libc/minix-config.inc
• Fixed some problems with dhclient and made changes to install dhclient replacing dhcpd

I have pushed most of the changes to the repository. Any remaining changes will appear by tommorrow.

These last couple of weeks, I continued the work on IPv6:

• I finished work on some of leftover the userland socket calls.
• Modified LwIP server adding nd6(neighbour discovery) and mld6 (multicast listener discovery) over IPv6.
• Then I tested TCPv6 client and server mode connections.
• I am still having problems with UDPv6 connections. I have spotted the source of the problem and have yet to write a patch for it.

LwIP is not yet a complete substitute for inet. It has to be improved and tested before it can replace inet.Firstly, DHCP has to be fixed. dhcpd currently doesn't work so well with lwIP. There are two approaches to fix this:

• Make changes to the current dhcpd to work with lwIP. I was informed that there are already a few quick fixes for this. These need to be looked at and incorported into dhcpd.
• Use the DHCP functionality being offered by lwIP

The interface between lwIP and VFS also requires some polishing. The socket interface is provided with the help of VFS. It seems there are some problems with the raw socket functionality. Also, lwIP has to be tested further. Sometimes, I experience the system going into infinite loop with ftp listings and such. There are other little things like displaying error messages about ioctl when an ftp port command fails. These need to be put down formally, reproduced and then patched. All that testing will be included in this module.

Currently lwIP doesn't support extensive routing or IP forwarding. Looking at ip_route() in liblwip/src/core/ipv4/ip.c, we see that, as of now, a packet is checked for match on the subnets of all the available network interfaces . If it doesn't match the packet is sent on a default interface. This needs to be improved. The state information required to decide the route has to be acquired and the route calculated. I have also looked through inet codebase. Perhaps, src/servers/inet/ipr.c could be a starting point.

[EDIT : Confirmed that improving routing support in lwip is out of the scope of the project. It seems, the lwIP community is also not so interested bringing in extensive routing in “lw”IP ]

lwIP has IPv6 support, but it is not at all complete. A lot of patches were added after the 1.4.0 release according to lwIP mailing list discussion and they haven't been tested thoroughly as yet. Testing IPv6 would also be a major task of this module. LwIP currently supports the dual stack. I have a decent understanding of IPv6. But it is not profound. I will have to study this a little more. So, this module is perhaps the largest.

This would involve adding hooks to let NPF know when a packet arrives and passing the packet to NPF after stripping the datalink headers.

There are also some secondary goals like adding features to LwIP and upstreamed.

• TCP Segmentation offloading
• Advanced congestion control algorithms
• TCP Window scaling option [DONE sheep/goat project]

• Investigate the status of IPv6 in LwIP
• Study the communication protocol between VFS and LwIP
• Set up a meeting with Tomas and Dirk before coding period starts

• Import lwIP 1.4.1
• Test all the basic functionality of lwIP. Improve lwIP accordingly.

• Study the routing codebase of inet
• Add the same functionality to lwIP

Buffer

• Study IPv6 further, if necessary
• Import lwIP IPv6 into branch
• Test and evaluate what lwIP IPv6 gives out of the box
• Discuss what all features should be supported
• Improve lwIP IPv6
• Communicate any improvements upstream

• Study how NPF hooks work, perhaps a callback which is called on each arriving packet.
• Add the hooks to LwIP
• Test NPF

• Finish any testing and debugging leftover from Module 3 or 4
• Ensure all the primary goals of the project are met
• If there is time left, start with secondary goals after a green signal from mentor.

• Improve comments in the code for the benefit of testers
• Complete documentation on how to set up IPv6
• Make sure all the work is merged with the master branch

• Relevant link 1
• Relevant link 2