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 <23hiro@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.kapshuk@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 <bakul@bitblocks.com> wrote:
>>
>> On Sat, 25 Aug 2018 14:20:44 +0300 Alexander Kapshuk
>> <alexander.kapshuk@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.
>>
>
>