I'm not sure this worth looking into or fixing, but there is an incompatibility between the uIP TCP/IP stack and Slirp as used with -net user option.
$ arm-softmmu/qemu-system-arm.exe -M at91sam -kernel tests/basic-emac-uip-helloworld-at91sam7x-ek-at91sam7x256-sram.elf -net nic,model=at91sam,macaddr=00:45:5
6:78:9a:bc -net user -redir tcp:1000::1000
The guest successfully receives the IP addresses using DHCP and starts to listen on port 1000. Now I try to connect to it from the host machine. When the SYN packet is received in the guest code, the SYN-ACK packet is prepared. Due to an implementation error it is never sent though and ARP request is sent instead, if the ARP tables are not filled already (which is always the case for the first connection). After a while Slirp figures out that no reply was received and sends the SYN again. The guest code thinks that it already sent SYN-ACK and replies with ACK, probably due to mismatched sequence numbers at that point. This repeats practically forever and none of the parties can recover from it (by the means of RST or other way).
If anyone can offer some advice how to resolve it or how the TCP/IP stacks should behave if the first SYN-ACK during the connection establishment is lost I'd be glad. Attached is a packet dump from QEMU VLAN.
Best regards,
Filip Navara
dump-uip.pcap