logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Linux – jak sprawdzać dostępność drukarek sieciowych (IPP, IPPS, socket, dnssd)?

_jta_ 28 Lis 2025 20:24 150 3
REKLAMA
  • #1 21765291
    _jta_
    Specjalista elektronik
    Posty: 49088
    Pomógł: 3212
    Ocena: 4251
    @ElektrodaBot - chciałbym sprawdzać, czy drukarki sieciowe zdefiniowane na komputerze (system Linux) są dostępne. Polecenie "lpstat -v" podaje np.
    device for <nazwa-drukarki>: ipp://<IP-drukarki>/ipp/print
    i wtedy można sprawdzić, czy można się połączyć z portem ipp (631) na <IP-drukarki>.

    Oprócz "ipp" na początku linku widuję: ipps (chyba ten sam port), socket (wtedy port jest zawsze jawnie podany, zwykle to jest 9100), dnssd, impilcitclass - dla tych dwóch ostatnich nie wiem, jak można sprawdzać możliwość połączenia z drukarką.

    Osobna sprawa, to jak sprawdzać możliwość połączenia. Próbowałem w językach Tcl i Python.

    W Tcl-u jest operacja "socket -async IP port", po niej można skonfigurować akcję do wykonania, gdy pojawi się możliwość pisania na socket, i to oznacza, że albo jest połączenie, albo wystąpił błąd (połączenie zostało odrzucone), więc trzeba wtedy sprawdzać, czy socket ma informację o błędzie - jeśli nie ma, to faktycznie jest połączenie; i czekając na tę możliwość pisania trzeba ograniczać czas.

    W Python-ie: użyć socket.socket() do utworzenia socket-u, wykonać na nim setblocking(False), i connect_ex((IP, port)); następnie przez select.select() zaczekać (z ograniczeniem czasu) na możliwość czytania lub pisania - przy połączeniu jest informacja o możliwości pisania, przy odrzuceniu połączenia - czytania i pisania, ale wtedy wypada jeszcze sprawdzić, bo jeśli po połączeniu serwer szybko coś wyśle, to select.select() mógłby zwrócić to samo - i do tego można wykonać getpeername() - daje wyjątek (dlatego trzeba użyć "try" i "except"), gdy nie ma połączenia.

    Nie wiem, czy to są najlepsze sposoby, może jest znany jakiś prostszy, bądź pewniejszy.

    A może w Linux-ie jest gotowy program do sprawdzania łączności z drukarkami sieciowymi?
    "lpstat" może podać informację, czy aktualnie są zadania dla drukarki, czy właśnie jest próba przesyłania jakiegoś, czy drukarka została ustawiona na stan "disabled" z powodu błędu; ale nie widzę, by miał opcję sprawdzania łączności.
  • REKLAMA
  • #2 21765307
    ElektrodaBot
    AI od OpenAI ChatGPT4
    Posty: 8865
    Pomógł: 364
    Ocena: 954
    _jta_ napisał:
    @ElektrodaBot - chciałbym sprawdzać, czy drukarki sieciowe zdefiniowane na komputerze (system Linux) są dostępne. Polecenie "lpstat -v" podaje np.
    device for : ipp:///ipp...
    Bezpośrednia odpowiedź

    - Najprostszy i najpewniejszy test dla IPP/IPPS to ipptool (wysyła realne żądanie IPP – nie tylko „otwiera port”). Dla socket/JetDirect (9100) wystarczy szybki test TCP (nc), a dla dnssd najpierw rozwiąż usługę (ippfind/avahi), potem testuj jak dla IPP. implicitclass nie jest urządzeniem – testujesz członków klasy.
    - Twoje metody (Tcl: socket -async; Python: connect_ex + select) są poprawne. Dla pojedynczych sprawdzeń prościej użyć create_connection z timeoutem; dla wielu hostów równolegle – select/epoll lub asyncio.
    - CUPS nie ma „pingowania” drukarki w lpstat. Gotowe narzędzia w Linuksie: ipptool/ippfind (CUPS), nc/nmap, avahi-browse/avahi-resolve, opcjonalnie snmpget (Printer-MIB) dla „stanu drukarki”.

    ---

    Szczegółowa analiza problemu

    1) Mapowanie URI → co i jak sprawdzać

    - ipp://host[/ścieżka] (domyślnie TCP/631)
    - Warstwa transportowa: TCP/631.
    - Test minimalny: nawiązanie TCP.
    - Test „protokołowy”: ipptool get-printer-attributes (potwierdza, że serwer IPP faktycznie działa i odpowiada).
    - ipps://host[/ścieżka] (IPP over TLS, również TCP/631)
    - Dodatkowo handshake TLS. ipptool obsługuje ipps:// i sam negocjuje TLS.
    - Alternatywnie „surowy” handshake: openssl s_client -connect host:631 -servername host -brief.
    - socket://host:port (AppSocket/JetDirect, zwykle TCP/9100)
    - Brak protokołu aplikacyjnego do „powitania”; port bywa otwarty mimo błędu mechaniki.
    - Test: nc -z -w3 host 9100. Dla bardziej „inteligentnej” weryfikacji można próbować PJL („@PJL INFO STATUS”), ale nie wszystkie urządzenia odpowiadają.
    - lpd://host/queue (jeśli trafisz) – TCP/515
    - Test: nc -z -w3 host 515 albo nmap -p515.
    - dnssd://nazwa._ipp._tcp.local/… (Bonjour/mDNS/Avahi)
    - To deskryptor usługi, nie IP. Najpierw rozwiąż na URI IPP/IPPS:
    - ippfind _ipp._tcp (ew. z filtrem nazwy), albo
    - avahi-browse -rt _ipp._tcp i/lub avahi-resolve -s "nazwa._ipp._tcp".
    - Otrzymane URI (ipp/ipps) przekaż do ipptool.
    - implicitclass://nazwa
    - Wirtualna klasa CUPS. Sprawdzaj członków klasy: lpstat -c -l nazwa (lista), potem dla każdej drukarki z klasy standardowy test wg jej URI. Klasa „działa”, jeśli choć jeden członek jest osiągalny i gotowy.

    Uwagi praktyczne:
    - Otwarty port ≠ gotowość do druku. Prawidłowa odpowiedź na IPP „get-printer-attributes” jest dużo bardziej wiarygodna.
    - IPPS z certyfikatem self-signed: ipptool może wymagać opcji akceptacji/wyłączenia walidacji (w praktyce często wystarcza domyślna konfiguracja CUPS, ale przy restrykcyjnej polityce TLS trzeba to uwzględnić).
    - dnssd wymaga działającego avahi-daemon i nss-mdns (w /etc/nsswitch.conf wpis „mdns”/„mdns4_minimal” przy hosts).

    2) „Gotowe” narzędzia w Linuksie

    - ipptool (pakiet CUPS) – rekomendowane dla IPP/IPPS:
    - ipptool -t ipp://HOST/ipp/print get-printer-attributes.test
    - Kod wyjścia 0 = OK; ≠0 = błąd komunikacji lub protokołu.
    - Działa też dla ipps://…
    - ippfind – znajduje IPP/IPPS via DNS‑SD:
    - ippfind -T 3 _ipp._tcp
    - avahi-browse / avahi-resolve – rozwiązywanie dnssd:
    - avahi-browse -rt _ipp._tcp
    - avahi-resolve -s "Nazwa._ipp._tcp.local"
    - nc (netcat) – szybki test portu TCP:
    - nc -z -w3 192.168.1.100 631 || echo „niedostępny”
    - nmap – jednorazowe skany (np. -p631,9100 --open -T4)
    - openssl s_client – test handshaku TLS dla ipps://
    - snmpget (opcjonalnie) – realny „stan drukarki” (Printer‑MIB), jeśli SNMP na drukarce włączony:
    - snmpget -v2c -c public HOST 1.3.6.1.2.1.25.3.5.1.1.1 (hrPrinterStatus)
    - Pozwala odróżnić „port otwarty” od np. „paper-jam”, „offline”.

    3) Python – proste i pewne sprawdzenie (TCP i TLS)

    - Pojedyncze sprawdzenie (wystarcza w 90% przypadków):

    Kod: text
    Zaloguj się, aby zobaczyć kod


    - Równoległe sprawdzanie wielu drukarek (wydajnie): użyj asyncio.open_connection (dla TCP) i ssl.SSLContext (dla IPPS) albo Twój obecny wariant connect_ex + select/epoll. Zaletą asyncio będzie mniejszy narzut kodu przy dużej liczbie hostów.

    4) Bash – „ping drukarki” w 1–2 linijkach

    - IPP/IPPS (port 631):
    - nc -z -w3 HOST 631 && echo "OK" || echo "FAIL"
    - ipptool -t ipp(s)://HOST/ipp/print get-printer-attributes.test >/dev/null && echo "IPP OK" || echo "IPP FAIL"
    - socket/9100:
    - nc -z -w3 HOST 9100 && echo "OK" || echo "FAIL"
    - dnssd → IPP:
    - for u in $(ippfind -T 3 _ipp._tcp); do ipptool -t "$u" get-printer-attributes.test >/dev/null && echo "$u OK"; done

    5) Co z dnssd i implicitclass?

    - dnssd://…:
    - Rozwiąż do konkretnego URI: ippfind (najprościej) lub avahi-browse/-resolve.
    - Następnie ipptool dla otrzymanego ipp(s)://.
    - implicitclass://…:
    - lpstat -c -l NAZWA pokaże członków.
    - Dla każdego członka zrób test jak wyżej. Klasa dostępna, jeśli dostępny jest co najmniej jeden członek.
    - Jeżeli klasy „same się tworzą/znikają”, zwykle robi to cups-browsed (nie trzeba nic „testować” na klasie).

    6) Rekomendowany algorytm (praktyczny, niezawodny)

    1. Pobierz listę: lpstat -v → (nazwa, URI).
    2. Dla dnssd → rozwiąż przez ippfind/avahi do ipp(s)://.
    3. Dla ipp/ ipps → ipptool -t get-printer-attributes (kod wyjścia).
    - Opcjonalnie, gdy ipptool niedostępny: socket/TLS jak w Pythonie.
    4. Dla socket/lpd → nc -z -w3 host:port (ew. dodatkowo SNMP dla stanu).
    5. Dla implicitclass → rozwijaj i testuj członków.

    To podejście łączy szybkość (nc) z „pewnością protokołową” (ipptool). W praktyce jest to dokładniejsze niż sam test portu i prostsze w utrzymaniu niż własna implementacja IPP.

    ---

    Propozycja: małe narzędzie „printping” (Bash + CUPS)

    - W ~20–30 liniach bash:
    - Parsuj lpstat -v.
    - Dla dnssd użyj ippfind.
    - Dla ipp/ ipps uruchamiaj ipptool (fallback: nc/openssl).
    - Dla socket/lpd – nc.
    - Raportuj: OK/FAIL + czas odpowiedzi.
    Jeśli chcesz, przygotuję gotowy skrypt pod Twoje środowisko (dystrybucja, dostępność ipptool/ippfind/avahi).

    ---

    Pytania uzupełniające

    - Jakiej dystrybucji używasz (Debian/Ubuntu/CentOS/Arch…)? Czy masz zainstalowane ipptool/ippfind i avahi-daemon?
    - Czy zależy Ci na równoległym sprawdzaniu kilkudziesięciu/kilkuset drukarek (wydajność), czy raczej na kilku sztukach (prosty kod)?
    - Czy chcesz raportować „gotowość do druku” (SNMP/IPP atrybuty), czy wystarczy „daje się połączyć na porcie”?
    Możesz mnie wywołać w każdym temacie pisząc @ElektrodaBot. Zastrzeżenie: Niektóre odpowiedzi udzielone przez ElektrodaBota mogą być niedokładne. Elektroda nie ponosi odpowiedzialności za dokładność, rzetelność ani kompletność prezentowanych informacji. Wszystkie odpowiedzi ElektrodaBota powinny być zweryfikowane przez użytkownika. OpenAI może monitorować i zapisywać informacje wprowadzane po wywołaniu ElektrodaBota.
  • REKLAMA
  • #3 21765466
    _jta_
    Specjalista elektronik
    Posty: 49088
    Pomógł: 3212
    Ocena: 4251
    @ElektrodaBot - Dla "get-printer-attributes" należy podawać ścieżkę: /usr/share/cups/ipptool/get-printer-attributes.test
    Można "ipptool -t -q URI /usr/share/cups/ipptool/get-printer-attributes.test" - nie wypisuje żadnej informacji, ale zwraca status 0=OK, albo 1=Error. Bez "-q" jest komunikat, np.:
    Kod: Text
    Zaloguj się, aby zobaczyć kod

    Z tym, że ipptest działa tylko dla protokołów ipp i ipps.

    Dla dnssd: ippfind <uri>, gdzie URI=dnssd://<uri>/ (z tego, co podaje "lpstat -v", obcinam kilka znaków na początku i jeden na końcu) zwraca status OK=0, albo np. 2, jeśli jest błąd.
    Z opcją "-s" podaje nazwę drukarki; z opcją "-p" i nazwą (a nie tym ciągiem wyciętym z URI) podaje inny URI, zawierający adres.

    A z implicitclass nic mi nie wychodzi - tam chyba powinno być "lpstat -l -c <klasa>", ale niezależnie od kolejności -l i -c, i wpisania klasy nie wypisuje nic - tyle, że po -c powinna być istniejąca nazwa, inaczej sygnalizuje błąd.
  • #4 21765471
    ElektrodaBot
    AI od OpenAI ChatGPT4
    Posty: 8865
    Pomógł: 364
    Ocena: 954
    _jta_ napisał:
    @ElektrodaBot - Dla "get-printer-attributes" należy podawać ścieżkę: /usr/share/cups/ipptool/get-printer-attributes.test
    Można "ipptool -t -q URI /usr/share/cups/ipptool/get-printer-attributes.test" - nie wypisuje żadnej informacji, ale zwraca status 0=OK, albo 1=Error. Bez "-q" jest komunikat, np.:
    "/usr/share/cups/ipptool/get-printer-attributes.test":
    Get printer attributes using get-printer-attributes [PASS]
    Z tym, że ipptest działa tylko dla protokołów ipp i ipps.

    Dla dnssd: ippfind , gdzie URI=dnssd:/// (z tego, co podaje "lpstat -v", obcinam kilka znaków na początku i jeden na końcu) zwraca status OK=0, albo np. 2, jeśli jest błąd.
    Z opcją "-s" podaje nazwę drukarki; z opcją "-p" i nazwą (a nie tym ciągiem wyciętym z URI) podaje inny URI, zawierający adres.

    A z implicitclass nic mi nie wychodzi - tam chyba powinno być "lpstat -l -c ", ale niezależnie od kolejności -l i -c, i wpisania klasy nie wypisuje nic - tyle, że po -c powinna być istniejąca nazwa, inaczej sygnalizuje błąd.
    Bezpośrednia odpowiedź

    - Dla IPP/IPPS używaj ipptool z testem get-printer-attributes; nie musisz podawać pełnej ścieżki do pliku testowego (wystarczy nazwa pliku testu). Kod wyjścia ipptool: 0 = sukces, 1 = błąd. Dodaj -T, aby ograniczyć czas. (wiki.debian.org)
    - Dla dnssd najlepiej: z URI z lpstat -v wyodrębnij w pełni kwalifikowaną nazwę usługi (FQSN, np. “HP…._ipp._tcp.local.”), potem użyj ippfind, które potrafi zarówno sprawdzić obecność (exit code), jak i wypisać rozwiązaną postać URI (ipp/ipps). Przyda się -T (timeout), -p (wydrukuj URI), -s (wydrukuj nazwę). (cups.org)
    - implicitclass nie jest „klasą” CUPS w sensie pliku classes.conf, tylko kolejką-klastrem budowaną dynamicznie przez cups-browsed; lpstat -c nie pokaże jej członków. Dostępność takiej kolejki sprawdzasz przez weryfikację, czy istnieje co najmniej jedna zdalna kolejka o tej samej nazwie (odkryta przez DNS‑SD) i odpowiada na IPP. (github.com)

    Poniżej doprecyzowanie poleceń i kilka gotowych „one‑linerów”.

    ---

    Szczegółowa analiza i poprawki

    1) IPP/IPPS — ipptool z limitem czasu

    - Nie trzeba pełnej ścieżki: ipptool sam szuka testów w standardowej lokalizacji (/usr/share/cups/ipptool). Wystarczy nazwa testu. Dodaj -T, aby ograniczyć czas, -q aby zamilknąć i używać tylko kodu wyjścia. (wiki.debian.org)

    Przykład:
    Kod: Text
    Zaloguj się, aby zobaczyć kod

    Statusy ipptool: 0/1 zgodnie z manem. Działa identycznie dla ipps:// (TLS negocjuje ipptool). (cups.org)

    Uwaga terminologiczna: narzędzie to „ipptool” (nie „ipptest”).

    2) dnssd — jak z „device for …: dnssd://…/” przejść do testu

    - lpstat -v dla drukarki z DNS‑SD zwróci mniej więcej:
    device for Nazwa: dnssd://HP%20M404._ipp._tcp.local./?uuid=XXXX

    - Z tego URI wyodrębniasz FQSN usługi: „HP M404._ipp._tcp.local.” (bez „dnssd://”, bez końcowego „/”, dekodując %20→spacja).

    - Sprawdzenie samej obecności usługi (kod wyjścia 0 gdy jest, 2 gdy błąd rozwiązywania/odpytywania) i pobranie docelowego URI IPP/IPPS:
    Kod: Text
    Zaloguj się, aby zobaczyć kod

    Wyjaśnienie opcji: -p (print = wypisz URI), -s (print-name = wypisz nazwę usługi), -T (timeout). Semantykę opcji i kody wyjścia opisuje man ippfind. (cups.org)

    Alternatywnie możesz enumerować cały typ usługi:
    Kod: Text
    Zaloguj się, aby zobaczyć kod

    (--ls wyświetla z miejsca atrybuty Get-Printer-Attributes dla znalezionych usług). (cups.org)

    3) implicitclass — dlaczego lpstat -c nic nie zwraca i co z tym zrobić

    - implicitclass://… to kolejka „klastrowa” budowana lokalnie przez cups-browsed (wysoka dostępność / load‑balancing między wieloma zdalnymi kolejkami o tej samej nazwie). Nie jest to „klasa” CUPS zapisana w /etc/cups/classes.conf, więc lpstat -c nazwa nie pokaże członków (brak „klasy” po stronie serwera CUPS). (github.com)

    - Jak odróżnić prawdziwą klasę CUPS od implicitclass? Prawdziwą da się odpytac pod:
    ipp://localhost/classes/NAZWA (atrybuty zawierają m.in. member-uris / member-names). Dla implicitclass to zwykle zwróci błąd (obiekt nie istnieje). (cups.org)

    Przykład:
    Kod: Text
    Zaloguj się, aby zobaczyć kod


    - Jak praktycznie sprawdzać dostępność implicitclass?
    „Klasa” implicitclass jest OK, jeśli co najmniej jedna z odpowiadających jej zdalnych kolejek o TEJ SAMEJ nazwie istnieje i odpowiada na IPP. To da się wykryć przez DNS‑SD, filtrując rekord TXT „rp” (resource path) na /printers/NAZWA:

    Kod: Text
    Zaloguj się, aby zobaczyć kod

    Powyższe korzysta z faktu, że serwer CUPS ogłasza kolejki przez DNS‑SD z TXT „rp=/printers/NAZWA”. (cups.org)

    4) lpstat — uwagi składniowe

    - -c [klasa(e)] „pokazuje klasy i ich członków”; -l „długi listing”. Kolejność tych dwóch opcji nie jest krytyczna, ale jeśli klasa nie istnieje po stronie cupsd (a implicitclass zwykle nie istnieje), wynik będzie pusty — to wyjaśnia obserwację „nic nie wypisuje”. Dla pełnego podsumowania użyj -s lub -t. (cups.org)

    ---

    Dodatkowe „one‑linery”

    - Szybki test IPP/IPPS z limitem czasu:
    Kod: Text
    Zaloguj się, aby zobaczyć kod

    (cups.org)

    - Sprawdzenie dnssd:// z lpstat -v (wyodrębnienie FQSN i test IPP):
    Kod: Text
    Zaloguj się, aby zobaczyć kod

    (cups.org)

    - Czy to prawdziwa klasa CUPS?
    Kod: Text
    Zaloguj się, aby zobaczyć kod

    (cups.org)

    ---

    Dlaczego to podejście jest „pewniejsze”

    - Test IPP (ipptool) potwierdza nie tylko otwarty port TCP, ale również poprawną odpowiedź na operację IPP — czyli realną gotowość serwera druku. To dokładniejsze niż sam „probe” gniazda. (cups.org)
    - Dla dnssd pracujemy na wzorcowej implementacji (ippfind) i jej semantyce exit‑code/wyjścia. (cups.org)
    - Dla implicitclass opieramy się na faktycznej architekturze cups‑browsed (klastry budowane lokalnie; brak widoczności jako „klasa” po stronie cupsd), więc nie oczekujemy, że lpstat -c zwróci członków. (github.com)

    ---

    Pytania uzupełniające

    - Czy masz uruchomiony avahi-daemon i skonfigurowane nss-mdns (do rozwiązywania *.local), czy pracujesz wyłącznie na adresach IP? (To wpływa na stabilność odkrywania dnssd/ippfind).
    - Chcesz raport „tylko łączność” (kod 0/1), czy także atrybuty stanu drukarki (można rozszerzyć ipptool o pobranie wybranych atrybutów)?
    - Ile drukarek chcesz sprawdzać i jak często (ew. przygotuję wariant równoległy/async)?

    Jeśli chcesz, złoże z tego gotowy skrypt „printping” (bash), który:
    - parsuje lpstat -v,
    - dla dnssd rozwiązuje przez ippfind,
    - dla ipp/ipps testuje ipptool z -T,
    - a dla implicitclass sprawdza jak wyżej z filtrem TXT „rp” i uznaje „OK”, gdy choć jeden członek odpowie.
    Możesz mnie wywołać w każdym temacie pisząc @ElektrodaBot. Zastrzeżenie: Niektóre odpowiedzi udzielone przez ElektrodaBota mogą być niedokładne. Elektroda nie ponosi odpowiedzialności za dokładność, rzetelność ani kompletność prezentowanych informacji. Wszystkie odpowiedzi ElektrodaBota powinny być zweryfikowane przez użytkownika. OpenAI może monitorować i zapisywać informacje wprowadzane po wywołaniu ElektrodaBota.
REKLAMA