"Oops!" is fixable"Oh shit!" is not

Mmm, tomatoes...

2011-11-30T02:11:00.000-08:00

So I installed TomatoUSB on my Asus RT-N16. The router has 2 USB ports (can be extended with a hub) and firmware has support for block devices & printers. IPv6 support, 1Gbps ethernet, jumbo frames, per-IP QoS... even has a torrent app built in so you can download while your computers are offline.
Anyway, first few hurdles:

Found a way to route to DSL modem, same exact script as DD-WRT (how convenient!)
Found a way to add a non-root user, altered it to allow public key only and saved to nvram! (didn't know how to do it in dd-wrt, had to manually run the user setup script after each reboot). The only issue was permissions, which is easily fixed/hacked with init script

Found a way to enable multiple printers (more on that in a moment)

Found a way to send firmware to a printer that needs it (TODO as soon as I get a new USB2.0 hub)

Found a way to set up sane to share a scanner! This is what pushed me to choose Tomato over DD-WRT on this router, actually. I'm sure there's a way to do the same thing there, but convenient google result is more convenient :)

For running multiple printers, I have an Epson CX8400 printer/scanner and HP LJ 1018. But there's a minor problem: whichever printer is turned on first, becomes lp0 and is then automagically shared on port 9100. But what if someone turns on both? I don't want to make anyone remember that they first have to turn one, and only then another!Well, turns out there's a hacky way. First, some background

the way to share a printer on the next port (9101) is simply run "p910nd -b -f /dev/usb/lp1 1", where "-f /dev/usb/lp1" points it to the lp# device symlink, "1" means I want to use port 9101 (default is 9100 and the only remaining one is 9102), and in this case p910nd executable will rename itself to p9101d
Loading Printer's Firmware in Hotplug Script page tells me there's an easy way to trap add/remove action on these guys, even tells me how to find the product ID. But after printing all vars, it's apparent there's no mention of the /dev/*lp# device.

Oops!As luck would have it, though, one of those vars, DEVPATH, corresponds to the same file in /sys -- and the correct subdevice has a symlink to lp0 or lp1!

DEVPATH='/devices/pci0000:00/0000:00:04.1/usb1/1-2/1-2:1.1'

root@rooter:/tmp/home/root# ls -ld /sys/devices/pci0000:00/0000:00:04.1/usb1/1-2/1-2\:1.1/usb\:lp1
lrwxrwxrwx    1 root     root             0 Dec 31  1969 /sys/devices/pci0000:00/0000:00:04.1/usb1/1-2/1-2:1.1/usb:lp1 -> ../../../../../../class/usb/lp1

This is easily parseable by a shell script (hotplug). Said script can immediately create an extra symlink, specific to the printer model -- that one is guaranteed to be the right one! Then, all I need to do is share it -- and there's already a way to do all these things.So, without further stalling for time, here's the hacky script:

if [ $INTERFACE = "7/1/2" ]; then
 f=/sys/${DEVPATH}/usb:*; [ -e $f ] && d=`ls -d $f |sed 's/.*://'`
 if [ $PRODUCT = "3f0/4117/100" ]; then
  l=/dev/usb/HP1018
  if [ $ACTION = "add" ] && [ "n$d" != "n" ]; then ln -sf /dev/${d} $l; p910nd -b -f $l 2
   #TODO: send firmware to the printer
  elif [ $ACTION = "remove" ]; then rm -f $l; killall p9102d 2>/dev/null
  fi
 elif [ $PRODUCT = "4b8/839/100" ]; then
  l=/dev/usb/EpsonCX8400
  if [ $ACTION = "add" ] && [ "n$d" != "n" ]; then ln -sf /dev/${d} $l; p910nd -b -f $l 1
  elif [ $ACTION = "remove" ]; then rm -f $l; killall p9101d 2>/dev/null
  fi
 fi
fi

Not only does it create everything - it cleans up, too! And it can do the firmware trick as well (need usb hub for the thumbdrive - I'll probably need it for optware/sane, so might as well use it for the printer firmware, too, instead of mucking about with built-in flash)

IP Aliasing (Fedora), Multiple IPs (DD-WRT)

2010-10-19T00:59:00.001-07:00

# cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0:1
 .. edit ifcfg-eth0:1 - change UUID and all references to eth0 become eth0:1
# ifup eth0:1

(from http://fedoraforum.org/forum/showthread.php?t=239242)

# Save Startup
WANIF=`nvram get wan_iface`
WANMASK=`nvram get wan_netmask`
ifconfig $WANIF:1 173.X.X.250 netmask $WANMASK broadcast [BROADCAST]
ifconfig $WANIF:2 173.X.X.251 netmask $WANMASK broadcast [BROADCAST]
ifconfig $WANIF:3 173.X.X.252 netmask $WANMASK broadcast [BROADCAST]

# Save Firewall

# WAN .250 -> LAN .15
iptables -t nat -I PREROUTING -d 173.X.X.250 -j DNAT --to 192.168.0.15
iptables -t nat -I POSTROUTING -s 192.168.0.15 -j SNAT --to 173.X.X.250
iptables -I FORWARD -d 192.168.0.15 -p tcp --dport 21 -j ACCEPT
iptables -I FORWARD -d 192.168.0.15 -p tcp --dport 80 -j ACCEPT
iptables -I FORWARD -d 192.168.0.15 -p tcp --dport 5900 -j ACCEPT

# WAN .251 -> LAN .20
iptables -t nat -I PREROUTING -d 173.X.X.251 -j DNAT --to 192.168.0.20
iptables -t nat -I POSTROUTING -s 192.168.0.20 -j SNAT --to 173.X.X.251
iptables -I FORWARD -d 192.168.0.20 -p tcp --dport 21 -j ACCEPT
iptables -I FORWARD -d 192.168.0.20 -p tcp --dport 80 -j ACCEPT
iptables -I FORWARD -d 192.168.0.20 -p tcp --dport 5900 -j ACCEPT

(from http://www.dd-wrt.com/wiki/index.php/One-to-one_NAT)

Pretty sweet!

N900 MMS

2010-10-18T15:52:00.000-07:00

So I've been having problems getting MMS messages on my phone.
Turns out, I had it set to "polite" mode, though the "proper" mode is the "havoc". Started working instantly... bugger

SSL certs - self-signing

2010-10-17T23:51:00.000-07:00

Basic setup from http://www.yatblog.com/2007/02/27/how-to-create-a-ssl-certificate/

$ openssl genrsa -des3 -out server.key 1024
$ openssl req -new -key server.key -out server.csr
$ cp server.key server.key.org
$ openssl rsa -in server.key.org -out server.key
$ openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Works great and can use it with wildcard subdomains. But there's a caveat when using wildcard -- the cert is only valid for *.domain.com, not for domain.com
There's something called subjectAltName, but getting it to work is tricky (or, rather, it was tricky finding out how to get it to work...)

Finally found it here http://lists.mandriva.com/cooker-server/2004-01/msg00189.php

Instead of the last command, do this:

$ cat >ext.cnf <<EOF
[ alt_name ]
subjectAltName = DNS:domain.com,DNS:*.domain.com
EOF
$ openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt -extfile ext.cnf -extensions alt_name

Cool bash trick

2010-10-15T20:53:00.001-07:00

# yum install bash-completion

RAID -- downgraded to Oops

2010-07-20T13:46:00.000-07:00

As planned, I reverted the chunk size back to 64. Meanwhile, it occurred to me to try the same operation in a sandbox. So I made 4 10m files and tried to make an array out of them. That failed, since files are not block devices. Next I tried /dev/ram## devices and the array was up. I copied some files to it and played around trying to replicate the same actions I made on the live array. I was able to shrink it, change chunk size there and back multiple times without any problems. That brought my hopes up, obviously.

So, this morning re-re-chunking finally finished and I tried to resize the array:

# mdadm --grow -z max --backup-file=/root/grow_md0_size_back.bak /dev/md0
mdadm: component size of /dev/md0 has been set to 293033536K
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdd1[3] sda4[0] sdc1[2] sdb1[1]
293033472 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

Uhh.. what? Moshi-mosh..?
Can't do anything, array size is staying too small. Finally, I decide to take a leap of faith: stop the array and reassemble it (normally it's just like unmount/remount, but who knows what would happen with an array this messed up)

# mdadm --stop --scan
...
# mdadm --assemble --scan
mdadm: /dev/md0 has been started with 3 drives (out of 4).
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sda4[0] sdc1[2] sdb1[1]
879100608 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_] 
# mount /raid

Huh.. 3 out of 4, but it mounts. Woohoo! Time for backups...

Meanwhile, investigating:

in /var/log/messages:

Jul 20 09:56:41 slon kernel: md0: detected capacity change  from 0 to 900199022592
Jul 20 09:56:41 slon kernel: md0: unknown  partition table

That looks scary, but is normal. To the kernel, md0 is just a block device like a normal HDD -- and it doesn't have its own partition table. This is OK because ext filesystems don't require a partition table, you can use the entire drive for one.

Eventually, I found 2 errors I've made:

The new partition had type "83 Linux" instead of "fd Linux raid autodetect"
I left out a / in front of /dev/sdf1 in /etc/mdadm.conf -- so when mdadm looked at /dev/sdf1 it thought it wasn't part of my array

No idea if one of these was the cause of the resizing problem, but everything is up and running now.

RAID -- Oh shit!

2010-07-19T11:54:00.000-07:00

I wanted to add a 4th drive to the RAID box. That was easy enough:

mdadm --add /dev/md1 /dev/sdb3
mdadm --grow --raid-devices=4 --backup-file=/root/grow_md0.bak /dev/md0

Normally, at this point you're supposed to resize the FS to use the whole capacity (otherwise it keeps using the old size, only spread out over 1 more drive).

Then I decided to try 512k chunks because of some pages claiming it gives better performance.
Cue Trouble.

# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdd1[3] sda4[0] sdc1[2] sdb1[1] 
      879100608 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
# mdadm --grow -z 293033472  --backup-file=/root/grow_md0_size.bak /dev/md0
mdadm: component size of /dev/md0 has been set to 293033472K
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdd1[3] sda4[0] sdc1[2] sdb1[1] 
      293033472 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

mdadm --grow -z 293033472 --backup-file=/root/grow_md0_size.bak /dev/md0

mdadm --grow -c 512 --backup-file=/root/grow_md0_rechunk.bak /dev/md0

Of course, I didn't notice that the -z command changed the total array size to the number of blocks I specified, instead of setting it per-drive (as the man page says). So, thinking that I took off 64k from end of each drive (which should've been empty because FS was not resized yet), I kept on g[r]owing:

# mdadm --grow -c 512 --backup-file=/root/grow_md0_rechunk.bak /dev/md0

Since it was taking a whole day to do this, I thought I'd remount the FS and keep using it. No such luck:

# mount -oro /raid/
mount: wrong fs type, bad option, bad superblock on /dev/md0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

# dmesg|tail
[...]
EXT4-fs (md0): bad geometry: block count 146516768 exceeds size of device (73258368 blocks)

# vim /var/log/messages
[...]
Jul 18 12:00:44 slon kernel: md0: detected capacity change from 900199022592 to 300066275328
Jul 18 12:00:44 slon kernel: md0: unknown partition table

After re-chunking process finished, I set it to resize the chunks back the way they were before. When that is done, I'll try to resize the array back to the old size.
I don't think I'm THAT lucky, but there's a chance it'll work.

A major fuckup, indeed.

iptables + MythTV + PS3

2010-07-13T11:37:00.000-07:00

MythTV boasts UPnP/DLNA support, and PS3 is one of the supported clients. Unfortunately, most pages omit the firewall setup step, tell you to "enable UPnP on your firewall," or tell you to turn it off altogether.
Time for a little investigatin' with tcpdump.
First, with iptables disabled:

10:47:38.891960 00:1f:a7:c6:ec:5a (oui Unknown) > Broadcast Null Unnumbered, xid, Flags [Response], length 46: 01 00
10:47:41.797553 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1f:a7:c6:ec:5a (oui Unknown), length 300
10:47:44.240437 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1f:a7:c6:ec:5a (oui Unknown), length 300
10:47:44.255077 ARP, Request who-has PSthWii.home.lan tell 0.0.0.0, length 46
10:47:44.755239 ARP, Request who-has PSthWii.home.lan tell PSthWii.home.lan, length 46
10:47:44.756140 ARP, Request who-has PSthWii.home.lan tell PSthWii.home.lan, length 46
10:47:44.756507 IP PSthWii.home.lan > 239.255.255.250: igmp v2 report 239.255.255.250
10:47:44.757841 IP PSthWii.home.lan.51812 > 239.255.255.250.ssdp: UDP, length 223
10:47:44.758199 IP PSthWii.home.lan.51811 > 239.255.255.250.ssdp: UDP, length 137
10:47:44.766670 ARP, Request who-has rooter.home.lan tell PSthWii.home.lan, length 46
10:47:44.823698 ARP, Reply PSthWii.home.lan is-at 00:1f:a7:c6:ec:5a (oui Unknown), length 46
10:47:44.823718 IP slon.home.lan.56740 > PSthWii.home.lan.51812: UDP, length 364
10:47:44.857535 IP PSthWii.home.lan.51812 > 239.255.255.250.ssdp: UDP, length 223
10:47:44.905061 IP slon.home.lan.56740 > PSthWii.home.lan.51812: UDP, length 364

The first 6 lines are DHCP-related, and are of no consequence in this case. Then, there's an IGMP query to a multicast address and 2 SSDP packets (i.e. PS3 is asking "is there any servers that want to serve content to me?"). Two more packets for DHCP and then the MythTV backend already talking directly to the PS3.
That was easy enough. Now same thing with iptables enabled:

10:58:52.370765 00:1f:a7:c6:ec:5a (oui Unknown) > Broadcast Null Unnumbered, xid, Flags [Response], length 46: 01 00
10:58:53.402886 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1f:a7:c6:ec:5a (oui Unknown), length 300
10:58:56.187136 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1f:a7:c6:ec:5a (oui Unknown), length 300
10:58:56.399562 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1f:a7:c6:ec:5a (oui Unknown), length 300
10:58:59.562880 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1f:a7:c6:ec:5a (oui Unknown), length 300
10:58:59.571572 ARP, Request who-has PSthWii.home.lan tell 0.0.0.0, length 46
10:59:00.073984 ARP, Request who-has PSthWii.home.lan tell PSthWii.home.lan, length 46
10:59:00.074317 ARP, Request who-has PSthWii.home.lan tell PSthWii.home.lan, length 46
10:59:00.074618 IP PSthWii.home.lan > 239.255.255.250: igmp v2 report 239.255.255.250
10:59:00.074977 IP PSthWii.home.lan.52104 > 239.255.255.250.ssdp: UDP, length 223
10:59:00.076220 IP PSthWii.home.lan.52103 > 239.255.255.250.ssdp: UDP, length 137
10:59:00.079967 ARP, Request who-has rooter.home.lan tell PSthWii.home.lan, length 46
10:59:00.178902 IP PSthWii.home.lan.52104 > 239.255.255.250.ssdp: UDP, length 223
10:59:00.276588 IP PSthWii.home.lan.52104 > 239.255.255.250.ssdp: UDP, length 223
10:59:08.117789 IP PSthWii.home.lan > 239.255.255.250: igmp v2 report 239.255.255.250
10:59:15.317776 IP PSthWii.home.lan > 239.255.255.250: igmp v2 report 239.255.255.250
10:59:37.882885 IP PSthWii.home.lan > 239.255.255.250: igmp leave 239.255.255.250

The first 8 lines are DHCP-related, then same IGMP query as before and same SSDP queries as before... And that's it!
First guess: iptables doesn't allow the ssdp query to come in. Google tells me that SSDP port is 1900, so I add this entry to /etc/sysconfig/iptables:

-A INPUT -i eth0 -s 192.168.0.0/24 -d 239.255.255.250 -m udp -p udp --dport 1900 -j ACCEPT

Turn on iptables and restart the PS3 - everything works :)

Note: binding to eth0 and LAN ("-s 192.168.0.0/24") is not 100% necessary.

The only thing remaining is to make the NIC join the multicast group automatically. Simple enough -- add a file /etc/sysconfig/network-scripts/route-eth0 with these 3 lines in it:

GATEWAY0=0.0.0.0
NETMASK0=255.0.0.0
ADDRESS0=239.0.0.0

Wine/Steam Oops

2010-07-08T01:00:00.000-07:00

So apparently Steam requires Corefonts to be installed or it'll crash. How nice of wine to tell me abou.. wait a minute, it didn't!!
Luckily there's winetricks which warns you about it.

P.S. crossover-games installs it semi-silently (you can see individual fonts installing, but there's no notice that says you need them). It also installs Flash and MS XML parser.. guess we don't need those so much :P

MSS network problem: take 2

2010-07-05T21:16:00.000-07:00

Well, the network problem is solved.
The driver was really messy when it came to transmit queue. Tx interrupt handler guessed the current size of queue (and failed to restart it in some cases), while xmit tried going to hardware to check if the queue is full and stopped it left and right.
And tx_timeout wasn't resetting everything (missed resetting the cur/dirty frame counters).

Anyway, now it's halfway-working. I'm planning to add checksum offloading, vlans, all the good stuff from the solaris driver.

But for now it's time to start using my MSS, it's been doing nothing but standing there for way too long.

MSS network problem: take 1

2010-06-28T13:23:00.000-07:00

So I got the RAID to work fine, but network interface refuses to cooperate.
First of all, it takes a while to come up (few seconds, doesn't come up during boot for some reason). When it does come up, it's not very stable - last time I tried backing up with clonezilla to the MSS, it copied over 20G and froze - the NIC refused to receive any more data until I reset it. It also breaks when I run iperf.
Unfortunately, kernel folk have no time for me, so I've decided to take matters into my own hands. Apparently there have been a number of bugs on sis190 driver, though most patches are already in. I haven't read through this one yet, may have something good.
Also, there's a FreeBSD driver that was based on Linux + OpenSolaris drivers - it claims to support vlans and hardware checksums (neither is supported in Linux driver),
So far, I've determined that the error "ADDRCONF(NETDEV_UP): eth0: link is not ready" is from ipv6 implementation, so I've turned that off and the message is not there anymore... but interface still takes a while to come up, so it's not really a fix. I've traced through the driver somewhat and found where printouts happen.

I will continue tracing through the code until I understand more or less how the damn thing works. On one hand, it's only 2000 lines, but then You can hide a semi truck in 300 lines of C :)
The rest of the plan so far is to "branch" the sis190 driver and build it as a custom driver while I debug. Hopefully it will be enough.

Yum troubles - oops!

2010-06-11T23:34:00.000-07:00

Ran a yum update earlier today - it got frozen at "cleaning up" stage. So, I reboot and tell it to clean up after itself. Problem is, the dumb program erased the programs I've updated (apparently, "clean up" means "rm -rf" in RH python)

When I realized what happened, an old story came to mind. Something about a mainframe where user ran something to the effect of 'rm -rf /' and had no backups to restore from. Thinking quickly, he did NOT reboot the server (most luser's first reaction to any problem) and tried to see what he could salvage, if anything. After an awesome hack with text editor (vi?), hacking together a program with some hex code, he was able to bring the system back to more or less working condition.
The key concept here is "Don't Panic!" (phrase popularized by HHGttG).

So, anyway, I started looking around for what I can still do and/or salvage. No new programs could be started (including any command-line utilities like ls), but built-in shell commands (like echo) worked. The yum log mentioned a list of backed up files (e.g. /etc/shadow was renamed to /etc/shadow.rpmsave, and so on). I didn't remember if those appeared in /var/log/yum.log, so I decided to save it. I selected the text I wanted to save and checked that Clipman got it. Unfortunately, I had 'save on quit' turned off in it, and no way to re-enable (prefs start a new program). As my luck would have it, Firefox was still open and kind of working. I say "kind of" because the tabs & bookmarks lost their text, as did input fields on the pages - but I was able to [blindly] type in pastebin.com and open it up. From there, pasted in the log and specified my gmail addy. Verified that gmail got a copy of the link and finally decided to reboot.
Now, at this point I was hoping it'd "just work," but already had a plan in mind - boot off a Fedora live CD, chroot & reinstall everything that was removed. Or, worst case, copy over the binaries from the live CD to get yum working.
Guess what, I ended up having to do just that - chroot refused to work because ld-*.so was removed and bash refused to start. I copied it and some other libs over one by one (thankfully, the shell/program immediately complained specifically about which library was missing). Got yum working, installed keepassx in the live copy (needed to get at my password file with gmail password.. yes, I don't know it by heart :P), wrote a $0.02 script to list all packages 'erased' earlier today, and told yum to get reinstallin'. No problem, it didn't even have to download any of them (they were still in cache); meanwhile, copied the .rpmsave files (backed them up first) into their original locations.
Lo and behold, the system works!

Next, I'm planning to convert the FS to btrfs so I'd have checkpoints before any yum update (so this kind of shit won't happen again). Of course, I need to back up the existing data first, so I need to fix the MSS network interface.. but that's another story.

MSS LED problem: take 4

2010-02-15T00:42:00.000-08:00

I think the burned MOSFET and LM258 (the IC right next to it) form a brightness control for the LEDs. LM258 is an amplifier, its output goes directly to the gate of AO3409. Some IC must be sending the signal at low voltage, but the signal isn't making it through right now. 258's output is ~2-3V.
The LM258 is pretty robust -- according to the spec sheet, you can even short the output (if <15V and temp 25C) to the ground for unlimited amount of time without making it burn out... Anyway, I tried shorting IN+ (pin 3) to the ground -- that caused 258 to output 0V and made front panel LEDs work until OS booted up. Shorting IN- (pin 2) to the ground didn't make front panel work, so I tried shorting it to IN+. That made 258's output 12V and the front panel LEDs started working. I then booted up to windows and tried the LED controls -- everything works except for brightness (which is of course stuck at high). It's probably a bad idea to short circuit the inputs like that, though. For all I know, maybe keeping the LEDs in the high brightness mode too long is why Q1 burned out in the first place.
I've tried visually tracing where the signals to the 258 come from, but didn't find anything. I couldn't see traces under the 258, so I had to guess some of them - so that might've been the problem. Also, there might be multiple layers of traces, which is pretty common for motherboards.

Anyway, at least it's partial success :)

MSS LED problem: take 3

2010-02-12T23:14:00.000-08:00

Well, I installed the little bastard and still no lights :(
The chip from Digikey is AO3409 and has markings A9N̅A1H. The original chips had markings 340 and A91̲A2D.
That's pretty close, and people say Jrock is a reliable source. I didn't overheat the mosfet while soldering, either. So that leaves me with "something else is broken"

Guess I'll have fun figuring that out

MSS LED problem: take 2

2010-02-10T15:15:00.000-08:00

User Jrock found what the Q1 is!

I have it from a reliable source that Q1 is a AO3409 P-Channel Enhancement Mode Field Effect Transistor. Data sheet is here:

http://www.aosmd.com/pdfs/datasheet/AO3409.pdf

Looks like it's in stock at Digikey too for about 51 cents :).

Ordered 25 of these from Digikey, will send some to other MSS users if they want to save on digikey shipping.

Reminders for myself

2010-02-01T14:18:00.000-08:00

MSS:
* might not be a mosfet
* check if the 3 circles around the 0 in 340 are a logo
* check where the leads go, a sample diagram for nearby chips might provide extra info
* motherboard is marked SJ-D4. According to CPU-Z, manufacturer is Wistron. Yet another marking says HannStar J MV-4 94V-0. eBay doesn't seem to have any replacements for it :(
* Other users took a photo of their chips, one is marked 340, and another A91A 2D. Still no idea what they are, but at least there's a better chance of finding out now. Asked on electronics board but so far it's about as effective as #electronics.

RFID:
* found maxmicrochip.com -- might help figuring out how to read FECAVA chips

Fedora: volume problem

2010-02-01T14:12:00.000-08:00

Fedora 12 has a nifty (and by "nifty" I really mean "extremely annoying") feature -- it lets audio applications control the globally set volume. This means if you open a clip in mplayer, it turns the Master and PCM volumes all the way to maximum. And when you stop playback, they both go to 0. Fun, indeed.

To disable it, edit /etc/pulse/daemon.conf, add this line and log out/in:

flat-volumes = no

MediaSmart Server (MSS) project: take 1

2010-02-01T00:59:00.000-08:00

MSS is a weird computer. It's built to run "Windows Home Server" which basically stores all users' files remotely like a NAS. Which is what I want to turn it into. Except I'll use Linux and make it run software RAID (probably RAID5). Win 2k3 only copies certain directories (you have to mark them) to multiple drives for redundancy, there's no RAID. Anyway, screw Windows :P

I got it at Newegg a few months ago with a Rosewill eSATA extender - that makes for up to 8 hotpluggable SATA drives. The MSS was marked as "Recertified". Due to bundle discount and $50 refunded due to a wrong size HDD sent with MSS (should've been 500G, they sent 320G), the total came down to $300

One thing about MSS is that it doesn't have an external VGA header. You have to open it up and make your own VGA cable (or buy one for something like $30). I of course chose to make my own, but that's not too interesting.
Anyway, I started with installing Fedora 12 (it was beta/RC at the time). It didn't go too smoothly, unfortunately. Apparently it doesn't work unless the SATA bus is set to IDE mode, but I guess that's not all that big a deal. Video card drivers don't drive the video properly -- there's corruption on the X screen.. but then I didn't get this box for its video card.
With a small C program, I got the HDD LED lights to work -- it was pretty sweet. I also eventually found the elusive* AMD 3800 X2 EE SFF (model ADD3800IAA5C) and got MSS to work with it. Then I booted it up (successfully) and thought I'd finally finish installing Fedora & setting up the drives. And then I noticed that the LED weren't working at all.

I've tried re-flashing and switching back to the old chip -- no dice. Tried recovering 2k3 WHS -- also nothing. It appeared that the damn signal was being sent in reverse (what should've been ground was +5V compared to the other)
Today, I thought I'd trace where the bad signal is coming from. Connected with multimeter, got polarity. Put the software in blinking mode and tried with the scope - not very interesting (it was going up and down only ~1V). Then for whatever reason I thought I'd connect the scope backwards (ground to what was supposed to be ground, instead of the alternative). That made MSS emit a high pitched faint noise. I said "huh" and replaced the LED connector. For some reason I thought I saw the LEDs flash quickly, so I replaced it a few more times. Then there was a click, burnt electronics smell and the LEDs lit up! Oops!

I took out the mobo and literally followed my nose to find this little guy

Interestingly, it was obviously fried but the LEDs worked. I took a few pictures and decided to solder it off the board. After that the LEDs don't work again.
Now I'm trying to find what that chip might've been. This page says it might be Fairchild FDV340P (p-ch mosfet 20V 70 mA). I didn't find FDV340P on FairchildSemi (nor at Mouser and Digikey), but there's a FDN340P. No idea if that's the right part though.

* It's a very nice chip, actually. Only 35W but dual core and 3800+ rating. But because it's so nice, it's also hard to find (AMD doesn't make it anymore and most people buy it right away if listed on ebay)

RFID: take 1

2010-01-31T15:18:00.000-08:00

I was wondering if I could read my cat's RFID tag with an RFID reader. According to this pet ID info page and the actual number given to me, it should be FECAVA type chip which works at 125 kHz.

The first reader I got was parallax serial RFID reader (MakerShed, $40.. also got the P4 adapter and a free Maker Faire ticket :). Stupid mistake: didn't get a compatible card to test the reader. I thought I'd find something around the house to do that.. apparently it's not as easy as I thought. Reading the cat's tag didn't work, neither did trying to read some ID cards I had. Later I ordered a card from SparkFun. That worked great -- I saw the card ID in minicom.. but reading the cat's tag failed :(

2nd reader I got from SeeedStudio along with a small pack of cards (trying to not make the same mistake.. just in case reader wasn't compatible). Sadly, when I hooked it up I only got garbage on screen. After some back and forth, I hooked the reader to my oscilloscope and saw that the output wasn't consistent with 9600 baud they advertised (for 9600, the bits should be about 100µs -- a.k.a. 0.1ms -- apart. Actual spikes were ~1ms apart). I then suspected that I got the Wiegand version of the reader (though I definitely ordered UART version). After reading the datasheet, I saw that the pins labeled TX/RX for UART are labeled Data0/Data1. Wiegand version uses both to transmit data, UART can use either (RX is apparently inverse of TX). I hooked up the scope to both output pins and confirmed that the output looks like the Wiegand output from the doc.

However, so far I haven't seen either reader react to my cat's chip. Guess using the same frequency isn't enough :(

RepRap: take 1

2010-01-30T21:49:00.000-08:00

So I've decided to build a RepRap. After a little research, I decided that although Cupcake can get me up and running faster, RepRap would be a lot more fun since I get to build it myself.
I thought for a while that I could get away with getting imperial-sized parts instead of metric as specified in the docs.. but then I realized how much of a pain that would be to adjust everything, including the printed parts. So the only things I got in imperial are threaded rods (and their matching nuts).

For the bars, docs say "silver steel ground bars" are the best reasonable option -- US equivalent is apparently called "oil hardening drill rods". Got those and threaded rods (and some screws) from Wholesale Tool Co -- $44.99 (w/shipping+tax)

Got a bunch of metric screws/nuts/washers at Fastener Warehouse.
*** WARNING*** : this is a shitty store, I had to wait 5 weeks to get 6 out of 8 items.. the other 2 are still "backordered". No idea if I'll ever get them. $49.58

Bearings came from The Big Bearing Store. I didn't expect them to be so expensive... but they were cheapest there. $76.37
Update: VXB has a kit for $50

Got electronics at MakerBot store. They're fun to solder but not all that much fun.. I just got the premade ones and the stepper motors. $255.15

Total so far is ~$425. Not too bad, since official estimate is $520. Then again, I don't have the extruder and replicated parts yet.

For comms I thought I'd use the P4 adapter I got from MakerShed along with unrelated items.

When electronics came in, I tried testing the motherboard. Didn't get the proper reply with P4 so I checked the USB connector page and saw that it uses CTS and RTS. Since P4 only has DTR, I assumed it wouldn't work and moved on. My next available choice was the Bus Pirate (I have a v2go). I contacted the author and asked him to add CTS/RTS. He did that (really quickly, might I add!) and I tried again -- no dice :(

Yesterday I finally found some time to sit down and check things out. Thanks to the helpful folk in #reprap@irc.freenode.net, I finally figured out that the firmware for Cupcake CNC is different from RepRap firmware. Thus began the saga of trying to get the firmware onto the mobo. The part that kept failing was uploading firmware. The guys on #reprap told me to keep trying reset with different timings -- did that for a while, but to no avail. At some point I noticed that it was reporting a bad byte -- either 0x48 or 0x52. When looking at the output in minicom I realized why -- Cupcake sends "R3G Master v106" at startup and "Host timeout" on any other simple input (space, enter, etc.).
Things learned:
# Cupcake firmware runs the serial comms at 38400 baud. RepRap uses 19200
# Setting the autoreset jumper* is NOT enough. Apparently, sanguino (which is what the RepRap motherboard basically is) expects the reset signal to be sent through a special pin (which I left unconnected with P4 at first). Luckily, P4 supports the autoreset feature on sanguino quite well -- just connect the RT (a.k.a. RST, a.k.a. DTR) pin on P4 to GRN (a.k.a. RTS) pin on the motherboard.
* Note: the autoreset leads don't come with cupcake version, I soldered them in on mine. They're labeled, though.
# Cupcake firmware doesn't even have the same bootloader as the RepRap (as far as I can tell, RepRap uses plain sanguino bootloader). As far as I can tell, you can't flash RepRap firmware directly onto the Cupcake mobo.

I've decided to re-flash the bootloader with the only method available to me -- the Bus Pirate. It's amazingly easy.. the hardest part was getting the BP hook leads to connect to the ICSP connector (I didn't have a 6-pin female connector readily available so I crammed them in there :). Note, though -- I installed avrdude 5.8 from Fedora repos and it didn't support Bus Pirate. Looking at timestamps, I think 5.10 is the earliest version that supports it.
I don't think I needed the mobo to be on for this, but it seemed to work ok. Command used:

avrdude -p m644p -c buspirate -P /dev/ttyUSB0 -U flash:w:ATmegaBOOT_644P.hex

Next step was to get the actual code onto the motherboard. Another snag -- software kept saying connection timed out. Apparently the bootloader didn't power on the PSU -- but I was powering the P4 from it.. oops!
Shorted the right pins in the PSU to turn it on, ran the update program... and it worked! I was afraid for a while because the red LED (debug) kept blinking for a long time and the arduino proggy didn't say "Done uploading". On the other hand, the LED was blinking consistently at ~2Hz unlike at the beginning of the process -- apparently that's the RepRap program running on the mobo. I had to powercycle the PSU before I saw something in minicom.

And that's how far I got so far.
Update: mobo tested perfectly.
WOOHOO!!!