I know I've been out of the loop for a while, trying to get back into the swing of things but having trouble keeping up with the work.
Anyway, I am testing the latest IPP Everywhere self cert tests and uncovered a couple of issues?
1. If a device can be configured to not support IPP, but only support IPPS, then all dnssd-tests.sh fail, because "ippfind _ipp._tcp,_print" fails to discover the printer as the printer is not advertising _ipp._tcp (note in the response below there is an HP device supporting both IPP and IPPS, but the device boxster is configured to only support IPPS):
?130 ~/OneDrive - Xerox/pwg/ipp/everywhere/sw-ippeveselfcert11-20210517(1627)> ./ippfind _ipp._tcp -T 5
√ ~/OneDrive - Xerox/pwg/ipp/everywhere/sw-ippeveselfcert11-20210517(1628)> ./ippfind _ipps._tcp -T 5
√ ~/OneDrive - Xerox/pwg/ipp/everywhere/sw-ippeveselfcert11-20210517(1629)>
Should the IPP Everywhere tests work for those devices that only support IPPS?
√ ~/OneDrive - Xerox/pwg/ipp/everywhere/sw-ippeveselfcert11-20210517(1629)> ./dnssd-tests.sh boxster
B-1. IPP Browse test: FAIL
B-2. IPP TXT keys test: B-3. IPP Resolve test: FAIL
B-4. IPP TXT values test: B-5. TLS tests: SKIP
B-5.1 HTTP Upgrade test: SKIP
B-5.2 IPPS Browse test: SKIP
B-5.3 IPPS TXT keys test: SKIP
B-5.4 IPPS Resolve test: SKIP
B-5.5 IPPS TXT values test: SKIP
Summary: 10 tests, 0 passed, 4 failed, 6 skipped
boxster DNS-SD Results.plist: Found non-key inside <dict> at line 17
?1 ~/OneDrive - Xerox/pwg/ipp/everywhere/sw-ippeveselfcert11-20210517(1630)>
2. The other issue I have is associated with RFC 2817 HTTP Upgrade to TLS. I run this test with boxster re-configured to support both IPP and IPPS. In this test Wireshark trace shows RFC 2817 Section 3.2 Mandatory Upgrade request coming from dnssd-test (ipptool):
Packet 65 in attached Wireshark trace
OPTIONS * HTTP/1.1
boxster responds with 101 Switching Protocols:
Packet 68 in attached Wireshark trace
HTTP/1.1 101 Switching Protocols
Upgrade: TLS/1.2, HTTP/1.1
But the communication then ends. Per RFC 2817 Section 3.3 reference is made to RFC 2616 section 10.1.2 "The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response". However, since I've never seen this in a trace, I do not know what the server is supposed to respond with (what those packets look like). If there is a TLS upgrade handshake that needs to occur, doesn't the client have to initiate it with a TLS "Client Hello"? Does anyone have a Wireshark trace that shows a working functionality for this and if so can you provide it? boxster is running an Apache HTTP server configured to support RFC 2817, but it appears it is Apache itself which is not properly supporting the RFC 2817 upgrade, as it appears to not properly implement RFC 2616 section 10.1.2 in this instance.
On 5/17/21, 3:00 PM, "ipp on behalf of Michael Sweet via ipp" <ipp-bounces at pwg.org on behalf of ipp at pwg.org> wrote:
[This last call starts today, May 17, 2021 and ends no earlier than May 31, 2021]
I have posted a beta of the IPP Everywhere v1.1 Printer Self-Certification Tools Update 3 to:
This update fixes the following issues:
- The DNS-SD tests now look for a TLS key whose value contains a TLS version
number (Issue #64)
- The document tests now wait for each job to complete before proceeding to the
next job (Issue #66)
- Finishing options were not reported correctly by `ippevesubmit` in the JSON
file (Issue #67)
- The `media-needed` test did not work on streaming printers (Issue #68)
Please respond to this message once you have tested this update, along with any issues you have encountered.