Networking over Bluetooth using ...
keenblog
Networking over Bluetooth using BlueZ/PPP
Low power consumption and high hardware compatibility is exactly the right alternative to WiFi when all what you want to do is sitting in the green and chit-chat with other hackers and browse the web a bit.
But it needs you to do some tinkering before it works nicely, so reading what steps I took to make it work for me might make things easier for you.
But it needs you to do some tinkering before it works nicely, so reading what steps I took to make it work for me might make things easier for you.
First I want to mention that the ethernet-level Personal Area Network (PAN) didn't work for me. The hosts weren't able to ping each other at all, despite a successfully established connection. Searching the BlueZ mailing list reveals several people are having the same trouble, but there doesn't seem to be a proposed solution yet but to try another dongle. Thanks, NO thanks. I can do it 
And the only things I need are BlueZ' Dial-up Networking daemon (dund), iptables and pppd. I install these (packages bluez-utils, ppp and iptables) on my laptop running Mandriva (the client) and on my desktop running Debian Etch/testing (which will act as an access point/server).
Most actions require root privileges (as indicated by the '#' character before each command) so all commands given here should be run while being logged in as the super user. Use sudo if you don't like that.
To prevent others from connecting without permission, I set up a PIN on both hosts. In
Don't forget to make it executable (
Now that we got Bluetooth set up, on both the server and client
On the server, create
The first IP will be the IP assigned to the server, the second will be assigned to the client. Now we're almost there...
On the server, launch the daemon that'll wait for the client's connection, create the virtual serial interface, and launch pppd:
Explanation: -s tells the daemon to listen for incoming connections, -p tells it to start listening again after the connection is terminated, -A tells it to only connect on successful authentication using a PIN, and -E encrypts the connection to make things a little harder for evil packet thiefs. The "call dun" is passed to pppd, telling it to use /etc/ppp/peers/dun for configuration.
Now you'll have to know the servers Bluetooth address. While dund is able to search a suitable connection target using the -Q option, it would require the server to always stay discoverable, which we don't want. So find out the server's address using
Now connect from the client to the server:
You should now have a working TCP/IP connection and be able to ping the other host's IP:
Log messages will appear in your /var/log/messages, or pass the -n option to dund to make it stay in foreground and output messages to stdout.
Now what I want to do is share the server's LAN and WAN connection, if you only need a private client/server connection (who knows why, maybe to use a proxy or do everything using an SSH tunnel) you can skip the rest and be happy.
I set up my iptables as follows:
This turns the server into a router using just three commands. Nice, isn't it? Don't forget to set eth0 to whatever connection you want to share with the client.
Now on the client you'd probably want to tell it to use the server as a gateway, use the following command:
If you can't resolve hostnames anymore, add a nameserver to
You can verify everything's working by showing the route for connecting to a host:
The first IP should be that of the server's ppp0 interface.
If all's gone well so far, congratulations! Working TCP/IP and Internets over Bluetooth It's rock-solid for me and only disconnects when I move out of range or pull the dongle 
It restores quickly though thanks to the -p option of dund.
If you got any ideas how to improve speed/ping time or how to connect a M$ Windos box, please let me know.
And the only things I need are BlueZ' Dial-up Networking daemon (dund), iptables and pppd. I install these (packages bluez-utils, ppp and iptables) on my laptop running Mandriva (the client) and on my desktop running Debian Etch/testing (which will act as an access point/server).
Most actions require root privileges (as indicated by the '#' character before each command) so all commands given here should be run while being logged in as the super user. Use sudo if you don't like that.
To prevent others from connecting without permission, I set up a PIN on both hosts. In
/etc/bluetooth/pin I set both the server's and client's PIN to be the same. Then I create a script called /bin/bluepin to return the PIN in /etc/bluetooth/pin:#!/bin/bash
PIN=`cat /etc/bluetooth/pin`
echo "PIN:$PIN"
PIN=`cat /etc/bluetooth/pin`
echo "PIN:$PIN"
Don't forget to make it executable (
# chmod +x /bin/bluepin). Now start the bluetooth service (# /etc/init.d/bluetooth start or simply # service bluetooth start on Mandriva) and let hcid know about the PIN helper: # passkey-agent --default /bin/bluepin &Now that we got Bluetooth set up, on both the server and client
/etc/ppp/options contains no more than:noauth nodeflate nobsdcomp lock
noipdefault
usepeerdns
noipdefault
usepeerdns
On the server, create
/etc/ppp/peers/dun containing the following:noauth nodeflate nobsdcomp lock
mtu 1500
mru 1500
192.168.15.1:192.168.15.2
silent
proxyarp
local
netmask 255.255.255.0
mtu 1500
mru 1500
192.168.15.1:192.168.15.2
silent
proxyarp
local
netmask 255.255.255.0
The first IP will be the IP assigned to the server, the second will be assigned to the client. Now we're almost there...
On the server, launch the daemon that'll wait for the client's connection, create the virtual serial interface, and launch pppd:
# dund -s -p -A -E call dunExplanation: -s tells the daemon to listen for incoming connections, -p tells it to start listening again after the connection is terminated, -A tells it to only connect on successful authentication using a PIN, and -E encrypts the connection to make things a little harder for evil packet thiefs. The "call dun" is passed to pppd, telling it to use /etc/ppp/peers/dun for configuration.
Now you'll have to know the servers Bluetooth address. While dund is able to search a suitable connection target using the -Q option, it would require the server to always stay discoverable, which we don't want. So find out the server's address using
# hciconfig on the server, or make it temporarely discoverable using # hciconfig hci0 piscan and then find it using $ sdptool browse on the client. It'll look like 00:03:0D:00:07:8A.Now connect from the client to the server:
# dund -c 00:03:0D:00:07:8A -p -A -EYou should now have a working TCP/IP connection and be able to ping the other host's IP:
$ ping 192.168.15.2
PING 192.168.15.2 (192.168.15.2) 56(84) bytes of data.
64 bytes from 192.168.15.2: icmp_seq=1 ttl=64 time=29.1 ms
64 bytes from 192.168.15.2: icmp_seq=2 ttl=64 time=16.7 ms
64 bytes from 192.168.15.2: icmp_seq=3 ttl=64 time=15.3 ms
64 bytes from 192.168.15.2: icmp_seq=4 ttl=64 time=13.5 ms
--- 192.168.15.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3012ms
rtt min/avg/max/mdev = 13.595/18.718/29.126/6.115 ms
PING 192.168.15.2 (192.168.15.2) 56(84) bytes of data.
64 bytes from 192.168.15.2: icmp_seq=1 ttl=64 time=29.1 ms
64 bytes from 192.168.15.2: icmp_seq=2 ttl=64 time=16.7 ms
64 bytes from 192.168.15.2: icmp_seq=3 ttl=64 time=15.3 ms
64 bytes from 192.168.15.2: icmp_seq=4 ttl=64 time=13.5 ms
--- 192.168.15.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3012ms
rtt min/avg/max/mdev = 13.595/18.718/29.126/6.115 ms
Log messages will appear in your /var/log/messages, or pass the -n option to dund to make it stay in foreground and output messages to stdout.
Now what I want to do is share the server's LAN and WAN connection, if you only need a private client/server connection (who knows why, maybe to use a proxy or do everything using an SSH tunnel) you can skip the rest and be happy.
I set up my iptables as follows:
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -s 192.168.15.0/24 -j MASQUERADE
# iptables -A FORWARD -i ppp0 -o eth0 -j ACCEPT
# iptables -A FORWARD -o ppp0 -i eth0 -j ACCEPT
# iptables -t nat -A POSTROUTING -s 192.168.15.0/24 -j MASQUERADE
# iptables -A FORWARD -i ppp0 -o eth0 -j ACCEPT
# iptables -A FORWARD -o ppp0 -i eth0 -j ACCEPT
This turns the server into a router using just three commands. Nice, isn't it? Don't forget to set eth0 to whatever connection you want to share with the client.
Now on the client you'd probably want to tell it to use the server as a gateway, use the following command:
# route add default gw 192.168.15.1If you can't resolve hostnames anymore, add a nameserver to
/etc/resolv.conf, like nameserver 208.67.222.222 (for OpenDNS).You can verify everything's working by showing the route for connecting to a host:
# traceroute google.de
traceroute: Warning: google.de has multiple addresses; using 72.14.221.104
traceroute to google.de (72.14.221.104), 30 hops max, 38 byte packets
1 192.168.15.1 (192.168.15.1) 17.087 ms 25.160 ms 8.080 ms
[snip]
traceroute: Warning: google.de has multiple addresses; using 72.14.221.104
traceroute to google.de (72.14.221.104), 30 hops max, 38 byte packets
1 192.168.15.1 (192.168.15.1) 17.087 ms 25.160 ms 8.080 ms
[snip]
The first IP should be that of the server's ppp0 interface.
If all's gone well so far, congratulations! Working TCP/IP and Internets over Bluetooth
It's rock-solid for me and only disconnects when I move out of range or pull the dongle It restores quickly though thanks to the -p option of dund.If you got any ideas how to improve speed/ping time or how to connect a M$ Windos box, please let me know.
Trackbacks
Trackback specific URI for this entry
No Trackbacks