Iyonix softload ROM 19/3/23 and Printers issue

Hi All,

Just testing the fix for ShareFS and found a potential new issue with the latest 19/3/23.

On my Iyonix I have a network printer using JetDirect and also an Uniprint instance of it.

I also have PrintSpool running.

I have upgraded the disc image from that of around 9/3/23 and also the ROM from that date to the latest 19/3/23 versions and on rebooting and doing the softload I get error messages as Printers is loading to say “Unrecognised file type” from the JetDirectFS printer and "This version of UniServerFs does not support that operation.

I have narrowed it down to the printer definition which is for the Network printers where the connection is JetDirectFS:xxx.xxx.×.xxx and also UniprintFS:PC Name/HP5520.

If I replace the connection to one pointing at a file on the hard disc then the error goes away as it does if I make the printers inactive.

Stopping PrintSpool working does not fix the issue.

If I revert the softload ROM to 9/3/23 version then I do not get any errors when the connection type is set to either JetDirectFS or UniPrintFS.

The changes since 9/3/23 ROM do not mention anything to do with printers but obviously it seems something in the ROM build between then and the 19/3/23 is causing the issue with a printer setup where the connection is not a file and rather a Service type /Ip addesss/name.

Any help testing would be appreciated.

Update:

Done some testing with a Pi4B as well and the same issue is present when using the latest 19/3/23 ROM on the Pi so makes using my network printers unusable with the latest ROM.

I have a Postscript printer, HP 254DW, and also a Photosmart 5520 type where it is classed as Lj class in the PDF if that helps.

Update2:

If I use PrintSpool’ss built in LPR server and set the HP 254DW printer to a file then this works rather than using JetDirectFS details in the File box within Printers connection’s dialogue box.

So it is something it doesn’t like either with JetDirect/UniServe or not being a actual file path on the disc.

The only change I can see in the period 9/3/23 to 19/3/23 is the change to FileSwitch 2.91?

ROOL or ROD stack?

Either stack.

Along with the Pi4B and Iyonix you can now add Beagleboard all with the 19/3/23 ROM that causes the issue.

See details that narrow it down between the 9/3/23 and 19/3/23 ROM’s.

I’d come across this a couple of days ago, but life got in the way before my investigations got me anywhere. Seeing Doug’s post prompted me into further action.

I found that replacing RComp’s JetDirect module with Stefan Bellon’s update of the original from Elliott Hughes gets rid of the error and allows printing to my HP printer across the network.

Using a Pi4, with today’s ROM and HardDisc4, both ROOL and ROD stack tried. I don’t normally use ShareFS.

Hope this helps, rather than muddying the waters.

Hi Dave,

Thanks for the further information.

Were you running a Beta ROM earlier than 19/3/23 so we can narrow it down?

Good to know we have a couple of work arounds be it Stefan’s JetDirect or Ian Hamilton’s PrintSpool.

It seems that both applications effected are RComp ones so best I think to let them know.

Using beta ROM dated 19-Mar-23

Are you seeing issues with any of our other programs – NetFetch/Hermes, Messenger etc? Would be helpful to isolate down what the problem is.

Fileswitch-wise, I think both programs use filepaths to specify IPaddress and port etc. eg. UniPrintFS:Ipaddress/name

Are you seeing issues with any of our other programs – NetFetch/Hermes, Messenger etc?

Not seeing an issue with those programs or with PDFMaker/PrintPDF/PrintSpool either.

Fileswitch-wise, I think both programs use filepaths to specify IPaddress and port etc. eg. UniPrintFS:Ipaddress/name

Yes and as I pointed out ealier in the thread if you change it to use a file name location based on the same machine then you don’t get the error message:

i.e. SDFS::HardDisc4.$.Printout

Obviously it will not print out to the network printer but it shows that with PDFMaker/PrintPDF that printing to a real file name is OK.

Just to say I’ve reproduced the issue, and Alan is on the case.

However, if whomever has been working on Fileswitch would like to drop me an email, it’d be good to figure out where this would best be fixed, as this notation has been acceptable for a long time.

The history entry for ShareFS says:

Fix for latent buffer overwrite bug activated by the change to Internet 5 style structures in version 3.61

Given the source is now able to be seen, would it be possible to say what was actually changed?

I ask because if a change to the networking stuff was causing something to be overwritten, I’m wondering if other things (like some of my code?) might be similarly affected.

We have updates for this as test versions now, so if anyone affected would like to test this now, please drop me an email.