Press "Enter" to skip to content

Category: computers

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

Coupons.com Sucks

Coupons.com requires you to install some special software for diabetic coupon printing, and it specifically does not work in VMs.

My grandma needed some coupons printed which are related to an arthritis drug called Zostrix (note the rel="nofollow") but was having some problems doing so. My mom also had such problems, so I decided to give it a go using my shiny new printer.

It turns out that the coupons for this drug are printed via Coupons.com, but when I went to use their service I was informed that it didn’t support my browser (FF3 on a Mac). Switching over to a VM running IE7 under XP I found that the site requires one to install some sort of silly coupon printing software in order to do the printing. Since I was using a VM I took a snapshot then attempted to install the software, at which point I received the above error.

The damned software refuses to install in a VM.

At this point I’m just not going to print the coupons… I don’t want to cruft up my normal or work machines (the only interactive non-VMs I have) with such crap, so there’s not much more I can do. Digging around a bit more on it, I found this writeup called A Closer Look at Coupons.com which details quite a number of questionable things done by this software.

13 Comments

Paved Night Ride

Everyone who was on the ride around Mt. Clemens except for me. Left to right is Perry, John, Marty, Nick, and Mike.

Here, have a photo of everyone who went for a ride tonight from Mt. Clemens High School to Metro Beach and back, except for me. It’s not a very good photo. This one of Marty and Nick is better, despite the huge amount of noise from the high ISO.

After getting home from the ride I stuck the extra RAM in the printer and my Mac, and everything seems to be working great. The printer (Xerox Phaser 6130N) got a 1GB Crucial SO-DIMM (CT12864AC53E) to bring it to 1.1GB and the Mac Pro got 4GB of RAM bringing it to 7GB. I now can run multiple VMs with ease and deal with multiple large image files without a bunch of paging.

It’s been a good day and a good evening.

Leave a Comment

Xerox Phaser 6130N

Xerox Phaser 6130, which was $249 via Costco.

A few weeks back I mentioned that I really needed a new printer, as my old HP LaserJet 5L had mostly ceased working. Well, last week Costco had a Xerox Phaser 6130N listed on their site for $249 shipped, with a Tripp Lite surge protector and USB cable.

I ended up jumping on this deal, because it has all the features I was looking for in a printer, except a duplexer, which really isn’t that important anyway. In short, this is a networked color laser which speaks real Adobe PostScript 3 (Wikipedia PostScript article), making it properly usable from any OS without silly Gutenprint (GIMP-Print) drivers and their crappy dithering.

The price was also outstanding, as Newegg sells this printer for $359.99 and most other places want even more than that. I also made a quick trip over to Crucial for a $16.99 piece of CT12864AC53E should bring the total RAM in the printer up to 1152MB. That ought to make printing complex documents fast.

Leave a Comment

rowla.nuxx.net, RIP

PuTTY screenshot of a disconnected session to rowla.nuxx.net after shutting it down for the last time.

That’s it. rowla.nuxx.net has been turned off, and I’m slated to pick it up tomorrow sometime around lunch. Everything has been moved over and seems to be working great. So, if I host your stuff on nuxx.net and you are having a problem, please let me know so that it may be corrected.

Leave a Comment

Time For A New Printer

Old parallel port printer cable connecting into the back of my work laptop, a Dell D610.

I guess I really need a new printer. After almost a year of limping along with a failing HP LaserJet 5L at home I’m finding I can’t even convince it to print any more. Today I was able to get it to print a test page while manually guiding the paper deep into the feed mechanism, but then I was unable to print properly from either my Mac or work laptop via lpr (to the JetDirect), or straight from my work laptop via parallel port.

Two pages bearing print did leave the printer eventually when connected via parallel port, but only half of the PDF which I needed to print (a free admission ticket to Addison Oaks for riding the mountain bike trails) was actually render correctly. Oh well. I guess it’s time to go to Kinkos.

Leave a Comment