Hello everyone,

I'm using OpenBSD as a guest system with qemu, and currently I'm unable
to get network working.  As far as I can say, the problem is not in my
qemu setup, since I've also tried LFS Linux LiveCD as a guest and it
worked fine (see below).

Host:   Debian Linux testing
Guest:  OpenBSD 4.5
qemu:   0.10.4 w/o kqemu

OpenBSD installs fine, then the following setup is used to run qemu
(skipping tests and irrelevant stuff):

run-openbsd.sh:
------------------------------------------------------------------------
disk_image="`dirname $0`/obsd1.img"
boot="c"
mem="256"
output="-vnc 192.168.1.1:1"
ifname=`sudo tunctl -u $USER -b`
net_nic="nic,vlan=0,model=pcnet,name=obsd1-pcnet0"
net_mode="tap,vlan=0,ifname=${ifname},script=/etc/qemu-ifup"

qemu    -hda $disk_image \
        -boot $boot \
        -m $mem \
        $output \
        -net $net_nic \
        -net $net_mode
------------------------------------------------------------------------

/etc/qemu-ifup:
------------------------------------------------------------------------
ADDR='192.168.3.1 netmask 255.255.255.252'
sudo -p "Password for $0:" /sbin/ifconfig $1 $ADDR
------------------------------------------------------------------------

As a result, I get on Linux (host):

$ ip addr show dev tap0
35: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state 
UNKNOWN qlen 500
    link/ether 00:ff:3f:3b:dc:6b brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.1/30 brd 192.168.3.3 scope global tap0
    inet6 fe80::2ff:3fff:fe3b:dc6b/64 scope link 
       valid_lft forever preferred_lft forever

$ ip route show
192.168.3.0/30 dev tap0  proto kernel  scope link  src 192.168.3.1 
192.168.0.0/30 dev eth1  proto kernel  scope link  src 192.168.0.2 
192.168.255.0/30 via 192.168.1.2 dev eth0 
192.168.2.0/24 dev wlan0  proto kernel  scope link  src 192.168.2.1 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.1 
default via 192.168.0.1 dev eth1

Okay, now in the freshly installed OpenBSD (guest):

# ifconfig pcn
pcn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 52:54:00:12:34:56
        priority: 0
        groups: egress
        media: Ethernet autoselect (autoselect)
        inet 192.168.3.2 netmask 0xfffffffc broadcast 192.168.3.3
        inet6 fe80::5054:ff:fe12:3456%pcn0 prefixlen 64 scopeid 0x1

# netstat -f inet -rn
Routing tables

Internet:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
default            192.168.3.1        UGS        1     1927     -     8 pcn0
127/8              127.0.0.1          UGRS       0        0 33204     8 lo0
127.0.0.1          127.0.0.1          UH         1       62 33204     4 lo0
192.168.3.0/30     link#1             UC         1        0     -     4 pcn0
192.168.3.1        link#1             UHLc       1        5     -     4 pcn0
224/4              127.0.0.1          URS        0        0 33204     8 lo0

And when I ping host's tap0 from it (default gw)

# ping 192.168.3.1
PING 192.168.3.1 (192.168.3.1): 56 data bytes
ping: sendto: Host is down
ping: wrote 192.168.3.1 64 chars, ret=-1
ping: sendto: Host is down
ping: wrote 192.168.3.1 64 chars, ret=-1
ping: sendto: Host is down
ping: wrote 192.168.3.1 64 chars, ret=-1
--- 192.168.3.1 ping statistics ---
6 packets transmitted, 0 packets received, 100.0% packet loss

Because

# arp -an
? (192.168.3.1) at (incomplete) on pcn0

So I launched tcpdump to see what's wrong (on linux host):

$ sudo tcpdump -i tap0 -s 0 -w obsd1.dump

Booted OpenBSD, made few pings, halted it, then analyzed the dump:

$ tcpdump -t -r obsd1.dump
reading from file obsd1.dump, link-type EN10MB (Ethernet)
IP6 fe80::2ff:c6ff:fead:f73e > ip6-allrouters: ICMP6, router solicitation, 
length 16
IP6 fe80::2ff:c6ff:fead:f73e > ff02::16: HBH ICMP6, multicast listener report 
v2, 1 group record(s), length 28
IP6 fe80::2ff:c6ff:fead:f73e > ip6-allrouters: ICMP6, router solicitation, 
length 16
arp who-has 192.168.3.2 tell 192.168.3.2
IP6 :: > ff02::1:ff12:3456: ICMP6, neighbor solicitation, who has 
fe80::5054:ff:fe12:3456, length 24
arp who-has 192.168.3.1 tell 192.168.3.2
arp reply 192.168.3.1 is-at 00:ff:c6:ad:f7:3e (oui Unknown)
arp who-has 192.168.3.1 tell 192.168.3.2
arp reply 192.168.3.1 is-at 00:ff:c6:ad:f7:3e (oui Unknown)
arp who-has 192.168.3.1 tell 192.168.3.2
arp reply 192.168.3.1 is-at 00:ff:c6:ad:f7:3e (oui Unknown)
arp who-has 192.168.3.1 tell 192.168.3.2
arp reply 192.168.3.1 is-at 00:ff:c6:ad:f7:3e (oui Unknown)
arp who-has 192.168.3.1 tell 192.168.3.2
arp reply 192.168.3.1 is-at 00:ff:c6:ad:f7:3e (oui Unknown)

It seems like OpenBSD guest doesn't recieve or ignores arp replies.

I also tried Linux LFS LiveCD to check that it's not my qemu
configuration problem.  Did the ususal:

$ ip link set dev eth0 up
$ ip addr add 192.168.3.2/30 brd 192.168.3.3 dev eth0
$ ping -c 2 192.168.3.1

And it worked fine (and even ping www.ru, with additional setup).
Tcpdump:

$ tcpdump -t  -r lfs.dump
reading from file lfs.dump, link-type EN10MB (Ethernet)
IP6 fe80::2ff:39ff:fe72:bf12 > ip6-allrouters: ICMP6, router solicitation, 
length 16
IP6 fe80::2ff:39ff:fe72:bf12 > ff02::16: HBH ICMP6, multicast listener report 
v2, 1 group record(s), length 28
IP6 fe80::2ff:39ff:fe72:bf12 > ip6-allrouters: ICMP6, router solicitation, 
length 16
IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 
52:54:00:12:34:56 (oui Unknown), length 548
IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 
52:54:00:12:34:56 (oui Unknown), length 548
IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 
52:54:00:12:34:56 (oui Unknown), length 548
arp who-has 192.168.3.1 tell 192.168.3.2
arp reply 192.168.3.1 is-at 00:ff:39:72:bf:12 (oui Unknown)
IP 192.168.3.2 > 192.168.3.1: ICMP echo request, id 31748, seq 0, length 64
IP 192.168.3.1 > 192.168.3.2: ICMP echo reply, id 31748, seq 0, length 64
IP 192.168.3.2 > 192.168.3.1: ICMP echo request, id 31748, seq 256, length 64
IP 192.168.3.1 > 192.168.3.2: ICMP echo reply, id 31748, seq 256, length 64
arp who-has 192.168.3.2 tell 192.168.3.1
arp reply 192.168.3.2 is-at 52:54:00:12:34:56 (oui Unknown)

Additionally, I've found that OpenBSD sends a 'gratuitous arp request',
while linux doesn't, but I think that's not the case.

Any guesses?

Reply via email to