Re: [Freedos-user] Print via network - a workaround to the Samba bug
Dear gentlemen, today I've tested some ideas... one worked, one did not. 1) put a UNIX-domain named pipe in the Samba share, locally on the server: cd /mnt/samba mknod print.q p chmod 666 print.q The above needs to run as user root. The following can run as an unprivileged user: To test the idea (dry run): while true; do cat print.q; echo "\n Another one:"; done To actually run the print jobs though the printer back end: while true; do lpr -P PRNTEST < print.q; done In the DOS client, having a drive G: mapped to the network share, I can do this (either works): echo "Howdy :-)" >> G:\print.q type autoexec.bat >> G:\print.q copy /Y /B autoexec.bat G:\print.q Before trying this, I was a little worried that especially the "copy" would erase the pipe and replace it with a plain file - that did not happen, the pipe still exists and functions. The named pipe provides a clear job start and job end, inherently, by closing the pipe to the "consumer" process (lpr) when the "producer" has closed his file copy/append operation. In our case, the "producer" runs in DOS, and sends output to the pipe via the CIFS/SMB network filesystem. Note that after some time, lpr times out waiting for data (and exits, and gets respawned). This is normal and probably harmless. As far as I could observe, an lpr waiting for a print job to come does not "block the CUPS queue" in any way. I've also tried prn2file: https://board.flatassembler.net/download.php?id=1086 Unfortunately, this doesn't seem to work right over a Samba share. Nothing ever got printed. The prn2file.com gets loaded, I can configure the port to hook, but when I copy a file to LPT2, it does not fall out of the pipe in the Samba server machine. Interestingly, smbstatus indicates that the pipe is locked in RW mode by something running in the DOS client... Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network - a known bug in Samba
Thanks, Frank: ...while looking for some existing "LPT port redirection software" for DOS, I've first found this proggie: I have tried using that. But I found its documentation limited! And I have not been able to get printing done thereby. It's a little TSR in .COM format that installs in memory, captures any printing on LPT1 (done using the BIOS printing service at INT 17h) into a chunk of XMS memory and upon another invocation, can dump the captured data into a file. So it does not write the file in the background... I thought that the documentation claimed it rewrote the file that I was trying to print! It does write the file in the background and opens the file in "append" mode. I'm gonna try it, hopefully later today. Thank you for your continuing efforts. -- members.iinet.net.au/~kilgallin/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network - a known bug in Samba
...while looking for some existing "LPT port redirection software" for DOS, I've first found this proggie: http://info.elf.stuba.sk/packages/pub/pc/utiltext/lpt2file.zip It's a little TSR in .COM format that installs in memory, captures any printing on LPT1 (done using the BIOS printing service at INT 17h) into a chunk of XMS memory and upon another invocation, can dump the captured data into a file. So it does not write the file in the background... I've taken a look at the code using IDA Pro, just for fun - to confirm my impression that hooking INT 17h is no rocket science... ...and then, I found this: https://board.flatassembler.net/topic.php?t=2319 https://board.flatassembler.net/download.php?id=1086 The download is called prn2fil3.zip . It comes with ASM source code. It does write the file in the background and opens the file in "append" mode. I'm gonna try it, hopefully later today. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network - a known bug in Samba
Thanks to Eric for taking a look at my Wireshark screenshot... I was getting ready to make some PCAP files available, but ultimately it is not needed, because I already know where the problem is :-) After some further investigation, it started dawning on me, that this does look like a bug in Samba after all. That the write_print_file_request probably deserves a complementary response, which the client is possibly awaiting, but the response never comes (just an autonomous ACK from the TCP layer). Another step in the right direction was to set Samba logging to the max for the "lanman" subsystem and see what gets caught. Not much actually, but the last message mentioning reply_printwrite would suggest that smbd indeed called a function that should've transmitted a response to the "write print file request". So... why does no such response ever get tranmitted? reply_printwrite() finally rang a bell with Google :-) Curiously, three months ago some fellow archaeologist in Poland has noticed the same problem (happening to his DOS-based LanMan clients), reported that to the Samba mailing list, and got an immediate response + a fix. To a bug that's been in the Samba code since maybe 2008 :-) https://lists.samba.org/archive/samba/2021-April/235828.html https://bugzilla.samba.org/show_bug.cgi?id=14696 The fix is in 4.14.5 and probably 4.13.9. The Samba package in Ubuntu 20.04 is 4.11.6, released in January 2020. I don't think 4.11 series will get a patch, 4.11.17 is from December 2020. Rather, I'd expect the fix to eventually land in an upcoming LTS release of Ubuntu, which is probably a couple months down the road... https://launchpad.net/ubuntu/+source/samba Obviously there's always the possibility to compile from source... (or pay Samba+ for a binary package.) Side note: Today I've installed DOS 6.22 in a VirtualBox and the MS LanMan 2.2 on top of that: https://www.youtube.com/watch?v=oqMzF41dyvk=624s http://ftpmirror.your.org/pub/misc/ftp.microsoft.com/bussys/Clients/LA NMAN/ It took some manual work to get the Intel e1000 driver massaged in, but in the end it works. Combined with the host instance of Windows 7, another virtual partition with XP, and an external box running Linux, the setup behaved rather erratic - which I put down to the virtual bridge that gets set up by VirtualBox. VM's coming and going, the physical NIC port coming up and down, wireshark getting started on the Win7 host and XP guest, all of that probably takes its toll on the stability of this "virtualized" setup :-) In the end I managed to stabilize the setup enough to make the LanMan 2.2 on DOS first connect to the Ubuntu test server, and demonstrate the same results that I got with my previous MS Network Client 3.0 (probably) on FreeDOS. There are minor differences in the protocol, but the net effect is exactly the same: just the "request" packet, already carrying some payload, gets transmitted, and then the TCP session times out and gets scrapped by the client. I also managed to have the LanMan 2.2 client on DOS connect to another VM running Windows XP, and tried to print something to an XP-based shared printer (dummy, set up just to accept the print job). This worked - indeed the print request needs a response. Interestingly, against XP, the LanMan has used a slightly different protocol version. Starting again with an "Open Print File Request" (and getting a response containing an FID), the next message would be a "Write Raw Request", followed by a "Write Raw Response". Which is in contrast to the "Write Print File Request" seen from that same client against the Samba on Ubuntu. Never mind, this is probably just a cosmetic difference. Enough for today, I guess. Apart from waiting for a fix to Samba, I may try some workarounds through the disk share... something for Bryan to play with if he's interested. I'm thinking of making a named pipe in Linux, and append to it through Samba, if that turns out to work. Not sure that "copy" will be the right tool for this - it cannot be made to "append". And, I suspect that "type" won't cope with binary files (unlike UNIX "cat"). And I was wondering if ddlink might help... no, probably not. Cannot capture and redirect LPT devices, AFAICT. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
Thanks, Michael: I hate to even suggest this, but are you using the /B option on the file copy to indicate that a binary copy is needed? That didn't fix the printing problem. It's the same with /a. The first 5.1 lines of a text file got printed. -- members.iinet.net.au/~kilgallin/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
Just a short update: I've retreated in my footsteps all the way back to my lab at work, and its PXE-booted legacy NetBootDisk profile, and I have to say that the LPT2 obtained via net use lpt2: \\printserver\queue misbehaves *exactly* the same as in my minimized VirtualBox environment, and as on Bryan's bare metal at home. At my workplace, it's miscellaneous bare metal x86 hardware on the client, against a Debian 9 print server with stock Samba of that distro (and lprng printing service). Earlier this year, I just did a quick test and made a rushed conclusion that DOS printing redirection worked fine. Means to me that I should start from a clean sheet - maybe with MS-DOS first, installed from scratch, and MS Network Client installation disks, and see if that makes a difference... That's gonna take me a while. I'm also wondering about stuff such as planting a UNIX named pipe in some directory on the Linux box, that gets served by Samba as a disk share... or just run a script that would wait for a plain file with a pre-configured filename, wait for a few seconds after it stops growing and spool that via lpr or something :-) Ugly workarounds to make printing via "print to file" in the DOS box more seamless. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
Hi Frank, http://support.fccps.cz/download/adv/frr/dosnet/write_print_file_request.png This says that, assuming that 192.168.3.54 is your DOS computer, you got a TCP ACK from the Linux PC (139 to 39183), then SMB tree connect ANDX from the Linux PC, then a MALFORMED PACKET from the DOS PC for SMB open print file, another TCP ACK from the Linux side, followed by a SMB open print file response, then the SMB write print file request from the DOS PC, containing the first 127 (?) bytes of printable text in a 222 byte packet, to which the Linux PC again responds by TCP ACK, but the DOS PC stops sending anything for 45 seconds after that, only to send a TCP FIN much later. So I would worry about the malformed packet. Maybe you also have some packet loss, possibly due to some packet driver configuration issue on the DOS PC? Does it work reliably for example when you use DOS browsers to view larger files offered by web servers? Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
This is a re-post, my first two attempts had too many attachments.
I'm re-attaching just the TXT file being printed, and here are some
relevant screenshots:
http://support.fccps.cz/download/adv/frr/dosnet/ps.png
http://support.fccps.cz/download/adv/frr/dosnet/write_print_file_reque
st.png
I'm giving up on attaching the 90kb PostScript created by CUPS,
nothing interesting in there (see the .PNG render above).
On 16 Jun 2021 at 21:41, Michael Brutman wrote:
>
> I hate to even suggest this, but are you using the /B option on the
> file copy to indicate that a binary copy is needed? Otherwise, the
> first Ctrl-Z in the file will end the file copy prematurely.
>
Dear Mr. Brutman,
first of all thanks for your personal attention and for the infomed
suggestion. I did not know about this pitfall, thanks for weeding
that one out.
This does not appear to be my problem. See the attachments.
The file that I'm sending is a clear text file - I've captured the
standard output of "net help" into a TXT file, and I'm trying to
print that. The TXT file contains no occurrence of the 0x1A character
(26 decimal) - if that's what CTRL+Z in DOS produces.
I'd swear the printing has worked for me, once, in a slightly
different environment (NetBootDisk launched via PXE in our "legacy"
boot profile). I may have been not diligent enough in my testing.
Right now Bryan works in FreeDOS booting from drive C on bare metal,
I'm trying this in a VirtualBox.
I'll have to try again in my PXE environment...
A disk share works fine, files do get copied intact.
Just the LPT redirection fails in this curious way.
BTW, on various occasions during the network startup scripts, the
ancient MS networking stack in DOS seems to wait for no apparent
reason for many seconds, before taking further action. For
comparison, I've tried loading the "packet driver" flavoured stack,
and that loads real fast, the mTCP app suite starts instantly, DHCP
takes like a second to finish etc.
Frank
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: NETHELP.TXT
Date: 15 Jun 2021, 23:23
Size: 1993 bytes.
Type: Text
NETHELP.TXT
Description: Binary data
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
I hate to even suggest this, but are you using the /B option on the file copy to indicate that a binary copy is needed? Otherwise, the first Ctrl-Z in the file will end the file copy prematurely. On Wed, Jun 16, 2021 at 3:37 PM Frantisek Rysanek wrote: > Dear gentlemen, > > on and off, with Bryan we've been playing with Ubuntu, Samba, CUPS > and the MS Network Client running in FreeDOS. And we're facing a dead > end - same symptoms observed by me and by Bryan: > > We can load the MS stack, to the point that we can "net use" network > disk volumes = map a local drive letter to an ARC path from the > server. And the disk is perfectly accessible. > > But, printing is giving us an interesting misbehavior. > We can ask for > net use LPT2: \\server\printqueue > That does succeed. But, whatever we copy to the redirected LPT2 > (we've also tried LPT1 for that matter), we only get a couple lines > printed. Like 4 to 6 lines, if we try to print plain text. > > I've observed the problem with Wireshark. The MS client connects a > TCP session to Samba, they negotiate the protocol version, the client > starts a print request, sends the first packet with an actual > payload, gets a TCP ACK, and the very next TCP packet from the client > to the server has a FIN flag - and the TCP session get gracefully > ended. Interestingly, the client produces one extra packet with an > ACK for the session, after the FIN / FIN+ACK coordinated handshake > has closed the session. Wireshark's TCP tracing marks that extra ACK > packet as a duplicate... > > I have no clue why this is happening. I've tried loading all the > drivers "low" (instead of "high" or UMB). No joy. > > I'm wondering, which of the bunch of drivers and executables (about 8 > of them) is specifically responsible for the printer port redirection > function. And, what could make it close the TCP session prematurely. > Does it perhaps expect a different "pattern of data writes" on the > hooked LPT port service? Which a plain "copy" command does not > satisfy? > > Any ideas are welcome :-) > > Frank > > > > > ___ > 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
Re: [Freedos-user] Print via network
Dear gentlemen, on and off, with Bryan we've been playing with Ubuntu, Samba, CUPS and the MS Network Client running in FreeDOS. And we're facing a dead end - same symptoms observed by me and by Bryan: We can load the MS stack, to the point that we can "net use" network disk volumes = map a local drive letter to an ARC path from the server. And the disk is perfectly accessible. But, printing is giving us an interesting misbehavior. We can ask for net use LPT2: \\server\printqueue That does succeed. But, whatever we copy to the redirected LPT2 (we've also tried LPT1 for that matter), we only get a couple lines printed. Like 4 to 6 lines, if we try to print plain text. I've observed the problem with Wireshark. The MS client connects a TCP session to Samba, they negotiate the protocol version, the client starts a print request, sends the first packet with an actual payload, gets a TCP ACK, and the very next TCP packet from the client to the server has a FIN flag - and the TCP session get gracefully ended. Interestingly, the client produces one extra packet with an ACK for the session, after the FIN / FIN+ACK coordinated handshake has closed the session. Wireshark's TCP tracing marks that extra ACK packet as a duplicate... I have no clue why this is happening. I've tried loading all the drivers "low" (instead of "high" or UMB). No joy. I'm wondering, which of the bunch of drivers and executables (about 8 of them) is specifically responsible for the printer port redirection function. And, what could make it close the TCP session prematurely. Does it perhaps expect a different "pattern of data writes" on the hooked LPT port service? Which a plain "copy" command does not satisfy? Any ideas are welcome :-) Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Print via network
OK, Eric:
https://downloadcenter.intel.com/download/29138/Intel-Ethernet-Adapter-Drivers-for-MS-DOS-
Linux Archive Manager unpacked it!
Maybe you could copy paste a directory listing
of what was in it to the mailing list
{
.
├── APPS
│ └── NVMCHECK
│ └── DOS
│ ├── nvmcheck.exe
│ └── nvmcheck.txt
├── license.pdf
├── license.txt
├── PRO100
│ └── DOS
│ ├── e100b.dos
│ ├── e100beds.nif
│ ├── oemsetup.inf
│ └── protocol.ini
├── PRO1000
│ └── DOS
│ ├── e1000.dos
│ ├── oemsetup.inf
│ └── protocol.ini
├── readme.txt
└── verfile.tic
}
--
members.iinet.net.au/~kilgallin/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
On Mon, 26 Apr 2021 at 19:49, Bryan Kilgallin wrote: > > Linux Archive Manager unpacked it! Great! So, your next step is probably to try to get the MS Network Client. It's included on all the Windows NT Server CDs. If I remember correctly, v3.0 includes sharing functionality -- it makes DOS into a server. You don't want or need that; it takes a *lot* of memory. You just need the client part. I think the preceding version of the MS Client (v2.5 maybe?) is client-only, no server, which is much easier and takes less RAM. Find that, try to install it, and point it at the NDIS directory in that driver you downloaded. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
On 4/26/2021 1:53 PM, Thomas Mueller wrote: roven – Profile: https://about.me/liamproven I think it might be possible to extraxt a self-extracting archive under DOS or other OS with UNZIP. But I see Linux Archive Manager did it for you. 7Zip does it most likely as well... RAlf -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
> On Mon, 26 Apr 2021 at 01:21, Bryan Kilgallin wrote: > > I copied the PRODOS.EXE file to my FreeDOS PC and entered "prodos". > > Which resulted in this error: > > "This program cannot be run in DOS mode.". X-CMAE-Envelope: MS4wfEiBrDMfwu2ej4M78s5EatnUwGwg+Qn1lpn92MBsnyvNtZKtCm2FPW73sQlfwabvkEEvEFFHtgooXqZGpnC5GSRbnrqHg6G6SG0b6WQgmYAPi4uEz3d1 AsX/dmQUIjvWOy+TzIGBCGx1XgI1G2aBvpRJDY3NuALpsRrqK88jL6Zz7gJ789yaondq4r1PMRz8pg== > Could be a self-extracting archive. If you have Windows, try running > it under Windows, then copy across the unpacked files. If you don't, > you could try WINE on Linux, or just try opening it with a Linux > archive manager -- many of them can unpack Windows SEAs. > -- > Liam Proven â Profile: https://about.me/liamproven I think it might be possible to extraxt a self-extracting archive under DOS or other OS with UNZIP. But I see Linux Archive Manager did it for you. Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
You are right, Liam: I copied the PRODOS.EXE file to my FreeDOS PC and entered "prodos". Which resulted in this error: "This program cannot be run in DOS mode.". Could be a self-extracting archive. If you have Windows, try running it under Windows, then copy across the unpacked files. If you don't, you could try WINE on Linux, or just try opening it with a Linux archive manager -- many of them can unpack Windows SEAs. Linux Archive Manager unpacked it! -- members.iinet.net.au/~kilgallin/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
On Mon, 26 Apr 2021 at 01:21, Bryan Kilgallin wrote: > > I copied the PRODOS.EXE file to my FreeDOS PC and entered "prodos". > Which resulted in this error: > "This program cannot be run in DOS mode.". Could be a self-extracting archive. If you have Windows, try running it under Windows, then copy across the unpacked files. If you don't, you could try WINE on Linux, or just try opening it with a Linux archive manager -- many of them can unpack Windows SEAs. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
Eric Auer wrote: Intel actually does provide DOS drivers for this chip (but they say the stopped supporting DOS after 2019) which contains at least NDIS support. I have not checked whether it contains a packet driver as well: https://downloadcenter.intel.com/download/29138/Intel-Ethernet-Adapter-Drivers-for-MS-DOS-?wapkw=82540EM I copied the PRODOS.EXE file to my FreeDOS PC and entered "prodos". Which resulted in this error: "This program cannot be run in DOS mode.". -- members.iinet.net.au/~kilgallin/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
On Sun, 25 Apr 2021 at 10:44, Bryan Kilgallin wrote:
>
> Transmission Control Protocol / Internet Protocol ( TCP/IP ) used
> for instance by UNIX, GNU/Linux, Windows Vista, OS X and the Internet,
We already know it must be TCP/IP. Everything else is obsolete.
> Unfortunately, I don't see an intersection/match with my HL-3150CDN
> printer's protocols!
Any network printer under about a quarter of a century old supports TCP/IP.
On Sun, 25 Apr 2021 at 11:53, Bryan Kilgallin wrote:
>
> Liam wrote:
>
> {[1] Find out what network protocol(s) your printer speaks}
>
> {Protocols
Just _printing_ protocols. Nothing else matters.
> LPR/LPD
Sounds promising.
> Custom
> Raw Port/Port9100, IPP/IPPS,
Probably too new for DOS.
So your problem now is:
[1] Find a driver for your Ethernet card. Someone else is addressing that.
[2] Set up a TCP/IP stack and bind it to the card.
[3] Find and install an LPD/LPR client on that stack.
I found this, from this list, 14Y ago.
https://freedos-user.narkive.com/uTRrLddU/printing-to-a-network-printer
--
Liam Proven – Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
Sorry, Eric:
PCISCAN showed:
Bus 1
Dev C
Func 0
Slot 2C
Vend 0006
Dev. 100E
Class Name Network
Subclass Name Ethernet.
Correction: the vendor is "8086".
In case the vendor is something else, this might be an
Intel 82540EM Gigabit LAN controller.
You are correct!
{Type PCI
Vendor ID 8086
Device ID 100E
Device Details 82540EM Gigabit Ethernet Controller
TypeID
Information 100E
Vendor Details Intel Corporation
TypeID
Information 8086}
https://devicehunt.com/view/type/pci/vendor/8086/device/100E
Intel actually does provide DOS drivers for this chip
(but they say the stopped supporting DOS after 2019)
which contains at least NDIS support. I have not
checked whether it contains a packet driver as well:
https://downloadcenter.intel.com/download/29138/Intel-Ethernet-Adapter-Drivers-for-MS-DOS-
OK, I have put that .EXE file onto a USB stick. My next action will be
transferring it to my FreeDOS PC
--
members.iinet.net.au/~kilgallin/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
Hi Bryan, > PCISCAN showed: > Bus 1 > Dev C > Func 0 > Slot 2C > Vend 0006 > Dev. 100E > Class Name Network > Subclass Name Ethernet. In case the vendor is something else, this might be an Intel 82540EM Gigabit LAN controller. If 0006:100e is indeed correct, it is something not seen elsewhere. Intel actually does provide DOS drivers for this chip (but they say the stopped supporting DOS after 2019) which contains at least NDIS support. I have not checked whether it contains a packet driver as well: https://downloadcenter.intel.com/download/29138/Intel-Ethernet-Adapter-Drivers-for-MS-DOS-?wapkw=82540EM If you have only NDIS, you also have to install DIS PKT: http://wiki.freedos.org/wiki/index.php/Networking_FreeDOS_-_NDIS_driver_installation As you see, several other drivers can be required to get a MS CLIENT "stack" which would let you access, but only old versions of, Windows net drives and printers: Load PROTMAN /I:X:\Y, then your network controller driver, then DIS PKT, all three as device drivers in either config.sys or using DEVLOAD, in that order, with X:\Y\ being the directory where your config text file PROTOCOL.INI resides (adjust accordingly). The content of the text file is at least: [protman] DriverName=PROTMAN$ [YOURDRIVERNAME] DriverName=YOURDRIVERNAME$ [PKTDRV] drivername=PKTDRV$ bindings=YOURDRIVERNAME intvec=0x60 chainvec=0x68 See also the documentation which gets installed when you unpack the DOS driver package from Intel. Apart from the 2 *.DOS files (device drivers, note the unusual name *.DOS instead of *.SYS) you will also need the PROTMAN and NETBIND command line tools and TSRs. All drivers and tools may have problems with being loaded into UMB (devicehigh, loadhigh etc.) so you should avoid that until you have tested whether it works for your PC. You have to start NETBIND after loading the three *.DOS devices to activate things. The PROTMAN exe will be started automatically by the PROTMAN device, but you can also run it manually later for other purposes. Depending on the type of your printer, you can install the mTCP set of utilities as explained in http://wiki.freedos.org/wiki/index.php/Networking_FreeDOS_-_mTCP As explained, you need to set MTCPCFG=c:\somewhere\yourfiletcp.cfg which has to set your PACKETINT (0x60), IPADDR, NETMASK, GATEWAY, NAMESERVER and MTU (1500). You can also use DHCP instead: Then, only PACKETINT and the host name which you want to give your DOS PC (e.g. mydospc) have to be set and all other settings will be requested from your router, modem or other available DHCP provider. If the mTCP tools do not remember the DHCP answers, it can mean that they have to ask before each activity, so you may prefer non-DHCP for better speed, but I do not know whether or not mTCP remembers DHCP data across calls? Use the NC (netcat) tool to send files to the printer: http://wiki.freedos.org/wiki/index.php/Netcat nc -target 192.168.2.20 9100 -bin < testfile.txt In this example, 192.168.2.20 would be the IP address of your printer, which you will have to look up (it may be shown on your printer display, or you look at what Linux or Windows says about your printer) and 9100 is a popular port for streaming "page (or printer?) definition language" data to printers. Depending on your printer, it might accept all sorts of file formats, as explained here: https://en.wikipedia.org/wiki/Page_description_language However, I would expect that PostScript, PDF, ESC/P, HP PCL and plain text have reasonable chances to be supported (at least one of them) by your printer if it is a printer with sufficient built-in intelligence. According to the website https://support.brother.com/g/b/spec.aspx?c=au=en=hl3150cdn_us_as_cn the Brother HL-3150CDN is unfortunately a non-intelligent GDI printer. You have to send pre-generated raw pixel data to the printer and you will probably NOT find a tool which converts your DOS text into pixel data in DOS If you had a HL-3170CDW, it would be intelligent enough to understand HP PCL6 and a Brother PostScript 3 dialect. In short, while your PC network controller is supported by DOS, you will not be able to use your printer without the help of other operating systems in DOS because the printer expects too much of its work to be done by you. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
Hm, Liam: [1] Find out what network protocol(s) your printer speaks Device URI: implicitclass://Brother_HL_3150CDN_series/ Make and Model: Brother HL-3150CDN series, driverless, cups-filters 1.27.4 -- members.iinet.net.au/~kilgallin/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
Liam wrote:
{[1] Find out what network protocol(s) your printer speaks}
{Protocols
IPv4 ARP, RARP, BOOTP, DHCP, APIPA(Auto IP), WINS/NetBIOS name
resolution, DNS Resolver, mDNS, LLMNR responder, LPR/LPD, Custom
Raw Port/Port9100, IPP/IPPS, FTP Server, TELNET Server,
HTTP/HTTPS server, TFTP client and server, SMTP Client,
SNMPv1/v2c/ v3, ICMP, Web Services (Print), CIFS client, SNTP client}
{Security Protocols
Wired
APOP, POP before SMTP, SMTP-AUTH, SSL/TLS (IPPS, HTTPS,
SMTP, POP), SNMP v3 802.1x (EAP-MD5, EAP-FAST, PEAP, EAP-TLS,
EAP-TTLS), Kerberos}
Manual Appendix p. 191
--
members.iinet.net.au/~kilgallin/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
Liam wrote:
{[2] Look for DOS support for 1 of those protocols}
FreeDOS protocols:
{The following protocols are supported by these three drivers:
Transmission Control Protocol / Internet Protocol ( TCP/IP ) used
for instance by UNIX, GNU/Linux, Windows Vista, OS X and the Internet,
Internetwork Packet Exchange / Sequenced Packet Exchange ( IPX/SPX
) protocols, used for instance by Novell NetWare,
Network Basic Input Output System (NetBIOS) Extended User Interface
(NetBEUI a.k.a. CIFS ) protocol used for instance by OS/2, Windows 9x,
ME and 2000.}
http://wiki.freedos.org/wiki/index.php/Networking_FreeDOS_-_DOS_networking_today#Protocols
Unfortunately, I don't see an intersection/match with my HL-3150CDN
printer's protocols!
--
members.iinet.net.au/~kilgallin/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
On Fri, 23 Apr 2021 at 00:37, Bryan Kilgallin wrote: > > OK, I have plugged-in an Ethernet cable from the DOS PC to my router. > Now what? [1] Find out what network protocol(s) your printer speaks [2] Look for DOS support for 1 of those protocols [3] Install a DOS network stack that includes that protocol. But without answering #1 we can't really give much more in the way of pointers. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Print via network
As requested, I reply to a private message from Eric Auer.
{As you say that this
printer can also print via network, have you tried to
use that method in DOS? Network drivers are sometimes
easier than USB drivers and you can use "netcat" (nc).}
OK, I have plugged-in an Ethernet cable from the DOS PC to my router.
Now what? How can I use FreeDOS to send data via Ethernet to my Brother
HL-3150CDN laser-printer, in a format that the latter can read?
PCISCAN showed:
Bus 1
Dev C
Func 0
Slot 2C
Vend 0006
Dev. 100E
Class Name Network
Subclass Name Ethernet.
How can I use FreeDOS or Linux (nmap?) to check the connection?
--
members.iinet.net.au/~kilgallin/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
