From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <20180825182739.667A1156E400@mail.bitblocks.com> In-Reply-To: From: Alexander Kapshuk Date: Sun, 26 Aug 2018 16:45:55 +0300 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Subject: Re: [9fans] Static ip configuration for a standalone cpu server in qemu on Linux Topicbox-Message-UUID: de3ce73e-ead9-11e9-9d60-3106f5b1d025 With the tap device up: ip addr show dev tap0 4: tap0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 9a:44:ad:1f:39:d9 brd ff:ff:ff:ff:ff:ff inet 10.0.0.1/24 scope global tap0 valid_lft forever preferred_lft forever inet6 fe80::9844:adff:fe1f:39d9/64 scope link valid_lft forever preferred_lft forever And the qemu command using the mac address given in the fqa example: qemu-system-x86_64 \ -boot order=d \ -drive file=$HOME/Plan9.raw.img,format=raw \ -netdev tap,id=eth,ifname=tap0,script=no,downscript=no \ -device e1000,netdev=eth,mac=52:54:00:00:EE:03 And the ether= attribute removed from /lib/ndb/local, Both pings below work now. ping 10.0.0.2 # Linux ip/ping 10.0.0.1 # Plan 9 tcpdump -nS -vv -i tap0 tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 262144 bytes 16:35:00.265147 IP (tos 0x0, ttl 1, id 46876, offset 0, flags [DF], proto UDP (17), length 195) 10.0.0.1.48952 > 239.255.255.250.1900: [udp sum ok] UDP, length 167 16:35:01.266364 IP (tos 0x0, ttl 1, id 47164, offset 0, flags [DF], proto UDP (17), length 195) 10.0.0.1.48952 > 239.255.255.250.1900: [udp sum ok] UDP, length 167 16:35:02.266828 IP (tos 0x0, ttl 1, id 47770, offset 0, flags [DF], proto UDP (17), length 195) 10.0.0.1.48952 > 239.255.255.250.1900: [udp sum ok] UDP, length 167 16:35:03.267406 IP (tos 0x0, ttl 1, id 48737, offset 0, flags [DF], proto UDP (17), length 195) 10.0.0.1.48952 > 239.255.255.250.1900: [udp sum ok] UDP, length 167 16:35:28.213321 IP (tos 0x0, ttl 255, id 5, offset 0, flags [none], proto ICMP (1), length 64) 10.0.0.2 > 10.0.0.1: ICMP echo request, id 46534, seq 24833, length 44 16:35:28.213374 IP (tos 0x0, ttl 64, id 2728, offset 0, flags [none], proto ICMP (1), length 64) 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 46534, seq 24833, length 44 16:35:29.212816 IP (tos 0x0, ttl 255, id 6, offset 0, flags [none], proto ICMP (1), length 64) 10.0.0.2 > 10.0.0.1: ICMP echo request, id 46534, seq 24834, length 44 16:35:29.212873 IP (tos 0x0, ttl 64, id 2867, offset 0, flags [none], proto ICMP (1), length 64) 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 46534, seq 24834, length 44 16:35:30.223989 IP (tos 0x0, ttl 255, id 7, offset 0, flags [none], proto ICMP (1), length 64) 10.0.0.2 > 10.0.0.1: ICMP echo request, id 46534, seq 24835, length 44 16:35:30.224042 IP (tos 0x0, ttl 64, id 2906, offset 0, flags [none], proto ICMP (1), length 64) 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 46534, seq 24835, length 44 16:35:31.223030 IP (tos 0x0, ttl 255, id 8, offset 0, flags [none], proto ICMP (1), length 64) 10.0.0.2 > 10.0.0.1: ICMP echo request, id 46534, seq 24836, length 44 16:35:31.223086 IP (tos 0x0, ttl 64, id 3895, offset 0, flags [none], proto ICMP (1), length 64) 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 46534, seq 24836, length 44 16:35:32.222034 IP (tos 0x0, ttl 255, id 9, offset 0, flags [none], proto ICMP (1), length 64) 10.0.0.2 > 10.0.0.1: ICMP echo request, id 46534, seq 24837, length 44 16:35:32.222090 IP (tos 0x0, ttl 64, id 4241, offset 0, flags [none], proto ICMP (1), length 64) 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 46534, seq 24837, length 44 16:35:33.233714 IP (tos 0x0, ttl 255, id 10, offset 0, flags [none], proto ICMP (1), length 64) 10.0.0.2 > 10.0.0.1: ICMP echo request, id 46534, seq 24838, length 44 16:35:33.233769 IP (tos 0x0, ttl 64, id 4545, offset 0, flags [none], proto ICMP (1), length 64) 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 46534, seq 24838, length 44 On to the standalone CPU + auth server setup instructions now. Thanks very much for all your help. On Sun, Aug 26, 2018 at 7:56 AM Alexander Kapshuk wrote: > > Understood. > I'll give it a try and let you know how I go. > Thanks. > > > On Sun, Aug 26, 2018, 00:20 hiro <23hiro@gmail.com> wrote: >> >> nothing in the fqa mentions the tap device's mac address (which linux >> generated randomly in order not to conflict with whatever you might be >> using on the other side). >> >> look at the tap device as an ethernet interface that is plugged into >> the same L2 switch as the VM's virtual interface. >> >> you don't want mac address collisions in one L2 network, so yes, use a >> different one for the VM. >>