Re: [Freedos-user] Debian 9 64b / QEMU 2.8.1 / FreeDOS 1.3rc2 as a guest: DHCP requests end up zero-padded
On 1 Jan 2020 at 17:19, Tom Ehlert wrote: > > in short: when debugging network problems, avoid EMM386/JEMMEX. > > HIMEM and friends should be fine, though. > Okay, I'll try to figure out my way through this... I definitely do need something to load all the resident drivers "high" wherever possible, otherwise I'm out of conventional memory. AFAICT the XMS managers are okay for this (e.g. himem.sys). Next, I strongly prefer to stick to FreeDOS because some important scripts use features not supported by the MS-DOS command.com. So first I'll try MS himem.sys under FreeDOS. HimemX.sys did not seem to make a difference compared to JEMMEX... Makes me wonder if JEMMEX with NOEMS would have a chance of working = if NOEMS changes something relevant about the JEMM's "back end behavior", or just disables the EMS interface (front end). Maybe if I cannot get this to work in FreeDOS, I could try a very bare-bones setup in MS-DOS, with hard-coded drivers and their configs, just to see if I have a chance in MS-DOS (= if it makes sense to try to massage all the scripts into MS-DOS syntax / limitations). Thanks for your insight :-) I seem to recall trying to program something in DOS that needed more RAM, and I had a choice of XMS vs. EMS. I picked XMS, because it allowed me to allocate a large window of memory that I could just work with directly. Whereas EMS would swap 64k "pages" in and out of a single 64k window in the "conventional address space"... I really don't know how DOS drivers for PCI devices using MMIO would work without a memory manager / DOS extender (DPMI seems to spring to my mind as the way to have "physical to virtual" mappings established). I seem to recall that the 16bit PCI BIOS calls can arrange a number of things, but the memory mapping is not in its capabilities? Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Bolitare doesn't exit...
January 1, 2020 2:14 PM, "Jim Hall" wrote: > On Sun, Dec 29, 2019 at 9:12 AM wrote: > >> I love Bolitare, but when I'm done playing it would be nice to be able to >> return to freedos. > > That's weird. Bolitare exits for me. Did you click the Games menu, > then click Exit? > > Without the mouse, use Alt-G, then X > > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user I'm running under VirtualBox and with emm386... either of those may be why it exits to a black screen... ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Bolitare doesn't exit...
On Sun, Dec 29, 2019 at 9:12 AM wrote: > > I love Bolitare, but when I'm done playing it would be nice to be able to > return to freedos. That's weird. Bolitare exits for me. Did you click the Games menu, then click Exit? Without the mouse, use Alt-G, then X ___ 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
On 31 Dec 2019 at 13:30, Eric Auer wrote: > > 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. > The e-mail client in Windows that I'm using for mailing lists (Pegasus Mail) uses a fixed maximum line length. Which used to be a rule in the old days... That's why long URL's in message body get line-wrapped and that's why I prefer to attach text with longer lines as a separate file, where the formatting is not subject to the MUA's intelligent interventions... > > 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: > It was just easier to take a photo. To take a screenshot, I'd probably have to install further software into the funny diskless client environment. > 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 > Ohh amazing, it must've taken you quite some effort to type it all. I didn't bother, as it's just a log of a few drivers starting up... > (and that is where QEMU stops - maybe waiting for DHCP responses?) > Yes, that's where the TCP/IP stack (TCPTSR.EXE?) should report "okay, got an IP address" and then some messages about Samba logon. Again Windows or Linux just start up and start working with the emulated NIC, their DHCP queries succeed etc. Just in FreeDOS with JEMMEX or HimemX, I get the DHCP queries zero-padded on the outside - while the drivers seem to be otherwise happy with the emulated network hardware they should cater for. I have a faint awareness of PCI IOMEM mapping to the CPU address space on bare metal, I know how to ask for it in Linux driver source code and I seem to recall seeing that in DPMI as well, but I know next to nothing about how this could interact with a hypervisor (QEMU+KVM) and in what ways the DOS+DPMI environment (or DPMI-less, maybe) can differ from a full-fledged modern OS at the guest side... Maybe Japheth would have a clue, but the last update of his memory manager is several years old... And the version of QEMU that I'm using is not very new, either - if that should matter. Frank ___ 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 Frank, > 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. if experiencing wrong packets, don't use any (J)EMM386. most network cards use DMA to access the buffers to send/receive. in virtual memory environments as created by EMM386, logical addresses and physical addresses are network stacks on top of EMM386 require VDS (Virtual DMA Services) as virtual memory as seen from software are not necessarily identical to physical addresses as seen from the hardware, and must be translated by VDS (virtual DMA Services). while VDS is supported by EMM386 and friends, it's a non-trivial process and might cause problems by itself. living in the QEMU virtual machine doesn't help either ;) in short: when debugging network problems, avoid EMM386/JEMMEX. HIMEM and friends should be fine, though. Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
