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

Thu Apr 29 10:58:18 UTC 2021

I've also searched trough github and found that the commit that removed
those 0 bytes (if they are in fact what I believe they are - a response
packet) was 591669ba066cde377c0c14e3473f23b35530b4ba which was
called r24431: Convert the reply_printXX calls to the new API. Of course
that were the changes in source3 directory rather than source4, but it
could be what originated the changes in samba 4 as well - that's only my
guess

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

> I haven't received last email but I can see your text appearing on the web
> archive of the mailing list - I hope I'm replying in a correct way :)
>
> I'm using the binaries from debian buster - the exact version
> is 4.9.5+dfsg-5+deb10u1+rpi1 but I've also compiled latest stable release:
> 4.14.3. from what I could tell on github, last changes to this function
> were made ~15 years ago
>
> I've seen this issue has appeared already on the mailing list and I wrote
> to the authors of the tickets and one of them responded that the last
> version of samba that was working (that he checked) with this printing
> protocol was 3.0.3. I have then looked inside the 3.0.3 source and the
> function that implements this there is called reply_printwrite and at the
> very beginning of the function I can see those two zeroes (one of them is
> presumably 16 bit):
>
> int outsize = set_message(outbuf,0,0,True);
>
> which makes the response packet of 0xc1 + 3 zero bytes.
>
> I'm starting samba via systemd:
>
> sudo systemctl start smbd
> sudo systemctl start nmbd
>
>
> czw., 29 kwi 2021 o 08:45 Mateusz Mikołajczyk <
> mikolajczyk.mateusz at gmail.com> napisał(a):
>
>> yes, I'm aware that this protocol (and even this way of printing) is
>> deprecated and believe me, I would like to move away from it :(
>> unfortunetely that's the luxury I don't have.
>>
>> smb.conf is as following (lines proceeding with # removed for brevity,
>> MINOLTA is the name of the CUPS printer (konica minolta)):
>>
>> ```
>> [global]
>>    workgroup = WORKGROUP
>>    netbios name = SERVER
>>    server string = SERVER
>>    log file = /var/log/samba/log.%m
>>    max log size = 1000
>>    logging = file
>>    panic action = /usr/share/samba/panic-action %d
>>    server role = standalone server
>>    obey pam restrictions = yes
>>    unix password sync = yes
>>    passwd program = /usr/bin/passwd %u
>>    passwd chat = *Enter\snew\s*\spassword:* %n\n
>> *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
>>    pam password change = yes
>>    map to guest = bad user
>>
>> [MINOLTA]
>>    printer = MINOLTA
>>    browseable = yes
>>    printing = cups
>>    path = /var/spool/samba
>>    printable = yes
>>    guest ok = yes
>>    writable = yes
>>    create mask = 0777
>>
>>    ntvfs handler = simple
>>    aio read size = 0
>>    aio write size = 0
>>
>>    strict sync = yes
>>    sync always = yes
>> ```
>>
>> p.s. it could be that this (i.e. synchronous reply with a 0xc1 packet and
>> 3 null bytes) was an undocumented feature available only in the xp server,
>> because when I tried to connect the DOS client to a windows 10 machine (of
>> course I enabled smb1 / cifs protocol first) the print job would be added
>> to the spooler but would indefinetely show 'buffering'.
>>
>>
>> czw., 29 kwi 2021 o 08:35 Mateusz Mikołajczyk <
>> mikolajczyk.mateusz at gmail.com> napisał(a):
>>
>>> yes, I'm aware that this protocol (and even this way of printing) is
>>> deprecated and believe me, I would like to move away from it :(
>>> unfortunetely that's the luxury I don't have.
>>>
>>> smb.conf is as following (lines proceeding with # removed for brevity,
>>> MINOLTA is the name of the CUPS printer (konica minolta)):
>>>
>>> ```
>>> [global]
>>>    workgroup = WORKGROUP
>>>    netbios name = SERVER
>>>    server string = SERVER
>>>    log file = /var/log/samba/log.%m
>>>    max log size = 1000
>>>    logging = file
>>>    panic action = /usr/share/samba/panic-action %d
>>>    server role = standalone server
>>>    obey pam restrictions = yes
>>>    unix password sync = yes
>>>    passwd program = /usr/bin/passwd %u
>>>    passwd chat = *Enter\snew\s*\spassword:* %n\n
>>> *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
>>>    pam password change = yes
>>>    map to guest = bad user
>>>
>>> [MINOLTA]
>>>    printer = MINOLTA
>>>    browseable = yes
>>>    printing = cups
>>>    path = /var/spool/samba
>>>    printable = yes
>>>    guest ok = yes
>>>    writable = yes
>>>    create mask = 0777
>>>
>>>    ntvfs handler = simple
>>>    aio read size = 0
>>>    aio write size = 0
>>>
>>>    strict sync = yes
>>>    sync always = yes
>>> ```
>>>
>>> p.s. it could be that this (i.e. synchronous reply with a 0xc1 packet
>>> and 3 null bytes) was an undocumented feature available only in the xp
>>> server, because when I tried to connect the DOS client to a windows 10
>>> machine (of course I enabled smb1 / cifs protocol first) the print job
>>> would be added to the spooler but would indefinetely show 'buffering'.
>>>
>>> czw., 29 kwi 2021 o 05:43 Jeremy Allison <jra at samba.org> napisał(a):
>>>
>>>> On Thu, Apr 29, 2021 at 01:38:04AM +0200, Mateusz Mikołajczyk via samba
>>>> wrote:
>>>> >Hello. I am investigating a weird issue with an old MS Net client for
>>>> DOS
>>>> >(v 3.0). I have used wireshark in order to inspect the packets and see
>>>> the
>>>> >difference between samba and windows xp server responses. this
>>>> question is
>>>> >only about printing capabilities as file sharing works flawlessly.
>>>> >
>>>> >when the client negotiates protocol it is settled as 2 / Greater than
>>>> CORE
>>>> >PROTOCOL and up to LANMAN2.1
>>>> >
>>>> >the start of print request seems to be OK, the server (in both
>>>> >implementations) returns a file ID in the response that's labeled as
>>>> 'Open
>>>> >Print File Response / 0xC0'. Then the client sends print job (packet
>>>> id:
>>>> >0xc1) (124 bytes of it in fact - I suppose that's either due to some
>>>> buffer
>>>> >size or a maximum packet length) and that's when the servers differ in
>>>> >terms of response.
>>>> >
>>>> >windows xp responds with 0xc1 and the data section contains 3 zero
>>>> bytes
>>>> >(0x00, 0x00, 0x00). Wireshark describes this as 'Write Print File
>>>> >Response'. Samba does not respond at all which makes the client simply
>>>> >hang. Then, after couple of seconds samba simply puts the print job to
>>>> cups
>>>> >which makes the output truncated. By inspecting samba source code for
>>>> 0xc1
>>>> >I saw a reference to smbsrv_reply_printwrite. I've read the source
>>>> code for
>>>> >that function and I can't understand why it would not return a
>>>> response at
>>>> >all. I would understand if it would return an error packet or
>>>> something but
>>>> >there's simply no response at all.
>>>> >
>>>> >here's what I tried so far:
>>>> >
>>>> >   ntvfs handler = print
>>>> >   aio read size = 0
>>>> >   aio write size = 0
>>>> >
>>>> >   strict sync = yes
>>>> >   sync always = yes
>>>> >
>>>> >but somethinig tells me that because at the very beginning of the
>>>> function
>>>> >there's a hardcoded NTVFS_ASYNC_STATE_MAY_ASYNC then I am simply out of
>>>> >luck?
>>>>
>>>> Looks like you're using the (unsupported code) ntvfs file
>>>> server. That's legacy code only used for testing.
>>>>
>>>> You need to be talking to smbd, not the samba binary.
>>>>
>>>> Please ensure you have smbd running, and as I'm sure
>>>> Rowland will ask, please submit your smb.conf :-).
>>>>
>>>
>>>
>>> --
>>> pozdrawiam serdecznie,
>>> Mateusz Mikołajczyk, a.k.a. toudi
>>>
>>
>>
>> --
>> pozdrawiam serdecznie,
>> Mateusz Mikołajczyk, a.k.a. toudi
>>
>
>
> --
> pozdrawiam serdecznie,
> Mateusz Mikołajczyk, a.k.a. toudi
>

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