I thought that the mac address in the qemu command had to be the same as the link/ether address of the tap device. Should I make one up and use that in the qemu command? Thanks.
On Sat, Aug 25, 2018, 22:49 hiro <23h...@gmail.com> wrote: > the qemu error seems helpful: how did you chose mac=C6:1C:63:D9:91:1D > in the qemu command? i see no mention in the fqa that it should be the > same as the hypervisor's interface! > > On 8/25/18, Alexander Kapshuk <alexander.kaps...@gmail.com> wrote: > > Thanks Hiro and Bakul for your prompt responses. > > > > Here's what I've got to report... > > > > I brought tap0 as user root: > > ip link set dev tap0 up > > > > ip addr show dev tap0 > > 4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > > state UP group default qlen 1000 > > link/ether c6:1c:63:d9:91:1d brd ff:ff:ff:ff:ff:ff > > inet 10.0.0.1/24 scope global tap0 > > valid_lft forever preferred_lft forever > > inet6 fe80::c41c:63ff:fed9:911d/64 scope link > > valid_lft forever preferred_lft forever > > > > ping -c4 10.0.0.2 > > PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. > > From 10.0.0.1 icmp_seq=1 Destination Host Unreachable > > From 10.0.0.1 icmp_seq=2 Destination Host Unreachable > > From 10.0.0.1 icmp_seq=3 Destination Host Unreachable > > From 10.0.0.1 icmp_seq=4 Destination Host Unreachable > > > > --- 10.0.0.2 ping statistics --- > > 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 75ms > > pipe 4 > > > > # In qemu I got this output: > > arpreq: 10.0.0.1 also has ether address c61c63d9911d > > > > # Tcpdump output on Linux host: > > tcpdump -nS -vv -i tap0 > > tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size > > 262144 bytes > > 22:12:40.302180 IP6 (hlim 255, next-header ICMPv6 (58) payload length: > > 16) fe80::c41c:63ff:fed9:911d > ff02::2: [icmp6 sum ok] ICMP6, router > > solicitation, length 16 > > source link-address option (1), length 8 (1): c6:1c:63:d9:91:1d > > 0x0000: c61c 63d9 911d > > 22:12:47.874535 IP (tos 0x0, ttl 1, id 18152, offset 0, flags [DF], > > proto UDP (17), length 195) > > 10.0.0.1.49968 > 239.255.255.250.1900: [udp sum ok] UDP, length 167 > > 22:12:48.875587 IP (tos 0x0, ttl 1, id 18675, offset 0, flags [DF], > > proto UDP (17), length 195) > > 10.0.0.1.49968 > 239.255.255.250.1900: [udp sum ok] UDP, length 167 > > 22:12:49.875963 IP (tos 0x0, ttl 1, id 19386, offset 0, flags [DF], > > proto UDP (17), length 195) > > 10.0.0.1.49968 > 239.255.255.250.1900: [udp sum ok] UDP, length 167 > > 22:12:50.876052 IP (tos 0x0, ttl 1, id 20194, offset 0, flags [DF], > > proto UDP (17), length 195) > > 10.0.0.1.49968 > 239.255.255.250.1900: [udp sum ok] UDP, length 167 > > 22:13:25.356189 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > 10.0.0.2 tell 10.0.0.1, length 28 > > 22:13:26.382153 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > 10.0.0.2 tell 10.0.0.1, length 28 > > 22:13:27.406149 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > 10.0.0.2 tell 10.0.0.1, length 28 > > 22:13:28.430247 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > 10.0.0.2 tell 10.0.0.1, length 28 > > 22:13:29.454154 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > 10.0.0.2 tell 10.0.0.1, length 28 > > 22:13:30.478150 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > 10.0.0.2 tell 10.0.0.1, length 28 > > > > Thanks. > > On Sat, Aug 25, 2018 at 9:29 PM Bakul Shah <ba...@bitblocks.com> wrote: > >> > >> On Sat, 25 Aug 2018 14:20:44 +0300 Alexander Kapshuk > >> <alexander.kaps...@gmail.com> wrote: > >> > I am trying to follow the instructions given here: > >> > > >> > http://fqa.9front.org/fqa3.html#3.3.1.4.4 > >> > 3.3.1.4.4 - Linux TAP > >> > > >> > Here's what I've done so far: > >> > (1). Set up a tap0 device as user root: > >> > ip tuntap add dev tap0 mode tap user sasha > >> > ip address add 10.0.0.1/24 dev tap0 > >> > > >> > ip addr show dev tap0 > >> > 4: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group > >> > default qlen 1000 > >> > link/ether c6:1c:63:d9:91:1d brd ff:ff:ff:ff:ff:ff > >> > inet 10.0.0.1/24 scope global tap0 > >> > valid_lft forever preferred_lft forever > >> > >> I see that tap0 state is DOWN. Try bringing it up. > >> If that still doesn't work, run > >> tcpdump -ni tap0 > >> and tell us what you discover. > >> > > > > > >
