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

[Mateusz Mikołajczyk]

hmm now I realized that that's exactly what the reply_simple_send function
does.. I'll keep digging

czw., 29 kwi 2021 o 14:20 Mateusz Mikołajczyk <mikolajczyk.mateusz at gmail.com>
napisał(a):

> 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
>


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