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

[Mateusz Mikołajczyk]

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