IPP, bonjour, chromebook, Meraki, ubiquiti

[J_Arnold]

Here they are

1. Click clock area in lower right to open settings icon (gear cluster)
2. Open settings
3. Click "advanced" dropdown
4. Open "print and scan"
5. Open printers
6. click "add printer" icon to right of add printer
7. You should see add printer manually. Put in name, "address" is ip address of printer. On "protocol" dropdown select AppSocket (tcp/ip), select add
8. Advanced printer configuration dialogue box opens. Select the manufacturer and model or provide a ppd. Then click "add" and you are done.

Again, usually you only get minimum configurations like color/bw, duplex. I haven't done a chromebook using access codes for a while, but the last time I did it wasn't available. You had to print to a print server which relayed the access code to the printer.

Thank you. I will definitely give that a try, and you are correct. Toshibas still have no feature access.

[tonerhead]

I agree with you, I stay away from IPP as well. I was just trying to help. Airprint uses the IPP and IPP2 protocol. You can use CUPS printers with your organization’s Chrome OS devices. CUPS uses IPP to print to local and network printers.
Otherwise they use cloud based printing or PPD. Apple is pushing Aiprint on all of their devices. So I don't see it going away anytime soon. Last thing. I do not use Airprint. I use Lpd.

Over the years it seems like every IT person I run into wants to use LPD port for Macs. Even the IT techs we have want to use LPD for the port. I often ask why, no one can give me an answer why. In a Windows world printing started on a com port, then moved to lpt port. When networking came along they needed to go from parallel to network printing so along came lpr (which uses lpd). Then finally came IP or hostname printing. LPD is old technology. Macs have the ability to print IP so why not use it? LPD protocol is just a translator which coverts parallel printing commands into commands that can be sent down ethernet. According to Wiki, LPD started 39 years ago. I wish I knew why we are still using it or what the advantage to using it is.

Side note: I had a cop shop that had to print from their squad cars to a printer in the station (small, 4 cops total). So their IT did a port forwarding of port 9100. Within a day or two, some script kiddie hacker figured that out and would print off pirate faces to their printer. So they came back to our company and said we had to come up with a solution or they were going to start looking elsewhere for something that would work. The first thing I told them to try was port forward 515 and use lpr protocol for printing. Worked fine, script kiddie didn't figure it out. No longer work for that company, but I believe the cop shop is still using that idea. In my mind it was stupid in the first place, they should have been using a vpn but weren't.

[PrintWhisperer]

Over the years it seems like every IT person I run into wants to use LPD port for .....

Ports and drivers are 2 different issues, and unless you are doing some special printing it doesn't matter what port monitor you use as long as the device supports it. For the OP, driver support in the target OS is where the issues come up he's just focused on the wrong thing looking for Windows like support in home devices.

Fact is even Windows V4 printing is moving in the 'austere built-in driver' requiring additional app support as MAC and Linux platforms and IPP/IPPS for cloud printing so may as well learn the new meta.(See MS V4 Printer Extensions/MS Universal Print)

LPR/LPD is the Unix derived protocol (in my 1988 college class it was used for serial printers) and hence MAC OS-(linu)X is grounded in it. It provides flow control and error checking outside of the TCP protocol that Port 9100 does not.

Port 9100 also suffers due to FIFO if multiple hosts print simultaneously, particularly if one is sending a big job. The first in places all other incoming hosts on TCP Keep-Alive and the unit stops receiving their print data. This would make it the worst port type for a busy unit with multiple hosts printing like a bunch of tablets.

BTW Windows LPR port monitor can be added in Server Roles or Windows Features by adding Print and Document Services.

LPR/LPD allows multiple print channels on the same port number by defining the additional parameter of 'queuename'. This allows alternate processing routes such as is seen on Fiery where they use LPR/LPD for the Print/Hold/Direct queues. MyQ uses it to identify all their queues for routing.

[J_Arnold]

Ports and drivers are 2 different issues, and unless you are doing some special printing it doesn't matter what port monitor you use as long as the device supports it. For the OP, driver support in the target OS is where the issues come up he's just focused on the wrong thing looking for Windows like support in home devices.

Fact is even Windows V4 printing is moving in the 'austere built-in driver' requiring additional app support as MAC and Linux platforms and IPP/IPPS for cloud printing so may as well learn the new meta.(See MS V4 Printer Extensions/MS Universal Print)

LPR/LPD is the Unix derived protocol (in my 1988 college class it was used for serial printers) and hence MAC OS-(linu)X is grounded in it. It provides flow control and error checking outside of the TCP protocol that Port 9100 does not.

Port 9100 also suffers due to FIFO if multiple hosts print simultaneously, particularly if one is sending a big job. The first in places all other incoming hosts on TCP Keep-Alive and the unit stops receiving their print data. This would make it the worst port type for a busy unit with multiple hosts printing like a bunch of tablets.

BTW Windows LPR port monitor can be added in Server Roles or Windows Features by adding Print and Document Services.

LPR/LPD allows multiple print channels on the same port number by defining the additional parameter of 'queuename'. This allows alternate processing routes such as is seen on Fiery where they use LPR/LPD for the Print/Hold/Direct queues. MyQ uses it to identify all their queues for routing.

Well thought out and excellent post. Thank you.

[tonerhead]

Ports and drivers are 2 different issues, and unless you are doing some special printing it doesn't matter what port monitor you use as long as the device supports it. For the OP, driver support in the target OS is where the issues come up he's just focused on the wrong thing looking for Windows like support in home devices.

Fact is even Windows V4 printing is moving in the 'austere built-in driver' requiring additional app support as MAC and Linux platforms and IPP/IPPS for cloud printing so may as well learn the new meta.(See MS V4 Printer Extensions/MS Universal Print)

LPR/LPD is the Unix derived protocol (in my 1988 college class it was used for serial printers) and hence MAC OS-(linu)X is grounded in it. It provides flow control and error checking outside of the TCP protocol that Port 9100 does not.

Port 9100 also suffers due to FIFO if multiple hosts print simultaneously, particularly if one is sending a big job. The first in places all other incoming hosts on TCP Keep-Alive and the unit stops receiving their print data. This would make it the worst port type for a busy unit with multiple hosts printing like a bunch of tablets.

BTW Windows LPR port monitor can be added in Server Roles or Windows Features by adding Print and Document Services.

LPR/LPD allows multiple print channels on the same port number by defining the additional parameter of 'queuename'. This allows alternate processing routes such as is seen on Fiery where they use LPR/LPD for the Print/Hold/Direct queues. MyQ uses it to identify all their queues for routing.

Thank you for explaining it. You are the first to explain it to me.

[jmaister]

oh boy, heavy readings...

I'm not network savy at all...connect the dots till they work...is what i learnt to do..

All I rely on is Socket Direct, tcp/ip. Never liked IPP, it was never reliable per any use case in the last ten years for me. Contracting IT company swear by IPP because "newer technology is better" mindset. But I have never bought into those.

"The better technology is the one you never call the printer guy for."


I guess this chrombook printing isnt something that will go away.


*edit: manual config to socket on chromebook does not work for me.

and if I turn IPP off, printing stops. This isnt even cloud printing, this is only LAN.

[J_Arnold]

That is interesting. I have a chromebook, I have set up chromebooks, I have never used IPP. Same with Macs, never. It seems like appsocket, jetdirect or tcp/ip works without failure for me. I guess I am assuming though that the chromebooks and macpads link to lan for internet, not through like apipa reaching out for whatever is available off network. I have taken Macs away from airprint and recreated printers through appsocket or equivalent. Seems to work much better. Just saying maybe I'm doing it wrong, but in my mind works better than IPP.

Most manufacturers create specific drivers for macs, so I don't use cups unless needed. The trouble with Chromebooks are manufacturer's don't write many drivers for them, just generic that print and maybe duplex.

I have found with phones, manufacturers have their printing and scanning apps which allow printing scanning capabilities. I might guess these use IPP connection to apipa networking. Don't know for sure.

I'm not an expert on this stuff. Just saying what has worked for me and asking a question about IPP. I remember years ago IPP seemed to be used primarily in long distance printing like an office in NY printing through the internet to an office in CA. Now businesses have vpn's etc and 2 offices are connected through a wan. I am curious is IPP still really viable? Again, just trying to learn a topic.

My thoughts on APPsocket and jet direct (p9100) protocols: It is considered as the fastest simplest and probably one of the most reliable, but the security is lacking and extremely vulnerable and everyone knows it., so it is a matter of time before it is obsolete or will have to be majorly revised.