Configure QEMU (Guest Debian-9.0 Sparc64 - Host Ma

Firstly, with a QEMU Virtual Machine (Debian Sparc64 Etch 4.0), I have been able successfully to get ssh and scp commands from Guest to Host (MacOS Hight Sierra OS 10.13.3).

I wanted only to transfer files between guest and host.

To get it, I have followed this tutorial :

1) I have installed TUN/TAP drivers

2) Launching QEMU like this :

qemu-system-sparc -boot c -hda debian_etch.img -m 512M -net nic -net tap,script=no,downscript=no

3) Once VM booted, do on MacOS host : ifconfig tap0 192.168.10.1

4) On Debian Etch host, into /etc/network/interfaces :

auto eth0
iface eth0 inet static
address 192.168.10.2
netmask 255.255.255.0
gateway 192.168.10.1

and doing : /etc/init.d/networking restart

5) Finally, make on guest: $ scp -r dir user_host@192.168.10.1:~/

Now, I would like to get the same thing with a "Debian Sparc64 Stretch 9.0" guest.

It seems that ifconfig is deprecated with recent versions of Debian.

Anyway, I tried to launch the Sparc64 image with :

qemu-system-sparc64 \
-drive file=debian-9.0-sparc64.qcow2,if=none,id=drive-ide0-0-1,format=qcow2,cache=none \
-m 1024 \
-boot c \
-net nic \
-net tap,ifname=tap0,script=no,downscript=no \
-nographic

and do again the steps 1),3),4) but unfortunately, ssh and scp from guest don't work.

I must make notice that with this Debian Sparc64 9.0 guest, network logical name is changing (maybe for each boot). For example, /etc/network/interfaces contains :

auto enp0s5
allow-hotplug enp0s5
iface enp0s5 inet static
address 192.168.10.2
netmask 255.255.255.0
gateway 192.168.10.1

Finally, I get from guest the following result :

# ssh user_host@192.168.10.1
  ssh: connect to host 192.168.10.1 port 22: No route to host

ip a gives :

# ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.2/24 brd 192.168.10.255 scope global enp0s5
       valid_lft forever preferred_lft forever
    inet6 fec0::5054:ff:fe12:3456/64 scope site mngtmpaddr dynamic 
       valid_lft 86207sec preferred_lft 14207sec
    inet6 fe80::5054:ff:fe12:3456/64 scope link 
       valid_lft forever preferred_lft forever

If someone could give me some clues to fix it and get ssh/scp commands to work from guest to host (I have not network on Guest and no sshd server, so I want only the direction guest-->host for ssh/scp).

UPDATE 1:

I keep on debug this issue.

1) First, from this link, I rename at each boot the network interface of guest "Debian 9.0 Sparc64" to eth0 :

vi /etc/udev/rules.d/10-network.rules

   SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="52:54:00:12:34:56", NAME="eth0"

with MAC adress given by :

$ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.2/24 brd 192.168.10.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe12:3456/64 scope link 
       valid_lft forever preferred_lft forever

2) I used tcpdump on TAP interface of the host MacOS High Sierra :

# tcpdump -vv -i tap0
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:23:06.112155 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:06.112228 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:07.128440 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:07.128499 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:08.152323 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:08.152381 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:11.119346 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:11.119396 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:12.120190 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:12.120250 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:13.145028 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:13.145075 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:16.127525 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:16.127575 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28
00:23:17.145202 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.1 tell 192.168.10.2, length 46
00:23:17.145272 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown), length 28

Should I conclude that guest (192.168.10.2 on guest /etc/network/interfaces) and host (192.168.10.1 set by ifconfig tap0 192.168.10.1) are communicating, since I see both adresses with tcpdump above ?

If I do a tcpdump -vv -i tap0 on host while I restart networkin on guest, I get :

00:27:07.648620 IP6 (hlim 1, next-header Options (0) payload length: 36) :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
00:27:07.804644 IP6 (hlim 1, next-header Options (0) payload length: 36) :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
00:27:08.569140 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) :: > ff02::1:ff12:3456: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::5054:ff:fe12:3456
      unknown option (14), length 8 (1): 
        0x0000:  3bd4 4c86 3dd6
00:27:08.612632 IP (tos 0x0, ttl 255, id 37381, offset 0, flags [none], proto UDP (17), length 118)
    192.168.10.1.mdns > 224.0.0.251.mdns: [udp sum ok] 0 PTR (QU)? 6.5.4.3.2.1.e.f.f.f.0.0.4.5.0.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
00:27:09.592322 IP6 (hlim 1, next-header Options (0) payload length: 36) fe80::5054:ff:fe12:3456 > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
00:27:09.592483 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::5054:ff:fe12:3456 > ip6-allrouters: [icmp6 sum ok] ICMP6, router solicitation, length 16
      source link-address option (1), length 8 (1): 52:54:00:12:34:56
        0x0000:  5254 0012 3456
00:27:09.616466 IP (tos 0x0, ttl 255, id 18614, offset 0, flags [none], proto UDP (17), length 118)
    192.168.10.1.mdns > 224.0.0.251.mdns: [udp sum ok] 0 PTR (QM)? 6.5.4.3.2.1.e.f.f.f.0.0.4.5.0.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
00:27:09.976787 IP6 (hlim 1, next-header Options (0) payload length: 36) fe80::5054:ff:fe12:3456 > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]

Are there useful informations in these messages, in order to get ssh/scp from guest to host ?

Finally, is it normal to have the following state (UNKNOWN) for guest eth0 :

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN

UPDATE 2: I tried also to launch by using guestfwd flag with "-net tap" flag like this :

qemu-system-sparc64 \
-boot c \
-hda debian-9.0-sparc64.qcow2 \
-net nic \
-net tap,ifname=tap0,script=no,downscript=no \
-net 'user,guestfwd=tcp::22-tcp::22' \
-m 1024 \
-nographic

But still no ssh access from guest to host.

I don't know if, into -net 'user,guestfwd=tcp::22-tcp::22', in which order I have to put the IP of guest and host and the ports to use for each of them (I used here 22 for both)

If someone could give me some precisions about "guestfwd" flag.

UPDATE 3 :

Finally, the issue is fixed by doing on MacOS host (as root) :

1) set IP 190.168.10.1 on bridge0 with "ifconfig bridge0 192.168.10.1"

2) Launch Qemu with following command :

qemu-system-sparc64 \
-boot c \
-hda debian-9.0-sparc64.qcow2 \
-device virtio-balloon \
-net nic,model=virtio,macaddr=52:54:00:12:34:56 \
-vga none \
-net tap,ifname=tap0,script=no,downscript=no \
-m 1024 \
-nographic

MAC Adress 52:54:00:12:34:56 is important.

3) Once Qemu is booted, add tap0 interface to bridge0 : ifconfig bridge0 addm tap0

4) Finally, from guest Debian Sparc64, I can connect to MacOS host with (as simple user or root) :

ssh user_host@192.168.10.1

Some remarks:

Yes, ifconfig is deprecated, but to my best knowledge, it is so since at least six years or so, and it still is here ... which has its reasons. I think you could use it without bad conscience.

Regarding your tcpdump excerpt: Your feeling that it contains useful information is right. It does not show a real communication between guest and host, though, but it shows ARP queries. ARP is the Address Resolution Protocol and is needed for the following reason:

Basically, as long as TCP/IP is stacked on top of Ethernet, computers (whether or not they are virtual) need to know the Ethernet hardware address (MAC (Media Access Control) address) of their communication partners.

So if a computer A with IP address a.a.a.a wants to talk to a computer B with IP address b.b.b.b, A needs to know B's MAC address first. Therefore, A sends an Ethernet broadcast frame into the local Ethernet segment (basically, a broadcast frame is a frame which goes to all machines connected to the respective segment), asking: "I need to talk to the guy which has IP address b.b.b.b. If any of you guys out there has this IP address, what is your Ethernet MAC address?".

Your tcpdump excerpt shows that this ARP resolution fails. Your guest asks over and over again without ever getting an answer. As long as this is the case, the guest is not able to do any TCP/IP communication with the host.

So your problem was not related to SCP/SSH only, but to the IP protocol in general. For example, the guest would not have been able to show a web site which is located on the host.

Furthermore, since the host did not feel like sending an answer, any other guest would have had the same problem. I strongly assume that your old debian etch would have failed the same way if you had started its VM exactly the same way and on exactly the same host with absolutely identical configuration as the the VM with the new debian stretch.

Of course, ARP requests from the guest first get to the bridge where the guest VM's TAP is connected. As long as that bridge does not have the IP address assigned the guest asks for, the guest's ARP requests won't be answered. This problem is usually solved in the following way:

On the host, take the IP address away from the physical network interface and assign it to the bridge. Then the bridge answers the guest's ARP queries. But this doesn't get you anywhere yet, because now you can't use the host's physical network interface any more (you have taken away its IP address).

Therefore, you connect the host's physical network interface to the bridge as well. Usually, this is a static configuration, i.e. it is not done dynamically when starting VMs. This means that the OS on the host is configured to create a bridge and to add its physical network interfaces to the bridge upon startup. In contrast, the guests' TAPs are added dynamically to the bridge when the guests are started, and are removed from the bridge when the guests are shut down.

Dynamically adding and removing the guests' TAPs to the host's bridge is often done by the upscript and downscript parameters which you are giving to the -tap ... configuration option. Obviously, you are doing this manually (item 3 of your UPDATE 3).

To summarize, your problem was that the host did not answer the guest's ARP queries. This happened because those queries get to the bridge where the VM's TAP is attached to, but you had not assigned an IP address to that bridge (to be more precise, at least not the IP address the guest's ARP queries were asking for).