Networking issues (ankh/lwip/drivers/?)

[Stark, Josef]

Hi all,

while experimenting with network apps in L4Re, I experienced some issues:

1. (not important) DHCP isn't working:
The lwip example (ankh/examples/lwip) doesn't seem to work, neither with the integrated DHCP-Server of QEMU, nor with a dnsmasq running on a tap interface plugged into a vde_switch. Workaround: Replacing "dhcp_start(&my_netif);" with "netif_set_default(&my_netif); netif_set_up(&my_netif);" and, beforehand, setting the adress manually with "IP4_ADDR()" (#include <ipv4/lwip/ip4_addr.h>).
I also couldn't get DNS to work.

2. (not so important) some NIC-drivers aren't working:
QEMU-x86 can emulate the following interfaces: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. 
According to its Makefile, ankh supports the following interfaces: NE2K, LOOP, RTL8139, RTL8169, PCNET, E100, E1000, E1000E and UX.
However, of the intersection (ne2k_pci, rtl8139, pcnet und e1000) only ne2k_pci seems to work somewhat reliably.
The others simply don't work with or without some errors being shown by ankh.
With ne2k_pci I can only get a throughput of about 1MB/s, I'm guessing because the card is pretty old.

3. Sporadic delays/ errors:
Although this didn't happen too often, sometimes, when a client tried to send some small data to a server in another QEMU-instance, I experienced delays in the range of about 1 second before the receiver got the data.
On other occassions, a connection could not be established at all. However, no error messages were shown.

4. Multithreaded server issues:
I couldn't manage to get a multithreaded server to work. Neither a server, 
a) which receives data on two different ports, each handled in a separate thread, nor
b) which receives data on a single port, handles however multiple clients simultaneously via separate threads,
did work.

Since a) and b) seem somewhat related I will elaborate only on b):

As long as just one client is connected to the server, sending and receiving on both ends works fine.
As soon as a second client (in another QEMU-instance, all connected via a vde_switch) tries to send data after connecting, both connections from server to the first and second client break down and no data gets through anymore. No errors shown. Finally the write() calls timeout.
Just as I wrote this, it did one time actually work, both clients connected, able to send and receive data. But I couldn't reproduce this success.
After removing the L4Re-specific parts of the code I compiled and ran it on Linux, where it does work flawlessly, even with 6 simultaneous client processes, not just 2.


I'm not sure why these issues occur, either there are bugs somewhere in L4Re's network stack or the NIC drivers, but it's also perfectly possible that I made some mistakes or that vde_switch doesn't work correctly (Although I did test whichever was possible (e.g. 4.a ) also only using simple QEMU TCP sockets). In order to be able to reproduce the results, I attached my configuration (see below and attachments).


Hopefully, someone can tell me what's going on here. I would really be glad.

Thank you!
Josef



----------------------------------------
Configuration:

First of all, I run "sudo vde_switch -daemon -mod 660 -group users". This is only neccessary once; the vde_switch is then used by all QEMU-instances.
To start the scenario, I use a simple script (see attachment run.sh), which starts all the QEMU-instances and sets different MAC-adresses for each instance (in cooperation with Makeconf.boot). server.c and client.c are heavily based on the lwip example.
While server_linux.c and client_linux.c are the stripped-down files I used for testing the network code on linux, all the other attached files are needed for running the L4Re-scenario.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makeconf.boot
Type: application/octet-stream
Size: 197 bytes
Desc: Makeconf.boot
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20150313/39d530f1/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: run.sh
Type: application/x-shellscript
Size: 385 bytes
Desc: run.sh
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20150313/39d530f1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client.cfg
Type: application/octet-stream
Size: 1261 bytes
Desc: client.cfg
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20150313/39d530f1/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.cfg
Type: application/octet-stream
Size: 1261 bytes
Desc: server.cfg
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20150313/39d530f1/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: modules.list
Type: application/octet-stream
Size: 1647 bytes
Desc: modules.list
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20150313/39d530f1/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client.c
Type: text/x-csrc
Size: 3618 bytes
Desc: client.c
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20150313/39d530f1/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.c
Type: text/x-csrc
Size: 3965 bytes
Desc: server.c
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20150313/39d530f1/attachment-0001.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client_linux.c
Type: text/x-csrc
Size: 1277 bytes
Desc: client_linux.c
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20150313/39d530f1/attachment-0002.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server_linux.c
Type: text/x-csrc
Size: 1648 bytes
Desc: server_linux.c
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20150313/39d530f1/attachment-0003.c>