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 > 0x0000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ [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&DEV_1209&SUBSYS_11001AF4&REV_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 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. > > > > _______________________________________________ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
