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&t=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
