本文共 9116 字，大约阅读时间需要 30 分钟。
From:
Dramatis apparatus:
Note from later: I am still using this basic technique, with an Asus S6F laptop running Fedora Core 6 on a stock 2.6.18-1.2849.fc6 kernel, plus a Nokia 6230i 'phone. Most of this document still applies, but you can read FC6-specific notes . I also no longer need to build the rfcomm module into the kernel, as it ships with the stock RH kernel.
Note from much later (20081128): I am now using an GSM phone. i still have connectivity working, but the mechanics are somewhat different as the 'moko is physically connected to my laptop via usb instead of wirelessly via bluetooth, and it is running linux in its own right, so is used as a router and NAT device as well as a serial wireless internet connectivity device. If this interests you, please see the relevant writeup .
This joyous expedition comes in stages:
, I downloaded and installed the following packages:
bluez-libs-2.3-1 bluez-utils-2.2-1 bluez-sdp-1.0rc2-1 bluez-bluefw-0.9-1 The last being firmware loading code specific to the 3Com card (and others using the bt3c_cs driver). I added to /etc/modules.conf# bluetooth stuffalias net-pf-31 bluezalias bt-proto-0 l2capalias bt-proto-2 scoalias bt-proto-3 rfcomm
This is from the .
With this all in place, I start bluetooth services
# /etc/rc.d/init.d/bluetooth start
and insert the 3Com card. Syslog notes:
cardmgr[602]: socket 0: 3Com Bluetooth PC Cardcardmgr[602]: executing: 'modprobe bt3c_cs'bluefw[3859]: Loading firmware to pccard device 0101:0040hcid[3784]: HCI dev 0 registeredcardmgr[602]: executing: './bluetooth start hci0'/sbin/hotplug: no runnable /etc/hotplug/bluetooth.agent is installedhcid[3784]: HCI dev 0 up
I verify card operation with
# hciconfighci0: Type: PCCARD BD Address: 00:04:76:C8:D3:E3 ACL MTU: 128:8 SCO MTU: 64:8 UP RUNNING PSCAN ISCAN RX bytes:112 acl:0 sco:0 events:12 errors:0 TX bytes:308 acl:0 sco:0 commands:12 errors:0
(this shows DOWN if the hcid daemon isn't running; it can be manually brought up with "hciconfig hci0 up".
I activate bluetooth on my 'phone (which has been configured to have the name "Tom's phone" under Bluetooth->Bluetooth settings->My phone's name), and can find it with
# hcitool scanScanning ... 00:02:EE:60:97:6E Tom's phone
Other options to verify functionality thus far include asking if there are any dialup networking devices out there (there had bloody better be, it's a 'phone). Incidentally, i hate "dialup networking". What's wrong with "modem"?
# sdptool search DUNInquiring ...Searching for DUN on 00:02:EE:60:97:6E ...Service Name: Dial-up networkingService RecHandle: 0x10031Service Class ID List: "Dialup Networking" (0x1103) "Generic Networking" (0x1201)Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 1Language Base Attr List: code_ISO639: 0x656e encoding: 0x6a base_offset: 0x100Profile Descriptor List: "Dialup Networking" (0x1103) Version: 0x0100
I can even bluetooth-ping the 'phone to verify connectivity
# l2ping 00:02:EE:60:97:6EPing: 00:02:EE:60:97:6E from 00:04:76:C8:D3:E3 (data size 20) ...0 bytes from 00:02:EE:60:97:6E id 200 time 39.76ms0 bytes from 00:02:EE:60:97:6E id 201 time 35.67ms0 bytes from 00:02:EE:60:97:6E id 202 time 32.21ms3 sent, 3 received, 0% loss
Here, I gave a ^C after 3 packets.
, which outlined how 2.4.20 (stock) kernel doesn't contain the rfcomm code. Downloaded thence the latest Marcel Holtmann rfcomm patch, being 2.4.20-mh4. Applied to kernel source
# cd /usr/src# patch -p0 < /tmp/patch-2.4.20-mh4
went to kernel source dir, menuconfig'ged, and lo, the RFCOMM options appeared. Turned on RFCOMM and BNEP, and all associated checkboxes, did
# make dep# make bzImage && make modules && make modules_install
Booted from new kernel (2.4.20-mh4), did
# rfcomm bind 0 00:02:EE:60:97:6E 1
got nothing at prompt, but syslog shows
kernel: BlueZ RFCOMM ver 0.4kernel: Copyright (C) 2002 Maxim Krasnyansky kernel: Copyright (C) 2002 Marcel Holtmann
as the driver is force-loaded, and i can also do
# rfcomm showrfcomm0: 00:02:EE:60:97:6E channel 1 clean
But I could find no device to attach minicom to, for testing. Digging revealed that the device special files are major number 216, so after I did
mknod /dev/rfcomm0 c 216 0
I was able to use minicom to initiate a connection to the phone on device /dev/rfcomm0, at 9600 baud, with software flow control. My 'phone immediately asked me if I wanted to pair with my laptop (I said yes), and then asked me for a PIN before immediately giving me a disconnect message.
Examining the /etc/bluetooth/hcid.conf file revealed a line of code defining a "pin helper", which when i ran it gave a GTK error. Assuming this might be breaking things, I replaced it with a small script /etc/bluetooth/bluepin (and declared that in hcid.conf, restarting hcid), which said simply
#!/bin/bashecho "PIN:00"
Yes, this is a pathetic PIN, but I found i only had a second or so to type it in before the 'phone dropped the connection on me. kindly suggests an elegant alternative:
> In the page, you mention your "00" pin that you took because you> had just a second to enter a pin. I have a solution: do not use> minicom for the first connect but a simple>> cat < /dev/ttyUB0> > or whatever the device is in your case. This ensures that a connect> takes place without sending any characters before the pin is > confirmed. With that, I had any time to enter a longer pin on> my 6310i. Then, in the phone, go to the trusted devices and disable> the pin enforcement, and you can connect easily from then on.
I have not tried this (yet), and at the time it did not occur to me, so I settled for a lame PIN. Once I got it typed in, the 'phone seemed happy to accept the connection and establish the pairing (syslog reported
Jan 5 19:51:30 tirith hcid[20134]: Saving link key 00:04:76:C8:D3:E3 00:02:EE:60:97:6E
which looks good). Minicom was now able to talk to the onboard modem and get simple AT-OK responses. I told it ATDT01223999999 (substituting my home telephone number for 01223 999999), and my home 'phone rang. So, I'm definitely able to talk to the 'phone.
, which went like:
atOKate1OKat+cgdcont=1,"IP","orange.co.uk","",0,0OKatd*99***1#NO CARRIER
The 'phone dutifully displayed a "no GPRS service available" message, so I suspect that I am correctly telling it to use GPRS, and it is correctly telling me that I haven't registered for GPRS service. Now, I have to talk to Orange to get them to turn on GPRS service for me.
Having spoken to my provider (Orange UK), and spoken to someone who was clueful enough to know what I was after when I asked for AT modem commands, and with the help of the page mentioned immediately above, I got it working.
Here's my pppd peers file (/etc/ppp/gprs ):
/dev/rfcomm0 57600 connect '/usr/sbin/chat -v -f /etc/ppp/chat-gprs'noauthdefaultroutedebug
and here's my chat script (/etc/ppp/chat-gprs ):
TIMEOUT 5ECHO ONABORT '/nBUSY/r'ABORT '/nERROR/r'ABORT '/nNO ANSWER/r'ABORT '/nNO CARRIER/r'ABORT '/nNO DIALTONE/r'ABORT '/nRINGING/r/n/r/nRINGING/r''' /rATTIMEOUT 12OK ATE1OK 'AT+cgdcont=1,"IP","orangeinternet"'OK ATD*99***1#
Note the lack of authentication. It seems that the 'phone itself is authenticated by the network, which is (I suppose) the point! To make a connection, I use rfcomm release 0; rfcomm bind 0 00:02:EE:60:97:6E 1 then type pppd call gprs . The 'phone immediately wants to confirm a Bluetooth connection from my laptop, which I permit.
Update, 2004 09 06: me@theboywho.me.uk reports good results with the following script, which I report verbatim: OK 'AT&F' OK 'ATV1E0S0=0&D2&C1' OK AT+CMEE=1 OK 'AT+cgdcont=10,"IP","orangeinternet"' OK-AT-OK ATD*99***10# CONNECT ""
After a short delay, pppd logs the following to syslog:
pppd[22167]: Serial connection established.pppd[22167]: Using interface ppp0pppd[22167]: Connect: ppp0 <--> /dev/rfcomm0[...]pppd[22167]: local IP address 172.23.201.2pppd[22167]: remote IP address 10.6.6.6
a small G appears at the top left-hand corner of the 'phone display, which I understand shows that a GPRS conection has been made, and I can route to the outside world. My provider seems to be filtering pings, but I can (for example) make a TCP connection to port 22 on an ssh server I use, and I can use DNS to resolve off my favourite server outside, so I conclude that it works.
For anyone who's curious about numbers, I am on orange's cheapest plan, which is GBP4 (about 6 Euros) a month for 0.5MB. orange say (7.1.2003) that traffic over the plan limit is charged by the kB, pro rata the main plan rate. We'll see how much traffic I use: my main usage is ssh, which isn't all that big; 0.5MB would vanish in a heartbeat with web browsing, though.
And that's it. Unless anything stops working, that's the end of this technote.
转载地址：http://ahbqb.baihongyu.com/