Bug 14421 - Printing from DOS client ends abruptly
Summary: Printing from DOS client ends abruptly
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Printing (show other bugs)
Version: 4.12.3
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: printing-maintainers
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-28 21:02 UTC by Adan Calderon
Modified: 2021-01-08 07:40 UTC (History)
0 users

See Also:


Attachments
Logs, conf, cups backend shell script, screen shots, and pcap of DOS client. (187.02 KB, application/x-zip-compressed)
2020-06-28 21:02 UTC, Adan Calderon
no flags Details
possible patch (7.38 KB, patch)
2020-06-29 06:25 UTC, Volker Lendecke
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adan Calderon 2020-06-28 21:02:32 UTC
Created attachment 16095 [details]
Logs, conf, cups backend shell script, screen shots, and pcap of DOS client.

I can not seem to print from a DOS client (MS Network Client 3.0).  

The output is stopped.

I issue out the following at the command prompt:

NET USE LPT1:  \\<SAMBA-SERVER-NAME>\<PRINTER-SHARE-NAME>
DIR > LPT1

The output gets chopped off.

Doing the same on a Windows 7 Client works correctly.

I am attaching a pcap I captured for the DOS client as well as log level 10 debug files.

On a side note, regardless of what I put for log level, testparm reports 1.
Comment 1 Volker Lendecke 2020-06-29 06:25:39 UTC
Created attachment 16096 [details]
possible patch

Can you try the attached patch? I don't have DOS around, neither do I have a printer configured. So I can't test this right now
Comment 2 Adan Calderon 2020-06-29 17:26:14 UTC
I tried patching but got the following:
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|From 05fafc1df28e7848a1e6869d0103ea96dc21f0e4 Mon Sep 17 00:00:00 2001
|From: Volker Lendecke <vlendec@samba.org>
|Date: Tue, 14 Aug 2007 20:20:51 +0000
|Subject: [PATCH] r24436: Convert reply_lockread/writeunlock to the new API
| (This used to be commit 1b6add251ca1db565a03407db30884132dd93e7d)
|
|---
| source3/smbd/process.c |   4 +-
| source3/smbd/reply.c   | 118 +++++++++++++++++++++++++++--------------
| 2 files changed, 80 insertions(+), 42 deletions(-)
|
|diff --git a/source3/smbd/process.c b/source3/smbd/process.c
|index 837991f2ee5d..aaaf475d2e5d 100644
|--- a/source3/smbd/process.c
|+++ b/source3/smbd/process.c
--------------------------
patching file source3/smbd/process.c
Using Plan A...
Hunk #1 FAILED at 709.
1 out of 1 hunk FAILED -- saving rejects to file source3/smbd/process.c.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/source3/smbd/reply.c b/source3/smbd/reply.c
|index 1d0791a899f2..f41387fb68eb 100644
|--- a/source3/smbd/reply.c
|+++ b/source3/smbd/reply.c
--------------------------
patching file source3/smbd/reply.c
Using Plan A...
Hunk #1 FAILED at 2741.
Hunk #2 FAILED at 2777.
Hunk #3 FAILED at 2788.
Hunk #4 FAILED at 2805.
Hunk #5 FAILED at 3341.
Hunk #6 FAILED at 3378.
6 out of 6 hunks FAILED -- saving rejects to file source3/smbd/reply.c.rej
Hmm...  Ignoring the trailing garbage.
done
Comment 3 Adan Calderon 2020-07-06 01:17:53 UTC
(In reply to Adan Calderon from comment #2)

I updated Samba to 4.12.5.  I also looked at what the patch it suppose to do.

It seems like a lot of the code that it is trying to add has already been added.  This includes the insertions of NULL in process.c and chucks of code to reply.c

It is still not printing completely.  I am also testing by trying to capture the raw output being redirected to LPT1 into a TEXT file for the time being.  There is no need for a physical printer.  The CUPS backend shell script is included in the previous attachments.


I think the idea was to simply add the global parameters

printing = cups 
printcap name = cups

to the smb.conf

Add the following shell script /usr/lib64/cups/backend/rawcapture
#!/bin/sh
# -------------------------------------------------------------------
# "/usr/lib64/cups/backend/rawcapture":
# -------------------------------------------------------------------
#
FILENAME=
PRINTTIME=`date +%Y-%m-%d_%H.%M.%S`
# no argument, prints available URIs
if [ $# -eq 0 ]; then
  echo "No Arguments"
  exit 0
fi
# case of wrong number of arguments
if [ $# -ne 5 -a $# -ne 6 ]; then
  echo "Usage: rawcapture job-id user title copies options [file]"
  exit 1
fi
# get output directory from device URI, and check write status
SAVEDIR=${DEVICE_URI#rawcapture:}
if [ ! -d "$SAVEDIR" -o ! -w "$SAVEDIR" ]; then
  echo "ERROR: directory $SAVEDIR not writable"
  exit 1
fi
# generate output filename
OUTPUTFILENAME=
if [ "$3" = "" ]; then
  OUTPUTFILENAME="$SAVEDIR/unknown.cap"
else
  if [ "$2" != "" ]; then
    OUTPUTFILENAME="$SAVEDIR/$2-$PRINTTIME.cap"
  else
    OUTPUTFILENAME="$SAVEDIR/$PRINTTIME.cap"
  fi
fi

# Copy File
cp $6 $OUTPUTFILENAME

# Make the file visible and writable by everyone.
chmod 777 $OUTPUTFILENAME
exit 0

Then when adding the printer via the CUPS web page

I gave it a description of "RAW Capture"
and a Connection of "rawcapture:/RAWcaps/"
and the Driver: "raw"

In the smb.conf I have the directory /RAWcaps shared
[RAW_Captures]
    comment = RAW Captured Printouts
    path = /RAWcaps
    public = yes
    browseable = yes
    writable = yes
    printable = no
    guest ok = yes
    read only = no
    create mask = 0744
    directory mask = 0755

On my Windows 7 Client machine I am able to do a:

NET USE LPT1:  \\<SAMBA-SERVER-NAME>\<PRINTER-SHARE-NAME>
DIR > LPT1

and I get a text file with the contents of the directory.

On a MS-DOS Client 3.0 machine, I do get a text file with some text but it is not complete. It also takes a long time.
Comment 4 Björn Jacke 2021-01-07 20:46:01 UTC
Volker, is the comment #1 patch really the one you intended to attach here? It's upstream since 2007 ;-). Was there another patch that you had in mind?
Comment 5 Volker Lendecke 2021-01-08 07:40:12 UTC
Probably it's the wrong patch, you're right.