lpr

Petr Baláš petr na balas.cz
Neděle Květen 31 19:11:23 CEST 2009


1) mit jistotu ze kabely jsou OK (zkusit jiny kabel, jinou zasuvku),zkusit
pripojit tiskarnu skrz nejaky maly switch nejlepe co
nejpomalejsi (zazil jsem situaci, kdy mi PC fungoval jen po pripojeni
skrz dalsi maly hub, s velkym v racku si proste nerozumel).
Ostatne ony problemy ktere naznacuji by mohlo elegantne resit
pripojeni skrz stary 10Mbit hub :-)

2) podivat se tcpdumpem co se doopravdy deje

3) popr. zkusit vynutit mensi MTU (pripojit skrz nejaky svuj server
a na jeho sitovce nastavit maly MTU) - zazil jsem v linux routeru
vadnou sitovku ktera propoustela jen male pakety - ssh mi fungovalo
ale prenos niceho jineho ne. Docasne to resilo snizeni MTU.

Petr Balas


2009/5/31 rga <rga na centrum.cz>

> > fuj, raw printing :)
>
> No jo, někdy nic nenaděláš...
> já se pořád snažím o ideální svět...
> ... ale pořád mi někdo háže klacky pod nohy... ;-)
>
> Když už jsem to nakousl, třeba někdo (ze síťařů) dá tip,
> snad to nebude až tak off-topic...
> ... Linuxu se to minimálně trošku týká ;-)
>
> Mám tu takový něpěknou problém:
>
> Snažil jsem se o troubleshooting remote printingu,
> (vzdálený) ERP server v matce tiskne přes (vzdálený) Linux
> na (pro mě) lokální tiskárnu s printserverem,
> přes VPN tunel a firewall.
> Podle externí firmy, co outsourcuje firewall,
> komunikaci na cestě nic neblokuje,
> a neví, kde by mohl být problém...
> Prý jedině v tiskárně (jak jinak ;-)).
>
>
> Tiskárna je Zebra ZM400 s interním print serverem.
> Konfigurace tiskárny (nastaveno firmou implementující ERP)
> na Linuxu:
>
> /usr/local/etc/printcap
>
> ##LPRNGTOOL## QUEUE
> .common
> :mc=0
> :mx=0
> :sd=/var/spool/lpd/%P
> :sh
>
> ##LPRNGTOOL## QUEUE filtertype=IFHP ifhp_options= printerdb_entry=
> zm400
> :cm=Zebra ZM400
> :ff='\f'
> :lf=/var/log/lpd
> :lp=192.168.250.16%9100
> :lprngtooloptions=FILTERTYPE="IFHP" IFHP_OPTIONS="" PRINTERDB_ENTRY=""
> :mx=0
> :sd=/var/spool/lpd/%P
> :sh
>
> Když byla tiskárna ve stejném subnetu jako ERP server,
> vše fungovalo jak mělo.
> Když se přestěhovala z mateřské firmy k nám
> (do jiného subnetu dostupného pro ERP server přes VPN a firewall),
> a změnila se IP adresa v printcap, tisk přestal fungovat.
> Resp. začal fungovat velice zvláštně.
> V tiskové úloze se přes "escape sequence" (Zebra ZPL II language)
> tisknou etikety. Pokud se tiskne 1-4 etikety, jsou vytištěné správně.
> Pokud se tiskne víc než 4 etikety, nevytiskne se nic.
>
>
> Sebral jsem Linuxu připravený print job a zkusil ho tisknout "manuálně",
> přes právě zmíněný
>
> cat printjobfile | netcat -w 1 192.168.250.16 9100
>
> Na tiskárně se vytiskly 2 etikety (v souboru jich bylo 20) a konec.
> Tiskárna ve svém logu hlásila
>
> Job Information: TCP/IP * IP Address 192.168.251.2 * TCP Port 9100 * 1024
> Bytes
>
> Zkoušel jsem také tisknout z jiného Windows Server 2003 v daném subnetu,
> a to pomocí LPR (TCP 515)
>
> lpr.exe -S 192.168.250.16 -P raw -o l -d printjobfile
>
> a občas vidím (v TCPView od Sysinternal) connection ESTABLISHED
> ze serveru na tiskárnu. Ale nic se nevytiskne a po timeoutu lpr.exe
> skončí s hláškou
>
> Error: print server did not accept request.  Job aborted.
>
> nebo
>
> Error: data may have been lost.  Could not abort job.
>
> Jindy se spojení "zasekne" ve stavu SYN_SENT a po vypršení timeoutu
> dostanu hlášku
>
> Error: print server unreachable or specified printer does not exist.
>
>
> Zkusil jsem tedy soubor s print jobem zkopírovat přes FTP k sobě
> a pustit ten stejný job u mě, a jak přes Windowsí lpr.exe,
> tak přes netcat na Linuxu se vytiskne všech 20 etiket
> naprosto správně.
>
> Teď nastává otázka: co je špatně.
> Určitě něco, co souvisí se sítí, ale co?
>
>
> Pár "zajímavostí":
>
> ping s většími packety na tiskárnu "vychází" celkem zvláštně:
> vzdálený server na lokální tiskárnu, packety > 1992 B nejsou "odpovězeny"
> lokální počítač na lokální tiskárnu, packety > 1463 B nejsou "odpovězeny"
>
> Zaráží mě, proč přes VPN odpovídá na větší packety než v LAN?
> MTU pro LAN i VPN je 1500.
>
> Začal jsem upravovat print job tak, abych dosáhl různé velikosti,
> a zjistil, že pokud je velikost souboru s print jobem
> (soubor s escape sekvencemi)
> do 2396 B včetně, jsou vytištěny všechny etikety,
> pokud je velikost souboru 2397 B a větší, jsou vytištěny
> jen první dvě etikety (resp. 1024 B souboru),
> a tomu odpovídá i výše uvedený řádek z logu tiskárny.
>
>
> Zkusil jsem upgrade firmware tiskárny na nejnovější
> (jeden z bugů odstraněných v předchozím firmware byl i
> "The Internal 10/100 Print Server now responds
> to TCP packets when sent at a high rate."), no nepomohlo.
>
> Reportoval jsem problém do Zebry, no zatím bez reakce.
>
> Ještě jsem si teď všiml v changelogu firmware u jedné
> z dřívějších změn tohoto:
> "The maximum MTU for the Internal Wired Print server
> on the ZM400/ZM600 has been set to 1460."
>
> Nevím, jestli by konkrétně tento případ mohl souviset
> s Path MTU Discovery a s blokováním
> ICMP Type 3: Destination Unreachable
> Code: 4 Fragmentation Needed and Don't Fragment was Set
> na firewallu.
> Externí firma spravující firewall tvrdí, že nic neblokují
> a že mají vše nastaveno správně. Už jsme ale párkrát
> na "profesionalitu" (a maximálně paranoidní zabezpečení
> firewallu nejen "externě", ale i v rámci VPN matka/dcera)
> této firmy doplatili...
>
> Nedávají ty čísla nějakému síťaři nějaký nápad? Tip?
> V čem by mohl být problém?
> Podezdřívám nějakou souhru VPN + print server v tiskárně.
> Ale nemám zdání, co dál zkusit...
>
> --
> rga <mailto:rga na centrum.cz>
>
> _______________________________________________
> Linux mailing list
> Linux na linux.cz
> http://www.linux.cz/mailman/listinfo/linux
>



-- 
Petr Baláš - petr at balas dot cz



Další informace o konferenci Linux