Every time I copy data between my desktop and laptop, I think about how it would be faster if my laptop had gigabit ethernet. I have a gigabit switch and an onboard gigabit NIC on my desktop, but the laptop is slow old 100BaseT. However I do this rarely enough that shelling out 30 bucks for a gigabit PC card would be a waste of money (I could buy a NDS game for $30!).
Then it occurs to me that both computers have firewire, and I have a firewire cable. I know you can do networking over firewire, but does it require a special cable? Out of mainline kernel drivers? Nope and nope. It’s this easy:
On each computer:
$ sudo modprobe eth1394
$ dmesg | grep eth1394
[ 2829.651634] eth1394: eth1: IPv4 over IEEE 1394 (fw-host0)
[ 2829.652104] eth1394: eth2: IPv4 over IEEE 1394 (fw-host1)
$ sudo ifconfig eth2 192.168.XXX.Y broadcast 192.168.XXX.255 \
netmask 255.255.255.0
Where 192.168.XXX. is a local network block not already in use, and Y is 1 on the first machine and 2 on the second. If you have multiple firewire host cards and ports, you will get multiple ethernet devices. I plugged the cable into my Audigy, which I guessed correctly was the second host, so I used eth2. I then shoved these commands into $HOME/bin/fweth.sh on each computer so I can start it up quickly next time. The eth device numbers should be the same every time if you don’t have any other dynamic network devices. I then added entries to /etc/hosts so I can ssh/unison/scp without typing the IPs.
Preliminary experiments suggests the connection is screamingly fast. Great success!
Note: I’m pretty sure eth1394 has been in the mainline kernel for a long time, and most distributions likely include the module in the default installation. I’m using Ubuntu Hardy with stock kernel, 64-bit and 32-bit on desktop and laptop respecitively, and no tinkering was necessary. Also a word of warning: according to the linux ieee1394 faq, eth1394 is “neither stable nor fully standards (RFC 2734) compliant–but getting close!”. YMMV.
Windows XP and Mac OS X also have firewire networking, but I’m not sure how well they interoperate with each other and with the Linux version. I’m curious to know if anyone tries it.
UPDATE: I installed sidux and upgraded to kernel 2.6.27, and eth1394 stopped working – the interfaces were not even created. It turns out that the new firewire subsystem does not yet include a port of eth1394, and sidux blacklists the old system in favor of the new by default. Editing /etc/modprobe.d/ieee1394 accordingly and loading ohci1394 fixed the problem.
Thanks for this; I too am trying to do this between two Hardy machines. I’ve done the above and can ping between the above two machines, which tells me the interfaces are up and running . . . but I can’t do anything else. Can’t access a shared drive from one to the other, can’t telnet, can’t ssh. I can ping all day with no problems, but everything else just hangs, eg. ssh 192.168.100.200 from one to the other will just hang indefinitely until I CTRL-X out.
I don’t think this is firewall related, as I can easily connect and use normal network services between the two computers using the ethernet network.
I have found a few other pages which have similar information to the above (this is the most straightforward I’ve seen), but none talk about what to do after the interfaces are actually up and running, e.g., is there anything else you need to do to get the Firewire network actually usable?
Thanks, BV
The network should be usable without any more work. However it’s possible that there are problems at other layers. Most services are configured by default to listen on all network interfaces, but this can be changed with configuration options. Also if you are running a firewall, I doubt it would allow traffic between the new interfaces by default. It is very common for firewalls to filter traffic based on which interface (or ip address) the packets are to/from, not just source/destination ports.
What do you get when you run ‘sudo netstat -atpn | grep sshd’? You should see an entry for 0.0.0.0:22, which means sshd is listening on port 22 at all addresses. If not, check /etc/ssh/sshd_config. Also there could be an entry in /etc/hosts.deny which is blocking access, even if you don’t run a firewall.
Thanks for this; still can’t figure it out. Both machines show ssh listening on all interfaces, e.g.:
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 8558/sshd
/etc/hosts.deny has no entries, no firewall running. Recently upgrade both systems to Ibex, no change.
Strange, really not sure what could be going on here, thanks for your help,
– BV