Re: CUPS: [Client 1] Unable to encrypt connection: An illegal parameter has been received.

On Mon, 21 Jan 2019 21:00:39 +0100 "O. Hartmann" <o.hartmann_at_walstatt.org> wrote:
> Am Wed, 16 Jan 2019 18:33:36 +0100
> Tijl Coosemans <tijl_at_FreeBSD.org> schrieb:
>> On Wed, 16 Jan 2019 15:23:40 +0100 "O. Hartmann" <ohartmann_at_walstatt.org> wrote:  
>>> We have an experimental IPV6 network and within this network, FreebSD CURRENT
>>> (r343087) is acting as a CUPS print server, while a bunch FreeBSD 12-STABLE
>>> boxes are CUPS clients.
>>> 
>>> The setup, so far, worked with IPv4. Introducing IPv6 addresses on both server
>>> and host results in the error
>>> 
>>> [Client 1] Unable to encrypt connection: An illegal parameter has been received.
>>> 
>>> In file cups/client.conf we address the appropriate printer via
>>> 
>>> ipps://xxx.xxx.xxx.xxx/printers/printer_name (IPv4 of the CUPS server host)
>>> 
>>> This works fine.
>>> 
>>> But ipps://[XXXX:XXXX:XXXX::XXXX]/printers/printer_name (IPv6 of the CUPS
>>> server host) doesn't work and results in the error on the server as shown above.
>>> 
>>> I fiddled also around with the SSLOption parameter in client.conf and parallel,
>>> to match requiremets, in cups/cupsd.conf of the server host - with no effect.
>>> 
>>> On the server side, it seems that all the documents I could pick up from
>>> cups.org or Apple do not specify any IPv6 address in an "Allow from" statement:
>>> everything seems to be stuck with IPv4. While the cupsd.conf SSLListen option
>>> is for IPv6
>>> 
>>> SSLListen [fd01:dead:beef::affe]:631
>>> 
>>> which works, I get an error when trying to put anything IPv6-similar with the
>>> convention with the brackets "[" and "]" in a "Allow from" option in the
>>> sections where I need to restrict access. An IPv6 without "[" and "]" seems to
>>> be accepted - but when coemmnting out ANY IPv4 address and leaving only IPV6 in
>>> the "Allow from " statement, no remote connection is allowed.
>>> 
>>> This drives me nuts. Since the aim will be to have a printing facility within a
>>> IPv6 only network, I feel a bit lost.
>>> 
>>> Does anyone have had similar problems?    
>> 
>> What you're supposed to do instead is run a cupsd on the client and add
>> the print server as a network printer (using your ipps URI).  When you
>> have to choose the make of the printer choose Raw so you don't need a
>> PPD and cupsd will forward the job to the server without doing any
>> filtering.  You can set this up on one client and then copy the cups
>> configuration in /usr/local/etc/cups to the other clients.  Running a
>> local cupsd allows clients to queue print jobs when the print server is
>> down.  
> 
> I had those settings on the client system, too: reference printer is
> ipps://host.name/printers/print_queue_name, but not with "RAW" filter. I changed that.
> 
> While I'm able to print CUPS testpages via the web interface on the CUPS server system
> itself, I still receive 
> 
> [Client 1] Unable to encrypt connection: An illegal parameter has been received.
> 
> in the log file on the CUPS server, when the satellite/client system tries to connect to
> the CUPS print queue.

I've just committed WITH_DEBUG support to print/cups (r490938) so please
update your ports tree and rebuild and reinstall cups on the print server
using "make WITH_DEBUG=yes install".  Then run cupsd like this:

env CUPS_DEBUG_LOG="/tmp/cups.debug" CUPS_DEBUG_LEVEL="9" cupsd

Then try to connect from the client.  /tmp/cups.debug should now contain
"An illegal parameter has been received" but with more context.