VirtualBox

Ticket #7298 (closed defect: obsolete)

Opened 4 years ago

Last modified 3 months ago

bridged networking is not working

Reported by: pva Owned by:
Priority: major Component: network/hostif
Version: VirtualBox 3.2.8 Keywords:
Cc: Guest type: Windows
Host type: Linux

Description (last modified by frank) (diff)

I've configured bridged networking for windows XP SP3 guest on eth0 interface of my PC. Now, I've set 192.168.56.103/24 - for windows and 192.168.56.35/24 for linux (manually, no dhcp because dhcp is not working too, I see requests but no answers from host) but still I'm unable to ping neither from windows linux, neither from linux windows. Attaching tcpdump shows different pictures in this both cases:

If I ping from windows linux host I do see arp requests like:

10:11:11.332662 ARP, Request who-has 192.168.56.35 tell 192.168.56.103, length 46

If I ping from linux windows I see NO packets - they are missed in limbo.

As for networking setup on host, here it is:

peter@tablet ~ $ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 00:1d:72:8c:4e:ff brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.35/24 brd 192.168.56.255 scope global eth0
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 00:1f:3b:35:50:29 brd ff:ff:ff:ff:ff:ff
4: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
5: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 0e:37:f3:70:e4:9b brd ff:ff:ff:ff:ff:ff
    inet6 fe80::c37:f3ff:fe70:e49b/64 scope link 
       valid_lft forever preferred_lft forever
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 3
    link/ppp 
    inet 10.205.52.219 peer 10.6.6.6/32 scope global ppp0
peter@tablet ~ $ ip route
10.6.6.6 dev ppp0  proto kernel  scope link  src 10.205.52.219 
192.168.56.0/24 dev eth0  proto kernel  scope link  src 192.168.56.35 
127.0.0.0/8 via 127.0.0.1 dev lo 
default via 10.6.6.6 dev ppp0

eth0 is the following controller:

00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network Connection (rev 03)

Attachments

VBox.log Download (63.4 KB) - added by pva 4 years ago.
VBox.log

Change History

Changed 4 years ago by pva

VBox.log

comment:1 Changed 4 years ago by pva

Host's arp table looks this way:

peter@tablet ~ $ ip neigh
192.168.56.103 dev eth0  INCOMPLETE

BTW, bridge-like setup I've managed to obtain with the following crazy way:

  1. I put another host-only network adapter (visible as vboxnet0 on host) (and assigned it 192.168.56.105/24 inside guest OS).
  2. After that I've created bridge br0 between eth0 and vboxnet and set 192.168.56.33/24 IP on br0.
  3. Modified guest's bridge networking to use br0 (same IP address inside guest)
  4. dropped IP address on eth0 (ip addr del 192.168.56.35/24 dev eth0)

And everything works! I'm able to see from guest host and from host guest (both IP addresses):

tablet ~ # ping 192.168.56.105
PING 192.168.56.105 (192.168.56.105) 56(84) bytes of data.
64 bytes from 192.168.56.105: icmp_seq=1 ttl=128 time=2.55 ms
^C
--- 192.168.56.105 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.557/2.557/2.557/0.000 ms
tablet ~ # ping 192.168.56.103
PING 192.168.56.103 (192.168.56.103) 56(84) bytes of data.
64 bytes from 192.168.56.103: icmp_seq=1 ttl=128 time=1.98 ms
^C
--- 192.168.56.103 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.987/1.987/1.987/0.000 ms
tablet ~ # 
C:\Documents and Settings\pva>ping 192.168.56.33

Обмен пакетами с 192.168.56.33 по 32 байт:

Ответ от 192.168.56.33: число байт=32 время<1мс TTL=64
Ответ от 192.168.56.33: число байт=32 время<1мс TTL=64
Ответ от 192.168.56.33: число байт=32 время<1мс TTL=64

Статистика Ping для 192.168.56.33:
    Пакетов: отправлено = 3, получено = 3, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
    Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек
Control-C
^C
C:\Documents and Settings\pva>

Yea, I have no ideas how this works but it does :)

comment:2 Changed 4 years ago by pva

And probably also related: this is kernel 2.6.34-gentoo-r3 (2.6.34.2 with few additional patches).

comment:3 Changed 4 years ago by frank

Is there any firewall involved? Note that Windows usually blocks ICMP requests by default so please try to disable the Windows firewall first.

comment:4 Changed 4 years ago by pva

No firewall. Just plain windows XP installation and iptables are all ACCEPT in linux. Also note that ping works in crazy configuration I've posted above...

comment:5 Changed 4 years ago by frank

  • Component changed from network to network/hostif

But the plain Windows XP installation actually does block ICMP...

comment:6 Changed 4 years ago by vl409

I confirm problems with bridged networking setup.

Set Vbox to use bridged networking with tap0 interface. Start Vbox, then add tap0 to the bridge: brctl addif br0 tap0. Networking does not work, although you can see packets on tap0 from host, but neither host's br0 nor vbox's adapter don't receive packets from peer.

Now stop Vbox machine and exit from Vbox. Start Vbox and see that networking works fine.

I.e. Vbox bridged networking won't work with host interface that was added to bridge later than vbox started. It used to work for last 2 years for me without problems.

P.S. Versions:

VirtualBox 3.2.8 r64453 Linux-2.6.31-gentoo-r6-x86_64-Intel-R-_Core-TM-2_Duo_CPU_E8500_@_3.16GHz-with-gentoo-2.0.1

comment:7 Changed 3 years ago by aleksey

pva,

The output of ip addr command looks a bit weird to me. Was host's eth0 connected to physical cable at the time? In the output the NO-CARRIER flag is set. The qdisc state of eth0 is also down, which means that host OS won't even bother to queue packets for this interface.

comment:8 Changed 3 months ago by frank

  • Status changed from new to closed
  • Resolution set to obsolete
  • Description modified (diff)
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use