Using a firewire cable as a network cable
Spesso sono proprio le cose più utili e indispensabili che diamo per scontate.
Fra queste senza dubbio si possono annoverare le connessioni di rete con relativi device.
Così possono capitare momenti nella vita in cui un uomo si trova a dover fare una rete fra due pc non dotati di scheda wireless e senza avere un cavo ethernet…unico cavo a disposizione un cavo firewire…ce la farà il nostro eroe?
Il tutto è più semplice di come può sembrare inizialmente, per utilizzare la nostra scheda firewire come una scheda di rete è necessario modprobbare un paio di moduli, collegare i due host col cavo in questione e configurare il device di rete che viene creato con ifconfig facendo attenzione a specificare anche l’ip del nostro peer, il tutto è riassunto dai seguenti comandi:
paolomargara@mrcrow:~$ sudo modprobe raw1394 paolomargara@mrcrow:~$ sudo modprobe eth1394 paolomargara@mrcrow:~$ sudo ifconfig eth2 192.168.0.3 pointopoint 192.168.0.6 up
…le stesse operazioni vanno ripetute sull’altro host ovviamente invertendo gli indirizzi ip.
Una volta fatto ciò eseguendo dmesg dovrebbe comparire qualcosa di simile a quanto segue:
[ 166.381975] ieee1394: raw1394: /dev/raw1394 device initialized [ 179.468755] eth1394: eth1: IPv4 over IEEE 1394 (fw-host0) [ 417.087819] ieee1394: Current remote IRM is not 1394a-2000 compliant, resetting... [ 418.038046] ieee1394: Node added: ID:BUS[0-00:1023] GUID[384fc0000ee83050] [ 418.038069] ieee1394: Node changed: 0-00:1023 -> 0-01:1023 [ 632.037192] NET: Registered protocol family 17 [ 895.681427] ieee1394: Node changed: 0-01:1023 -> 0-00:1023 [ 895.681434] ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[384fc0000ee83050] [ 910.235164] ieee1394: Error parsing configrom for node 0-00:1023 [ 910.913752] ieee1394: Error parsing configrom for node 0-01:1023 [ 910.913757] ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0011d800018ea855] [ 911.185288] ieee1394: Node resumed: ID:BUS[0-00:1023] GUID[0011d800018ea855] [ 911.863975] ieee1394: Node changed: 0-00:1023 -> 0-01:1023 [ 911.863980] ieee1394: Node resumed: ID:BUS[0-01:1023] GUID[384fc0000ee83050] [ 1146.839591] ieee1394: Node suspended: ID:BUS[0-01:1023] GUID[384fc0000ee83050] [ 1155.238399] ieee1394: Node resumed: ID:BUS[0-01:1023] GUID[384fc0000ee83050]
Nel malaugurato caso in cui il tutto non dovesse funzionare al volo vi consiglio di verificare che la default route sia corretta (pacchetti che passano per la scheda firewire e non per la scheda ethernet), verificare di non avere regole che blocchino il traffico su schede di rete diverse da quella che usate abitualmente nel vostro script iptables (se ce l’avete) ed in fine se ancora non va, be siete stati veramente sfortunati, provate a vedere con tcpdump che fine fanno i pacchetti.
Constatazioni sulla banda
Terminata la fase di reale necessità mi sono chiesto se una connessione di rete fra schede firewire fosse più veloce di una connessione con schede ethernet.
La risposta più becera è che la velocità teorica di una connessione firewire è di 400 Mb/s e quella di una connessione ethernet ormai è alla peggio 100 Mb/s se non 1000Mb/s, quindi analizzando le velocità massime teoriche vien facile affermare che se si usano schede ethernet a 100Mb il firewire risulta più veloce mentre così non è se si usano schede 1Gb.
Ecco avete appena scoperto che sò fare i conti.
Visto che in un’ambito di reale utilizzo i numeri sono spesso diversi ho deciso di fare una prova pratica, il software utilizzato è la semplice utility bing che non fà altro che inviare pacchetti ICMP di tipo echo request con dimensione in un predeterminato range, ecco i risultati.
Link firewire:
paolomargara@mrcrow:~$ sudo bing -e 10000 -s 512 -S 1024 192.168.0.3 192.168.0.6 BING 192.168.0.3 (192.168.0.3) and 192.168.0.6 (192.168.0.6) 512 and 1024 data bytes (8192 bits) ... --- 192.168.0.3 statistics --- bytes out in dup loss rtt (ms): min avg max std dev 512 10000 10000 0% 0.015 0.026 0.179 0.008 1024 10000 10000 0% 0.014 0.024 7.968 0.080 --- 192.168.0.6 statistics --- bytes out in dup loss rtt (ms): min avg max std dev 512 10000 10000 0% 0.113 0.178 48.117 0.659 1024 10000 10000 0% 0.156 0.231 48.097 0.938 --- estimated link characteristics --- host bandwidth ms warning: rtt big 192.168.0.3 0.014ms < rtt small 192.168.0.3 0.015ms 192.168.0.6 190.512Mbps 0.098
Link ethernet:
paolomargara@mrcrow:~$ sudo bing -e 10000 -s 512 -S 1024 192.168.0.3 192.168.0.2 BING 192.168.0.3 (192.168.0.3) and 192.168.0.2 (192.168.0.2) 512 and 1024 data bytes (8192 bits) ... --- 192.168.0.3 statistics --- bytes out in dup loss rtt (ms): min avg max std dev 512 10000 10000 0% 0.015 0.030 0.181 0.004 1024 10000 10000 0% 0.014 0.028 0.275 0.005 --- 192.168.0.2 statistics --- bytes out in dup loss rtt (ms): min avg max std dev 512 10000 10000 0% 0.219 0.293 1.176 0.019 1024 10000 10000 0% 0.339 0.448 2.960 0.043 --- estimated link characteristics --- host bandwidth ms warning: rtt big 192.168.0.3 0.014ms < rtt small 192.168.0.3 0.015ms 192.168.0.2 68.267Mbps 0.204
Da ciò si deduce che il link firewire pur non raggiungendo il su massimo teorico mantiene ottime performance attestandosi sui 190Mb/s garantendo performance superiori di quelle ottenibili con schede ethernet a 100Mb, mi auguro che il risultato ottenuto con schede ethernet sia dipeso da qualche problema di uno dei due sistemi utilizzati (che per inciso erano gli stessi in entrambe le prove).
Dimenticavo: nel caso in cui abbiate un cavo usb maschio-maschio potete collegare i due pc in rete utilizzando il modulo usbnet, con l’usb 1.1 avrete prestazioni penose ma con l’usb 2.0 avrete prestazioni interessanti.
Bello. Non mi serve, ma bello. Personalmente ho sempre ritenuto il firewire una tecnologia abbastanza evitabile a meno che uno non sia appassionato di videocamere. Alla fine uno usa USB 2x oppure ethernet per le fotocamere, i dischi esterni e i collegamenti diretti tra PC.
Sì, semplice ma utile. Domanda: le interfacce vanno per forza configurate in modalità pointtopoint?
Per forza no…in effetti anche configurate non in modalità point-to-point il tutto funziona egregiamente.