I passed it yesterday.  Woot.

It wasn't too bad, and basically consisted of a mass slaughter of a bunch of trees, reading around 800 pages, and setting up a few logical routers on a Juniper M10i.

Well, although the Kindle is nice, I think my battery is defective.  Two tests, the first with wireless enabled:

1. Charge until the LED goes out (~2 hr)
2. Use Kindle for 30 minutes
3. Let Kindle sleep for 9 or 10 hours
4. (battery down to 1% - unit will not power on)

According to Amazon, when the unit sleeps and the wireless is turned on, it's not really sleeping, it's completely lying to you.  I think this is false, but I shut off the wireless just for completeness:

1. Charge until the LED goes out (~2 hr)
2. Use Kindle for 30 minutes
3. Let Kindle sleep for 9 or 10 hours
4. Use Kindle for 10 minutes - battery is around 80-90%
5. Let Kindle sleep for 4-5 hours
6. Battery down to 62%

After roughly 40-45 minutes of usage, the battery should not drain to 62%.  It's supposed to last much longer.  So Amazon is sending me a new one, and according to them, there have ben "lots of" battery problems.

Annoying.

I'm a gadget addict, I'll admit it.  I received my Amazon Kindle today, and took some obligatory photos.

First impressions…

The screen is easy to read, and the Kindle User's Guide was easily navigable and clear.  Web content in basic mode renders nicely, especially Wikipedia articles.  Sprint's EVDO connection is snappy, but that might due to only HTML being downloaded.  The unit is nice and slim, reminding me of a PADD.  It also fits nicely in my inner jacket pocket.

The PDF conversion is fairly weak.  I e-mailed the JNCIS Study Guide to my Kindle account to test it out.  Unfortunately, there seems to be no way of jumping to a specific page, except for clicking on links embedded in the PDF.  Hitting the back button isn't always predictable, either.

The interface is horribly laggy, and typing reminds me of SSH over a GPRS connection.  It might have something to do with prerendering for the E Ink display, but I doubt it.  Not a big deal, though, since the unit isn't made for composing large pieces of text.

For those of you are wondering, this is what I saw in my access log from the Kindle:

207.171.167.25 - - [11/Feb/2008:18:52:55 -0500] \
"GET / HTTP/1.1" 200 855 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0) NetFront/3.3"

And some DNS resolution:

25.167.171.207.in-addr.arpa domain name pointer iad-fw-global.amazon.com.

Looks like the Internet connection is fed through Sprint's network directly to Amazon, and egresses out NTT/Verio.

I upgraded the Debian Asterisk package to 1:1.4.17~dfsg-2+b1, recently.  What a mistake that was!

First, I had to redo most of my configuration files from scratch.  Not a big deal, but I had to hit the following:

• extensions.conf
• sip.conf
• voicemail.conf
• musiconhold.conf

After getting things sort-of working again, I found that I didn't have voicemail, the music on hold MP3 wasn't working, and the "match as you go" dialing was trying to match everything after two digits.  <growl>

Turns out the default directory for moh changed from /usr/share/asterisk/mohmp3 to /var/lib/asterisk/moh.  I moved my MP3s and changed the appropriate files, but now the on-hold music plays at roughly 1/5 the previous rate.  These are _default_ settings that I used in the previous release, too!

The voicemail extension wasn't working, since the CALLERIDNUM variable apparently has changed, or gone away.  I had to replace the following:

exten => *98,1,VoiceMailMain(${CALLERIDNUM}@${CONTEXT})

with:

exten => *98,1,VoicemailMain(${CALLERID(num)}@${CONTEXT})

The other thing that's still broken is the match-as you go feature.  I've tried messing with DigitTimeout and all the other options, but Asterisk still tries dialing after the 2nd digit (my extensions are 4 digits long).  Typing the extension and _then_ hitting dial still works, though.

Annoying!

< cnj> This is why you don't upgrade things!

Maybe :(

Most cable modems use 192.168.100.1 as a management interface, accessible from the Ethernet interface.  I typically block all RFC1918 traffic in and out of my network, so, without creating an exception, I wouldn't be able to access said IP.  So I sort-of got a 1:1 NAT working, for it.

First, I created an additional loopback IP on the box closest to the cable modem:

% ifconfig lo:1
lo:1      Link encap:Local Loopback  
          inet addr:10.3.4.29  Mask:255.255.255.255
          UP LOOPBACK RUNNING  MTU:16436  Metric:1

So my whole network could route to it, I advertised it into OSPF (soon to be BGP) with Quagga's ospfd:

router ospf
 ospf router-id 10.3.4.3
 network 10.3.4.29/32 area 0.0.0.0
[...]

Then, I added two iptables rules:

IPTABLES="/sbin/iptables"
$IPTABLES -t nat -A PREROUTING -d 10.3.4.29 -j DNAT --to-destination 192.168.100.1
$IPTABLES -t nat -A POSTROUTING -j MASQUERADE -d 192.168.100.1

This takes all transit connections destined to 10.3.4.29, changes the destination address on the way in to 192.168.100.1, then applies source NAT on the way out, so the cable modem sees all connections coming from the ISP-assigned address.

It works, but there are two oddities I haven't been able to fix/explain:

1. The TTL is not updated during transit through the box where the NAT is being done.  This makes it look like, from a traceroute, that the loopback address is really on the Linux box, and not on something behind it.  Other firewall implementations (Cisco PIX, Juniper NetScreen/ISG/SSG) modify the TTL, and optionally mask the intemediate hops toward the host that is the destination NAT target.
2. The NAT rules are not applied to local connections.  If I telnet to port 80 on 10.3.4.29 from another box on my network, I get the web interface of the cable modem.  However, if I telnet to 10.3.4.29 from the router, I get a RST since there is no web server running locally.

I'm pretty sure I saw some "NAT of local connections" in the Linux kernel awhile back, but I can't seem to find it, now.  Weird.  Anyhow, I can still monitor traffic on the cable modem's various interfaces.  Neat.

I got back from my trip to California, today.  I took some photos, and had a fairly successful dining experience:

• Tarantino's Restaurant
• Claim Jumper
• Denny's (listed for completeness…)
• Scoma's Fisherman's Wharf (here)
• Faz's Restaurant

It's a little chilly, but sunny!  Lots of tech companies in the area…

Cisco:

Juniper:

Fry's:

Air force?

Back to San Francisco this evening!

It's only a day away!  IPv6 Addresses for the Root Servers are coming.

Looks like I can reach 5/6 of them.  f.root-servers.net loops in OCCAID:

 1  gw-121.ewr-01.us.sixxs.net  1.528 ms
 2  bbr01-g0-3.nwrk01.occaid.net  1.176 ms
 3  bbr01-g1-0.asbn01.occaid.net  7.474 ms
 4  bbr01-g2-7.dlls01.occaid.net  48.234 ms
 5  dcr01-p1-5.lsan01.occaid.net  81.829 ms
 6  bbr01-g0-2.irvn01.occaid.net  82.888 ms
 7  dcr01-g0-2.lsan01.occaid.net  83.106 ms
 8  bbr01-g0-2.irvn01.occaid.net  83.122 ms
 9  dcr01-g0-2.lsan01.occaid.net  83.353 ms
10  bbr01-g0-2.irvn01.occaid.net  84.269 ms
[...]