Wireless Hacks. 1917 IndustrialStrength Tips and Tools [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Wireless Hacks. 1917 IndustrialStrength Tips and Tools [Electronic resources] - نسخه متنی

Rob Flickenger

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید










Hack 17 Bluetooth to GPRS in Linux


Use your Bluetooth phone as a modem when Wi-Fi
isn't available.

No doubt the novelty of being able to
scan for nearby Bluetooth devices from your Linux machine will wear
off all too soon, and you'll be wanting to actually
do things with your shiny new Bluetooth
connection. Being able to use your cell phone as a

modem from all those places you
can't pull in a Wi-Fi signal would be pretty cool,
wouldn't it?

Bluetooth supports a number of
"profiles," which define the way
that Bluetooth devices can communicate with each other. In this case,
we want to make use of the
Dial-up Networking (DUN) profile,
which relies on a protocol called RFCOMM to emulate
a serial link between two devices. You can use RFCOMM to connect your
Linux box to your phone, and then run pppd over
the link to get access to the Internet. This works using GPRS, or
even an ordinary Internet dial-up.

Assuming you've got Bluetooth working [Hack #16], you should be able to
bring your phone within range of your computer and scan for it using
hcitool. We'll presume that
you've done this, and that
hcitool reports a BD address for your phone of
00:11:22:33:44:55.

You can also use
sdptool
to verify that there's a device in range that
supports the DUN profile:

$ sdptool search DUN
Inquiring ...
Searching for DUN on 00:11:22:33:44:55 ...
Service Name: Dial-up Networking
Service RecHandle: 0x10001
Service Class ID List:
"Dialup Networking" (0x1103)
"Generic Networking" (0x1201)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1

Note this channel number, because you'll need it
later. As you can see, hcitool and
sdptool offer a lot of other useful Bluetooth
diagnostic functions, which you can read more about on their
respective manpages.

Before you can actually connect to the phone, however, you may need
to set up what's referred to as device
pairing between your Linux box and your phone,
so that your phone knows to allow your computer access to its
services, and possibly vice versa. Your computer's
PIN can be found in
/etc/bluetooth/pin, and you will want to alter
this to a unique value that only you know.

Most phones have a Bluetooth PIN that you can configure within the
phone itself. BlueZ comes with a little Python
utility called bluepin that pops up a GTk+
dialog to ask for your phone's PIN as needed; this
utility apparently doesn't work out of the box
requires in some Linux distributions. More to the point, who wants to
be asked for your phone's PIN every time you use the
thing, anyway? The following Perl script can be saved to
/etc/bluetooth/pindb, and you can use it store
PINs for multiple
Bluetooth devices:

#!/usr/bin/perl
while ( ) {
print "PIN:$1\n" if /^$ARGV[1]\s+(\w+)/o;
}
__DATA_ _
# Your Bluetooth PINs can go here, in BD address / PIN pairs,
# one to a line, separated by whitespace.
#
# ## etc.
00:11:22:33:44:55 11111

Make sure that /etc/bluetooth/pindb is owned by
root and chmod 0700you don't want ordinary
users being able to look up your Bluetooth device PINs. The options
section of your /etc/bluetooth/hcid.conf should
accordingly look something like this:

options {
autoinit yes;
security auto;
pairing multi;
pin_helper /etc/bluetooth/pindb;
}

This ensures that HCI devices are configured at boot, that pairing is
allowed, and that hcid will ask pindb
for your PINs on a per-device basis. Be sure to restart
hcid by running
/etc/rc.d/init.d/bluetooth restart if you made any
changes to your /etc/bluetooth/hcid.conf.

Now that your computer is set up for pairing, you'll
have to set up your phone similarly, for which
you'll need to refer to your user's
manual. This set-up process often requires that the phone can scan
for your computer's Bluetooth adapter, so be sure
that your computer is within range with a working Bluetooth adapter.
The interface will probably come up as "BlueZ
(0)", or something similar, unless you changed the
"name" option in your
hcid.conf. You probably want to set up the
pairing on the phone as "trusted,"
or the moral equivalent, so that the phone doesn't
ask you to verify the connection each time you try to dial out from
your Linux box.

Now that I've shown that there's a
device in range that offers dial-up networking, and set up
pairing with it, the next step is to
bind an RFCOMM interface to that device. First, make sure that there
are RFCOMM entries in your /dev directory, using
ls -l /dev/rfcomm*. If ls
reports "No such file or
directory", you can trivially create 64 RFCOMM
device entries by switching to the superuser and doing the following:

# for n in `seq 0 63`; do mknod -m660 /dev/rfcomm$n c 216 $n; done
# chown root:uucp /dev/rfcomm*

If you're running Debian, you probably want to
chown your RFCOMM devices to
group dialout, instead of
uucp.

Now, as the superuser, bind /dev/rfcomm0 to your
phone on the channel reported for DUN by sdptool
earlier, using the
rfcomm utility from
bluez-utils:

# rfcomm bind /dev/rfcomm0 00:11:22:33:44:55:66 1 

You'll know that the device was bound successfully
if, like any good Unix utility, rfcomm just
returns silently. You can demonstrate that it did actually work,
however, by running rfcomm without any
arguments:

# rfcomm
rfcomm0: 00:11:22:33:44:55 channel 1 clean

Now you can pretty much just treat this serial device as if it were
an ordinary modem. Just to prove it, try running
minicom as root, and switch the serial device to
/dev/rfcomm0. When the terminal loads, type
AT and press Enter. If the phone responds
OK, then congratulations are in
orderyou're talking to your cell phone over a
Bluetooth connection.

Before going any further, you may want to add the following to your
/etc/bluetooth/rfcomm.conf , so that the RFCOMM device is
configured by default when Bluetooth loads:

rfcomm0 {
# Automatically bind the device at startup
bind yes;
device 00:11:22:33:44:55;
channel 1;
comment "My Phone";
}

If you're running bluez-utils 2.3 or earlier on a
non-Debian-based distro, you may need to add
rfcomm
bind all to the start(
)
section of your
/etc/rc.d/init.d/bluetooth for this to work
right.

From here, it's just a short hop to getting your
computer on the Net. Put the following
into /etc/ppp/peers/gprs:

/dev/rfcomm0
connect '/usr/sbin/chat -v -f /etc/ppp/peers/gprs.chat'
noauth
defaultroute
usepeerdns
lcp-echo-interval 65535
debug

Then save the following as
/etc/ppp/peers/gprs.chat:

TIMEOUT         15
ECHO ON
HANGUP ON
'' AT
OK ATZ
OK ATD*99#

Alternately, if you prefer using
wvdial, try adding the following to your
/etc/wvdial.conf:

[Dialer gprs]
Modem = /dev/rfcomm0
Phone = *99#
Username = foo
Password = bar

Note that while European providers give you a username and password,
in the U.S. you still need to supply dummy values to satisfy
wvdial. Consult your network
provider's web site for details about what values
you may need to use. Your GPRS is actually already authenticated by
your very presence on the cellular network, so you
don't have to re-auth just to use PPP. The
"phone number" listed is the
standard GPRS dial-up number, which may work for you right off the
bat if your phone is configured properly. Most
GSM phones support multiple GPRS access
points, howeverso, if the default for your phone
doesn't work for you, try going into minicom and
typing AT+CGDCONT? followed by a carriage
return. Your phone should respond with a list of available
Packet Data Protocol (PDP)
contexts. Pick the one that seems the most appropriate, and then set
your GPRS phone number in /etc/wvdial.conf to
*99***n#,
replacing n with the
number of the PDP profile you want to use. Failing that, try
contacting your service provider for advice!

You can test this setup as root by running either
pppd call
gprs or wvdial
gprs, depending on your setup, and watching
/var/log/messages in another window. The only
hitch with this setup is that it doesn't set up your
nameservers in /etc/resolv.conf by default. The
way around this on Red Hat is to store the following in
/etc/sysconfig/network-scripts/ifcfg-ppp0 (or
ppp1, ppp2, etc. as you
prefer):

# comment out CHATSCRIPT and uncomment WVDIALSECT if you're using wvdial
DEVICE=ppp0
MODEMPORT=/dev/rfcomm0
CHATSCRIPT=/etc/ppp/peers/gprs.chat
# WVDIALSECT=gprs

This way you can just use
ifup
ppp0 and ifdown
ppp0 to bring the link up and down. To get the
identical result on Debian, use the pppd
configuration just shown, and add the following to your
/etc/network/interfaces:

iface ppp0 inet ppp
provider gprs

If you're not using a Red Hat- or Debian-like
distribution, you can always just add the following additional lines
to your
/etc/ppp/peers/gprs to make DNS work right, and use
pppd call
gprs and killall pppd to bring
the link up and down:

welcome 'cp -b /etc/ppp/resolv.conf /etc/resolv.conf'
disconnect 'mv /etc/resolv.conf~ /etc/resolv.conf'

That's just about all you need to know to get online
from anywhere you can get GSM service. Just don't
expect blistering speeds from it: as of this writing,

GPRS
ranges in speed from under 5k/s to just over 20k/s, depending on your
servicenot exactly high speed by modern standards, but amazing
where you would otherwise have nothing at all.

As a little bonus, here's a short
iptables
script to let
you share that GPRS with anyone in Wi-Fi range, which could be stored
as or called from /etc/ppp/ip-up.local:

# Enable IP forwarding and rp_filter (to kill IP spoof attempts).
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
# Load relevant kernel modules, if necessary.
for i in ip_tables ipt_MASQUERADE iptable_nat
ip_conntrack ip_conntrack_ftp ip_conntrack_irc ip_nat_irc ip_nat_ftp; do
modprobe $i 2>/dev/null;
done
# Masquerade anything that's not from a PPP interface
# (e.g. ethernet, Wi-Fi, etc.)
iptables -t nat -A POSTROUTING -o ppp+ -j MASQUERADE

But what, you ask, about regular
dial-up connections? How about faxes? Well, it turns out that
you're in luck: simply replace the GPRS access
number with any regular phone number of your choice and (on most
phones) you get a 9,600 baud data connection to that line.
Configuring efax
or mgetty-sendfax to
use Bluetooth to fax from a GSM phone in this manner is therefore
left as an exercise for the reader.

Schuyler Erle


/ 158