Monday, November 27, 2006

cleaning track...

Amazing how grimy old track can be. Yuck. I used a dry scotch brite cloth to wipe off all the dust, oxidation and dirt from these old brass rails. First with the green side to scrape off the big stuff, then with the yellow side to wipe off any leftovers. low and behold, it worked on the first try.

I cleand four straight pieces of track and within minutes the old "Krokodil" was going up and down the track powered by a 9V block battery held right against the rails. HO track is just wide enough for the connectors of the battery to fit.

This worked so well, I cleaned a dozen curves and set up a little oval on the table. After a few rounds of sputtering the track was clean enough that the locomotive was running around in circles just fine. Exciting!

Sunday, November 26, 2006

Model railroading...

So, over the weekend I had a good conversation about model railroading (and railroading in general), which made my heart ache with the thought of the really nice Maerklin layout we have at my parents place back in Germany. I pulled out the only electric train stuff I have in the house here, the "FischerTechnik Bauspielbahn", a Fleischmann track based trainset my father bought for me and my brother a long, long, long time ago. I must have played with this the last time maybe 20 years ago. To my surprise the one motor left in the two locomotives is still working just fine, including the familiar whining sound it always had. No idea what happened to the other motor.

Just the rails ... oh boy. Brass track. No conductivity at all. Zip. I learn from a Google search that brass track is the worst. Lots of oxidation of the non-conducting kind. ok, looks like in order to make this work, I'll have to clean the track ... somehow.

Reading up on cleaning blocks, and various other methods serious railroaders recommend is ... pretty cool. Doesn't really apply to my situation, though. Heck, this is not even a real layout or anything. Either way, I'll give this cleaning idea a shot on a few pieces of track. Just for fun.

Friday, November 24, 2006

Audiotron and smb server on different subnet

What a pain.

The Audiotron appears to be unable to work with a WINS server. There is no way to specify one in the Web UI. I tried various approaches to get this work:


  • force global browse master on gw by running the Samba nmbd server with the appropriate smb.conf file (Audiotron finds the browse master on gw, but apparently ignores the information about hosts in other subnets)
  • limit and eventually turn off the firewall rules dropping packets between the wired and wireless portions of my network (I do have holes for smb traffic, but it doesn't matter. I can get to //chef/media just fine using smbclient via wireless)
  • redirect 137/138/139 tcp/udp from gw to chef (doesn't work because of heavy use of broadcasts in the smb protocol)
  • Allow remote hosts in the Audiotron WebUI (no visible effect)
  • Hardcode the specific share name \\chef\media in the Audiotron WebUI (no visible effect)
  • make heavy use of tcpdump on all systems involved (except the Audiotron which is a closed box)
  • search Google (and this blog is among the first 20 hits when I search for [audiotron browse master]...)
  • make sure all the passwords are right for the media user, both in the Audiotron and on chef (checked)
  • confirmed using nmblookup that I can't see chef, when browsing the wireless broadcast domain (duh, of course not. It's a separate /24.)
  • The Audiotron aborts browsing the subnet, if it can't find a running smbd on gw (how annoying)


In some cases chef shows up in the Audiotron log with "No IP reply". The Turtle Beach docs are fairly unhelpful on this whole thing.

Since WINS is not supported by the Audiotron and hardcoding paths on the Audiotron doesn't seem to have any effect, I'm thinking about bringing the songs closer to the Audiotron: Mount the media partition via NFS from Chef on gw, then export the NFS mount from gw via Samba to the wireless side.

How ugly.

I searched more and found a note in the Audiotron FAQ that the Audiotron does indeed support WINS, but the server information has to come from DHCP. The option for isc-dhcpd is netbios-name-servers in dhcp.conf. That might work. I'll try that when we are back from shopping. It's Black Friday after all.

...

Finally! It's working.

Serving netbios-name-servers via dhcp didn't seem to have any visible effect.
The magic config options that made it work were "dns proxy = yes" and "wins proxy = yes"in smb.conf on gw. Then I went into manual configuration mode on the Audiotron and set it explicitly to get the music from \\chef\media.
Samba on chef was not configured to use the WINS nmbd on gw, so nmbd didn't serve IP information for chef, even though it served the name as part of the list when queried.

So, in the end, as usual, it was operator error. I could have saved myself quite some pain by configuring chef as WINS client of gw, or run a WINS server on chef outright and serve chef's IP as WINS server to the Audiotron via dhcp. Actually, that's not a bad idea, I'd rather not have smbd/nmbd running on gw...
Not tonight, though, now that Patricia is happily listening to music served by this crazy infrastructure.

So, here's what I'm going to try next:
- run WINS server on chef
- serve chef as netbios-name-server in dhcpd.conf for the audiotron
- turn off nmbd and smbd on gw
- Verify I can still listen to music...

Update:
The Audiotron appears to ignore the dhcp option netbios-name-servers. With only nmbd running on gw, being the WINS server, and the Audiotron manually set to go to \\chef\media, it finds my songs just fine. Good enough for me.

A curious note:
When the Audiotron tries to resolve a remote name it queries first for "A? CHEF.", it gets a NXDomain in my network. Then it uses the fully qualified domain name "A? chef.domain.comm". Not a typo, it actually appears to append an 'm' to the query. I couldn't find the source of the extra 'm'. Even reset the Audiotron to factory defaults and started over, still queries an extra 'm'.

Tuesday, November 21, 2006

There ... now it happened

It's my own fault. I connected the serial console of my Net-4801 to chef, started minicom and ... nothing happened. A fatal "Send Break" later, minicom is no longer responding and the userland on chef is dead. No idea _why_ that happened, but it coincided with the break on the serial port. Thankfully, chef's kernel dutifully continued to route traffic, so I could search Google, and openbsd.org, but to no avail. In the end I power-cycled chef and am now waiting for the raid check to complete. *sigh*

On the positive side, my Internet connection is now running through the NET-4801. mail and web will continue to be handled by chef for the time being (once it comes back up), but basic Internet access as well as my private domain server and key-protected ssh are working already. My prep-work from early October paid off. Another 1.5 hours to go until chef is back online. I'm going to bed, but set the alarm early, so I can fix email before Patricia gets up.

Things left to do for chef:
- ifconfig to .10
- connect LAN cable
- reconfigure syslog to use -u and accept syslog from gw
- test mail connectivity (local and remote)
- test web connectivity (local and remote, both sites)

Update:
I also had to add the rdr entries for PF to redirect web/mail connections to chef. Then, my website didn't work anymore from the inside, because the redirect is applied only on traffic that enters gw on the outside interface, so I changed the internal DNS views to resolve my websites straight to chef, instead of going through gw.
Testing the configuration from my workstation at work, it worked right away for web access, but for the heck of it I couldn't get a SMTP connnection going. Everything looked right on my end. Actually, I used the same config options for web as for mail. While thinking about this, I noticed a mail coming in. Huh? ... I remembered we block outbound SMTP from workstations at work. Alright, all good.

Sunday, November 19, 2006

pvr500 and composite input

I'd really like to access DVDs through the MythTV interface, as well as be able to hook up my camcorder and convert analog video to MPEG2 streams. My TV has only one composite input and that's taken by MythTV, so the DVD thing is mostly for convenience. The catch? It doesn't seem to work.

I got the closest today. After scouring Google and reading lots and lots of different How-tos the most promising approach for getting the DVD player/camcorder hooked up was to define a new video source, bind it to the composite input, manually define a channel and off we go. Uhm, yeah. Not quite. The new channel (1001 - DVD) shows up in the channel selection. However, when I do select it, apparently MythTV tries to use the tuner to select it, which doesn't work. Either, the channel doesn't switch, and I continue to see Fox and then roll over to channel 82, or depending on which approach I tried, the channel switches and I won't get out of this mode anymore, and only got a black screen. Even [ESC] didn't work anymore. Couldn't tell whether the front-end or the back-end hung.

What's more frustrating is that even with ivtvctl -p, I can't seem to switch inputs on the PVR500. It does work, however, if I don't start mythbackend at all on boot. I'm suspecting an issue between MythTV, the ivtv driver, and the PVR500 card.


I'm using Linux 2.6.15 with ivtv 0.4.4. Looks like I'm going to sync grumpy to the latest Debian testing, 2.6.18 and ivtv 0.7 (or so). And then rebuild the nvidia driver, and take care of other mayhem that might ensue. I'm hoping this will also fix the problems we have with closed captioning (VBI).

Sunday, November 05, 2006

kde kamera DOES support disconnecting and reconnecting the camera

... it's just not obvious.

I use KDE's kio_kamera to download my photos from our Canon Rebel Digital SLR. Whenever I connect the camera a new USB address gets allocated and we end up with a URL like this:

camera://Canon EOS 300D (normal mode)@[usb:001,006]/

The camera icon on the desktop eventually takes me to camera:/, which is an overview page of configured devices. When I plug in the camera, this page always comes up with links to the usb address when the camera was first plugged in that day (usually usb:001,004), so I can't just click through. Annoying. More annoying is that many pages under camera:/ are cached, so it appears to be working until I get to the actual images folders and then get "port not found".

Solution:
In the camera:/ location, refresh the page, then continue. Simple as that. Now, if I could get kio_kamera to do this for me...