[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 10:42:50 UTC 2021
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
More information about the samba
mailing list