2

I am running SunOS 4.1.4 (those were the days...) under QEMU, networked via a tap device on the host. I'm starting the vm like this...

qemu-system-sparc \
    -rtc base=utc \
    -drive file=sunos-root.img,format=raw,bus=0,unit=0 \
    -drive file=sunos-home.img,format=raw,bus=0,unit=1 \
    -drive file=sunos-gnu.img,format=raw,bus=0,unit=2 \
    -nic tap,br=virbr0,helper=/usr/libexec/qemu-bridge-helper \
    -nographic

...and everything works great, except for networking, which seems to work only sporadically.

When SunOS comes up, it is running, among other things, a telnet server and and rshell server via inetd. The tap interface is attached to bridge virbr0 (192.1681.22.1), and the SunOS vm is assigned 192.168.122.103:

bash-3.2# ifconfig le0
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet 192.168.122.103 netmask ffffff00 broadcast 192.168.122.255
        ether 52:54:0:12:34:56

If I'm lucky, I can simply telnet 192.168.122.103 (or rsh) from the host and it Just Works. Other times, it doesn't, and I can't figure out why. If I run this in a loop...

while ! rsh -l root 192.168.122.103 /bin/true; do
  sleep 1
done

...it will eventually work.

Outbound traffic from the virtual machine always works (I can, e.g., reliably telnet 192.168.122.1 22 to get the SSH-2.0-OpenSSH... banner from my host). Running tcpdump on the tap interface when failing to telnet to the vm, I see:

18:39:07.584861 IP 192.168.122.1.40270 > 192.168.122.103.telnet: Flags [S], seq 2038492576, win 64240, options [mss 1460,sackOK,TS val 2376785260 ecr 0,nop,wscale 7], length 0
18:39:07.585177 IP 192.168.122.103.telnet > 192.168.122.1.40270: Flags [S.], seq 2034944001, ack 2038492577, win 4096, options [mss 1460], length 0
18:39:07.585205 IP 192.168.122.1.40270 > 192.168.122.103.telnet: Flags [.], ack 1, win 64240, length 0
18:39:07.585279 IP 192.168.122.1.40270 > 192.168.122.103.telnet: Flags [P.], seq 1:28, ack 1, win 64240, length 27 [telnet DO SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL NAWS, WILL TSPEED, W
ILL LFLOW, WILL LINEMODE, WILL NEW-ENVIRON, DO STATUS, WILL XDISPLOC [|telnet]
18:39:07.773325 IP 192.168.122.103.telnet > 192.168.122.1.40270: Flags [.], ack 28, win 4069, length 0
18:39:10.323018 IP 192.168.122.1.40270 > 192.168.122.103.telnet: Flags [P.], seq 28:30, ack 1, win 64240, length 2
18:39:10.373287 IP 192.168.122.103.telnet > 192.168.122.1.40270: Flags [.], ack 30, win 4067, length 0
18:39:11.401927 IP 192.168.122.1.40270 > 192.168.122.103.telnet: Flags [P.], seq 30:32, ack 1, win 64240, length 2
18:39:11.573256 IP 192.168.122.103.telnet > 192.168.122.1.40270: Flags [.], ack 32, win 4065, length 0
18:39:12.672424 IP 192.168.122.1.40270 > 192.168.122.103.telnet: Flags [P.], seq 32:34, ack 1, win 64240, length 2
18:39:12.773266 IP 192.168.122.103.telnet > 192.168.122.1.40270: Flags [.], ack 34, win 4063, length 0

So you can see that there appears to be traffic passing back and forth, but it's still not working. This is what it looks like when things are successful:

18:41:38.435167 IP 192.168.122.1.40282 > 192.168.122.103.telnet: Flags [S], seq 404147648, win 64240, options [mss 1460,sackOK,TS val 2376936111 ecr 0,nop,wscale 7], length 0
18:41:38.435489 IP 192.168.122.103.telnet > 192.168.122.1.40282: Flags [S.], seq 2054336001, ack 404147649, win 4096, options [mss 1460], length 0
18:41:38.435525 IP 192.168.122.1.40282 > 192.168.122.103.telnet: Flags [.], ack 1, win 64240, length 0
18:41:38.435585 IP 192.168.122.1.40282 > 192.168.122.103.telnet: Flags [P.], seq 1:28, ack 1, win 64240, length 27 [telnet DO SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL NAWS, WILL TSPEED, W
ILL LFLOW, WILL LINEMODE, WILL NEW-ENVIRON, DO STATUS, WILL XDISPLOC [|telnet]
18:41:38.459878 IP 192.168.122.103.telnet > 192.168.122.1.40282: Flags [P.], seq 1:4, ack 28, win 4069, length 3 [telnet DO TERMINAL TYPE [|telnet]
18:41:38.459971 IP 192.168.122.1.40282 > 192.168.122.103.telnet: Flags [.], ack 4, win 64237, length 0
18:41:38.460564 IP 192.168.122.103.telnet > 192.168.122.1.40282: Flags [P.], seq 4:34, ack 28, win 4096, length 30 [telnet WILL SUPPRESS GO AHEAD, DONT NAWS, DONT TSPEED, DONT LFLOW, DONT LI
NEMODE, DONT NEW-ENVIRON, WONT STATUS, DONT XDISPLOC, SB TERMINAL TYPE SEND SE [|telnet]

You can see that this time the Telnet protocol exchange compltes successfully.

It's not a firewall issue (I added a -j ACCEPT rule at the top of the INPUT chain, there are no restrictions on OUTPUT, and this traffic won't hit the FORWARD chain).

Maybe the QEMU lance ethernet driver is just buggy?

1
  • 1
    There is traffic at the tcp layer, but telnetd doesn't seem to reply to the banner negotiation. Does a truss on telnetd show that it received the client hello? I wonder if the interface might start up in some weird mode where the hello isn't tranferred properly (similar to automatic LF→CRLF translations), you might want to compare a tcpdump from the host to one captured from inside the VM. – Ángel Nov 21 '20 at 0:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.