Collegamento seriale tra macchine Linux/Windows


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Login/Register
A cura di Davide Bianchi Mi sono ritrovato a dover trasferire un nuovo kernel ed altra roba dal mio desktop al mio portatile, purtroppo pero' la scheda di rete del mio portatile non era supportata dal mio kernel attuale... che fare ? Ecco quindi come risolvere il problema: una bella connessione via cavo seriale!

Il cavo

Per prima cosa ci vuole un cavo incrociato. Tale cavo e' anche noto come "cavo LapLink" (dal nome del programma che rese noto questo sistema di collegamento nei primi anni '90) o "null-modem".

E' possibile procurarsi questo cavo presso molti rivenditori di materiale informatico oppure fabbricarselo da se', se si ha a disposizione un saldatore, il cavo, i connettori ed un po' di buona volonta'. Lo schema dei collegamenti e' esposto sotto.

Piedinatura della seriale


Pin #  Pin #          Direction  What-it-May-Do/Mean
9-pin  25-pin
 3       2      TxD    -->    Transmits bytes out of PC
 2       3      RxD    <--    Receives bytes into PC
 7       4      RTS    -->    RTS/CTS flow control
 8       5      CTS    <--    RTS/CTS flow control
 6       6      DSR    <--    I'm ready to communicate
 4      20      DTR    -->    I'm ready to communicate
 1       8      DCD    <--    Modem connected to another
 9      22      RI     <--    Telephone line ringing
 5       7      SG               Ground 
Piedinatura di un cavo null-modem

Pin #   Pin #   ->	Pin #	Pin #
9-pin   25-pin          9-pin   25-pin
 3       2      TxD       2       3 
 2       3      RxD       3       2
 7       4      RTS       8       5
 8       5      CTS       7       4
 6       6      DSR       4      20
 4      20      DTR       6       6
 1       8      DCD       1       8
 9      22      RI        9      22
 5       7      SG        5       7

Come si interpreta sta' roba ? A sinistra c'e' il connettore "A", a destra il connettore "B". A seconda che abbiate due connettori da 9 o da 25 pin dovete prendere in considerazione le colonne marcate "9-pin" o "25-pin" da una parte o dall'altra.

Il piedino 'x' del connettore 'A' si collega con il piedino 'y' del connettore 'B'. Se il connettore A e' 9 pin, il piedino 3, si collega con il 2 del connettore B se e' a 9 pin o 3 se e' a 25 pin, e cosi' via.

Nota: Vi sono varie "piedinature" disponibili e dipende molto se usate controllo hardware degli errori o meno. Vedete anche http://www.nullmodem.com/NullModem.htm per ulteriori informazioni.

Il Software

Per collegare tra di loro due macchine Linux o Windows non serve altro che il cavo ed un protocollo: PPP.

Questo documento si basa sul pppd 2.4.0 su un kernel 2.4.2, se avete versioni diverse dovrete probabilmente adattare qualche cosa.

Il Server

Il PPP richiede che uno dei due computer agisca da "server", per fare cio' occorre configurare il pppd in modo che accetti delle connessioni.

Assumendo che il server utilizzi la COM2 per la comunicazione, questa e' vista su Linux come /dev/ttyS1. Se volete, potete forzare l'autenticazione del client (deve digitare username e password), oppure sorvolare su questi "dettagli" ed assegnargli un'utente fisso. Io ho preferito configurare il tutto perche' una password fosse richiesta. Non si sa mai, un giorno potrei voler attaccare il tutto al telefono per accedere da remoto...

La configurazione di PPP su linux e' gestita dai seguenti files:

/etc/ppp/options contiene proprieta' generali per tutte le connessioni
/etc/ppp/options.ttyS1 contiene proprieta' specifiche per la connessione attraverso /dev/ttyS1 (cioe' la nostra COM2 di cui sopra)
/etc/ppp/pap-secrets contiene informazioni relative all'autenticazione, passwords et similia
/etc/inittab e' il file di configurazione ed avvio di vari servizi iniziali, ed e' anche quello che ci serve per avviare "l'ascolto" sulla porta.

Il file /etc/ppp/options, dovrebbe essere una roba piu' o meno come la seguente:


#/etc/ppp/options
lock
#auth forces authorization from peer
#login makes authentication use the system password file
#NOTE: my pap-secrets allows anyone access, so if this is
#      not specified anyone could connect!
#      If this is a machine on which you dial out as well,
#      then comment auth and login out and move them to
#      /etc/options.ttySn
auth
login
Come si puo' vedere la maggior parte sono commenti (#), il parametro "lock" indica che un file di blocco deve essere creato per consentire un'accesso esclusivo alla seriale, i parametri "auth" e "login" indicano che l'utente deve identificarsi e che l'identita' verra' verificata usando i normali utenti/passwords. Cio' significa che l'utente che si collega via seriale deve essere registrato nel sistema come un'utente qualsiasi.

Notate che pppd continuera' a guardare /etc/ppp/pap-secrets per informazioni relative agli utenti ed alle password. Un'unico comando in tale file fara' si' che pppd utilizzi le informazioni del sistema. Il file pap-secrets dovrebbe essere qualche cosa di simile a:


#/etc/ppp/pap-secrets 
# Secrets for authentication using PAP 
# client     server      secret      IP addresses 
     *         *          ""         laplink_client
Questo consente la connessione a tutte le macchine con indirizzo IP "laplink_client" senza una password. Il parametro "login" nel file precedente pero', fa' si che il nome utente e la password fornite dall'utente debbano combaciare sia con i parametri di pap-secrets, sia con quelli di sistema.

Opzioni particolari per la singola seriale attraverso la quale la connessione viene effettuata sono nel file /etc/ppp/options.ttySn, dove 'n' e' il numero della seriale. Dato che stiamo usando COM2, la seriale e' ttyS1.


#/etc/ppp/options.ttyS1 
asyncmap 0 
crtscts 

#local indicates that modem lines are not used 
local 

#silent causes pppd to wait until a connection is made
#from the other side 
silent 

#these are entries that exist in the /etc/hosts file 
#the link does not work if this is at the end of this 
#file - order matters! 
laplink_server:laplink_client 

#auth forces authorization from peer 
#login makes authentication use the system password file
#NOTE: my pap-secrets allows anyone access, so 
#      if this is not specified anyone could connect!
#      If this is a server that will never use ppp
#      for dialing out, you should move auth and 
#      login to /etc/ppp/options
#auth
#login

#use PAP, not CHAP for authentication
require-pap
115200
Tutti questi parametri sono meglio descritti nelle pagine di manuale di pppd (a cui e' sempre bene fare riferimento).

Il parametro "crtscts" indica che pppd deve usare il controllo di flusso hardware per rilevare e correggere eventuali errori di trasmissione. Questo e' bene metterlo, perche' e' molto piu' veloce del controllo software "xonxoff". Perche' questo parametro funzioni pero', e' necessario che il cavo usato colleghi i pin RTS/CTS. Il cavo e' sicuramente completo se lo avete comperato, se lo avete fatto voi invece...

Il parametro 115200 indica la velocita' di trasmissione. Se avete dei problemi nella connessione potreste usare una velocita' inferiore, le velocita' valide sono riportate in numerosi documenti e in varie pagine di manuale, l'usare una velocita' erronea porta alla visualizzazione di un bel messaggio di errore.

Notate che le opzioni "auth" e "login" sono commentate qui, perche' sono specificate nel file di configurazione generale. Se il vostro computer e' anche usato per chiamate verso l'esterno (verso un'ISP per esempio), e' meglio spostare tali parametri qui', altrimenti chiederete al vostro ISP di fare login nel vostro sistema... e dubito che funzionerebbe...

Per ultimo la linea "laplink_server:laplink_client" che specifica gli indirizzi IP locali e remoti da assegnare dopo che il collegamento e' attivato. Potete usare degli indirizzi reali oppure riportare "laplink_server" e "laplink_client" nel file /etc/hosts ed assegnare la' gli indirizzi.

L'utilita' di mettere gli indirizzi in /etc/hosts e' che potete riferirvi a tali indirizzi dopo usando "laplink_server" o "laplink_client" che e' molto piu' semplice.

Ricordatevi di assegnare degli indirizzi IP che siano validi o tratti dal pool 192.168.x.x che e' considerato "non valido" su Internet, ma valido in una rete privata.

Ovviamente, e' possibile usare una configurazione differente che accetti connessioni solo da determinati utenti, oppure usare CHAP invece di PAP per l'autenticazione...

Attivare PPPD perche' accetti connessioni

E' possibile avviare pppd al boot del sistema, in modo che controlli la seriale ed accetti connessioni. Un sistema elegante e' quello di aggiungere una linea ad /etc/inittab.

Questo file controlla quali servizi sono avviati in quali livelli di inizializzazione. Basta aggiungere una linea del tipo:


pd:2345:respawn:/usr/sbin/pppd /dev/ttyS1 nodetach
Che significa (piu' o meno): nei livelli 2,3,4 e 5 (cioe' tutti quelli utili) lancia "/usr/sbin/pppd /dev/ttyS1 nodetach" e se "muore" riavvialo.

Il parametro "nodetach" passato indica a pppd di restare connesso al terminale che lo avvia piuttosto che avviare un'altra istanza. Questa opzione e' necessaria perche' il processo init ne avvierebbe immediatamente un'altro altrimenti, e dato che un solo pppd alla volta puo' usare la seriale, il nuovo pppd morirebbe subito, per venire rigenerato immediatamente... e cosi' via...

Per attivare il demone basta "risvegliare" init digitando /sbin/init q come root.

Avviare il server quando serve...

Se non volete che la vostra macchina stia li' ad aspettare una connessione in continuazione, potrebbe essere un'idea l'avvio del server solo quando vi necessita, in manuale cioe'. Tutti i settaggi rimangono gli stessi, potete avviare il server digitando /usr/sbin/pppd /dev/ttyS1 nodetach da root.

In questo caso l'opzione "nodetach" non e' necessaria, ma rende molto piu' semplice il terminare il comando con un bel ctrl-c.

E Windows ?

Sfortunatamente, l'implementazione di PPP di Windows non e' propriamente standard (se fossi carogna, come sono, direi che e' "standard Microsoft"). Prima di poter inizializzare la connessione, e' richiesto un certo scambio di "messaggi" tra il client ed il server. In particolare il client invia il messaggio "CLIENT", ed il server deve inviare "CLIENTSERVER" (?).

Ma niente paura! Anche se Windows e' lobotomizzato, Linux e' in grado di adattarsi... basta modificare /etc/ppp/options.ttyS1 nel modo seguente:


connect 'chat -v -f /etc/ppp/scripts/winclient.chat'
E creare il file /etc/ppp/scripts/winclient.chat come segue:

TIMEOUT 3600
CLIENT CLIENTSERVER\c
Dalla parte del Client

Dopo la configurazione del server, quella del client e' facilissima. Il file /etc/ppp/options deve avere una singola voce:

#/etc/ppp/options
lock
La seriale usata sul mio client e' /dev/ttyS0 (com1), quindi devo anche creare il corrispondente file di configurazione /etc/ppp/options.ttyS0:


#/etc/ppp/options.ttyS0
115200
crtscts
local
user fogg
noauth
Vediamo che novita' ci sono in questo file: la velocita' di comunicazione deve essere la stessa scelta sul server, con "user fogg" specifico il nome utente che verra' usato dal client al collegamento, ovviamente tale utente deve esistere come utente registrato nel server, il parametro noauth indica che il client non chiedera' la login al server.

L'ultimo pezzo: mettere il nome utente del client e la sua password nel file /etc/ppp/pap-secrets:


#/etc/ppp/pap-secrets
# Secrets for authentication using PAP
# client   server    secret              IP addresses
fogg         *       lamiabellapassword
Ovviamente dovrete usare una password "vera"... lasciare il campo "IP address" vuoto indica che il client si becchera' l'indirizzo IP dal server.

Collegarsi ad un server Windows

Come detto prima, il client deve "spedire" il suo messaggio se vuole che il server gli dia retta. Ancora una volta, useremo l'opzione "connect" ed uno scriptino CHAT per accontentare il server. Basta aggiungere una semplice riga a /etc/ppp/options.ttyS0:

connect chat -v -f /etc/ppp/scripts/winserver.chat
Poi creiamo il file /etc/ppp/script/winserver.chat:

TIMEOUT 10
'' CLIENT\c
Questo rendera' il server Windows tutto contento...

Contatto!

Per prima cosa attacchiamo il cavo (ve lo hanno mai detto che bisognerebbe spegnere le macchine prima di collegare o scollegare un cavo seriale ?), quindi avviamo il server ed infine il client:
/usr/sbin/pppd /dev/ttyS0 nodetach

Se tutto e' stato fatto come si deve dovremmo trovarci "in rete" con il nostro server e vedere (sul server) qualche cosa del tipo:


[root@opus /root]# pppd /dev/ttyS1 nodetach
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS1
user fogg logged in
Deflate (15) compression enabled
local  IP address 192.168.0.1
remote IP address 192.168.1.1
Se abbiamo avviato pppd da inittab, questi messaggi appariranno in /var/log/messages. Sul client dovremmo vedere qualche cosa del tipo:

[root@fogg /root]# pppd /dev/ttyS0 nodetach
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS0
Remote message: Success
Deflate (15) compression enabled
local  IP address 192.168.1.1
remote IP address 192.168.0.1
A questo punto possiamo accedere al nostro server tramite FTP, TELNET o quant'altro... se il nostro server e' connesso ad Internet tramite un modem o una scheda di rete, possiamo usare il nostro client per accedere ad internet se IP-Masquerading e' attivo, per ulteriori dettagli e' meglio vedere l'IP-MASQUERADING-HOWTO

Altre informazioni utili sull'argomento

Il PPP-HOWTO, il Modem-HOWTO, il Serial-HOWTO, l'IP-Masquerade-HOWTO. Tutti i documenti sono reperibili su www.linuxdoc.org


I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

3 messaggi this document does not accept new posts
Rickin alternativa via si può fare via Terminale Seriale Di Rick - postato il 26/08/2009 14:19
Il metodo è molto interessante, personalmente per i firewall che mettevo dai clienti per il precedente $LuogoDiSupplizio avevo predisposto le macchine perchè alla seriale rispondessero con un terminale VT100 da utilizzare con l'Hyperterminal et similia, sfruttando il vetusto z/x modem per il trasferimento dei files.
Come effetto collaterale potevo abilitare il kernel/lilo/grub perché scrivessero su seriale le righe di inizializzazione, in modo da poter usare la macchina senza monitor e tastiera (le info necessarie si trovano nell'HowTo dedicato, Remote Serial Console HOWTO).

con il tuo metodo c'è tuttavia il vantaggio di poter condividere l'accesso ad internet, anche se sono necessari altri passaggi.

Si impara sempre qualcosa di nuovo, grazie mille!

--
Rick


Sandman Di Sandman - postato il 25/02/2011 09:14

Nel lontano 96 mi ero installato slackware in maniera del tutto analoga (in SLIP però) il mio 486 laptop per evitarmi il cambio dei 50 floppy di installazione (cdrom ? Non possedevo un cdrom e neanche una ethernet pcmcia!) e, soprattutto, per paura che qualcuno di essi non venisse letto... bei tempi, grazie per avermeli fatti ricordare! :\)

--
Sandman


Francesco Di Francesco - postato il 14/05/2012 01:32

Ho avuto modo di giochicchiarci un po' di tempo fa (bello anche comunicare con minicom o scambiarsi file con xmodem); ma 'sta roba si usa ancora seriamente? Ok, la console seriale funziona ma ... la connessione slip/plip? O è un puro esercizio di stile?

Una cosa che non sono riuscito a fare, però non mi sono impegnato più di tanto, è la connessione seriale con win 3.1/dos (per quella che descrivi te si parte dal 95 in su).

--
Francesco


Precedente Successivo


Davide Bianchi, lavora come Unix/Linux System Administrator presso una societa' di "sicurezza informatica" (aka: $networkgestapo) di Haarlem. Contatti: mail: davide AT onlyforfun.net , Jabber: davideyeahsure AT gmail.com,


Volete contribuire? Leggete come!.
 
 

Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gort