Presentazione
Introduzione
Connettere due sistemi Linux tramite la, sempre presente, ma spesso inutilizzata, Porta Parallela. Un’ottima soluzione per link dedicati, NFS tra server e postazione Diskless, e perchè no… in alcune topologie, per backup e rindondanza di un’altra interfaccia. PLIP e’ Parallel Line IP per il trasferimento di pacchetti IP su porta parallela. Non si tratta di uno standard, ma si basa sul cavo standard Laplink e il protocollo Crynwr.
Perchè?
Il perchè lo sapete voi. Io ad esempio mi son trovato a sperimentare questa soluzione per creare un link pulito verso una diskless per il trasferimento dati dal server NFS. In questo modo, le interfacce ethernet di client e server rimangono libere da questo tipo di traffico, incrementando le prestazioni verso gli altri host della rete e verso-da Internet.
Un’altra soluzione, può essere un economico backup di un link principale, che cade. Tramite un routing statico o dinamico ben fatto, si può salvare il salvabile fino al vostro intervento.
Prestazioni e distanze raggiungibili
Il tipo di cavo che andiamo a usare è un db25M-db25M Null, che ricicliamo da un cavo di una stampante esistente o che acquistiamo a due soldi. Io sto utilizzado la prima soluzione con un cavo di 60cm, è fattibile. Sappiate comunque che il link si può estendere, garantiti, fino a 15 Metri, ma anche oltre: ci sono report di cavi di oltre 30 Metri.
Le prestazioni: ho toccato i 45 Kb/s con il mio cavo fatto a mano in un trasferimento di un file di 300 Mb su TCP, verso server… praticamente ho usato Iperf.
Lista della spesa
- 1 Porta Parallela su ciascun host interessato
- 1 GNU/Linux, meglio se 2.6 (ma possiamo tornare indietro nella storia del kernel alla 2.2 senza problemi)…con sorgenti disponibili al bisogno, forse ricompiliamo.
- 1 Cavo Db25M-Db25M meglio se parallelo null, ma si può adattare il pinout di cavo con destinazione d’uso diversa
- 30 minuti, se non sorgono problemi.
PS: in questo articolo i due link (le due macchine) avranno nome darbox e elfbox.
Layer 1 – Il cavo, Metodi di implementazione
Metodo 0
Con un cavo Parallel Printer Null possiamo implementare questo metodo, che trasferisce dati con una velocità di 4 bit alla volta. Potete costruirlo seguendo lo schema che segue oppure acquistarlo: il nome per questo media è Null Printer o Turbo Laplink.
STROBE output 1*
D0->ERROR 2 - 15 15 - 2
D1->SLCT 3 - 13 13 - 3
D2->PAPOUT 4 - 12 12 - 4
D3->ACK 5 - 10 10 - 5
D4->BUSY 6 - 11 11 - 6
D5,D6,D7 are 7*, 8*, 9*
AUTOFD output 14*
INIT output 16*
SLCTIN 17 - 17
extra grounds are 18*,19*,20*,21*,22*,23*,24*
GROUND 25 - 25
* Pin non connessi su nessuno dei due capi
NOTA = In fondo all’articolo, nell’appendice A, potete vedere un altro disegnino che riassume in maniera forse meno dettagliata ma più comprensibile la disposizione dei pin interfaccia versione interfaccia. Metodo 1
Avendo a disposizione due porte parallele Bidirezionali, si può utilizzare quest’altro metodo, che permette alle porte trasmissione e ricezione contemporaneamente, anzichè solo trasmissione. Dove ho trovato quest’altra implementazione parlano comunque di porte parallele bidirezionali; ad ogni modo, leggo in diversi altri how-to che anche nell’altra implementazione le porte dovrebbero essere settate da Bios come “Bi-dir”: quindi, finchè non faccio luce preferisco mettere da parte questo secondo metodo.
Il Pinout è differente:
STROBE->BUSY 1 - 11
D0->D0 2 - 2
D1->D1 3 - 3
D2->D2 4 - 4
D3->D3 5 - 5
D4->D4 6 - 6
D5->D5 7 - 7
D6->D6 8 - 8
D7->D7 9 - 9
INIT -> ACK 16 - 10
AUTOFD->PAPOUT 14 -“ 12
SLCT->SLCTIN 13 - 17
GND->ERROR 18 - 15
extra grounds are 19*,20*,21*,22*,23*,24*
GROUND 25 - 25
* Pin non connessi su nessuno dei due capi
Non garantisco la funzionalià di questo metodo, e nella descrizione ci riferiremo al metodo 0. Se qualcuno ne sa di più e’ pregato di farmelo sapere. Glie ne sarei grato.
Il kernel
Setup del kernel
Che si usi un kernel 2.6 (ormai consolidato), o un 2.4/2.2 la configurazione che andiamo a impostare è la medesima. Lo stesso non vale per il codice che ovviamente è stato migliorato, aggiornato e corretto; questo per dire, se avete problemi non imputabili a una vostra svista, aggiornate il kernel e vedete se si risolve. Potete controllare se il kernel attualmente in uso ha già i moduli dei driver che vi servono, nel qual caso vi eviterà la ricompilazione e risparmierete tempo. Abbiamo tre possibilità che andremo ad esplorare per vedere se abbiamo già il necessario:
Kernel Modulare
Se avete un kernel modulare i modi per appurare la disponibilità dei driver sono: vedere se sono caricati:
root@darkbox # lsmod Module Size Used by parport_pc 30468 1 plip 15784 0 parport 25344 2 parport_pc,plip
Se questo e’ l’ouput saltate pure alla sezione 4, siete già a posto. In ogni caso e’ molto probabile che abbiate i moduli ma che dobbiate caricarli:
root@darkbox# modprobe plip
Quindi ripetete il comando precedente, lsmod, e vedete se vi appare l’output di sopra. Se non succede nulla o ricevete risposta negativa passate alla prossima sezione ovvero: Kernel monolitico
In questo tipo di kernel non si caricano moduli, tutto e’ compilato staticamente built-in, quindi l’output di lsmod non può aiutarci. Invece possiamo aiutarci con un:
root@darkbox # dmesg |grep plip
magari lanciato dopo un riavvio per evitare che dmesg venga inquinato da messaggi occorsi dopo che hanno quindi cancellato la parte che ci interessa. Se nemmeno questo comando restituisce nulla, non resta che ricompilare il kernel. Compilare PLIP nel kernel
Esistono stupendi how-to che descrivono la ricompilazione del kernel Linux. Quindi qui affronteremo in breve, visto che costituirebbe argomento a parte farlo estensivamente, i passi necessari all’attivazione del supporto PLIP nel kernel 2.6. Per informazioni approfondite vi rimando al sito www.tldp.org . Nel menù di configurazione dovete assicurarvi di attivare le opzioni seguenti:
Device Drivers —> Parallel port support —> <M>Parallel port support
Networking support —> <M> PLIP (parallel port) support
Naturalmente dovete assicurarvi che lo stack TCP/IP sia attivo, come anche le funzioni di IP forwarding. Anche su questi argomenti ci sono dei completi How-TO che potete trovare nel sito indicato poco sopra. Ho volutamente selezionato i driver che ci interessano come moduli per semplificare poi dopo l’utilizzo. Se siete ormai pinguini, vi invito a decidere da voi come compilarvi il kernel, se preferite seguire lo stile monolitico, fate voi. Un altro appunto lo farei per quanto riguarda un sistema diskless che potrebbe essere uno dei due link. In questo caso e’ bene compilare il kernel come monolitico per evitare la frammentazione e relativa lentezza nel reperimento dei moduli, ricordate che un diskless recupera tutto ciò che gli serve via rete.
Usciti dal menuconfig non vi resta che dare i soliti (per kernel 2.6) comandi:
make make modules_install cp arch/i386/boot/bzImage /boot/my-PLIP-image
e modificare opportunamente la configurazione del bootloader, se necessario. Configurazione del link Caricare i moduli
Nel caso di compilazione monolitica dmesg dovrebbe indicarvi qualcosa del genere:
elfbox root # dmesg |grep PL NET3 PLIP version 2.4-parport [email protected]
Siete a posto così. Se invece avete compilato i driver come moduli date i comandi indicati al punto 3.2.1 (modprobe plip && lsmod) e assicuratevi che tutto sia a posto. Se il modulo non viene caricato e ricevete errore potreste dover specificare l’IRQ e l’IOaddr della porta, ad esempio così:
insmod plip io=0x378 irq=7
Questi parametri sono solitamente configurabili da bios, solitamente l’IRQ assegnato alla parallela e’ 5 o 7. Nel caso di compilazione built-in passate le informazioni al kernel all’interno del file di configurazione del vostro bootloader, Lilo o GRUB che sia o alla riga di comando del boot. Configurazione delle interfacce
Ora si può procedere alla configurazione delle interfacce. Linux tratterà la vostra Parallela come qualsiasi interfaccia di rete, e verrà chiamata plipX dove X è il numero di interfaccia, solitamente plip0. Prendiamo come esempio gli hosts darkbox e elfbox. Darkbox andrà configurato come segue:
darkbox root # ifconfig plip0 172.16.10.1 pointopoint 172.16.10.2 netmask 255.255.255.252 up
In pratica, decifrando l’ordine impartito abbiamo nell’ordine: il nome della interfaccia, l’ip assegnato, il tipo di link che vogliamo creare e l’ip di destinazione mappato, infine la netmask e, molto importante, l'”up” che dice di “alzare” l’interfaccia. Allo stesso modo elfbox all’altro capo del link:
elfbox root # ifconfig plip0 172.16.10.2 pointopoint 172.16.10.1 netmask 255.255.255.252 up
L’output di ifconfig sarà il seguente su elfbox:
elfbox root # ifconfig plip0 plip0 Link encap:Ethernet HWaddr FC:FC:AC:10:0A:02 inet addr:172.16.10.2 P-t-P:172.16.10.1 Mask:255.255.255.252 UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:1 dropped:0 overruns:0 carrier:1 collisions:0 txqueuelen:10 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:7 Base address:0x378
A questo punto il gioco e’ fatto e non dovreste aver nessun problema a pingare i due Point del link a vicenda… naturalmente se avete già pluggato il vostro cavo nuovo fiammante o quello fatto da voi.
Sicuramente il ping ha avuto successo e quindi potete passare alla configurazione del routing come più vi piace , con route o ip ro oppure nel modo di fare. Se avete qualche “screenshot” di prestazioni esaltanti nel trasferimento dati mi piacerebbe ricevere due rige per saperlo (sopra i 45 Kb/s diciamo). Potete anche giocare coi settaggi del bios per vedere come “gira meglio”, ma purtroppo e’ solo una parallelo, quindi c’è poco da fare, potete pitturarla di rosso, non diventerà una Ferrari. Non pinga? Ok, va bene, provo a darvi una mano… Troubleshooting Maledetto truffatore… Layer1
Giuro che a me funziona così come ve l’ho descritto, posso non essere Manzoni, ma più o meno si è capito. Quindi, il prolema siete voi… intanto se vi siete autocostruiti il cavo, beh, sicuramente l’avete ricontrollato tre volte, vero? E se l’avete comprato, avete comprato il cavo giusto!! Ma si, era solo per dire. Se l’interfaccia esiste, su entrambi gli host, e pinga se stessa, il problema e’ senza dubbio il cavo. E lo sapete che il cavo si controlla sempre quattro volte. Layer2
Più che layer 2 possiamo dire che un problema potrebbe essere la configurazione di una ex-stampante; provate a dare:
mega@darkbox $ cat /proc/devices Character devices:
1 mem
2 pty
3 ttyp
4 /dev/vc/0
4 tty
4 ttyS
5 /dev/tty
5 /dev/console
5 /dev/ptmx
7 vcs
e assicuratevi che non esista una riga “6 lp” e che quindi l’output sia simile a quello che vedete sopra. Seppure la porta può essere configurata per gestire Plip e Lp assieme (magari vediamo un’altra volta come fare) questo non l’ho provato, l’ho solo sentito dire e potrebbe invece essere fonte di problemi. Una cosa da considerare e’ l’utilizzo di Tools di analisi (sniffers), per assicurarvi che tutto vada per il verso giusto. Inoltre non so per voi, ma una delle cose più interessanti quando si può osservare un’implementazione nuova, e’ lanciare ethereal! Layer 3
Se il problema e’ identificabile a livello IP, e’ molto probabile che non abbiate configurato a dovere il kernel, oppure, se avete altre interfacce funzionanti (ovvero tcp/ip è invece configurato e non è causa possibile), potreste semplicemente aver digitato male durante la configurazione dell’interfaccia. Guardate nella history e controllate l’output di ifconfig plip0. Le due interfacce parallele devono essere mappate (incluse) una nell’output dell’altro dove appare la dicitura P-t-P. Spero di raccogliere maggiori informazioni su eventuali problemi riscontrati da voi e postarne quindi una soluzione; trovo per il momento, questa sezione ditroubleshooting un pò…scarna. Note Finali
Naturalmente ogni help, correzione (a eventuali catastrofiche fesserie che posso aver scritto), informazione sulla vostra personale realizzazione dell’oggetto di questa guida, le prestazioni nel trasferimento dati che riuscite a ottenere, eventuali problemi incontrati, non potranno che farmi piacere e inoltre potranno essere parte di una eventuale revision di questo Plip How-To.
Appendice A
1 – 1 Yes 2 – 15 3 – 13 4 – 12 5 – 10 6 – 11 7 not connected 8 not connected 9 not connected 10 – 5 11 – 6 12 – 4 13 – 3 14 – 14 Yes 15 – 2 16 – 16 Yes 17 – 17 18 not connected 19 not connected 20 not connected 21 not connected 22 not connected 23 not connected 25 – 25 not connected to metallic shield
A differenza della descrizione precedente, questo cavo ha i pin 1,14 e 16 connessi. Questi non sembrano creare problemi e il cavo funziona comunque. Questo se utilizzate un cavo di recupero, potete evitare di tagliare quei conduttori.
