Hi, This is a patch to support -net socket,listen ,-net socket,connect and -net socket,mcast for Win32. I used select instead of poll. I set blank space to see disconnecting the socket. Out of band data is not cared. I added listen socket to VLANClient to close socket. Allocated memories are freed when the program finishes. It seems that they are not freed on Linux host. Opened sockets are closed when program finishes. It seems that it is not closed on Linux host.
Here is a patch and binary I used. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060102-vlan-4.patch http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20060102-vlan.zip I took three experiment. Here is a report I made. ping, telnet, ssh and lynx are used as client. I made two copies of Redhat hard disk image and start them at different terminals. ne2k-pci kernel module is loaded so that I can see network interface by ifconfig -a. Overall notices are: It is necessary to set macaddr at the second OS. IP address or localhost is necesary to set listen or connect. Otherwise it is set to 0.0.0.0. Don't start two QEMU using one hard disk image. It will break your hard disk image. CASE 1: Guest-only network Command line options are: term1$ qemu -L ./pc-bios -hda redhat1.img -net nic -net socket,listen=localhost:1234 term2$ qemu -L ./pc-bios -hda redhat2.img -net nic,macaddr=52:54:00:12:34:57 -net socket,connect=localhost:1234 Setinng on guest OS: Redhat1 guest>ifconfig eth0 10.0.2.16 Redhat2 guest>ifconfig eth0 10.0.2.17 Results: ping works between two guests. telnet, ssh work fine between them.. CASE2: One guest using user-mode net, listening socket at the different VLAN bus and the other connecting to the one Command line options are: term1$ qemu -L ./pc-bios -hda redhat1.img -net nic,vlan=1 -net user,vlan=1 -net nic,vlan=2,macaddr=52:54:00:12:34:57 -net socket,vlan=2,listen=localhost:1234 term2$ qemu -L ./pc-bios -hda redhat2.img -net nic,vlan=2,macaddr=52:54:00:12:34:01 -net socket,vlan=2,connect=localhost:1234 Setting on guest OS: Redhat1 guest> dhcpcd eth0 (or dhclinet eth0. If eth0 has been already configured, it is not necessary to do this.) (eth0 will get 10.0.2.15 or 10.0.2.16.) Redhat1 guest> ifconfig eth1 192.168.10.2 The second guest OS does not have DHCP server so that it is necessary to set IP address. Redhat2 guest> ifconfig eth0 192.168.10.3 Redhat2 guest> route add default gw 192.168.10.2 eth0 Results: telnet and ssh works between guests. lynx works on Redhat1. It is necessary to set Redhat1 as a router to browse the Internet from Redhat2. Note: VLAN ID is NOT necessary the same between guests. Port number (in this case 1234) determines which bus is used. CASE3: One guest using user-mode net and listening socket in the same VLAN bus and the other guest is connecting to the one It doesn't work well but for your infomation. Command line options are: term1$ qemu -L ./pc-bios -hda redhat1.img -net nic -net user -net socket,listen=localhost:1234 term2$ qemu -L ./pc-bios -hda redhat2.img -net nic,macaddr=52:54:00:12:34:01 -net socket,connect=localhost:1234 Setting on guest OS: Redhat1 guest> dhcpcd eth0 (Or dhclient eth0) The second guest OS gets IP address from DHCP server but it is the same IP as the first OS's IP. It is necessary to set it manually. Redhat2 guest> ifconfig eth0 10.0.2.17 Redhat2 guest> route add default gw 10.0.2.2 eth0 Results: telnet sometimes works but sometimes refuse to connect. When telnetd is working on connected guest, it can be success. When ssh is used, RSA key is saved at the first time but failed with this message. Write failed: Connection reset by peer. After second time, it failed with this message. ssh_exchange_identification: read: Connection Reset by peer. I can browse the Internet from both Redhat1 and Redhat2. Notes: This case does not work well. It is not necessary to set Redhat1 as router to browse the Internet from Redhat2. It is good if case 3 works well, but it has a problem. These results are the same as on Linux host. For more information. http://www.h7.dion.ne.jp/~qemu-win/HowToNetwork-en.html#vlan Regards, Kazu _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
