From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MFluu-0005d0-Rm for qemu-devel@nongnu.org; Sun, 14 Jun 2009 05:22:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MFluq-0005cM-1o for qemu-devel@nongnu.org; Sun, 14 Jun 2009 05:22:20 -0400 Received: from [199.232.76.173] (port=42160 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MFlup-0005cJ-Pn for qemu-devel@nongnu.org; Sun, 14 Jun 2009 05:22:15 -0400 Received: from mail-ew0-f224.google.com ([209.85.219.224]:59408) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MFlup-000228-50 for qemu-devel@nongnu.org; Sun, 14 Jun 2009 05:22:15 -0400 Received: by ewy24 with SMTP id 24so369912ewy.34 for ; Sun, 14 Jun 2009 02:22:14 -0700 (PDT) MIME-Version: 1.0 Date: Sun, 14 Jun 2009 11:22:14 +0200 Message-ID: <5b31733c0906140222l5fd14448n1545eb4530cae72@mail.gmail.com> From: Filip Navara Content-Type: multipart/mixed; boundary=0016364c7a1d227e48046c4b7a94 Subject: [Qemu-devel] Slirp/uIP incompatibility List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --0016364c7a1d227e48046c4b7a94 Content-Type: multipart/alternative; boundary=0016364c7a1d227e3d046c4b7a92 --0016364c7a1d227e3d046c4b7a92 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, 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. Guest runs uIP in an emulated ARM machine with the AT91SAM7-EK board: $ 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 --0016364c7a1d227e3d046c4b7a92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I'm not sure this worth looking into or fixin= g, but there is an incompatibility between the uIP TCP/IP stack and Slirp a= s used with -net user option.

Guest runs uIP in an= emulated ARM machine with the AT91SAM7-EK board:

$ arm-softmmu/qemu-system-arm.exe -M at91sam -kern= el tests/basic-emac-uip-helloworld-at91sam7x-ek-at91sam7x256-sram.elf -net = nic,model=3Dat91sam,macaddr=3D00: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,=A0the SYN= -ACK packet is prepared. Due to an implementation error it is never sent th= ough and ARP request is sent instead, if the ARP tables are not filled alre= ady (which is always the case for the first connection). After a while Slir= p 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 du= e to mismatched sequence numbers at that point. This repeats practically fo= rever and none of the parties can recover from it (by the means of RST or o= ther way).

If anyone can offer some advice how to resolve it or ho= w the TCP/IP stacks should behave if the first SYN-ACK during the connectio= n establishment is lost I'd be glad. Attached is a packet dump from QEM= U VLAN.

Best regards,
Filip Navara
--0016364c7a1d227e3d046c4b7a92-- --0016364c7a1d227e48046c4b7a94 Content-Type: application/octet-stream; name="dump-uip.pcap" Content-Disposition: attachment; filename="dump-uip.pcap" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fvxja3h00 1MOyoQIABAAAAAAAAAAAAAAAAQABAAAAEAAAAERTDAAnAQAAJwEAAP///////wBFVniavAgARQAB FQABAABAEXnYAAAAAP////8ARABDAQEAAAEBBgCt3hIjAACAAAAAAAAAAAAAAAAAAAAAAAAARVZ4 mrwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAY4JTYzUBATcDAQMG/1ZfoQcQAAAA0lMM AE4CAABOAgAAAEVWeJq8UlQAEjUCCABFEAJAAAAAAEARbJwKAAIC/////wBDAEQCLJCyAgEGAK3e EiMAAAAAAAAAAAoAAg8KAAICAAAAAABFVniavAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABjglNjNQECNgQKAAICAQT///8AAwQKAAICBgQKAAIDMwQAAVGA/wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAx54MAC4BAAAuAQAA////////AEVWeJq8 CABFAAEcAAIAAEARedAAAAAA/////wBEAEMBCAAAAQEGAK3eEiMAAIAAAAAAAAAAAAAAAAAAAAAA AABFVniavAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABjglNjNQEDNgQKAAICMgQKAAIP /83wIUAQAAAA754MAE4CAABOAgAAAEVWeJq8UlQAEjUCCABFEAJAAAEAAEARbJsKAAIC/////wBD AEQCLI2yAgEGAK3eEiMAAAAAAAAAAAoAAg8KAAICAAAAAABFVniavAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABjglNjNQEFNgQKAAICAQT///8AAwQKAAICBgQKAAIDMwQAAVGA/wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAAAFecEADoAAAA6AAAA AEVWeJq8UlQAEjUCCABFAAAsAAIAAEAGYroKAAICCgACDwu1A+gAK/IBAAAAAGACIjhcFAAAAgQF tBYAAACrIAUAQAAAAEAAAAD///////8ARVZ4mrwIBgABCAAGBAABAEVWeJq8CgACDwAAAAAAAAoA AgIAAAAAAAAAAAAAAAAAAAAAAADhH07sFgAAANUgBQAqAAAAKgAAAABFVniavFJUABI1AggGAAEI AAYEAAJSVAASNQIKAAICAEVWeJq8CgACDxsAAACXfw4AOgAAADoAAAAARVZ4mrxSVAASNQIIAEUA ACwAAwAAQAZiuQoAAgIKAAIPC7UD6AAr8gEAAAAAYAIiOFwUAAACBAW0GwAAAMuwDgBAAAAAQAAA AFJUABI1AgBFVniavAgARQAAKAAEAABABmK8CgACDwoAAgID6Au1AAAAKAAr8gJQEAP0kd0AAAAA AAAAANYluvwnAAAAmzMOADoAAAA6AAAAAEVWeJq8UlQAEjUCCABFAAAsAAQAAEAGYrgKAAICCgAC Dwu1A+gAK/IBAAAAAGACIjhcFAAAAgQFtCcAAADXWQ4AQAAAAEAAAABSVAASNQIARVZ4mrwIAEUA ACgABQAAQAZiuwoAAg8KAAICA+gLtQAAACgAK/ICUBAD9JHdAAAAAAAAAADM2OQXMwAAAGzoDQA6 AAAAOgAAAABFVniavFJUABI1AggARQAALAAFAABABmK3CgACAgoAAg8LtQPoACvyAQAAAABgAiI4 XBQAAAIEBbQzAAAApxQOAEAAAABAAAAAUlQAEjUCAEVWeJq8CABFAAAoAAYAAEAGYroKAAIPCgAC AgPoC7UAAAAoACvyAlAQA/SR3QAAAAAAAAAApngzOz8AAACsoA0AOgAAADoAAAAARVZ4mrxSVAAS NQIIAEUAACwABgAAQAZitgoAAgIKAAIPC7UD6AAr8gEAAAAAYAIiOFwUAAACBAW0PwAAAN7HDQBA AAAAQAAAAFJUABI1AgBFVniavAgARQAAKAAHAABABmK5CgACDwoAAgID6Au1AAAAKAAr8gJQEAP0 kd0AAAAAAAAAAB7W91g= --0016364c7a1d227e48046c4b7a94--