[Qemu-devel] [Bug 1003054] Re: Socket not closed when a connection ends

[Vincent Autefage]

This implies serious duplication problem in case of reboot :

A [192.168.0.1] <--> B [192.168.0.2]


A# ping 192.168.0.1
PING 192.168.0.1 56(84) bytes of data
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=3.82 ms
64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=0.344 ms
64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=0.325 ms

B# reboot

A# ping 192.168.0.1 
PING 192.168.0.1 56(84) bytes of data
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=3.82 ms
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=3.82 ms (DUP!)
64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=0.344 ms
64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=0.344 ms (DUP!)
64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=0.325 ms
64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=0.325 ms (DUP!)

Vince

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1003054

Title:
  Socket not closed when a connection ends

Status in QEMU:
  New

Bug description:
  Hi,

  I've noticed in the QEMU monitor that when a TCP connection between to
  QEMU virtual machines is closed in one side, the other side is not
  closed. Consequence is that the network behavior is completely messed
  up in case of a reconnection.

  For instance, we consider that we have 2 virtual machines :

  $ qemu -name A -net nic vlan=0 -net socket,vlan=0,listen=127.0.0.1:7000
  $ qemu -name B -net nic vlan=0 -net socket,vlan=0,connect=127.0.0.1:7000

  If the socket of B is closed (error or machine down), the socket in A
  is not closed :

  B % host_net_remove 0 socket.0

  A % info network
    e1000.0: ...
    socket.0: ... (The removed connection)

  B % host_net_add socket vlan=0,connect=127.0.0.1:7000

  A % info network
    e1000.0: ...
    socket.0: ...  (The removed connection)
    socket.1: ...  (The new connection)

  By not perform any close on sockets of A, the new communication
  between A and B is corrupted (duplicated packets, invalid
  transmission, etc.).

  In the case of the close was performed by A, B should detect a problem
  on the socket and  retry a new connection, unfortunately, this is not
  the case.

  
  Those two problems corrupt the dynamicity of a QEMU topology which could be 
strongly problematic for the development of network tools based on QEMU.


  Thanks a lot.
  Vince

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1003054/+subscriptions