dnsmasq failure when running make boot

[VladNastase]

When running make boot dnsmasq fails to start and the guest gets assigned a random ip, not in the same subnet as tap0.
Here's the output of make boot:

$ make boot
qemu/create_net.sh tap0

dnsmasq: TFTP directory /home/v/school/so2/linux/tools/labs/tftp inaccessible: Permission denied
qemu/create_net.sh tap1

dnsmasq: TFTP directory /home/v/school/so2/linux/tools/labs/tftp inaccessible: Permission denied
/home/v/school/so2/linux/tools/labs/templates/assignments/6-e100/nttcp -v -i &
nttcp-l: nttcp, version 1.47
nttcp-l: running in inetd mode on port 5037 - ignoring options beside -v and -p
bind: Address already in use
nttcp-l: service-socket: bind:: Address already in use, errno=98
ARCH=x86 qemu/qemu.sh -kernel /home/v/school/so2/linux/arch/x86/boot/bzImage -device virtio-serial -chardev pty,id=virtiocon0 -device virtconsole,chardev=virtiocon0 -serial pipe:pipe1 -serial pipe:pipe2 -netdev tap,id=tap0,ifname=tap0,script=no,downscript=no -net nic,netdev=tap0,model=virtio -netdev tap,id=tap1,ifname=tap1,script=no,downscript=no -net nic,netdev=tap1,model=i82559er -drive file=core-image-sato-qemux86.ext4,if=virtio,format=raw -drive file=disk1.img,if=virtio,format=raw -drive file=disk2.img,if=virtio,format=raw --append "root=/dev/vda loglevel=15 console=hvc0" --display none -s -m 256
char device redirected to /dev/pts/0 (label virtiocon0)

ifconfig on the guest:

root@qemux86:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 52:54:00:12:34:56  
          inet addr:169.254.170.68  Bcast:169.254.255.255  Mask:255.255.0.0
          inet6 addr: fe80::5054:ff:fe12:3456%134535719/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:55 errors:0 dropped:0 overruns:0 frame:0
          TX packets:89 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:7215 (7.0 KiB)  TX bytes:29578 (28.8 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1%134535719/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:380 (380.0 B)  TX bytes:380 (380.0 B)

ifconfig on the host:

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:cb:83:ab:88  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s20f0u1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.10  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::16a6:9ec0:ab75:7d3a  prefixlen 64  scopeid 0x20<link>
        ether 00:0e:c6:ae:b3:ea  txqueuelen 1000  (Ethernet)
        RX packets 1462327  bytes 1088076753 (1.0 GiB)
        RX errors 0  dropped 30  overruns 0  frame 0
        TX packets 1074357  bytes 610418490 (582.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 7112  bytes 531925 (519.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7112  bytes 531925 (519.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.213.0.1  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::748a:4aff:fe32:6639  prefixlen 64  scopeid 0x20<link>
        ether 76:8a:4a:32:66:39  txqueuelen 1000  (Ethernet)
        RX packets 16300  bytes 2065161 (1.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 17409  bytes 37152107 (35.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.30.0.1  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::3c79:7cff:fe54:c83a  prefixlen 64  scopeid 0x20<link>
        ether 3e:79:7c:54:c8:3a  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1879  bytes 280948 (274.3 KiB)
        TX errors 0  dropped 36 overruns 0  carrier 0  collisions 0

wlo1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.11  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::a841:7ca2:68eb:2008  prefixlen 64  scopeid 0x20<link>
        ether b4:69:21:e8:26:32  txqueuelen 1000  (Ethernet)
        RX packets 2769  bytes 225431 (220.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1859  bytes 310461 (303.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Adding --tftp-no-fail to the dnsmasq command in create_net.sh fixes it for now as it lets dnsmasq start, but I don't know what is the usage of tftp and if it will be needed in the future.

Aditional info

dnsmasq version: 2.84rc2
qemu version: 5.2.0

[dddddddd123456233512233]

Adding --tftp-no-fail to the dnsmasq command in create_net.sh fixes it for now as it lets dnsmasq start，i do not known，could you tell me it

[johankor]

I'm encountering the same problem running Fedora 36. I worked around it by using the QEMU networking helper scripts. Ensure libvirtd service is running (it will—probably among a wealth of other things—set up a bridge we can use) by checking output of systemctl status libvirtd. Verify that the bridge is present using ip:

$ ip link
[snip]
virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc <snip>
 link/ether 52:54:00:c1:6c:b4 brd ff:ff:ff:ff:ff:ff

Next, modify the QEMU_OPTS in the QEMU makefile as follows:

-       -netdev tap,id=tap0,ifname=tap0,script=no,downscript=no -net nic,netdev=tap0,model=virtio \
-       -netdev tap,id=tap1,ifname=tap1,script=no,downscript=no -net nic,netdev=tap1,model=i82559er \
+       -nic bridge,br=virbr0,model=virtio-net-pci \

If ssh fails as follows:

ssh root@qemu-guest-hostname
Unable to negotiate with qemu-guest-hostname port 22: no matching host key type found. Their offer: ssh-rsa

Either fix the ssh server set-up on the guest, or ignore the warning:

ssh -oHostKeyAlgorithms=+ssh-rsa root@qemu-guest-hostname 

I realize this issue is really old, but I suspect it affects more Fedora users. A more recent similar issue was opened in #300.

[johankor]

In order to get scp to work, we need an additional flag: -O (capital letter o).

-O Use the original SCP protocol for file transfers instead of the SFTP protocol. Forcing the use of the SCP protocol may be necessary for servers that do not implement SFTP, for backwards-compatibility for particular filename wildcard patterns and for expanding paths with a ‘~’ prefix for older SFTP servers.

Example:

scp -O -oHostKeyAlgorithms=+ssh-rsa <files-to-copy> root@<hostname/IP>: