Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

Hi,

Just a few more comments to add about the Mopria-based IPP class driver, you can manually add an IPP 2.0 or later printer from the command-line with either of the following.

From an administrator PowerShell command line, run something similar to the following PowerShell comandlet :

    Add-Printer -IppURL ipp://xxx.xxx.xxx.xxx/ipp/print


Alternatively you can do the following on a regular command prompt or from PowerShell (and you don't even need admin privileges to add a driverless printer):

    rundll32 printui.dll,PrintUIEntry /ip

then click Next and enter the IPP URL...


Comes in handy if the printer can't be discovered with mDNS (Bonjoiur).



Cheers,
Doug
-----Original Message-----
From: Printing-architecture <[email protected]> On Behalf Of Michael Sweet via Printing-architecture
Sent: Thursday, December 14, 2023 8:40 AM
To: Alexander Pevzner <[email protected]>
Cc: [email protected]; Till Kamppeter <[email protected]>
Subject: Re: [Printing-architecture] RFC: Pantum M7300FDW and similar

Alex,

Windows 10 is the first version of Windows with the (Mopria-based) IPP class driver.  Earlier versions of Windows only supported the experimental IPP/1.0 (!) and relied on drivers to send data to IPP printers...


> On Dec 13, 2023, at 4:22 PM, Alexander Pevzner <[email protected]> wrote:
> 
> Till, I will try.
> 
> I already tried with Windows 7 that I have running in VM and didn't succeed (it wants to install Pantum drivers).
> 
> I'll try to install Windows 10 or 11 into VM and will see how it will work. However, it will take some time.
> 
> I'll return with results when results will be available.
> 
> On 12/13/23 20:31, Till Kamppeter wrote:
>> Alex, I will perhaps reply in more detail later, but I would like you to test something:
>> You say that Windows always wants you to install a driver.
>> Windows principally supports driverless printing. Have a look at 
>> https://openprinting.github.io/wsl-printer-app/
>> This is a HOWTO to eun a Printer Application (= emulation of driverless printer) under WSL and Windows sees this as a driverless printer.
>> So now click "Cancel" in any pop-up of Windows telling you to install a printer driver.
>> Now go to the HOWTO and only see the steps to set up a driverless printer (you will not need WSL nor a Printer Application).
>> So you start in the section which starts with "Add the printer to Windows".
>> Look in the "Bluetooth & devices > Printers & scanners" whether there is an entry which could represent your printer. Select it, finish the setup and test.
>> Is your printer working at all?
>> Is it completely working?
>> Does it show the same problems as under Linux?
>> If it works under Windows we will need to reverse-engineer what Windows is doing and compare it to what CUPS is doing.
>>    Till
>> On 13/12/2023 16:08, Alexander Pevzner wrote:
>>> Michael,
>>> 
>>> thank you very much for your response!
>>> 
>>> On 12/10/23 18:11, Michael Sweet wrote:
>>>> This code has been the focus of *six* CVEs since the move to Git in 2015 - not quite one CVE a year, but enough to be concerning.  More specifically, commit 5754bccee (https://github.com/apple/cups/issues/5630) addressed the code that allowed "alternate" encodings of member attributes that was causing interoperability issues.
>>> 
>>> CVE is about security, not about interoperability. You told several times that you are concerned about security risks associated with my patch, so it sounds like some kind if security review could be useful here.
>>> 
>>> BTW, where do you see security risk, in the changed (relaxed) IPP "syntactical" rules by itself or in my implementation (code modifications) made to implement this change?
>>> 
>>> Regarding interoperatibily, issue #5630, as I understand it, means that some clients that were able to speak with CUPS were not able to speak with real printers, because CUPS was too forgiving while printers were not.
>>> 
>>> First of all, I don't agree that this is about interoperatibility. This is about applicability of CUPS as strong testing/diagnostics tool. Being too forgiving, CUPS by itself still remains compatible with invalid implementations, but becomes not very useful to test these implementations for correctness (which is not primary purpose of CUPS, BTW).
>>> 
>>> Second, if I relax parsing of IPP responses, but not of incoming IPP requests, looks like we can achieve two goals: to be strict enough for testing of clients and to be compatible with broken hardware as well, isn't it?
>>> 
>>> And I know that the same IPP parser is used as a part of IPP self-certifications tools. If I will implement "relaxed IPP parsing" as an option, disabled by default, and will only enable it where CUPS interprets responses from printers, it will not change CUPS behavior as server and will not change IPP tools behavior, at this case will it look good enough for you?
>>> 
>>>>> 1. I agree, that following specification is very important, and, where possible, trying to do so.
>>>> 
>>>> IPP started in the IETF and the PWG has continued the IETF's goals for conformance terminology: any requirements are there to ensure interoperability and proper functionality.  Postel's Law doesn't apply when it breaks interoperability and potentially has bad side effects. See the following for some applicable reading/links:
>>> 
>>> I agree that interoperability should not be broken, but I don't see how my (updated) proposal, explained above, can break interoperability with anything.
>>> 
>>> Please, correct me, if I wrong.
>>> 
>>>> They already won't be able to print from iOS or macOS, and probably not from Windows (IPP class driver) or Android (Mopria print provider) because the Get-Printer-Attributes response cannot be parsed.  And if they actually ask someone about the problem they can be pointed to Pantum to get a firmware update.
>>> 
>>> Interesting that this device included into the Apple's list of 
>>> supported AirPrint devices: https://support.apple.com/en-us/HT201311
>>> 
>>> Unfortunately, I don't have any iOS/macOS device to test by myself. Regarding Windows, Windows wants to install vendor driver (which is known to work) and I don't know is it any way to force Windows to print "driverlessly".
>>> 
>>>> Firmware update capability is required for both AirPrint and Mopria, and at least the AirPrint folks require the ability to upgrade without special software and highly recommend automatic firmware updates over the Internet whenever possible...  Pantum is an AirPrint licensee...
>>> 
>>> Device has offline/online upgrade options. For offline upgdade, I was not able to find firmware image for this model (and other member of this discussion writes the same). Online upgrade claims that the newest version of firmware already installed.
>>> 
>>>> You need to notify PANTUM that they have an issue.  Regardless of whether you believe that a user will update the firmware, they don't even have an opportunity unless you report the issue to the manufacturer.  And in fact, you don't even know whether PANTUM has already fixed the issue!?!
>>> 
>>> I'm doing my best to reach them, but didn't succeed so far. If and when I'll get any feedback, I'll notify you (I mean all readers of this discussion).
>>> 
>>>> Let's say we accept invalid collection attribute values.  We get 
>>>> the media-col-database and media-col-ready values from the printer, 
>>>> and then send it a media-col collection to specify printing from 
>>>> tray 2 on cardstock: will the printer be able to understand a 
>>>> correctly encoded collection value for media-col if it doesn't 
>>>> return valid collection values for media-col-database/ready?  
>>>> (probably not)
>>> 
>>> I wrote the test. Printer correctly mirrors media-col parameters in the Print-Job response (and my test encodes requests correctly) but I don't see any change of the printed image when I play with these parameters.
>>> 
>>>> Did you fix the problem for the user?  Is this better?
>>> 
>>> In general yes, because actually all printer functionality is available for user.
>>> 
>>> Regarding tray selection, printer chooses paper from the manual tray if it is not empty or from the automatic tray otherwise, and I'm not sure if it can be changed programmatically. In any case, it is reasonable behavior.
>>> 
>>>>> I'd prefer to make it even more precious, affection only communication with Pantum devices. But in that places of the CUPS code where responses are parsed there is no information what kind devices we are speaking with.
>>>> 
>>>> And I would be even more opposed to such a change.  At that point you have created a printer driver...
>>> 
>>> Printer driver may be a way to ho, though at this case it is 1000x bigger effort.
>>> 
>>> But at this case we need to provide a mechanism to disable auto-discovered printer in a favor of device instance, found and handled by the driver.
>>> 
>>> And another thing, we loose IPP over USB functionality (or ipp-usb must mimic their printer in enough details to fool the driver that it speaks with actual hardware printer).
>>> 
> 
> --
> 
> Wishes, Alexander Pevzner ([email protected])
> 

________________________
Michael Sweet

_______________________________________________
Printing-architecture mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture