|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
Unlike most people in the United States, I like the metric system. I prefer to use it instead of imperial units as much as possible and change the settings on my electronic equipment to display metric units. Unfortunately, some equipment is fairly inconsistent with its support of the metric system and even 12 vs. 24-hour time. Here's what I've got:
This thing tricked me into thinking it supports both 24-hour time and Celsius by showing "options: 24 hours" in the manual. Unfortunately, it only supports changing the temperature unit. The time must stay in 12-hour mode.
I successfully changed this to 24-hour mode. There appears to be a thermal diode in the unit but there is no way to actually display the current temperature to the user so there is no way to set the scale.
My car is a bit odd. The navigation system can successfully be changed to use the metric system but the outside temperature and fuel level appear to be hard-coded to use imperial units. The clock must stay in 12-hour mode, too. Sadly, I do believe there is a "switch" for this but it's inaccessible to the user; the Canadian version of the car displays everything in metric.
This thing lives in the world of Fahrenheit and has a permanent 12-hour clock.
There is no way to change the clock to 24-hour mode.
I rent this thing from Comcast. It displays time in 12-hour mode, only.
I can switch this thing to 24-hour mode and Celsius, since it features a temperature sensor.
No 24-hour mode for this thing, even though the display is digital.
This also features a local and remote temperature sensor. I can switch this to Celsius and 24-hour mode easily.
If I were like one of those people who think we should have a law for everything, I'd say "there should be a law requiring all electronics companies to include support for the metric system in their products." Thankfully, I'm not one of those people, so I think the best thing to do is vote with your wallet. The next car I buy will support metric units in every feature!
It occurred to me that I haven't blogged in quite some time. So, here you go!
I moved into my townhouse in West Seattle about a month ago. The house itself is about eight (8) years old so there's not much I'm going to change or replace right off the bat. My fiancée has one or two things to say about the color schemes in some of the rooms, though, so there will be painting in the future. It's in the High Point community, which is still expanding rapidly and there are lots of new townhouses and single family houses being built. Unpacking took awhile but I'm more or less settled, now. I do need to buy some more furniture in the future since I have roughly 450 more square footage than I did in Charlotte.
I managed to get lucky with the cabling. All of the rooms in the house are wired for Cat5e and are already punched down in a central Leviton telecom panel in the closet of the master bedroom:
There's also a second port in several rooms that is wired for Cat5e but all of those ports are wired together. I ended up connecting my old Linksys PAP2T to those ports for analog phone compatibility, which I've actually used a bit. I ended up putting my Juniper EX2200-C and ALIX box in the closet, as well:
I haven't turned up my lab yet, since I was told I shouldn't be putting any loud things in the bedroom closet.
Ah, Comcast. I started off with xfinity 50/10 HSD and basic cable, which seemed fine until I realized I couldn't get more than one public IPv4 address. Back in Charlotte I was able to get the CPE limit increased to three (3) so I could have two firewalls as well as a Linux box connected to the Internet. After a long call with a fairly clueful CSR, he informed me that they no longer are able to increase the CPE limits for residential HSD and I'd have to get business class, which I did.
I got the same 50/10 service from Comcast Business but with a static /29. They wouldn't let me use my own modem because I was getting a static assignment so they gave me a Comcast-branded NETGEAR CG3000DCR. I suspect this is because of how they inject the /29 into their network, which is probably via RIP. The speed is fine and the latency to the CMTS isn't too bad, although it seems to bounce around a bit:
Here's a traceroute showing that nice paid peering between Comcast and Netflix:
Start: Thu May 8 20:34:26 2014 HOST: starfire Loss% Snt Last Avg Best Wrst StDev 1.|-- 10.1.10.1 0.0% 8 0.4 0.4 0.4 0.6 0.0 2.|-- 73.98.180.1 0.0% 8 8.7 8.5 7.2 10.0 0.7 3.|-- te-0-2-0-5-ur07.burien.wa.seattle.comcast.net 0.0% 8 9.7 9.5 7.6 11.1 0.9 4.|-- be-1-ur08.burien.wa.seattle.comcast.net 0.0% 8 9.5 9.5 8.2 10.6 0.5 5.|-- ae-1-0-ar03.seattle.wa.seattle.comcast.net 0.0% 8 9.7 9.6 8.5 10.9 0.7 6.|-- he-1-3-0-0-10-cr01.seattle.wa.ibone.comcast.net 0.0% 8 10.3 11.7 9.3 18.2 2.8 7.|-- he-0-13-0-0-cr01.sanjose.ca.ibone.comcast.net 0.0% 8 29.4 28.9 26.8 31.8 1.9 8.|-- he-0-11-0-0-pe03.11greatoaks.ca.ibone.comcast.net 0.0% 8 27.0 37.1 26.9 103.8 27.0 9.|-- as2906-c-0.sanjose.ibone.comcast.net 0.0% 8 69.0 68.4 61.2 79.2 5.3 10.|-- 198.45.56.12 0.0% 8 69.3 67.8 63.8 70.3 2.2
They also let me set my own PTR records, which is nice, although they offer no self-service way of doing this. I had to call them up. Oh.. and I must say there is a night & day difference between residential and commercial phone support.
Unfortunately, while Comcast does support IPv6 on the xfinity side of the house they do not yet support it for their commercial offering, so I'm still tunneling.
That being said, I had a bit of a headache when I tried to cancel the HSD portion of my xfinity residential service. At first when I canceled the service everything seemed fine. However, the CableCARD tied to my account (connected to the ATI DCT on my Windows Media Center PC) magically stopped working around the same time. I had to call them bad and they admitted they "made a mistake" when they were canceling my HSD account. That's fine. However, a few days later after I sold my old Motorola SB6141 to someone at work, I come to find out that the cable modem is still tied to my account. Again I had to call them and tell them to take it off my account. Surprisingly, my CableCARD and Motorola HD box didn't break this time.
The commute from West Seattle isn't as bad as everyone had warned. If I leave at around 07:00 I can be in the parking garage in around 18 minutes. From there it's a short 5-6 minute walk to the office and I can be at my desk by 07:30. I haven't quite figured out the best time to leave the office but it seems to take me anywhere from 25 to 30 minutes from the parking deck to my garage. Regardless, nothing as infuriating as I-485 back in Charlotte!
Work is fairly challenging and my first project is almost done. Amazon sure puts the wireless industry to shame with the sheer number of acronyms, nicknames, and proprietary lingo that is used for various things. I'm certainly having fun, so far! Yes, we are still hiring.
The first two warm days were last week and it got up to 29.4°C before I opened up the windows and cooled it down. I'm going to try the first summer without any air conditioning and then figure out if I need to get central AC or a portable unit for next year.
Anyway, the spring is fairly nice out here! It's nice and green, now:
The pollen is practically nonexistant compared to Charlotte. In fact, I haven't noticed any of it and, as a result, I've managed to skip my seasonal allergies completely, which is nice.
I think there's a bug in Mutt 1.5.23. Ever since I upgraded from 1.5.21 I've noticed doing a full-text message search is horribly slow. I think it may have to do with Debian bug 745532.
We've all heard about the recent NTP reflection attacks. Last night I noticed a higher-than-normal traffic volume on nox, so I checked it out with tcpdump:
Note, the first and second octets have been anonymized to protect the victim.
21:07:07.999600 IP 100.44.89.82.26528 > 64.16.214.60.123: NTPv3, Client, length 48 21:07:07.999608 IP 100.44.89.82.26528 > 64.16.214.60.123: NTPv3, Client, length 48 21:07:07.999617 IP 100.44.89.82.26528 > 64.16.214.60.123: NTPv3, Client, length 48 21:07:07.999625 IP 100.44.89.82.26528 > 64.16.214.60.123: NTPv3, Client, length 48 21:07:07.999712 IP 100.44.89.82.26528 > 64.16.214.60.123: NTPv3, Client, length 48 21:07:07.999722 IP 100.44.89.82.26528 > 64.16.214.60.123: NTPv3, Client, length 48 21:07:07.999730 IP 100.44.89.82.26528 > 64.16.214.60.123: NTPv3, Client, length 48
Yes, nox is a public NTP server. It's a member of the NTP Pool Project. No, it's not susceptible to an NTP reflection attack. It looks like some poor soul at 100.44.89.82 (looked like a SonicWALL when I poked around) was being attacked and the traffic above was being spoofed with the intention of having my server send back a reply that's much larger than the request. Here's a decode of one of the packets:
21:07:07.772681 IP (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 76)
100.44.89.82.10084 > 64.16.214.60.123: [udp sum ok] NTPv3, length 48
Client, Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 10s, precision -19
Root Delay: 1.000000, Root dispersion: 1.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 3604450027.692652940 (2014/03/21 21:07:07)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 3604450027.692652940 (2014/03/21 21:07:07)
What's odd about this is the packet above looks like just a normal NTP query. Unlike most of the NTP reflection attacks that exploit the monlist or similar commands, this wasn't really going to have the desired effect. And, of course, if you look at the initial (before I blocked that source address with iptables) traffic volume, it certainly did not:
The desired effect, of course, should have been an outbound traffic volume that was greater than the inbound traffic volume, or amplified. In this case, my server was just sending back a 48 byte packet for every 48 byte packet coming in, albeit apparently slightly ratelimited by the NTP daemon.
Was this a misconfigured DDoS bot? Did the attacker really not know what he or she was doing or missed DDoS 101? Or, was this traffic not actually spoofed and was a result of some broken NTP client? Maybe.
Regardless, if this wasn't a misconfigured NTP client, BCP 38 would have prevented this from happening to begin with. I don't know where the traffic was originating, but I do know that it was from a network that probably doesn't implement BCP 38.
Anyway, I thought this was a little odd so I figured I would share.
No, I'm not quoting Bill Clinton. I haven't posted in a few months because it was time for a change and I decided to pull the trigger. I left Time Warner Cable in Charlotte and moved to Seattle to work for Amazon Web Services.
I'm not going to say much about the job change because it's really not appropriate for a public-facing blog and there's really not much I can say. I'm happy to be advancing my career and working on a network that either powers 1% of the Internet or provides content to 1/3 of all Internet users (depending on who you ask).
Before I left Charlotte I got engaged to my beautiful fiancée on Valentine's Day.
We're set to be married next year on a day that commemorates the ratio between a circle's circumference and diameter.
At the moment I'm living in the Belltown area of Seattle in Washington state. My ten (10) minute commute is thoroughly spoiling as it'll be a bit longer when I move into my permanent residence in a couple of weeks.
I'm still trying to figure out Seattle. It's got elements from both uptown Charlotte and Manhattan but with its own twist. The people who I come in contact with on a daily basis are very friendly, which from what I hear is actually abnormal. The weather here is routinely overcast and rainy but I've found that weather forecasts are terribly inaccurate due to the surrounding mountains in the region. Most days that are forecasted as rainy actually end up with an hour or two of sun between the fronts, which is nice. I was told that only 17% of residences have central air conditioning. At first, I thought this was a bit odd (coming from the south!) but I suppose it makes sense due to the climate. I'll find out this summer if my computers will require extra cooling or if they'll be fine sans-AC!
One nice thing is the Comcast XFINITY service in the area provides native IPv6 with prefix delegation. Finally, no more tunneling! Although, I do like the permanent nature of a tunneled /56 or /48 as well as the reverse DNS delegation. Maybe I'll ultimately use a combination of both.
A week or so I configured some IPv6 prefix lists in my networking lab at home on a few Cisco IOS boxes running 15.1(4)M7. Almost a day after I finalized the configuration, I noticed that the prefix lists appeared to be reordering themselves from time to time. Specifically, the "show running-config" command would list the entries in a slightly different order, every once and awhile.
Normally, I wouldn't care. Prefix lists are not evaluated based on order and this was just a lab, anyway. However, I have RANCID setup to monitor all configuration file changes in my lab environment and I started getting several e-mails per day. Here's a sample:
Index: configs/defiant =================================================================== retrieving revision 1.485 diff -u -4 -r1.485 defiant @@ -340,11 +340,11 @@ passive-interface Loopback0 ! ipv6 prefix-list DEFAULT-ROUTE permit ::/0 ! - ipv6 prefix-list SPOCK-NETS permit 2001:48C8:1:104::37/128 ipv6 prefix-list SPOCK-NETS permit 2001:48C8:1:104::38/127 ipv6 prefix-list SPOCK-NETS permit 2001:48C8:1:13A::/63 + ipv6 prefix-list SPOCK-NETS permit 2001:48C8:1:104::37/128 ! route-map ADV-DEFAULT permit 10 match ip address DEFAULT-ROUTE !
This is happening on two routers running the same exact version of IOS with a similar prefix list. It seems like the configuration compilation that is executed from the "show running-config" command may be doing something wrong since when I display the prefix lists manually and they are shown in the same order each time:
defiant#show ipv6 prefix-list ipv6 prefix-list DEFAULT-ROUTE: 1 entries seq 5 permit ::/0 ipv6 prefix-list SPOCK-NETS: 3 entries seq 5 permit 2001:48C8:1:104::37/128 seq 10 permit 2001:48C8:1:104::38/127 seq 15 permit 2001:48C8:1:13A::/63
I haven't tried messing with different IOS versions, yet. I may do that later.
Oh, in other news.. among other things, I got a plush NCC-1701 for Christmas:
Yes, it's from ThinkGeek and makes noise.
Well, this one is a bummer. Apparently, Mac OS X Mavericks introduced a bug in either the gif(4) driver or kernel that crashes the whole machine when an IPv6 address is removed from a 6in4 tunnel interface. The gif(4) driver in the BSD world provides a generic driver to tunnel IP in IP (any version inside any other version).
If you want to try it, do this as root:
/sbin/ifconfig gif0 up /sbin/ifconfig gif0 tunnel 10.1.1.1 10.9.9.9 /sbin/ifconfig gif0 inet6 2001:db8:1:116::2/64 /sbin/route add -inet6 default 2001:db8:1:116::1 /sbin/route delete -inet6 default /sbin/ifconfig gif0 -tunnel /sbin/ifconfig gif0 inet6 2001:db8:1:116::2/64 -alias
The last command triggers a kernel panic and reboot after a few seconds. I discovered this after loading my IPv6 6in4 tunneling script on my old MacBook Air. The tunnel works fine when it's up. However, tearing it down seems to be problematic, to say the least. My script doesn't even get to the point where gif0 is brought down.
The backtrace and some associated information looks like this:
Thu Dec 19 13:37:50 2013 panic(cpu 1 caller 0xffffff80164d143e): Preemption level underflow, possible cause unlocking an unlocked mutex or spinlock Backtrace (CPU 1), Frame : Return Address 0xffffff80a5e536d0 : 0xffffff8016422f69 0xffffff80a5e53750 : 0xffffff80164d143e 0xffffff80a5e53760 : 0xffffff80164d11cf 0xffffff80a5e53770 : 0xffffff801664ce14 0xffffff80a5e537b0 : 0xffffff801662bb33 0xffffff80a5e538d0 : 0xffffff8016730aac 0xffffff80a5e539a0 : 0xffffff8016714519 0xffffff80a5e53dc0 : 0xffffff801672b6cc 0xffffff80a5e53e20 : 0xffffff801672b308 0xffffff80a5e53e60 : 0xffffff801672afea 0xffffff80a5e53f20 : 0xffffff801644a15a 0xffffff80a5e53fb0 : 0xffffff80164d6aa7 BSD process name corresponding to current thread: kernel_task Mac OS version: 13A603 Kernel version: Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 Kernel UUID: [removed] Kernel slide: 0x0000000016200000 Kernel text base: 0xffffff8016400000 System model name: MacBookAir3,1 (Mac-[removed])
The full report can be found here. I removed some values in it that I thought might be harmful if they are public (I could be mistaken). I also filed a bug report with Apple on this: 15701774. I'm fairly sure this is not hardware-related or related to VirtualBox, Cisco AnyConnect, or TunnelBlick kernel extensions being present since I can crash another Mavericks install running in a VM that has none of them loaded.
Update: I did realize I was not running the latest version of OS X Mavericks, 10.9.1. I just upgraded but the issue is still present. Here is a crash report under 10.9.1.
Update: Apple closed my bug report as a duplicate of 14929904.
Yes, I have a few things to say about this. It's not a review of the iPad Air but more of a whiny rant (shocker, I know).
I recently picked up an iPad Air MF018LL/A, which is the white cellular model with 128 GiB of storage. I use AT&T for carrier diversity with the 3 GiB/mo plan since my phone is on T-Mobile's network. The iPad Air replaced my iPad 3, which when I owned it was jailbroken and still running iOS 6. I happened to sell it and all of my accessories to a colleague who is now a first-time iPad owner.
Below: iPad 3 on the left, iPad Air on the right.
My first impression with the iPad Air was awful since it failed at the first thing I asked it to do: install an application. I got the dreaded "could not connect to iTunes store" error whenever I tried to install an application on Wi-Fi or cellular.
It turns out this is an iOS 7 issue that some folks got after upgrading from iOS 6 and there was a thread on the Apple Support Communities site about it. I had to ultimately do a factory reset and wipe of the device to fix it. I didn't lose anything because it was a brand new iPad and I had not loaded anything back onto it. It's odd that this hasn't been fixed in iOS 7.0.3, which is what's running on my iPad Air. I also wonder how iOS 7 was loaded onto the iPad. I'm almost wondering if iOS 6 was initially running on the iPad Air during development and the first few devices were shipped with a version of iOS 7 that was upgraded from an existing iOS 6 installation. Curious.
The iPad Air hardware is good. The CPU seems fast (Google Earth is smooth as butter) and the shell (+ components) is much lighter and thinner than the iPad 3. I'm not sure what I think about battery life, yet. So far, it seems to last slightly less than my iPad 3 but my analysis is most unscientific.
The antennas or cellular radio itself must be better in the iPad Air vs. the iPad 3 because I have five "dots" more often than I had five "bars" on the iPad 3. I suppose the "dots" could be mapped to different ranges of dBm in iOS 7, now, or the addition of more LTE bands is helping, although I didn't think LTE bands themselves overlapped within an area.
I configured the switch on the side of the iPad Air to control roation lock, since I have volume muted almost all of the time, anyway. I find that, compared to the iPad 3, it's more difficult to slide the button back & forth with my finger. The button itself appears to be rounded and the one on the iPad 3 had sharper edges that were easier to "grab" with my finger.
I'm disappointed that the fingerprint reader now being used on the iPhone 5s didn't make its way into the iPad Air. I guess it doesn't matter to me since I probably wouldn't have used it, anyway.
I don't mind the visual changes in iOS 7, to be honest. I thought the skeuomorphisms probably needed to go, too. There are a few things that bug me, though.
The control center is an abomination. Apple made the decision on what toggles should be available to users and didn't leave any room for customization. It's infuriating. I would like to swap out the airplane mode for a toggle that turns cellular data on and off. If I'm connected to Wi-Fi and want to shut off cellular data to save a little bit of battery life, I have to navigate all of the way to settings.
It appears the text size for items on the status bar at the top of the screen has become smaller. The text size setting doesn't appear to change the font size of them. What's weird is the items are larger at the lock screen but shrink when the device is unlocked. Very odd.
The IPv6 support seems better than in previous versions of iOS. I didn't have a problem loading all web pages over IPv6 on my dual-stack network at home. In iOS 6, some of those pages would have loaded over IPv4 due to Apple's odd HE implementation. DHCPv6 appeared to work on one of my test SSIDs but unfortunately the iPad put the IPv4 DNS servers before the IPv6 one. More testing is required, apparently.
One difference in the IPv6 support between iOS 6 and 7 is the implementation of RFC 4941 when SLAAC is used. iOS 6 added temporary addresses with random interface identifiers but always kept the link-local address based on EUI-64 as well as one GUA. iOS 7 appears to randomize the interface identifiers for both the link-local address and all the GUAs. I really wish it was possible to disable this.
I really miss the jailbroken functionality I had with iOS 6 on my iPad 3. Lots of people ask me why I bother to still jailbreak iOS devices—my reasons mostly relate to optimization and performance. I'll detail them all here.
3G Unrestrictor. This application works around some of the very annoying and pointless restrictions of iOS itself and many applications. Podcasts, iTunes, and the App Store won't download anything over 100 MB (I assume MiB) over a cellular connection.
There's no way to disable this and it's infuriating. TWC TV won't stream live TV over cellular. The list goes on. These restrictions are stupid because iOS and the various applications are essentially telling the user that they're too stupid and irresponsible to use their cellular data plan. If I want to burn up my plan downloading podcasts that is my prerogative! 3G Unrestrictor fixes all of these issues and fools applications into thinking the current network connectivity is via Wi-Fi.
SBSettings. SBSettings provides functionality similar to iOS' control center but is instead customizable and provides tweaks that allow various things on the status bar to be changed. Toggles include data, OpenVPN (if installed), 3G Unrestrictor, and more. The status bar can be configured to show the current Wi-Fi SSID, numeric signal strength indicators for both cellular and Wi-Fi, non-scaled battery percentage, and more other options than I can remember at the moment.
FakeClockUp. This application speeds up transitions and some animations on iOS. Although these animations take only a second or so every time, this can add up to minutes and hours of wasted time over the life of a device. This application is needed because iOS doesn't provide an option to disable these transitions.
Command-line Access. While most non-geeks do not care about such things, command-line access provides a wealth of flexibility. Among other things, it allows for network-related diagnostics and troubleshooting as well as the ability to directly back up media and application data that is otherwise inaccessible or only provided by other 3rd party applications.
Hopefully, the above will be usable for iPad Air owners once again when the iOS 7 jailbreak is released. Until then, we're locked into doing things the way Apple wants us to do them, sans-choice.
For folks out there, like me, who like to do clean installs of OS X and require boot media to do so, Apple has apparently provided a nifty script in the OS X Mavericks installer. It's one extra step compared to just writing InstallESD.dmg to a USB flash drive, I guess:
(quark:16:29)% cd /Applications/Install\ OS\ X\ Mavericks.app/Contents/Resources (quark:16:29)% sudo ./createinstallmedia --volume /Volumes/Untitled --applicationpath "/Applications/Install OS X Mavericks.app" Password: Ready to start. To continue we need to erase the disk at /Volumes/Untitled. If you wish to continue type (Y) then press return: Y Erasing Disk: 0%... 10%... 20%...100%... Copying installer files to disk... Copy complete. Making disk bootable... Copying boot files... Copy complete. Done. (quark:16:41)% df -h Filesystem Size Used Avail Capacity iused ifree %iused Mounted on /dev/disk0s2 39Gi 17Gi 22Gi 44% 4500660 5775196 44% / devfs 189Ki 189Ki 0Bi 100% 658 0 100% /dev map -hosts 0Bi 0Bi 0Bi 100% 0 0 100% /net map auto_home 0Bi 0Bi 0Bi 100% 0 0 100% /home /dev/disk1s2 7.3Gi 5.0Gi 2.3Gi 68% 1307226 615788 68% /Volumes/Install OS X Mavericks
Yep, it's nice and easy. The installer takes up roughly 5.0 GiB of space, so an 8 GiB (or GB, in this instance) USB stick is probably required.
Displaying page 6 of 121 of 965 results
     |
This HTML for this page was generated in 0.006 seconds. |