Printing

If anybody is interested, I have released version 0.03 of my FindIPP scanner.
https://heyrick.eu/blog/index.php?diary=20241130#findipp

In this version:

• Now also looks for PWG/IPPE support.
• You can press SPACE to abort the scan if you don’t want to wait to get to x.×.×.254).
• Slightly slowed down the scanning, because my HP4222e needs a firmer prod to get it going.
• Source code supplied (under CDDL).

Note that the source is only a single C file. There is no MakeFile as it was built as a part of something else. I tweaked the program slightly, so it should build with only the DDE and TCP/IP libraries (part of the DDE).

I’ve just thrown this together. It might work…

# Project:   FindIPP

CCflags      = -c -depend !Depend -I,C:,TCPIPLibs: -apcs 3/32bit -Wcdp -throwback -fan 
Linkflags    = -aif -o $@ 

libraries    = TCPIPLibs:o.Socklib TCPIPLibs:o.Inetlib TCPIPLibs:o.Unixlib C:o.stubs

FindIPP:     o.findipp $(libraries)
             @link $(linkflags) o.findipp $(libraries) 

.c.o:;       cc $(ccflags) $< -o $@

Hi Rick,
I can confirm that FindIPP 0.03 works the same as before on RPCemu with NAT, in that it starts scanning from 10.10.10.1 unless the -ip option is used.

Although I haven’t been able to test it on the real RPC yet, I have set up RPCemu on another laptop with ethernet bridging as a third test environment, where FindIPP 0.03 scans the real network and finds the printer. Dave’s !FindIPP and !GetIPP produce identical results to the real RPC.

Also I found this searching:
https://github.com/sudomesh/mdnssd-min
Which I managed to compile using GCC on RPCemu and although it will execute in a task window doesn’t find anything on any of my 3 setups.
Now this may because;
a) I’m a simple woodcutter who knows nothing about C and what I’m doing.
Or;
b) It’s hitting the same brick wall as Dave is.

I’m wondering about cloning the emulators and trying them with the ROD internet stack installed.

You won’t be able to run any mDNS-based application on RPCemu because the host has that address and port open, therefore RISC OS can’t open another one, nor can it share the host’s socket.

We’ve certainly had printing going, via both PWG IPP-Raster and the old Uniraster format’s. We’re also seeing the beginnings of duplexing working – not in all cases, though.

You won’t be able to run any mDNS-based application on RPCemu because the host has that address and port open, therefore RISC OS can’t open another one, nor can it share the host’s socket.

Nothing mDNS based I’ve tried works on the real machine either though. The ethernet bridge RPCemu has a separate IP address and even appears as such on the net scanner on my phone so that shouldn’t be affected by ports being open on the host machine should it? The emulator with the NAT interface could only receive mDNS responses from the fictitious 10.10.10.xx network, if I’ve understood what I’ve read correctly because the IP used by the multicast mDNS packets can’t be forwarded between networks.

Of course I maybe completely wrong because I’m just a simple woodcutter.

I don’t understand why some machines receive the multicast packets and others don’t. I’m sure I’m doing the correct things to control the multicast socket. One problem is that multicast is different; you don’t do it like you do for unicast. This means that there are, presumably, less experts in the field.

But if any of you experts is reading this, I would appreciate your advice and help!

I have released version 0.03 of my FindIPP scanner.

Tried that with my Epson XP-8700, but results are…

*findipp -ip 10.0.0.87 -dump
Will scan only 10.0.0.87
Will dump received blocks.
Looking for IPP enabled printers...
Checking 10.0.0.87 (SPACE to stop)...connected, interrogating...
The path /ipp/print is invalid, trying /ipp/printer (last ditch!)
@@ Received 255 bytes
@@ HTTP/1.1 426 Upgrade Required[0D][0A]Upgrade: TLS/1.0, HTTP/1.1[0D][0A]Connection: Upgrade[0D][0A]Server: Epson_IPP-Server/2.0.0[0D][0A]Cache-Control: no-cache[0D][0A]Pragma: no-cache[0D][0A]Keep-Alive: timeout=30[0D][0A]Connection: Keep-Alive: timeout=30[0D][0A]Connection: Keep-Alive[0D][0A]Content-Type: application/ipp[0D][0A]Content-Length: 0[0D][0A][0D][0A]
Unable to determine the correct URI for IPP for this device.
@@ Received 76 bytes
@@ HTTP/1.1 500 Internal Server Error[0D][0A]Content-Length: 0[0D][0A]Connection: close[0D][0A][0D][0A]
done.

Note that it is an IPP printer, and I have printed to it using Dave’s IPPTrnspt using a URI of ipps://10.0.0.87:631/ips/print

HTTP/1.1 426 Upgrade Required[0D][0A]Upgrade: TLS/1.0, HTTP/1.

Yes, what it is telling you is that it is an IPP printer that has been set to require an encrypted link.
My program doesn’t support that ¹, so won’t be able to report anything useful there.

¹ And since printers typically use self-signed certificates, it seems to be more an illusion of security than actual security – if something can spy on you on your own LAN then you’ve already been compromised.

I just had a eureka moment!

I turned igmp snooping off on my router and suddenly the command line utility that I managed to port finds my printer via mDNSSD on the RPCemu with the ethernet bridge but only in debug mode and only if I omitted local from the service name. The command issued was:

mdnssd-min -a 2 -t 20 -d ipp.tcp.

Which produced reams of info before freezing the emulator. I’m afraid !findipp still produced no result.

It does seem that my printer requires TLS … maybe FindIPP could trap the 426 and display a message, as I suspect such printers are likely to become more the norm. Even if a self-signed certificate is a security illusion.

I turned IGMP snooping off on my router and suddenly the command line utility that I managed to port finds my printer via mDNSSD

IGMP snooping ON – multicast traffic is forwarded only to clients that have signalled an interest in receiving traffic of a particular group.
IGMP snooping OFF – multicast traffic is flooded out of all switch/router ports. Effectively broadcasting the traffic, rather than selectively forwarding.
https://www.cbtnuggets.com/blog/technology/networking/what-is-igmp-snooping

If things start working when the flooding is ON and fail when it is not, then the client isn’t joining the multicast group.

BTW. Figuring out what goes where in a multicast environment and what twiddles certain systems need makes my head hurt.

Now why didn’t I think of that?

So the problem might be that the multicast packets aren’t being forwarded properly by the network infrastructure.

For those who don’t know about multicast, the idea is that there are multicast groups, denoted by an address in the 224.0.0.0 to 239.255.255.255 range, and devices that want to receive multicast traffic join the multicast group. Switches and routers listen to the requests to join and leave the groups, and forward traffic (or not) appropriately. Non-managed switches normally treat multicast traffic as broadcast, so the recipients that want the traffic get it, but so does everyone else.

The switch in front of me here is a cast-off HP 24-port, which clearly can be trusted to forward multicast traffic appropriately. Other devices in the path are a BT SmartHub (not nearly as smart as I would like it to be, but it appears to be smart enough for this job, as my FindIPP receives multicast traffic from other devices in the house that must come through it), and routers running OpenWRT.

There is a question in my mind about TTL (Time To Live), which AIUI has a different meaning for multicast – it affects the scope of the traffic, mostly whether it gets beyond your own LAN. This suggests to me that it isn’t, or shouldn’t be, decremented at each hop. But is this a point of failure if incorrectly handled?

Comments from Mr Pampling, please! And anyone else knowledgable about the practice of multicast.

I just captured some multicast traffic on the Linux box (mostly random, but including a request from my FindIPP app) and I’m seeing TTL values of 1, 64 and 255.

Edit: There is one device, a WD MyCloud (no longer accessible from the outside world!) that multicasts with TTL 4.

Most datagrams have TTL 1, including FindIPP’s request. The OpenWRT devices that implement a mesh network and a point-to-point bridge are 64. The 255 is a response to FindIPP’s request.

https://tldp.org/HOWTO/Multicast-HOWTO-2.html

Most datagrams have TTL 1, including FindIPP’s request.

Discovery datagrams – not going to go beyond the first routing gateway (every routing hop decrements the TTL by 1)

The 255 is a response to FindIPP’s request.

Theoretically, the FindIPP discovery might have come from the other side of the world, so set TTL as 255 to make sure the reply gets there without expiring.

Note 1: If your printer is wired and the client is wireless and there’s a failure, you may be looking at a setup with a router that isolates wireless clients from each other – common on many wireless hotspot setups (or enterprise networks that have a “guest wireless”)

Note 2: If your router offers a ready setup wireless range which is a distinct chunk of what seems to be a /24 CIDR it may be a /25 and a /25 pair of subnets for wired/wireless and routed between, a TTL of 1 would expire on the pass through. Using a TTL of 2-4 would be better

Note 3: Turn off IPv6 while experimenting, it has different behaviour with multicast than IPv4

If anyone using a native (i.e. non-emulated) RISC OS system would like to try it, I’ve put up a new version of FindIPP on my website, https://davehigton.me.uk This version sets the TTL (Time To Live) of outgoing packets to 16, as it’s possible that some switches or routers in use out there do not treat multicast TTL correctly and, as a result, might drop the outgoing packets before they reach their destination.

It is by no means certain that this will help, but it’s worth a shot.

I would also be interested to know, from the users who get no response from their printer(s), what make and model of network switch, router and/or hub is in the path between RISC OS machine and printer.

I’ve Wiresharked the traffic between FindIPP and my Linux print server, and caught lots of other mDNS traffic too, and what I’m sending definitely looks correct. It leaves me utterly perplexed as to why it doesn’t work for everybody (emulated systems excepted).

I just tried running FindIPP on my heating control server. To reach the Linux box, it has to go through an Edimax EW-8270 configured as an AP client, via wifi to the SmartHub, and through the HP network switch. The query came through, still with TTL 16, and the response reached FindIPP.

I’ve tried !FindIPP 0.05 on my RiscPC and I’m afraid there is still no joy.

The router is a TPlink Archer one. The Acorn is connected through a TPlink switch and through a powerline network. Android, Windows 10 and Linux all discover the printer fine.

There did used to be a problem with all devices finding the printer at times. At the time it’s address was a DHCP one with a permanent lease but since switching it to a static IP address it’s been fine even when asleep. The RiscPC is also on a static IP address.

Tried here. Window opens for 10 seconds waiting for responses, then closes and iconbar icon disappears. RO 5.29 on ARMX6, printers are HP P3015 mono and HP M277 colour multifunction, connected via D-Link gigabit switch. ARMX6 and one printer are using static addresses, the other printer is a DHCP reservation (because it keeps forgetting it’s supposed to be static).

Major IPP Printing Success! I have just printed our Christmas Card envelopes using Dave H’s IPPTrnspt, directly from Organizer → Labella → IPP Printer, gaining me considerable brownie points. Many thanks to Dave for the huge amount of investigation, trial and error he has done (and is still doing!) – it is already proving usable, and seemed faster than when I used Gutenprint to my old printer.

Thank you for your appreciation, Martin – and many thanks for working with me on it.

Next target is to get long edge duplexing working correctly, for which it seems that the host must invert the image on the second side. I don’t know whether that will be true for all printers; or whether it will be a feature that can be tested for; or whether it will have to be treated as a quirk of particular printers.

It is my understanding that the raster needs to be flipped around as necessary by the host. The printer is not expected to be able to do transforms, and potentially in the case if things such as inkjets it may well not even have enough onboard memory for more than a few print-inches of data.

Please think of PWG as a raster, not an image. It is something that is intended to be pushed into the printer to cause a reasonably faithful equivalent to be output to a piece of paper. It’s not the printer’s job to do transforms, only to transfer the raster to inks.

Think of it as akin to landscape printing; you don’t send a landscape raster, you send a portrait one with the content within rotated.

In a moment of boredom this evening, I decided to install Wireshark on one of my laptops.
After a bit of searching, I ran !FindIPP 0.05 on the RiscPCemu with the ethernet bridge. It captured one packet of 77 bytes from the emulator, there then followed 14 packets of various sizes from the printer to 224.0.0.251, non of which seem to have been received by FindIPP.

Thank you for doing that, Andrew. It shows that FindIPP is transmitting but not receiving.

RPCemu is different, of course. So is multicast. You mention “the ethernet bridge”, but what is this, and does it require some configuration in order to receive multicast packets? In fact, if the host system has that port open, is it even possible for the host to share received packets?

Hi Dave, I think the best way for you to understand RPCemu with ethernet bridging on windows is to read the guide for seting up networking on RPCemu. It uses a virtual network interface adaptor and the emulator does not use the hosts IP address, in the past I’ve had windows apps using WiFi and riscos using the wired interface. So everything that doesn’t work using NAT such as ping and shareFS work just as they do on a real machine.