[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Debian 9 64b / QEMU 2.8.1 / FreeDOS 1.3rc2 as a guest: DHCP requests end
From: |
Frantisek Rysanek |
Subject: |
Debian 9 64b / QEMU 2.8.1 / FreeDOS 1.3rc2 as a guest: DHCP requests end up zero-padded |
Date: |
Fri, 27 Dec 2019 18:33:36 +0100 |
Dear everybody,
this is a superficial early question,
just in case this is a known problem,
or to get your feedback ("upgrade the distro
and stick to the distro kernel", etc).
I'm playing with Debian 9 64bit (so far I haven't been motivated to
upgrade) which happens to contain the following QEMU:
QEMU emulator version 2.8.1(Debian 1:2.8+dfsg-6+deb9u8)
Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project
developers
Actually I'm using kernel 5.2.7 on the box (boxes) = "somewhat"
younger, compared to the original 4.9.0 from the Debian repo... ;-)
As a QEMU guest, I'm trying to boot a DOS-based "Client for microsoft
networks", actually the venerable Net Boot Disk 6.5 "distro" based on
FreeDOS and some custom candy.
https://www.netbootdisk.com/
I've unpacked the NBD 6.5 onto an 8MB HDD image and deactivated
the original on-the-fly unpacking into a RAMdisk = so it effectively
boots off a harddisk partition. I've been using it this way for ages,
PXE-booted using PXElinux into a MEMDISK holding the whole HDD
image... I've just been updating the NIC drivers.
Now I'm trying to move this into a QEMU guest, where the disk image
is provided to the guest as an emulated IDE disk drive.
And it basically works - the FreeDOS boots and I can
do things inside the OS and the FS on the emulated disk.
While trying to work around some other problem (some software,
including pciscan.exe by Bart Lagerweij, and the low-level NIC
drivers, were exciting an error in the older FreeDOS 1.0-ish kernel)
I upgraded the guest side to the latest FreeDOS 1.3-rc2.
Unfortunately the BAT scripts involved apparently rely on FreeDOS
syntax, so I cannot easily port the whole thing onto MSDOS 6.22 just
to give it a try...
So I'm at FreeDOS 1.3-rc2, PCISCAN works and the network drivers
appear to load - they report a MAC address etc. I've tried about two
older Intel NIC chips and a Realtek RTL8139 (all of them as emulated
by QEMU).
Now finally for the problem:
The network "client" software consists of several resident layers
that get loaded step by step. And the progress gets stuck
when the TCP/IP stack tries to ask for DHCP = when the
machine just booted tries to actually use the NIC for the first time
to generate traffic on the network. See a screenshot attached.
I believe the misbehaving piece of software is called TCPTSR.EXE .
I'm using QEMU's "-net nic -net bridge" to hook the guest into the
host's LAN. I actually have a soft-bridge instance prepared in the
host OS, before I start QEMU, and Windows PE 7/10 guests work just
fine on top of that arrangement: QEMU instantiates a tap0 and adds
that to the host's soft-bridge, and the Windows guest starts like a
cheetah.
So in that context, in the Debian-based host OS, I've tried sniffing
the traffic coming out of tap0 with tcpdump. And, I'm seeing
something interesting.
In perfect correlation with the DOS guest's DHCP client starting up,
I can see a "packet of all zeroes" every now and then. As if, for
some reason, the DHCP Discovery packets got zero-padded.
A short snippet is attached (packet header, as reported by tcpdump).
I've tried with or without KVM acceleration in QEMU.
I've tried several variants of the emulated NIC hardware.
I've tried JEMMEX (5.78=latest) with NOVDS and I've tried HimemX.EXE.
I've tried booting with Debian's stock SeaBIOS or with a more modern
OVMF UEFI+CSM (got pre-compiled binaries somewhere upstream).
None of this makes a difference, the resulting symptoms are exactly
the same.
The next step would be to upgrade the distro and compile a fresh QEMU
from source. Which would take a bit of effort...
So in that context, I'd be grateful for any opinions if this is worth
the bother, if someone has seen this before etc.
Thanks for your attention :-)
Frank Rysanek
P.S.: the "Debian host" itself is actually PXE-booted in UEFI mode,
with / mounted RW on top of overlayfs on top of a read-only NFS
volume, and the soft-bridge gets inserted early during initrd boot
(before ipconfig asks for DHCP). It's nifty, it all works like a
charm, and it wasn't all that much work. I love Debian. A howto will
follow soon.
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: FreeDOS_QEMU_DHCP_hangs.jpg
Date: 27 Dec 2019, 18:25
Size: 66354 bytes.
Type: JPEG-image
FreeDOS_QEMU_DHCP_hangs.jpg
Description: JPEG image
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: zero_padded_pkt_dump.txt
Date: 27 Dec 2019, 18:23
Size: 1407 bytes.
Type: Text
zero_padded_pkt_dump.txt
Description: Binary data
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Debian 9 64b / QEMU 2.8.1 / FreeDOS 1.3rc2 as a guest: DHCP requests end up zero-padded,
Frantisek Rysanek <=