HOW2 mobile, headless-rPi connect to LAN-printer?

I have a Brother printer and it does the same, tcp/9100 needs to be configured for whatever protocol you're using.
Reply to
Jerry Peters
Loading thread data ...
I know that both my Windows computers (At last through XP and I think 8.1but have not chcked show the I/P of the printer
So does my Android (print hammermill app) and though I do not have IOS I suspect their IOS app will too..By the way I highly recommnd that app.
My DHCP does not show it since I hard coded it but the printer will give it on request... Print a test/info page or use function/menu keys.
--Home, is where I park it.
--
This email has been checked for viruses by Avast antivirus software. 
http://www.avast.com
Reply to
John Davis
TCP 9100 is the ephemeral port listener, generally associated with HP JetDirect cards (or equivalent).
IIRC it's assuming data is coming across as formatted PCL or PJL (or whatever the "raw data" type the printer is expecting)[1]. Depends on what the printer is trying to emulate; though PCL is more common on regular printers -- big copiers / printers that include automated stapling / hole punching will likely be PJL wrapped though.
In addition to the JetDirect interface, they usually have LPD/IPP queues as you mentioned (name dependent on mfg and model, most seem to have a "PASSTHRU" and "RAW" [or "raw"], as well as several set for either PostScript or other specific printing languages).
[1] -- Assuming I'm recalling it correctly, this is from "Network Printing" book published by O'Reilly.
Reply to
Dan Purgert
On Wed, 25 Mar 2015 23:55:11 +0000 (UTC), Dan Purgert declaimed the following:
I'd downloaded a sample Brother MFC manual (didn't bother to look up whatever model the OP stated) but it did list port 9100, along with LPR/LPD, and half a dozen other protocols (SNMP, some M$ location protocol, etc.).
Couldn't find anything for a RIP format/language for it -- closest was a spec sheet that listed "GDI Emulation"; which makes it sound like a very big/fancy "winprinter"
It also only listed Windows and OS-X as supported... Unlike my HP printer whose documentation also gave a link to Linux support.
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
up
closest was
Yeah, I'm not entirely sure I'm recalling the thing right, and really don't care enough to hunt down said book. Thing is, even if I do dig it up, I think it's 10 or 15 years old at this point; so it'll only give information on what TCP9100 was used for back then (and, as I recall, it was primarily focused on HP Printers and LPR / LPRng ... so none of this fancy CUPS stuff we have today).
I would be a little surprised that a Brother printer is primarily running GDI, as most of their stuff is pretty well supported in *nix - either right out of the box, or with a quick LPR(ng) filter and printcap download. Though, they are a bit sparse, and forgot to mention that you also needed 1 or 2 "extra" programs installed along side it as prereqs ... but that could've been my mistake with using dpkg.
Reply to
Dan Purgert
Basically its about as high level as a parallel serial or USB port. 9100 was a RAW protocol.
How to get bytes from computer to printer. They still need to be the RIGHT bytes.
MOST printers today are postcript capable and that means CUPS =- which is very very postcript oriented - will be able to make a stab at supporting them.
Problems occur with winprinters that accept some weird PCL language that need a special rasterisation setup to accept a full image or postscript-in-a-weird-font type stuff, or need special commands to select specail features like duplex printing.
The latter can be handled by writing a PPD file. I've actually dome that for a printer that wasn't fully supported.
But rasterisation may be more difficult. I am not sure how cups handles that.
It seems on research there are a bundle of image and postcript to raster programs that cups uses - these should be totally portable to any architecture, and therefore part of any full CUPS and Ghostscript port.
And PPDs are just text files.
So I would say there is no part of CUPS that requires an architecture specific device driver beyond USB, serial, parallel or tcp socket level.
So cups on a Pi should 'just work' *once set up*. As well as it does on *86.
Now of the 'printer discovery tools' that allow automagic detection and installation of network printers, that is another matter.
Id google bonjour, as that seems to be the latest wheeze.
--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher
Thare are also third party rasterising programs that can be used with CUPS - Brother have a number of them for various models. AFAICT the one for my Brother works by using ghostrscript to generate a pnm which the proprietary code sends to the printer in some undocumented format. These tend to be only available as compiled binaries for x86 or x86-64 platforms so if you have a printer that needs one you're out of luck on a Pi.
--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:>IN                                      | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot
Thanks, I could never have imagined the computing had "progressed" to such absurd difficulty.
Reply to
Unknown
> >> what TCP9100 was used for back then > > Basically its about as high level as a parallel serial or USB port. 9100 > was a RAW protocol. > > How to get bytes from computer to printer. They still need to be the > RIGHT bytes. > > > MOST printers today are postcript capable and that means CUPS =- which > is very very postcript oriented - will be able to make a stab at > supporting them. > > Problems occur with winprinters that accept some weird PCL language that > need a special rasterisation setup to accept a full image or > postscript-in-a-weird-font type stuff, or need special commands to > select specail features like duplex printing. > > The latter can be handled by writing a PPD file. I've actually dome that > for a printer that wasn't fully supported. > > > But rasterisation may be more difficult. I am not sure how cups handles > that. > > It seems on research there are a bundle of image and postcript to raster > programs that cups uses - these should be totally portable to any > architecture, and therefore part of any full CUPS and Ghostscript port. > > And PPDs are just text files. > > So I would say there is no part of CUPS that requires an architecture > specific device driver beyond USB, serial, parallel or tcp socket level. > > So cups on a Pi should 'just work' *once set up*. As well as it does on > *86. > > Now of the 'printer discovery tools' that allow automagic detection and > installation of network printers, that is another matter. > > Id google bonjour, as that seems to be the latest wheeze.
--
Obviously, many writers here are 'in the industry'. 
So for them: the more complex the better. 
 Click to see the full signature
Reply to
Unknown
Congratuations to all those people who have fed the troll for the last few days helping him complete his mission of wasting your time.
Reply to
mm0fmf
The same way as any other kind of user. Cars are a couple of orders of magnitude more complex than they were 100 years ago while being much easier for users to drive.
Printers (the big office multifunction ones) do vastly more than my 9-pin dot-matrix device of 30 years ago would do, and even that was much more versatile than the teletypes of 10-20 years earlier.
The users never see the complexity, they just click that 'print' icon. Even the ones on their mobile phone screens. It all Just Works, for users of mass-market operating systems, anyway.
--
Joe
Reply to
Joe
The following initial google seem optimistic for 1 or both of the printers:--
Operating System (OS). STEP 1: Select OS Family. Windows; Mac support.brother.com/g/b/downloadtop.aspx?c...mfc9120cn... - 15k - [19]Cached - [20]Similar pages ---------
SAP
SSL ... support.brother.com/g/b/producttop.aspx?c=au...mfc9120cn... - 12k - [22]Cached - [23]Similar pages The other printer is the very common: lazer jet 3055
What I imagined was an incremental approach, to get my printing without disturbing the office-girl, by * before she arrives: switch on both printer/scanner/fax things; * unplug the eth0 cable, at the wall from her PC; * plug the battery powered rPi's eth0 cable * rPi does eg. using `nc` or countless other utilities to centering on 192.168.0.9100
If you can't find the printer IP/s, there's no value in knowing the protocol/S and CUPS and SAMBA...and...names!
Reply to
Unknown
-- snip --
This seems to be getting close to a solution.
Perhaps I can try `ping 192.168.0.9100` But it will be from a headerless rPi, with only an on/off switch.
== Let's test the idea from the x86 to the rPi. ~:ping 192.168.0.2 >> /pingTrace ^C~:less /pingTrace PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. 64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=1.18 ms 64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.433 ms 64 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=0.481 ms
That's a start.
Reply to
Unknown
Yes but the suposedly 'technos' allow themselves to be blinded by the marketers.
Even I missed the obvious first-step-probe/solution !! Just plug the rPi's eth0 to the printer/S socket in place of the LAN's.
What script-code would allow the rPi to test/probe the printer/S?
I only print 5 x 4 == 20 pages a year, so I can do that before the printer/s are powered-up in the morning.
Reply to
Unknown
It is at this point one realises one is dealing with a clueless fuckwit, and retreats very quietly..
--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher
On Sun, 29 Mar 2015 22:04:49 +0000 (UTC), Unknown declaimed the following:
And that command will fail -- the largest value allowed in any dotted IPv4 address is 255. 9100 is a PORT, not part of the address.
If the printers are on a DHCP LAN, you'll likely need to use some discovery protocol to find the printer (either you have to send a broadcast message of some type and collect all the responses, then query each responder [you now have the IP from the response] to find out if it is a printer; or the printer routinely broadcasts some identification packet that you have to intercept and parse).
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
On Mon, 30 Mar 2015 04:46:04 +0000 (UTC), Unknown declaimed the following:
formatting link
formatting link

And maybe the use of Wireshark to capture network traffic looking for announcements from the printer...
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
And look how many pages the fools replying to this troll have wasted.
Reply to
druck
Since you've snipped the context, one can't see what led up to the ping suggestion. Would it not confirm/not if the printer is set to IP=192.168.0.9100 ; as a starting point.
BTW originaly USEnet was for clueless to become informed; and did you forget to take your meds today?
Reply to
Unknown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.