Press "Enter" to skip to content

Category: computers

Oil Slick and Other Images

I do not like seeing oil slicks like this in a parking lot. This is from the snow plow / salt spreading people.

Here, have some moblog images:

· I do not like seeing oil slicks like this in a parking lot. This is from the snow plow / salt spreading people.
· Car with YOU SUCK @ PARKING written in paint marker on the side window.
· Engrish on a model helicopter box at Microcenter. (Click to read more.)
· Deatheater standing near the console at IPM.
· It’s December 1st, time to start on the advent calendar my mom gave me.
· DBAN having just finished running on my old D610.
· Bye bye, D610. Time for me to begin using another laptop at work.
· The bathroom at work has a shiny new air freshener installed.

Leave a Comment

ObeXplorer Feeds My Moblog

ObeXplorer running on my work machine under Vista browsing Push Upstairs, my Nokia E51.

I’m now running Vista on my work laptop, and while I had no problem finding Bluetooth drivers for it, I didn’t like the default Bluetooth OBEX program which only allowed one file at a time to be exchanged. Looking around online I came across ObeXplorer, a free OBEX tool written by Giorgi Dalakishvili. It provides exactly the basic browsing and copying functionality that I wanted, and now whenever I’m using a PC I use this to pull files off of my phone for upload to my moblog. On OS X I still use Bluetooth File Exchange.

If you’d like a copy of it, please visit Giorgi’s post about it, or download it from my mirror here: 2008_10_ObeXplorer.zip

3 Comments

Sanyo “The Claw” CD/DVD Media Destroyer

Sanyo The Claw CD/DVD Media Destroyer, model number CL-7, purchased from Woot for $4.99 (+$5 shipping). The piles of discs shown were destroyed one after another.

Not long ago John pointed me to a sale at Woot for a device which destroys CDs or DVDs. Having a huge stack of discs to dispose of and costing only $4.99 (+$5 shipping) I decided to order one. Today my Sanyo “The Claw” CD/DVD Media Destroyer arrived.

Yes, that’s exactly what it says on the box, not far from the part which shows that it is Compact Disc and DVD compatible. Too bad it doesn’t do Blu-ray.

After eating some dinner I set to work processing discs, and with a ~2 second cycle time per disc I was able to get through 163 discs (one after another) before The Claw stopped working, with a FreeBSD 3.2 CD stuck in the drive. Thankfully it was just a thermal shutdown, and after allowing it to rest in the garage for half an hour I was able to continue processing the discs, chewing through the remaining 70 or so in no time flat.

The Claw works by pinching the media between two spiked rollers, which put a bunch of small indentations all over both sides of the disc while at the same time somewhat deforming the plastic so that the disc isn’t really flat nor round. A test audio CD made a bunch of horrible noises when placed in a top load radio, so I can only imagine what putting one of these discs in a normal reader would do.

Here is a detailed image of what The Claw did to a NT 5.0 beta CD and here’s similar damage to a CD-R, including delamination of the foil. Here is a 600dpi scan of a processed CD-R showing the typical damage pattern.

Now that I’m done processing that giant stack of discs I’m not sure what to do with it. I could relabel it as a DVD cleaner and drop it off a the Salvation Army, but that’d just be mean.

5 Comments

Founders’ Backwoods Bastard

Founder's Backwoods Bastard poured into a glass. It tastes strongly of oak and bourbon.

Tonight I’m sipping a snifter of Founders‘ Backwoods Bastard while trying to figure out a Time Machine problem I’m having. Thankfully, the need to let the beer warm up to a bit below room temperature for drinking tied in well with time spent working on the backup.

This beer is interesting, and tastes quite a bit like their Curmudgeon, but with lots of oak. It’s nifty and worth drinking, if you like potent, strongly flavored beers.

Leave a Comment

NXE Xbox LIVE with pf and miniupnpd on OpenBSD 4.2

New Xbox Experience (NXE) showing a successful Xbox Live test via NAT and UPnP on OpenBSD 4.3 with pf and miniupnpd.

(UPDATE: This issue has been worked around / resolved. Please see Xbox Live Open NAT Using pf on OpenBSD.)

I rather enjoy turn-based artillery games like Worms, Scorched Earth (and Scorch 2000 and Scorched 3D), and GORILLA.BAS, so when I found out that Worms for Xbox Live Arcade was available, I purchased it.

A few months ago, before Microsoft released NXE, or the New Xbox Experience, I had no problems playing Worms online when using my Trashwall set up with the Microsoft proscribed forwards of 88/udp, 3074/udp, and 3074/tcp. However, after NXE was released it seemed to stop working. The Xbox LIVE test would consistently tell me that I have “Strict” NAT settings and that some things won’t work. I was unable to host private or public games. Xbox LIVE supposedly works best with either a direct internet connection or a firewall which implements UPnP, so I set to implementing UPnP on my pf-based firewall.

In order to do so I compiled and set up miniupnpd per the directions, but I ran into a whole bunch of weirdness along the way. I eventually got it working, getting an occasional successful Xbox LIVE test (as seen above) which indicates “Open” NAT, and I was able to play a private game against , but things don’t seem right.

Below the cut I’ll document what I’m been seeing.

Leave a Comment

Light Snow, Bike Riding, Feeling Sick

Bob riding across the S shaped bridge in The Pines at Stony Creek on a November evening.

Here’s a photo of Bob / utabintarbo riding across the S-shaped bridge which is part of The Pines at Stony Creek. He and I met up with the intention of getting some extra riding in before the normal Wednesday at 6:30 PM group ride, but after our first lap (and a naughty daylight backwards run through The Pines) I was so out of it that I had to stop and go home early. I think I’m getting the cold that Danielle had while we were in the UK, as I feel extremely tired, I’m coughing, can’t properly get my breath, and just feeling blah. I hope this doesn’t turn into pneumonia.

Riding was interesting as the leaf and snow covered trails were reasonably slippery, previously muddy areas were rock-hard narrow ruts, wet areas were now slick ice, and previously loose sand was hard as concrete fun. I had a very hard time making it through some normally easy areas, and I’m blaming this on being slightly overdressed for the cold weather and unable to breathe properly. Ah well, hopefully I’ll be better next week.

A couple of trips to Home Depot and Lowes has resulted in my purchase of some spray paint designed for frosting windows, a replacement light bulb for the ceiling fan in my bedroom, and new LED-based nightlights for the bathrooms. Tomorrow I’m hoping to remove the blinds in the bathroom and frost the windows. Hopefully that will go as well, which is how replacing the bulb in the ceiling fan went, making the room light up properly again.

On a very positive note, I had no problems uploading the image above, and I didn’t anticipate any after incorporating the fix mentioned in the bottom of this post about php-cgi hung as sbwait. It turns out that a default setting in lighttpd breaks particularly badly on FreeBSD 7.0-RELEASE, but not previous versions. Changing it to a different setting suggested by one of the lighttpd developers has worked around the issue. This is good.

Leave a Comment

php-cgi hung as sbwait with lighttpd on FreeBSD

Gallery Remote hung at "Upload completed: server processing...", which is the most obvious symptom of the lighttpd / php-cgi problems I've been having.

When uploading a quantity of photos to my gallery I like to use a tool like Gallery Remote to make it go easier. However, since moving to banstyle (and a newer version of FreeBSD and lighttpd and PHP) I’ve had Gallery Remote regularly hang at that “Upload completed: server processing…” message. It seems to happen after a few (typically two to five) images have been uploaded.

This problem has been bothering me for a while, but I was able to work around it by scping the files to the server then adding them locally, which doesn’t have this problem. Now that I have a bunch of photos from the UK trip to upload, I want to be able to use Gallery Remote again. This morning I set to getting working, but I seem to have failed.

In short, what happens is that after an upload hangs I see one of the php-cgi processes stuck in a status of sbwait, as can be seen in this screenshot:

81073 c0nsumer        1   4    0   116M 20988K sbwait 3   0:01  0.00% php-cgi

Digging around I found this thread where someone else indicates that they are having the same problem, and only on SMP boxes. (Note: banstyle.nuxx.net is four-way SMP using SCHED_ULE.) I also came across this report to the lighttpd folks regarding this issue. The consensus seems to be that when using a config such as mine, with PHP as a FastCGI and lighttpd, this occasionally happens. I’ve seen no reports of the issue occurring under Apache.

Since I’m able to reproduce the problem I did so, attached gdb to the seemingly hung php-cgi process, and grabbed a backtrace:

(gdb) bt
#0  0x00000008010a476a in read () from /lib/libc.so.7
#1  0x000000000057d5fc in fcgi_read ()
#2  0x000000000057e306 in sapi_cgi_read_post ()
#3  0x00000000004c84a4 in fill_buffer ()
#4  0x00000000004c88b5 in multipart_buffer_read ()
#5  0x00000000004c9c08 in rfc1867_post_handler ()
#6  0x00000000004c6ee5 in sapi_handle_post ()
#7  0x00000000004cc30c in php_default_treat_data ()
#8  0x00000000004cc7eb in php_hash_environment ()
#9  0x00000000004bff47 in php_request_startup ()
#10 0x000000000057f8c6 in main ()

(gdb) f 0
#0  0x00000008010a476a in read () from /lib/libc.so.7
(gdb) info frame
Stack level 0, frame at 0x7fffffff9c50:
 rip = 0x8010a476a in read; saved rip 0x57d5fc
 called by frame at 0x7fffffff9db0
 Arglist at 0x7fffffff9c40, args: 
 Locals at 0x7fffffff9c40, Previous frame's sp is 0x7fffffff9c50
 Saved registers:
  rip at 0x7fffffff9c48

Based on the input from some folks online, it’s looking like that is php-cgi doing what it’s supposed to and just waiting for more data, which means that the problem is likely somewhere in lighttpd. I’m not really sure where to go from here, besides wait for the lighttpd folks to (hopefully) fix the problem. With any luck I’ll be able to update this post later on with a solution. For now I’m going to contemplate the difficulty of going (back, in many ways) to Apache.

For reference, I’m running lighttpd 1.4.20 and PHP 5.2.6, both installed from ports, configured as described in my article about running lighttpd with PHP as FastCGI with each user having their own PHP processes.

UPDATE: So, it seems that there is a fix for this which was suggested in the aforementioned bug report. Setting the option server.network-backend = "writev" along with the already set (in my case) server.event-handler = "freebsd-kqueue" in lighttpd fixes it. I’m not sure if both options are needed to resolve the issue, but it seems that the default setting for server.network-backend of write is confirmed as broken under FreeBSD 7.0-RELEASE with lighttpd <= 1.4.20.

1 Comment

Tapping VoIP (aka Decoding ITU-T G.711 µ-law)

Screenshot of Wireshark decoding a RTP stream using ITU-T G .711 µ-law compression.

While setting up my Nokia E51 w/ VOIP I was informed that the communication between the handset and the server uses the ITU-T G.711 µ-law codec for the audio without any additional encryption, meaning that it is relatively easy to capture and listen in on. I’d never done a VOIP capture and decode, so I set set up a capture on the firewall (tcpdump -i gem0 -s 2000 -w file.cap host x.x.x.x) and grabbed a test phone call made to Danielle as she sat in the living room with some friends.

After opening the capture in Wireshark I used the basic built-in VOIP analysis tool to get the windows shown above. The main window is the capture and decode itself, another shows the one detected VoIP call and its details, and the third is a basic playback window replying the voice of the phone call. (Click on the image above or here for a full resolution copy of the screenshot.)

Using the RTP stream analysis stuff one is able to save out the audio as an .au file. I was running into some problems with this as one half of the conversation was padded by a few minutes of silence during export (a Wireshark bug, it seems), but the audio is still very much available. Both halves of the conversation were then brought it into Audacity, aligned, the level of the inbound (remote, Danielle) side was brought up a bit, and the audio was exported it as an MP3: voip_capture_sample.mp3.

This capture and decoding was easy for me to do because of the ready access to my own network and lack of encryption of the session. Getting another person’s calls is generally a bit more complicated. That said, imagine how easy it must be for a large government agency with a tremendous budget, amazing computing resources, and access to the backbones of the country’s telecommunications infrastructure.

Leave a Comment

SIP via Asterisk on Nokia E51

My current cell phone is a Nokia E51, one of Nokia’s more recent Symbian Series 60 cell phones. Beyond being a decent phone with a decent camera it also happens to do 802.11 wireless and be a SIP endpoint.

In short, this means that my cell phone can also be a VoIP client. Today, thanks to , my phone is working for making actual calls out via the public internet, into a server, then into the phone system.

Since there were a few quirks with getting this going I wanted to document the settings used in the phone for connecting to the Asterisk-based server.

First, make sure your phone has a valid wireless network connection available, which is done via Tools → Settings → Connection → Access points. Without a configured, functional AP your phone won’t be able to connect to the internet.

Now, to configure the phone itself, the following settings must be made:

Tools → Settings → Connection → SIP settings
Profile name: NameGoesHere
Service profile: IETF
Default access point: (Pick your access point from before.)
Public user name: sip:c0nsumer@sip.host.com
Use compression: No
Registration: Always on
Use security: No

Tools → Settings → Connection → SIP settings → Proxy server
Proxy server address: sip.host.com
Realm: asterisk
User name: c0nsumer
Password: PasswordGoesHere
Allow loose routing: Yes
Transport type: UDP
Port: 5060

Tools → Settings → Connection → SIP settings → Registrar server
Proxy server address: sip.host.com
Realm: asterisk
User name: c0nsumer
Password: PasswordGoesHere
Transport type: UDP
Port: 5060

Tools → Settings → Connection → Internet tel.
Create a profile with a name of your choice, then associate the SIP profile created earlier with this. This will set up one profile which can then be used to make calls across the network via VoIP.

After this, set your new NameGoesHere profile as the default via Tools → Settings → Connection → SIP settings → Options → Default profile.

With these settings your phone will always connect to the AP whenever it is found and register with the VoIP server. It will then be able to make and receive calls. Setting Registration to When needed makes the phone prompt before connecting to the AP and the SIP server when an attempt to dial an internet call is made. Inbound calls will not work in this case.

Leave a Comment

restrict default ignore

In setting up NTP on nuxx.net I ran into a bit of a problem: time wouldn’t sync. My configuration was fairly simple, following the information on support.ntp.org for using the pool of North American servers, blocking external access, but allowing ntpq (et al) to work from localhost:

server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
server 3.north-america.pool.ntp.org

driftfile /var/db/ntp.drift

restrict default ignore
restrict 127.0.0.1

However, it seemed that no matter what I tried (disabling the firewall, adding exceptions for TCP/UDP 123, changing order of the restrict statements, etc) the box wasn’t able to contact its peers:

c0nsumer@banstyle:~> ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 217.160.254.116 .INIT.          16 u    -   64    0    0.000    0.000 4000.00
 209.132.176.4   .INIT.          16 u    -   64    0    0.000    0.000 4000.00
 209.40.97.141   .INIT.          16 u    -   64    0    0.000    0.000 4000.00
 216.14.98.234   .INIT.          16 u    -   64    0    0.000    0.000 4000.00

After some more digging I found that the restrict default ignore option, which is widely recommended to keep external folks from connecting to your ntpd, prevents synchronization from happening, even with the exception for localhost.

Having realized that, my ntp.conf is now just the basic config for the NA servers and the drift file, and it all works great:

server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
server 3.north-america.pool.ntp.org

driftfile /var/db/ntp.drift

Yep, it’s syncing just fine:

c0nsumer@banstyle:~> ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*217.160.254.116 18.26.4.105      2 u  200  256   17   37.192    4.619   1.461
 209.132.176.4   66.187.233.4     2 u  201  256   17  101.819   21.118   9.529
 209.40.97.141   192.5.41.40      2 u  197  256   17   38.565  -31.122  21.081
 216.14.98.234   216.218.254.202  2 u  200  256   17   18.731    3.940   4.848

c0nsumer@banstyle:~> ntptrace
localhost: stratum 3, offset 0.004619, root distance 0.043540
server.donkeyfly.com: stratum 2, offset -0.000686, root distance 0.006361
bonehed.lcs.mit.edu: stratum 1, offset 0.000018, root distance 0.000000, refid 'CDMA'

Now I just let pf restrict access to NTP. That works just fine.

Leave a Comment