Trivia

Things That Seemed Useful At The Time

This is my page for jotting notes. This isn't a weblog, I don't plan to expose my innermost secrets or sell you links to my webcam. Instead, this page contains stuff I learned or figured out, which I didn't want to forget, and which I thought might save someone else some time or effort. If you want philosophy, I suggest H. D. Thoreau instead of P. Komarek.

eStarling WiFi Gmail / Flickr Enabled LCD Frame

Update 2006-12-24, slightly after noon:

I sent a link to this page to eStarling and ThinkGeek. I was very pleasantly surprised to get a response from eStarling a short while later! The response said they would forward the corrupted EXIF image links I provided to their engineers, and that the problems I am experiencing are consistent with the power supply problem. ThinkGeek wrote (a few days later), explaining the power supply issue and saying they would soon ship new power adapters to everyone. I am really impressed with eStarling's response. I hope the new power supply will fix the lock-ups I saw.

Update 2006-12-24 at noon:

I guess I didn't solve the lock-up problem. The frame functioned correctly at least until I went to bed, which means maybe 3-5 hours. By noon today, it had locked up again, this time between photo transitions. Since eStarling has talked about power supply problems already, I can hope that this is an easily-remedied power supply glitch. Regardless, I don't have time to get this fixed in time to give it as a gift this year. My current assesment: disappointed.

2006-12-24

I just picked up an eStarling WiFi digitial picture frame, from ThinkGeek. I have had a few problems, but so far I've worked around the only show-stopper.

Problem 1: The frame can lock-up:

I've had repeated problems with the frame locking up after about an hour of cycling through a set of four photos from my Canon SD-300 camera. I've tried removing the WiFi adapter (see Other Observations, further below) after it boots, but that didn't help. I waited until after boot to remove the WiFi adapter, because the frame doesn't want to show pictures before it successfully negotiates a wifi connection (maybe there's just a really long timeout, and maybe disabling dhcp would shorten the wait). I also worried that heat might be the culprit, but I judged that unlikely in this case. I also tried reading images only from an SD card, and the frame still froze within about an hour.

So I dumped network packets, and found the urls from which the frame downloads images. The images it downloads are modified versions of the photos I uploaded through the eStarling web interface. For example, the size has been changed to fit the frame. However, it seems that they corrupted the EXIF data in some way. According to output from the gqview image viewer:

warning: exif tag ExifVersion format mismatch, found string exif spec requests undefined
warning: exif tag UserComment format mismatch, found string exif spec requests undefined
warning: exif tag FlashPixVersion format mismatch, found string exif spec requests undefined
warning: exif tag FileSource format mismatch, found ushort exif spec requests undefined
warning: exif tag SceneType format mismatch, found ushort exif spec requests undefined

So I deleted those files from my eStarling account, and created four new files with the EXIF data stripped out. The frame has been running for a few hours now, without freezing. I am hoping that eStarling fixes their image processing pipeline, so that I can give my father the frame's email address and let him upload without supervision. I'm sure there's a better way to strip EXIF data than I used, but I didn't have to do any research for this command line ("convert" is part of ImageMagick):

convert original_image.jpg bmp:- | convert bmp:- -quality 70 new_image.jpg

You can use ImageMagick's "identify" command to see the EXIF info in your original and stripped images:

identify -verbose new_image.jpg

I have uploaded one of the four images, so other folks can test for themselves. You can download the original, the modified version the frame downloads, and the stripped version of downloaded image.

Problem 2 -- Configuring WiFi requires Windows:

The picture frame's WiFi configuration is supposed to be adjusted through a little Windows program they provide, and that's how I did it. However, you can access the frames storage just like any usb storage device, under Windows or GNU/Linux. On the filesystem, there's a "system" folder, and in that folder are three files. If my memory serves correctly, one file is empty-ish, and the other two are text files with the WiFi configuration parameters. If you want to change the WiFi essid (basically the network name) parameter, I think you could just edit this file in any text editor. I really wish companies would mention this sort of thing somewhere in the documentation.

Problem 3 -- Gmail not working for me, yet:

I still haven't gotten it to pop mails with image attachments from Gmail. This doesn't bother me too much, since the web-based upload tool is easy to use. Since I have to preprocess my images anyway (for now) to remove EXIF data, the difference between email and form-based upload is inconsequential. Until eStarling addresses whatever issue causes the frame to freeze, I'm not going to tell my dad how to upload photos anyway.

Other observations:

There is pretty much no documentation.
The WiFi radio is provided via a Marvell-based USB Wifi adapter, wrapped in an eStarling-branded plastic sheath. When you plug it in, it sticks up above the frame and is not particularly attractive. At least the logo faces back. I tried using a USB extension cable, but that looked worse since it wasn't black, and a typical USB A-style plug still sticks out above the picture frame. If I could find a right-angle adapter for a USB A connection, that would solve the problem.
The WiFi radio range seems poor. However, a note on the eStarling page says this is due to power-related problems, and they're shipping a new power adapter to everyone. I guess they'll get my address from ThinkGeek?
Overall, I am somewhat satisfied and still plan to give this frame to my dad for a Christmas gift. I just won't let him upload photos, since debugging a locked frame over the phone would be very difficult.

Update 2006-12-24 at noon:

D-Link DI-824VUP print queues

2004-06-17

Although D-Link doesn't seem to know the names of the print queues on their wirless print servers, a packet capture program will tell you. The network communication uses the Berkeley lineprinter protocol (i.e. the standard lpd you find on UNIX-ish system). D-Link admits that the parallel-port queue is called "lp". What they don't seem to recall is that the usb queue is called "lpUSB0". I optained this information by configuring a Windows client with the provided software (a Windows-to-Berkeley-lpd translator), and eavesdropping on the exchange using a hub and a network analyzer. In fact, the network analyzer (in this case, "ethereal") made the name lpUSB0 appear with a dot in the middle and I missed it. However, running "strings" on the network dump made the queue name more obvious.

I wonder if the queues are independent? Can you use this to print to a parallel port and usb printer simultaneously?

When I called to ask about the usb print queue name, they told me to see if I could find the information using Google.

ip3networks wireless access device at the Omni William Penn hotel

2004-07-10

The Omni William Penn hotel in Pittsburgh, Pennsylvania uses a wireless access device (apparently) from ip3networks. This device redirects your web browser's first access to a remote port 80. The redirection in this case was to a click-through waiver. I typed something like http://komarix.org into my browser, and I was redirected to

http://redirect.ip3networks.com/defaultportal/index.cgi?url=10.61.32.1

I found this redirection using wget. The addresses 10.61.32.1 is on a reserved network, as per rfc 1918, so don't bother following that link. When I tried to resolve redirect.ip3networks.com using the nameserver specified in the earlier (unmentioned) dhcp negotiation, I received no response.

In fact, I did receive a response, but not from port 53 (domain). The response was from port 9092. It appears that Mac OS X (FreeBSD too?) and Windows XP clients are happy to believe unsolicited DNS responses from unprivileged ports, but my laptop (kernel 2.4.27-pre2, MDK 10) printed an error message and waited for a proper reply. As a result, I was unable to follow the redirection and therefore unable to use the wireless network.

I have written to the hotel and to ip3networks about the issue. They could fix their DNS response, or use a redirection that did not require DNS. Until that is fixed, an easy-ish solution is to identify the redirect, perhaps using wget for simplicity. Phone someone to resolve any names in the redirection. Then enter the redirection URL by hand into your browser. This worked for me.

I do not know whether the DNS-reply-from-9092 problem is due to the ip3networks device design, or a misconfiguration by the Omni William Penn hotel staff or contractors.

Update 2004-07-14:

I have been contacted by several people from the Omni hotel IT group, as well as by Core Communications. Core works with Omni on (at least) their wireless services. So far, everyone seems very interested in solving the problem, and nobody has blamed GNU/Linux. They've even promised to call me once the problem is solved.

Update 2005-03-19:

I have not heard back about the problem, and probably won't hear back. I would assume that the wacky DNS reply still exists in the ip3networks device.