[Freedos-user] New FreeDOSers Monthly Reminder
-- We have only a few rules for posting to the FreeDOS mailing lists: 1. NO HATE SPEECH OR BULLYING Make sure everyone feels safe. Bullying of any kind isn't allowed, and degrading comments about things like race, religion, culture, sexual orientation, gender or identity will not be tolerated. Don't swear. We don't want this mailing list to become what Usenet turned into. 2. NO PROMOTIONS OR SPAM Remember, this group is about FreeDOS. General DOS topics are okay, but try to keep it related to FreeDOS. Self-promotion, spam and irrelevant links aren't allowed. Spammers will be banned. Keep posts on-topic. We set up this mailing list to discuss FreeDOS issues. 3. BE KIND AND COURTEOUS We're all in this together to create a welcoming environment. Let's treat everyone with respect. Healthy debates are natural, but kindness is required. No flame wars. If you feel really strongly against what someone has said, send a reply off-list. -- /* This is an automated message sent out to the mailing list at the first of each month. It is automagically downloaded from http://freedos.sourceforge.net/freedos/lists/remind.txt Feel free to contact John Price if necessary by replying to this message. */ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Debian 9 64b / QEMU 2.8.1 / FreeDOS 1.3rc2 as a guest: DHCP requests end up zero-padded
Hi! As the links got line-wrapped, here are the contents:
> http://support.fccps.cz/download/adv/frr/FreeDos/zero_padded_pkt_dump.txt
contains the following text:
> # tcpdump -n -i tap0
> 16:47:39.592071 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send
> seq 0, rcv seq 0, Flags [Command], length 2586
> 0x:
[etc.]
> ...etc. The last row starts at 0x0a10 and contains 10 bytes.
> http://support.fccps.cz/download/adv/frr/FreeDos/FreeDOS_QEMU_DHCP_hangs.jpg
is a photograph (why not a screenshot?) of this text in QEMU:
Defaulting to NIC found in slot 0x0002.
PCI\VEN_8086_1209_11001AF4_0F
Permanent Node Address: 525400123456
Current Node Address: 525400123456
Configured Speed/Duplex: Auto
TransmitBuffers: 4
ReceiveBuffers: 8
Microsoft DOS TCP/IP Protocol Driver 1.0a
Copyright (c) Microsoft Corporation, 1991. All rights reserved.
Copyright (c) Hewlett-Packard Corporation, 1985-1991. All rights reserved.
Copyright (c) 3Com Corporation, 1985-1991. All rights reserved.
Microsoft DOS TCP/IP NEMM Driver 1.0
MAC/DIS to Packet Driver converter loaded. Version 1.19
Copyrifgt 1991 FTP Software, Inc. All rights reserved.
Portions Copyright(c) 2000-2004 Symantec Corporation
The command completed successfully.
- Starting netbind
MS-DOS LAN Manager v2.1 Netbind
- Starting umb
- Starting tcp/ip
Initializing TCP/IP via DHCP
(and that is where QEMU stops - maybe waiting for DHCP responses?)
> 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
[Freedos-user] Debian 9 64b / QEMU 2.8.1 / FreeDOS 1.3rc2 as a guest: DHCP requests end up zero-padded
...thanks to E.Auer for the hint that my attachments are too large to
be included in the message. See them at the following links:
http://support.fccps.cz/download/adv/frr/FreeDos/zero_padded_pkt_dump.
txt
http://support.fccps.cz/download/adv/frr/FreeDos/FreeDOS_QEMU_DHCP_han
gs.jpg
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.
WPM$SNCH.PM$
Description: Mail message body
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
