Drucker im Netzwerk einrichten ?

Ich hab den Thread nicht vollständig gelesen.
Was ich aber gelesen habe, veranlasst mich, doch ein paar grundlegende Dinge klar zu machen.
(Das war jetzt sehr höflich, auch wenn man es nur kraft dieser Klammer bemerkt)

• nmap erkennt sehr wohl alle Ports.
  Aber nur, wenn man das ihm auch sagt. Die von dir verwendete Option beeinflusst lediglich, wie die Scanpakete gebastelt werden. nmap scannt ohne weitere Angabe nur die Well-known-ports. Die gehen von 1 bis 1024. Will man andere Ports auch scannen, so muss man das angeben:
  nmap -p 1024-10000 irgendein.host.de würde die Ports von 1024 bis Port 10000 scannen.
• ipp verwendet per definitionem den Port 631. IPP ist ein via HTTP gekapseltes Protocol.
• Port 9100 ist ein PDL - Port (PageDescriptionLanguage ). Man sendet dorthin einen Stream, der ähnlich aussieht, wie ein PDF. Es wird eine druckbare Seite beschrieben und dann gesendet.

URLs und URIs haben zwar syntaktisch gesehen deutliche Unterschiede, sehen jedoch völlig gleich aus, und werden meist auch so verwendet. Es wundert nicht, dass man das nicht deutlich unterscheiden kann, das ist sogar genau so gedacht. Für unsere Zwecke also egal.
Ein solche URL ist aus mehreren Teilen aufgebaut, und nicht alle Teile müssen enthalten sein.
<protocol>://<user>:<spasswort>@host.domain.tld/<Pfad>?arg1=something&arg2=otherthing&arg3&arg.......

Domainpark - Bitte den Rasen nicht betreten. Vielen Dank!:spasswort@host.domain.tld würde also den User "user" mit dem Spasswort "spasswort" auf dem Server "host.domain.tld" anmelden und dort die Seite /index.html verlangen, wenn dem dortigen Server beigebracht wurde auf den URL / mit /index.html zu antworten. (Lässt man etwas weg, so gelten Defaults)

Die Well-known-Ports sind eine Zuordnung.
Es ist eine Konvention, dass ipp == 631 und http == 80 ist.
Man kann sich daran halten, oder auch nicht.

Der URL ipp://1092.178.168.1:631 wäre also gleichbedeutend mit ipp://1092.178.168.1 WENN beide Seiten sich daran halten.
Gebe ich als Protocoll explizit ipp: an, so passiert im sendenden Host schon einiges. Er nimmt an, dass auch wirklich ipp gesprochen werden wird, und die Pakete entsprechend behandeln und formen. Und er nimmt, so kein anderer Port nach dem Hostteil des URLs angegeben wird (irgendwo.de:631) von Haus aus diesen Port.

Das Drucken unter Linux ist eine ganze Kette von Filtern und Programmen. Auch schon rein lokal.
Im einfachsten Falle druckt ein Shellbefehl reine ASCII Zeichen irgendwohin.
Im kompliziertesten Falle, verpackt eine Anwendung das Gemale oder Geschreibsel in eine PDL Datei/Stream und schickt es weiter.
Es wurde schon erwähnt, dass PDL ganz ähnlich aussieht, wie PDF.
Das wird dann zum Netzwerk weitergereicht, dort in einen Netzwerkstream verhackstückt zu einem anderen Rechner oder Drucker, der dann letztlich dort die Netzwerkverhackstückung wieder rausgebastelt und dann vom Zielrechner ODER dem Drucker zum tatsächlichen Druckertreiber gesendet wird, der es dann in Druckbefehle übersetzt.

Dasselbe lässt sich jedoch auch anders erledigen. Die Andwendung druckt LOKAL mit dem LOKAL installierten Druckertreiber und erzeugt einen Datenstrom, den der entfernte Drucker direkt drucken könnte. Er wird dann einfach RAW (ohne jede weitere Bearbeitung) über das Netzwerk gesendet.

Damit das nicht allzuleicht zu Durchschauen ist, sitzt mittendrin noch CUPS. Das CommonUnixPrintingSystem wurde (leider) von Apple gekauft, ist aber rein freie Software.
Bei jeder Linuxkiste ist Cups meist automatisch installiert. Alles gut.
Handelt es sich um einen Drucker, der an einem anderen Linuxrechner hängt, so sind schon ZWEI Cups Server beteiligt.
Der druckende Rechner schickt den Job einfach zum lokalen Cups, was es weiterschickt zum Cups auf dem entfernten Rechner. Und der gibt es zum Druckertreiber, der das dann letztlich zum Drucker bläst.

Die Verarbeitung kann also völlig unterschiedlich sein.
Aber die tatsächliche Verarbeitungskette bleibt gleich: Ein Applikation erzeugt ein gewünschtes Abbild, das vom Treiber für den jeweiligen Drucker aufbereitet und gedruckt wird.
Natürlich wäre auch diese schon komplexe Kette noch viel zu einfach.
CUPS auf Rechner27 könnte auch von Rechner1 einen Druckjob kriegen, den es von Cups auf Rechner2 rendern lässt, um es vom Cups auf Rechner 175 drucken zu lassen.

Die einfache Grundregel lautet: Ist der Druckjob einmal von einem Treiber, egal, wo der rödelt, bearbeitet, so wird der Druckjob NUR noch RAW weitergeleitet.
Das mag ein wenig helfen. Es dürfte genügen einfach mit den RAW Einstellungen zu spielen.

Dass ipp quasi ein gekapseltes HTTP ist, erleichtert die Sache ungemein. Im Browser als Adresse localhost:631 und schon kann man sein LOKAL operierende Dups managen. Und ein rechner:631 oder ein 192.178.168.23:631 managed eben das Cups auf rechner mit IP 192.178.168.23
Es rentiert sich, gleich diese Art zu lernen und sie zu verwenden.

JetDirect ist eine Netzwerkschnittstelle von HP
Da hat dann der Drucker selbst eine richtige Ethernet Karte eingebaut und ist meist via Netzkabel mit einem Hub/Switch/Router verbunden und somit via TCP/IP erreichbar. Wird ein Drucker via USB irgendwo angeschlossen ist es also ganz sicher KEINE JetDirect Verbindung.
Da aber auch diese Drucker von allen möglichen Rechnern bedient werden sollen, sitzt dahinter im Drucker selbst ein MiniCups und das Protokoll, das gesprochen wird ist eine Variante von PDL
(Die meisten DruckerBeschreibungsSprachen stammen eh von HP, einfach, weil die schon immer Drucker gebaut haben)
Also sprechen auch andere Drucker von anderen Herstellern die PDLs von HP.
(Wenn man mal wirklich keinen Treiber für den PrintExot XL 1000 von Firma AlienPrinters findet, kann man getrost HP Treiber versuchen und sie auf eine gängie PDL einstellen. Können wirklich fast alle Drucker aller Hersteller)

Da ich seit über 10 Jahren radikal Win-freie Zone bin, kann ich zu den Win-Aspekten nichts beitragen.
Und somit nicht wirklich helfen.
Außer, dass ich nochmal genau scanne würde, und vor allem mit den RAW Einstellungen spielen würde.
Wie es läuft, sollte jetzt klar sein.

Zitat von Berichtigung

nmap erkennt sehr wohl alle Ports.
Aber nur, wenn man das ihm auch sagt. Die von dir verwendete Option beeinflusst lediglich, wie die Scanpakete gebastelt werden. nmap scannt ohne weitere Angabe nur die Well-known-ports. Die gehen von 1 bis 1024. Will man andere Ports auch scannen, so muss man das angeben:

liest sich plausibel aber beim TE hat nmap 'auch so' Ports jenseits der 1024 angezeigt. Bei mir auch.

Starting Nmap 7.12 ( https://nmap.org ) at 2016-08-21 22:02 CEST
Initiating ARP Ping Scan at 22:02
Scanning 192.168.178.1 [1 port]
Completed ARP Ping Scan at 22:02, 0.21s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 22:02
Completed Parallel DNS resolution of 1 host. at 22:02, 0.00s elapsed
Initiating SYN Stealth Scan at 22:02
Scanning fritz.box (192.168.178.1) [1000 ports]
Discovered open port 53/tcp on 192.168.178.1
Discovered open port 80/tcp on 192.168.178.1
Discovered open port 5060/tcp on 192.168.178.1
Increasing send delay for 192.168.178.1 from 0 to 5 due to 36 out of 119 dropped probes since last increase.
Increasing send delay for 192.168.178.1 from 5 to 10 due to 12 out of 38 dropped probes since last increase.
Increasing send delay for 192.168.178.1 from 10 to 20 due to 11 out of 34 dropped probes since last increase.
Increasing send delay for 192.168.178.1 from 20 to 40 due to 11 out of 30 dropped probes since last increase.
Increasing send delay for 192.168.178.1 from 40 to 80 due to 11 out of 31 dropped probes since last increase.
Discovered open port 9100/tcp on 192.168.178.1
Discovered open port 8181/tcp on 192.168.178.1
Discovered open port 8089/tcp on 192.168.178.1
Increasing send delay for 192.168.178.1 from 80 to 160 due to 211 out of 701 dropped probes since last increase.
Discovered open port 9101/tcp on 192.168.178.1
Completed SYN Stealth Scan at 22:03, 78.47s elapsed (1000 total ports)
Nmap scan report for fritz.box (192.168.178.1)
Host is up (0.00063s latency).
Not shown: 993 closed ports
PORT     STATE SERVICE
53/tcp   open  domain
80/tcp   open  http
5060/tcp open  sip
8089/tcp open  unknown
8181/tcp open  unknown
9100/tcp open  jetdirect
9101/tcp open  jetdirect
MAC Address: 24:65:11:D8:B8:81 (AVM GmbH)
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 78.81 seconds
           Raw packets sent: 1589 (69.900KB) | Rcvd: 1229 (49.180KB)

und wenn du das

Da hab ich jetzt gelernt, dass sich da was geändert hat.
Es werden normal nicht mehr die Well-known-ports verwendet, sondern die 1000 meist verwendeten.
Sagt jetzt die Manpage.
Das guck ich mir nochmal genauer an.

Danke für den Hinweis.

Ohne den Aufruf von nmap zu sehen, lässt sich dennoch nicht viel sagen.
nmap ist ein sehr leistungsfähiges hochgezüchtetes Programm, das enormes Wissen um TCP/IP/IMCP voraussetzt.

Diese Erkennung kann auch durchaus einem erfolgreichten einfachen Hostdetect folgen.
Wenn ein Host schnell erkannt wird, werden jetzt wohl die am meisten verwendeten Ports gescannt.

Mich würde dennoch der genaue Aufruf von nmap interessieren.

Aus der Manpage:

Zitat von man nmap

--allports (keine Ports von der Versionserkennung ausschließen) .

Standardmäßig schließt Nmaps Versionserkennung den TCP-Port 9100 aus, weil manche Drucker einfach
alles ausdrucken, was an diesen Port gesendet wird, was zu Dutzenden von Seiten mit
HTTP-GET-Requests, binären SSL-Session-Requests usw. führen würde. Dieses Verhalten kann man
ändern, indem man die Exclude-Anweisung in nmap-service-probes verändert oder entfernt, oder Sie
geben --allports an, um alle Port zu scannen, unabhängig von einer Exclude-Anweisung.

Alles anzeigen

Immerhin hab ich jetzt gelernt, dass sich da was geändert hat.
Es werden normal nicht mehr die Well-known-ports verwendet.
Das scheint jetzt anders zu sein, das guck ich mir nochmal genauer an.

Insofern Danke für den Hinweis.