Opened 15 years ago
Last modified 9 years ago
#3146 closed defect
Host cannot connect to guest using 2.1.2 host network interface — at Initial Version
Reported by: | Mike Sadd | Owned by: | |
---|---|---|---|
Component: | network/hostif | Version: | VirtualBox 2.1.2 |
Keywords: | Cc: | ||
Guest type: | Linux | Host type: | Linux |
Description
Just installed VirtualBox 2.1.2 Linux (64bit) on Ubuntu 8.10. Enabled the new host interface connection using the kernel module, with much easier set-up than 2.0.6.
Most connections work very well, in that the Guest can connect to all machines, and all other machines on the sub-net except the host can connect into the guest.
One issue is the connection from the host into the guest, similar to the issue in tickets #3017, #3056, #3080. Tried the patch mentioned there, but it appears to be applied already in 2.1.2 and in any case did not correct the behavior.
To illustrate issue, consider the result of tcdump while using nc to establish a tcp connection.
On the guest system (ip 192.168.0.14), executed:
nc -l 1234
On the host system (ip 192.168.0.17), executed:
nc 192.168.0.14 1234
No connection is established. The output of tcdump is:
# tcpdump -n -i eth1 port 1234 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 02:18:18.822102 IP 192.168.0.17.59399 > 192.168.0.14.search-agent: S 975096716:975096716(0) win 5840 <mss 1460,sackOK,timestamp 3008047 0,nop,wscale 7> 02:18:18.822102 IP 192.168.0.14.search-agent > 192.168.0.17.59399: S 306608439:306608439(0) ack 975096717 win 5792 <mss 1460,sackOK,timestamp 465234 3008047,nop,wscale 5> 02:18:18.822102 IP 192.168.0.17.59399 > 192.168.0.14.search-agent: . ack 1 win 46 <nop,nop,timestamp 3008047 465234> 02:18:18.824493 IP 192.168.0.14.search-agent > 192.168.0.17.59399: R 306608440:306608440(0) win 0 02:18:21.349578 IP 192.168.0.14.search-agent > 192.168.0.17.59399: R 0:0(0) win 0 02:18:21.349769 IP 70.116.89.60.9367 > 192.168.0.14.search-agent: R 0:0(0) win 0 ^C 6 packets captured 6 packets received by filter 0 packets dropped by kernel
For comparison, if nc 192.168.0.14 is executed on a third host on the subnet, it works fine:
# tcpdump -n -i eth1 port 1234 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 02:19:20.942878 IP 192.168.0.3.dict-lookup > 192.168.0.14.search-agent: S 2628089796:2628089796(0) win 5840 <mss 1460,sackOK,timestamp 34219645 0,nop,wscale 2> 02:19:20.943098 IP 192.168.0.14.search-agent > 192.168.0.3.dict-lookup: S 1287294433:1287294433(0) ack 2628089797 win 5792 <mss 1460,sackOK,timestamp 527353 34219645,nop,wscale 5> 02:19:20.944878 IP 192.168.0.3.dict-lookup > 192.168.0.14.search-agent: . ack 1 win 1460 <nop,nop,timestamp 34219648 527353> 02:19:23.872159 IP 192.168.0.3.dict-lookup > 192.168.0.14.search-agent: F 1:1(0) ack 1 win 1460 <nop,nop,timestamp 34222577 527353> 02:19:23.872159 IP 192.168.0.14.search-agent > 192.168.0.3.dict-lookup: F 1:1(0) ack 2 win 181 <nop,nop,timestamp 530287 34222577> 02:19:23.872159 IP 192.168.0.3.dict-lookup > 192.168.0.14.search-agent: . ack 2 win 1460 <nop,nop,timestamp 34222579 530287> ^C 6 packets captured 6 packets received by filter 0 packets dropped by kernel
One difference may be in the third line of the output.
For host -> guest: [...] . ack 1 win 46 <nop,nop,timestamp 3008047 465234> For external ip->guest: [...] . ack 1 win 1460 <nop,nop,timestamp 34219648 527353>