[Samba] smbsrv_reply_printwrite not returning a response causing the print job to be truncated to 124 bytes

Mateusz Mikołajczyk mikolajczyk.mateusz at gmail.com
Thu Apr 29 12:20:26 UTC 2021


yes, you're absolutely correct.

That all being said, I've also looked on the specification of the protocol
- the PDF, point 2.2.4.68.2 (so it would seem that the protocol specifies
the response and it actually mentions that both of the response fields must
be zeroes) and I've looked on the other functions in reply.c and came up
with the following patch:

smbsrv_setup_reply(req, 0, 0);
smbsrv_send_reply(req);

(I've put those 2 lines at the end of the function - line 1482 - where it
is known that no error has occured)

I'm still compiling the code but I'm hoping that this will work :D if it
does, would you accept a patch? or is it likely to break compatibilty with
existing software?

czw., 29 kwi 2021 o 14:08 Rowland penny via samba <samba at lists.samba.org>
napisał(a):

> On 29/04/2021 12:49, Mateusz Mikołajczyk wrote:
> > yes, I have read it. In fact, had it not been for the damned DOS
> > client the printing would have work flawlessly as well. windows
> > machines are able to print from the same printer - just not the DOS
> > client. I suppose the reason is that (as I've read in either samba
> > wiki or manual pages) later versions of the protocol switched to a
> > different way of printing whereas the DOS seems to be using the old
> > LanMan printing (?).
> >
> > again, I actually suspect that this could be a hack of some sort added
> > on the win xp implementation because that's the server that seems to
> > be sending the print file write response. if I'd need to write a patch
> > and use a locally-compiled version of samba, I'd also be happy with
> > that because I do understand that nobody should even be using this
> > legacy function calls in the first place, but my problem is that I
> > don't know what I should write in order for the function to resemble
> > the old samba 3 behavior ;)
> >
> > I didn't knew that ntvfs handler would not be used, I only started to
> > experiment with configuration options as I had a hunch that this had
> > something to do with sync / async and I basically searched manual page
> > for smb.conf for every mention of either 'DOS', 'legacy', 'sync'
> > keywords and tried to apply them as some of them were limited to a share.
> >
> > I've also tried to use 'disable spoolss = yes' but then samba responds
> > with an error packet (code = 0x03 that is described by wireshark as
> > 'Hardware Error')
> >
> > Could it be that I should simply revert to samba 3.0.3 instead of
> > using the upstream version ? I don't actually require any DC
> > functionality at all, I was just hoping that I could achieve the same
> > functionality on the upstream release via some 'magical' configuration
> > switch :).
>
>
> Your problem is in your use of such old machines and protocols, which is
> probably being forced on you. In an ideal world you could replace them
> with something newer, but this isn't an ideal world, so you have to use
> what you have.
>
> Are the machines airgapped from any other machines ? If so I would think
> you would find it easier to use an older version of Samba than trying to
> get a newer version to work. You could write your own patches, but this
> will be much more work.
>
> Rowland
>
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>


-- 
pozdrawiam serdecznie,
Mateusz Mikołajczyk, a.k.a. toudi


More information about the samba mailing list