Printing

Years ago, there was some sort of firewall in some versions of RISC OS, wasn’t there?

Multicasting has to set the socket’s IP address as 0.0.0.0 (INADDR_ANY). If it’s given any other address, multicast reception cannot work.

I can send you the pcap file if you like? It isn’t very large.

I don’t think it would help, Andrew. It doesn’t show us why the receive path inside RPCemu and its host doesn’t work. It shows us that FindIPP’s send is working, and the printer is responding.

I’ve managed to rotate a colour JPEG image with no visible flaws. The only issue is that the margins aren’t yet correct.

Years ago, there was some sort of firewall in some versions of RISC OS, wasn’t there?

ROL version?

I don’t think it would help, Andrew. It doesn’t show us why the receive path inside RPCemu and its host doesn’t work. It shows us that FindIPP’s send is working, and the printer is responding.

Normally, I’d say if the “reply” isn’t getting to the client it would be because there was a router in the path with IGMP snooping enabled and the route pruning is ensuring that traffic doesn’t get sent where no client has expressed an interest in receiving.

Quick search pulls up an article that covers some differences between the multicast modes:
https://orhanergun.net/multicast-pim-dense-mode-vs-pim-sparse-mode

I’ve managed to rotate a colour JPEG image with no visible flaws.

Sorry if this seems like an idiot question… But why are you rotating a JPEG? Wouldn’t it suffice to have an option in the driver where it writes the raster data backwards?
Like RISC OS/application thinks it is doing the usual left to right top to bottom sort of thing but you’re actually sticking the data into the raster right to left, bottom to top.
Hence easily rotated 180°.

ensuring that traffic doesn’t get sent where no client has expressed an interest in receiving

Can’t help but think that if the machine is sending out an mDNS query and the router is blocking replies, then either the outgoing query is somehow malformed (and thus not recognised) or the router is not functioning correctly.

Also, I can see this being of use on corporate networks, but in a home router? The things that often can’t yet do IPv6 correctly?

why are you rotating a JPEG?

Sorry, what I wrote wasn’t clear. It’s a JPEG in a Drawfile. Printing the Drawfile results in a rasterised job. I based the test on a JPEG in the hope that it would make any flaw in the processing more visible.

Can’t help but think that if the machine is sending out an mDNS query and the router is blocking replies, then either the outgoing query is somehow malformed (and thus not recognised) or the router is not functioning correctly.

Andrew Daniel’s case is an emulated system. We know that the replies are reaching the host, so the router is not the problem. We don’t know if it will ever be possible for the host to pass on some or all of the multicast traffic to the emulated system.

Years ago, there was some sort of firewall in some versions of RISC OS, wasn’t there?

RISC OS Six

Dave, don’t forget I’m also testing on a real machine as well.

Andrew Daniel’s case is an emulated system. We know that the replies are reaching the host, so the router is not the problem.

See literature on PIM Spares vs. PIM Dense and route pruning.

Just gave it a test on my system.

Machine is a Pi 3B+ using RODev WiFi. Printer is an HP 4222e. Router is an Orange Livebox 6.

20:07:23.00 Run SDFS::RISCOSPi.$._ippstuff.FindIPP005.!FindIPP.!RunD
20:07:23.00 @RunType_FEB SDFS::RISCOSPi.$._ippstuff.FindIPP005.!FindIPP.!RunD
20:07:23.00 Obey SDFS::RISCOSPi.$._ippstuff.FindIPP005.!FindIPP.!RunD 
20:07:23.09 Set FindIPP$Dir <Obey$Dir>
20:07:23.09 WimpSlot -min 256k -max 256k
[clipped out Obey file stuff to load CLib/toolbox dependencies]
20:07:23.09 wimpslot -min 240k -max 240k
20:07:23.09 Run <FindIPP$Dir>.RunImageD
[clipped out C app doing the same thing in stubs ;)]
FindIPP 0.05 (2024 December 2) starting up
20:07:23.10 Exec
Result of bind: 0
Socket: 63
Transaction ID: 0x67C3
Result of sendto: 33
Message from 192.168.1.15
   1BCC8 ¦67 C3 00 00·00 01 00 00|00 00 00 00·04 5F 69 70 : gÃ..........._ip : +0 
   1BCD8 ¦70 04 5F 74·63 70 05 6C|6F 63 61 6C·00 00 0C 00 : p._tcp.local.... : +16 
   1BCE8 ¦01         ·           |           ·            : .                : +32 
ID: 0x67c3, bits: 0x0000, index: 4
This is a request
Finished dequeueing and processing, false, false
process_state: 0
Closing down; 0 printers found

I think I’ve got duplexing working for some printers. Well, maybe one, anyway.

I’ve emailed new modules to Martin Avison to try out.

See literature on PIM Spares vs. PIM Dense and route pruning.

I had never heard of different ways to achieve multicast. That having been said, one of them appears to operate by treating multicast as broadcast; you get that with cheap unmanaged switches IME. The way I’m assuming, the only one I’ve found in my professional career, is the one where devices join one or more multicast groups. The network infrastructure, and the device IP stack, have to support the requests to join and leave, and the infrastructure has to support the appropriate routing.

AFAIK RISC OS stacks have always supported multicast; I don’t think it’s a recent addition. But again, I’m using a recent build of RO 5.31 along with ROD’s IP stack so I can use IPv6.

The only other person I’m aware of who has written multicast code for RO is Gerph. I should ask him.

Just gave it a test on my system.

Transaction ID: 0x67C3
Result of sendto: 33
Message from 192.168.1.15
   1BCC8 ¦67 C3 00 00·00 01 00 00|00 00 00 00·04 5F 69 70 : gÃ..........._ip : +0 
   1BCD8 ¦70 04 5F 74·63 70 05 6C|6F 63 61 6C·00 00 0C 00 : p._tcp.local.... : +16 
   1BCE8 ¦01         ·           |           ·            : .                : +32 
ID: 0x67c3, bits: 0x0000, index: 4
This is a request

Well, it’s receiving its own request.

Dave, don’t forget I’m also testing on a real machine as well.

The question is where we can observer the traffic, that gives us useful information.

If you use WireSalmon on the real machine, that may tell us whether multicast responses are arriving at the machine. I say “may” because I don’t know whether doing so captures everything arriving at the machine or only everything that apps have sockets open for. But it’s worth a try.

Capturing somewhere else on the network should get either all or none of the mDNS traffic. I suppose that any machine that will run Wireshark will be a member of the mDNS multicast group and so will see all of it.

Where can I get wiresalmon?

Having relocated the venerable RiscPC to somewhere more usable, I decided to upgrade it to 5.30 soft load, which was grand until I powered it off and on again, after which it did a good impression of a dead machine, just getting as far as printing Acorn ADFS on the screen then stiffing completely.

Fortunately there are lots of older !Boot applications on its hard disc but I haven’t managed to get *Lanman98 or a soft load to 5.28 working again (The former only used to work on the latter), which is really the only way to get files onto it these days.

*Lanman98 now working in os 4.02

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.

There’s a RISC OS port of the ippdiscover utility available from here.
It needs the ARMEABISupport and SOManager modules to run. If you have RISC OS Python or Iris installed you should already have these.

Just type from a task window.

ippdiscover -v
querying 12 _ipp._tcp.local, _ipps._tcp.local

It should display info about the found devices and the printer URL to use.

e.g.
ipps://<ip address>/ipp/print

It works OK using RPCEmu.

ippdiscover from my Titanium finds my XP-8700, and gives the address that I am using in IPPTrnspt.

There’s a RISC OS port of the ippdiscover utility available from here.

Sadly, as noted in the ReadMe, it isn’t ROD stack compatible.

*ippdiscover -v

Fatal signal received: EMT trap

Stack backtrace:

Running thread 0xbb2cc (Main Thread)
*

Oh well…

Ippdiscover works on RiscPCemu with both types of networking as predicted.

I have not been able to try it out on the real machine yet under OS 5, because I’m still trying to sort out the mess trying to update it to OS5.30 left it in.

I did try it on OS4.02 but SOmanager, complained about an unknown process. I assume it doesn’t support 26 bit mode?

Now the RiscPC is sorted out, I can confirm that ippdiscover works on the physical machine and finds the printer using OS5.30.