|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
When the weather is nice, I occasionally take a stroll through the corporate park across the street. Apparently, this is what it looks like in Google Earth:
Hardware that made this possible:
Software:
Aside from carrying two gadgets (and keys) while walking, it's a no-hassle setup. The BT-Q818 is roughly a third the size of my phone, and is supposed to last for > 24 hours.
Woo, FCC! (And I don't woo them often)
WASHINGTON (AP) -- A government agency [FCC] on Tuesday said it will keep a rule in place that requires cell phones to be turned off during airline flights.
http://edition.cnn.com/2007/TRAVEL/04/03/cell.phones.airplanes.ap/index.html
Here's one for you:
You're really getting good at this!
Over the past few months, I've been getting increasingly fed up with Verizon's phone crippling, and spotty coverage in my area (Ballantyne, south Charlotte, NC). I decided to pick up a Nokia E61 and service with Cingular.
The E61 itself is a nifty little package, sporting the full set of Bluetooth features, a miniSD slot, a SIP client, and 802.11g.
Since I got unlimited MEdia Net access [read: Internet access] through Cingular, I figured it would be worthwhile to use the DUN capabilities of the E61, via Bluetooth's rfcomm interface, or USB's CDC ACM (if needed). The following instructions may be specific to Gentoo GNU/Linux:
First, I determined (erm, Matt reminded me of this) the correct DUN channel with sdptool:
destiny% sdptool browse 00:17:e3:3d:29:fc
[...]
Service Name: Dial-Up Networking
Service RecHandle: 0x100a2
Service Class ID List:
"Dialup Networking" (0x1103)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 2
It is apparently on channel 2. I then added a "channel 2" line and the Bluetooth address into /etc/bluetooth/rfcomm.conf, and enabled binding on startup.
Next step was to configure PPP. Gentoo's net scripts have some PPP-specific options, so I added the following to /etc/conf.d/net:
config_ppp0=( "ppp" )
link_ppp0="/dev/rfcomm0"
username_ppp0='WAP@CINGULARGPRS.COM'
password_ppp0='CINGULAR1'
pppd_ppp0=(
"usepeerdns"
"defaultroute"
"refuse-chap"
)
phone_number_ppp0=( "*99***1#" )
chat_ppp0=(
'ABORT' 'BUSY'
'ABORT' 'ERROR'
'ABORT' 'NO ANSWER'
'ABORT' 'NO CARRIER'
'ABORT' 'NO DIALTONE'
'ABORT' 'Invalid Login'
'ABORT' 'Login incorrect'
'TIMEOUT' '5'
'' 'ATZ'
'OK' 'AT+CGDCONT=1,"IP","WAP.CINGULAR"'
'OK' 'ATDT\T'
'TIMEOUT' '60'
'CONNECT' ''
'TIMEOUT' '5'
'~--' ''
)
After running /etc/init.d/net.ppp0 start, a ppp0 interface appeared with an RFC1918 address - all done! Yes, Cingular appears to NAT all connections via GPRS out regional PoPs. Latency isn't too bad (roughly 250 ms), and downstream bandwidth seems to max out around 160 to 192 Kbit/sec. Good enough for most things…
Although using the USB cable is easier and arguably less latent - it's crashy.
I replaced /dev/rfcomm0 with /dev/ttyACM0 in /etc/conf.d/net, and connected the E61 in "PC Suite" mode. Linux produced the following:
eclipse kernel: cdc_acm 3-2:1.10: ttyACM0: USB ACM device
eclipse kernel: usbcore: registered new driver cdc_acm
eclipse kernel: drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters
eclipse kernel: usbcore: registered new driver cdc_ether
eclipse kernel: rndis_host 3-2:1.12: RNDIS init failed, -32
eclipse kernel: usb%%d: unregister 'rndis_host' usb-0000:00:1d.1-2, RNDIS device
eclipse kernel: unregister_netdevice: device usb%%d/f7f45c00 never was registered
eclipse kernel: rndis_host: probe of 3-2:1.12 failed with error -32
eclipse kernel: usbcore: registered new driver rndis_host
The whole rndis_host error had me worried for a second, but I chose to ignore it. Firing up net.ppp0 produced a ppp0 interface, and everything looked good. Upon stopping the connection, though, Linux became unhappy:
eclipse kernel: BUG: unable to handle kernel paging request at virtual address 203f2057
eclipse kernel: printing eip:
eclipse kernel: c015383d
eclipse kernel: *pde = 00000000
eclipse kernel: Oops: 0000 [#1]
[...]
eclipse kernel: EIP: [sys_write+29/112] sys_write+0x1d/0x70 SS:ESP 0068:e2d89fa0
eclipse kernel: EIP: [<c015383d>] sys_write+0x1d/0x70 SS:ESP 0068:e2d89fa0
eclipse kernel: <1>BUG: unable to handle kernel paging request at virtual address 32333634
I'm currently running 2.6.18-gentoo-r3, so changes are it's fixed in a more recent kernel version (or patch).
Anyway, that's it… not too difficult. My next task is the SIP client.
Apparently late in 2006, larscapes.com became cityscapewallpapers.com. I suppose it's appropriate, since the majority of the photos are of… cityscapes. This recent photo reminds me of The Pegasus, for some reason.
I jumped out of a plane, today:
More media:
The video was terribly interlaced. IVTC helped with it a little bit, but not by much.
I'm an idiot, and have been misreading the "First went to school together" part of the friend details page on Facebook for quite awhile, apparently. Apologizes to all the old friends and acquaintances who I've known since elementary school… I think I put high school for some of you.
In other news, weather is getting warm again, finally. Woo.
Although I've seen it before, now it's finally starting to annoy me.
Intel's e1000 Linux driver updates the interface counters every two seconds, making for very choppy real-time graphs of link usage:
I initially found a post about this, including an easy fix, or so I thought. More discussions revealed that under certain circumstances, the supposed fix will cause watchdog timeouts when linked up at half-duplex (which isn't a problem for most of us, but…). Bug ID 1192 at that URL no longer exists. Here's the explanation from Intel:
e100 and e1000 both query h/w for stats on a timer (2 seconds) and cache the results. A call into the driver's get_stats function just returns these cached values. With e100, there is a problem in that issuing the command to dump stats doesn't return right away, so rather than blocking in the driver by waiting for the command to complete, the driver just reads the results of the dump command 2 seconds prior, and then reissues a new dump command. So e100 stats are delayed by ~2 seconds.
3c59x (and others) query the h/w for stats in the driver's get_stats function directly. This gives up-to-date stats. We could do this with e1000, but it'll take a little bit of surgery because there is some other code in the driver that is dependent on stats collected over 2 second period. Nothing that can't be fixed.
Keep in mind that the post is 3 years old. I suppose I can deal with choppy graphs, since blocking in the driver sounds like a bad thing. Oh well.
Displaying page 56 of 121 of 965 results
     |
This HTML for this page was generated in 0.006 seconds. |
