|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
Warning: Soapbox.
It's almost the end of 2013. World IPv6 Launch was over 15 months ago. However, it appears we still have some organizations and protocols that just aren't getting with the program. Even more shocking, we still have some that are taking measures to indirectly inhibit IPv6 development.
I've made a short list.
MPLS. draft-george-mpls-ipv6-only-gap goes over many of the problems that need to be overcome to operate an MPLS network that is free of IPv4. The short story is that it may be awhile before this is possible. I can see many new ISPs deplying RFC 6598 (possibly erroneously) or RFC 1918 space on their backbones just to meet the IPv4 requirements for MPLS, in the short term, unfortunately.
Twitter. Twitter owns 2620:fe::/40 but has not announced it into BGP, yet. The least they could do is provide something like http://ipv6.twitter.com/ on a proxy server to show their interest in keeping up with technology.
Debian GNU/Linux bug #592539 for isc-dhcp-server. The isc-dhcp-server package has both IPv4 and IPv6 functionality but the init scripts to start the IPv6 version of the daemon don't exist. Yes, this means that you can't use DHCPv6 on Debian without writing your own init script or starting it manually. The bug was opened in August of 2010 and has yet to be resolved. Get with the program, folks!
Amazon EC2. This is a sore subject. The only AWS service that supports IPv6 is ELB, unfortunately. EC2 doesn't support it in any region or availability zone, at the moment. This is preventing lots of organizations from correctly deplying IPv6.
Google Compute Engine. GCE is a very poor competitor to Amazon EC2 for a variety of reasons. Google could have actually made one feature more attractive than EC2 by offering IPv6 on it. Unfortunately, they didn't. Fail.
Skype. We all know about this one, so let's just move on.
FreeBSD. A change in the defaults for the IPv6 address selection algorithm in FreeBSD 9.x leaves users with an OS that always prefers IPv4 connectivity when both A and AAAA RRs exist for a particular label. There are two knobs that can be put in /etc/rc.conf that change this behavior (ipv6_activate_all_interfaces and ip6addrctl_policy). That being said, versions of FreeBSD prior to 9.x defaulted to always preferring IPv6 over IPv4 when both RRs exist. It's very backward-thinking of the FreeBSD folks to introduce such a drastic change in the operating system's defaults after supporting IPv6 for so long. Apparently, FreeBSD 4.0 introduced support for IPv6 back in 2000.
Carrier Grade NAT. Unlike traditional NAT, CGN is often deployed on residential networks as a second layer of NAT (the customers' home routers being the first layer). This second layer of NAT breaks end-to-end connectivity even worse than a single layer of NAT, rendering a variety of peer-to-peer applications useless. Even though the problems with CGN are numerous, it helps ISPs push back the deployment of IPv6 for a little while longer, unfortunately.
If any of you are thinking of running Junos 12.1X44 or 12.1X45 on the SRX branch series, think again. My SRX100H at home running 12.1X45-D10 runs out of memory every 3-4 days and reboots:
einstein (ttyu0) login: Sep 14 16:50:46 init: low_mem_signal_processes: send signal 16 to routing Sep 14 18:23:43 init: low_mem_signal_processes: send signal 16 to routing init died (signal 4, exit 0) panic: Going nowhere without my init! cpuid = 0 KDB: stack backtrace: 0x4af834+0x20 (0x6,0,0x3f7eef10,0x4bec10) ra 0x4af7fc sz 0 0x4af7c0+0x3c (0x6,0,0x3f7eef10,0x4bec10) ra 0x4ae114 sz 32 0x4ae090+0x84 (0x6,0,0x3f7eef10,0x4bec10) ra 0x445094 sz 56 0x445020+0x74 (0x6,0,0x3f7eef10,0x4bec10) ra 0x445110 sz 40 0x445020+0xf0 (0x6,0,0x3f7eef10,0x4bec10) ra 0x44625c sz 40 0x4461d4+0x88 (0x6,0,0x3f7eef10,0x4bec10) ra 0x446978 sz 64 0x446944+0x34 (0x6,0,0x3f7eef10,0x4bec10) ra 0x4b03f4 sz 32 0x4b03b4+0x40 (0x6,0,0x3f7eef10,0x4bec10) ra 0x4b06b8 sz 40 0x4b05d8+0xe0 (0x6,0,0x3f7eef10,0x4bec10) ra 0x4926b4 sz 32 0x492630+0x84 (0x6,0,0x3f7eef10,0x4bec10) ra 0x48d6b4 sz 48 0x48d588+0x12c (0x6,0,0x3f7eef10,0x4bec10) ra 0x4039a4 sz 3512 0x403968+0x3c (0x6,0x4d22b4,0x3f7f0060,0x4bec10) ra 0x403e40 sz 40 0x403d60+0xe0 (0x6,0x4d22b4,0x3f7f0060,0x4bec10) ra 0x3ffeefe0 sz 32 VA 0x3ffdefdc: not in user area or heuristics failed _start+0xbfeeef00 (0x6,0x4d22b4,0x3f7f0060,0x4bec10) ra 0 sz 0 pid 1, process: init Uptime: 4d1h54m46s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset: Stopping other CPUs
It doesn't bother me too much except I'm worried that eventually I'm going to start seeing some things in lost+found.
Also, my EX2200-C running Junos 13.2X50-D10.2 dies every week or two, too. I don't have a persistent console on it, though, so I'm not sure what's happening. The RE goes unreachable but the PFE still keeps on going (although possibly not learning additional MACs).
While it's neat to run the latest and greatest code, I'm glad I'm not running any of the mentioned X releases on any production gear at work. Yes, JTAC recommends certain releases for a reason.
A few weeks ago I posted a blog entry about cholesterol, specifically the lack of my HDLs. One of the suggestions I read about to increase HDLs involved taking fish oil. So, I've been trying this.
I picked up some Barlean's Fish Oil and have been taking two teaspoons of it per week (Monday and Thursday, usually). There was some question of whether it should be refrigerated so I decided to keep it in chilled.
I was going to give it six (6) months and see if it made any impact on my HDLs. I figured it wouldn't have any other effect on my health but it looks like it might be giving me more energy while swimming. Check out this graph of my swim times:
My times have slightly improved. I feel like I have more energy than I did before taking the fish oil, oddly enough. However, correlation does not imply causation so I can't be sure that the reason I have more energy is solely because of the fish oil. However, I will be continuing with it!
Well, it's official. I suck at SLAX. I managed to find myself in a small situation at work where I needed to create an op script that's called by some conditions under event-options. Anyway, I always get stuck on the most simplest of things with SLAX and today was no different.
I couldn't figure out how to activate and deactivate portions of the Junos configuration, of all things. I'm talking about stuff like this:
{master:0}[edit]
prox@enterprise# show protocols
bgp {
group foobar {
peer-as 64512;
neighbor 10.0.0.2;
}
}
{master:0}[edit]
prox@enterprise# deactivate protocols bgp group foobar
{master:0}[edit]
prox@enterprise# show protocols
bgp {
inactive: group foobar {
peer-as 64512;
neighbor 10.0.0.2;
}
}
{master:0}[edit]
prox@enterprise# activate protocols bgp group foobar
{master:0}[edit]
prox@enterprise# show protocols
bgp {
group foobar {
peer-as 64512;
neighbor 10.0.0.2;
}
}
For some reason, this was not easily searchable on Google or Bing. I did manage to figure it out, though. To deactivate a piece of the configuration, do the following:
var $config-change = <configuration> {
<protocols> {
<bgp> {
<group inactive="inactive"> {
<name> foobar;
}
}
}
}
var $connection = jcs:open();
var $results := { call jcs:load-configuration( $connection, $configuration = $config-change ); }
if( $results//xnm:error ) {
for-each( $results//xnm:error ) {
<output> message;
}
}
var $close-results = jcs:close($connection);
The above was easily found by just doing something like "show configuration protocols bgp | display xml" on the CLI. However, what I wasn't able to find was how to activate the section, again:
var $config-change = <configuration> {
<protocols> {
<bgp> {
<group active="active"> {
<name> foobar;
}
}
}
}
var $connection = jcs:open();
var $results := { call jcs:load-configuration( $connection, $configuration = $config-change ); }
if( $results//xnm:error ) {
for-each( $results//xnm:error ) {
<output> message;
}
}
var $close-results = jcs:close($connection);
The active="active" piece was all that was needed.
I really would prefer to code op scripts in Perl or Python but I don't think I have much of an option when calling them from event-options. Oh well.
I'm a little puzzled. Every year or two (uh, or three) I have a physical and get my cholesterol taken. It's constantly going down, which I suppose is a good thing and an indication my diet is not horrible:
This year, though, my HDL levels are lower than they should be. According to my doctor, they should be 40 mg / dL for men. Mine is now 38 mg / dL.
I've heard people say I should quit smoking, exercise, and keep my mass down. I can't quit smoking because I never started. I swim 2,600 yards ~3 three times per week and, at least according to Garmin Swim, burn 500+ calories every time. I jog 45-50 minutes every 2-3 weekends. I suppose I could improve on this, since I used to swim 4-5 times per week. I think my mass is fine.
Other folks have told me to start taking fish oil. To be honest, I thought taking fish oil was intended to lower cholesterol for folks who are in the severe red. I eat fish once or twice a week (mmm.. salmon and tuna), but apparently even if I ate fish every day it wouldn't be sufficient.
What does everyone else think? I'll have to admit I have done very little empirical research on this topic.
I finally decided to upgrade dax from FreeBSD 8.3-RELEASE to 9.1-RELEASE while stepping through 9.0-RELEASE. As alawys, I hit a snag.
When stepping through 9.0-RELEASE to get to 9.1-RELEASE (I'm not sure if this is really required but I figured it wouldn't hurt) I ran into a nasty situation with the VirtualBox kernel modules. Specifically, the kernel module vboxnetflt.ko in the 4.2.16 version of VirtualBox causes the FreeBSD kernel to panic before it's even mounted the root file system:
[.. output trimmed ..]
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
coretemp0: <CPU On-Die Thermal Sensors> on cpu0
coretemp1: <CPU On-Die Thermal Sensors> on cpu1
coretemp2: <CPU On-Die Thermal Sensors> on cpu2
coretemp3: <CPU On-Die Thermal Sensors> on cpu3
Timecounters tick every 1.000 msec
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xc
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80cb2717
stack pointer = 0x28:0xffffffff80d17ab0
frame pointer = 0x28:0xffffffff80d17ad0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff804d752e at kdb_backtrace+0x5e
#1 0xffffffff804a20e7 at panic+0x187
#2 0xffffffff806e9140 at trap_fatal+0x290
#3 0xffffffff806e9489 at trap_pfault+0x1f9
#4 0xffffffff806e994f at trap+0x3df
#5 0xffffffff806d3def at calltrap+0x8
#6 0xffffffff80c94c52 at supdrvCleanupSession+0x52
#7 0xffffffff80c94ee1 at supdrvCloseSession+0x11
#8 0xffffffff80c9622b at supdrvIDC+0x10b
#9 0xffffffff80cf3ee6 at supR0IdcNativeCall+0x16
#10 0xffffffff80cf40a0 at SUPR0IdcClose+0xa0
#11 0xffffffff80cf3809 at vboxNetFltInitIdc+0x79
#12 0xffffffff80cf3857 at vboxNetFltInitGlobalsAndIdc+0x27
#13 0xffffffff80cf312b at vboxnetflt_modevent+0x3b
#14 0xffffffff80cfb634 at ng_mod_event+0x44
#15 0xffffffff804912c8 at module_register_init+0xb8
#16 0xffffffff80456ac7 at mi_startup+0x77
#17 0xffffffff8027177c at btext+0x2c
Uptime: 2s
Automatic reboot in 15 seconds - press a key on the console to abort
--> Press a key on the console to reboot,
--> or switch off the system now.
Rebooting...
As a result, dax was stuck in an endless reboot for 15-20 minutes as I drove home, since I did the upgrade while mobile. It also took me awhile to figure out how to not load the vboxnetflt.ko at boot since I only had access to the loader prompt. The disable-module directive didn't seem to work:
OK lsmod 0x200000: /boot/kernel/kernel (elf kernel, 0xa46fb0) modules: x86bios.1 io.1 ufs.1 kernel_mac_support.4 [.. trimmed ..] 0xc47000: /boot/kernel/linux.ko (elf obj module, 0x45078) modules: linux.1 0xc8d000: /boot/kernel/accf_http.ko (elf obj module, 0x17d0) 0xc8f000: /boot/kernel/coretemp.ko (elf obj module, 0x29e0) 0xc92000: /boot/modules/vboxdrv.ko (elf obj module, 0x59c40) modules: vboxdrv.1 0xcec000: /boot/modules/vboxnetadp.ko (elf obj module, 0x5bf0) modules: vboxnetadp.1 0xcf2000: /boot/modules/vboxnetflt.ko (elf obj module, 0x7568) modules: vboxnetflt.1 0xcfa000: /boot/kernel/netgraph.ko (elf obj module, 0x15440) modules: netgraph.12 OK disable-module vboxnetflt vboxnetflt was not found OK disable-module /boot/modules/vboxnetflt.ko /boot/modules/vboxnetflt.ko was not found OK disable-module vboxnetflt.1 vboxnetflt.1 was not found
It would always load vboxnetflt.ko, for some reason. Apparently the trick was to unload all modules, load the kernel manually, and then boot. These steps got the system up and running again. The first thing I did was rename vboxnetflt.ko, of course.
I'm hoping this problem is fixed in 9.1-RELEASE, which I don't have time to mess with now but I'll probably get to tomorrow evening. I wasn't able to find much via web searching related to this type of problem, unfortunately. I can't be the only one encountering this, can I?
Update: It looks like taking the vbox* modules out of loader.conf and loading them after the OS is started fixes the problem. For some reason vboxnetflt.ko freaks out when loaded at boot. Instructions here are good to follow, too.
We all know by now that the Nexus 4 sports an LTE radio that is unsupported and has recently been disabled by Google. However, it does work if you enable it. Should you bother, though?
I'll try to answer that question, given I've spent a few days with it in two locations (Herndon, VA and Charlotte, NC) on T-Mobile.
First, the radio will only work with the 2.0.1700.33 radio firmware, which is the original firmware that was installed on my Nexus 4. This radio firmware works fine with Android 4.2.2, even though it was originally released in 4.2.1. Although most people will say that radio firmwares aren't tied to specific Android versions, I've encountered at least one situation where this wasn't the case - so, beware. This radio firmware can be downloaded from here.
Second, the radio only supports E-UTRA band IV. This is AWS, with a center frequency of 1700 MHz. Here's a handy list of all frequency bands used by the air interface of LTE, E-UTRA. As a result, you'll be able to use it with T-Mobile USA, among other things.
Third, lots of things don't work. This is hardly shocking news, since the darn thing is unsupported. Here's a short list:
Other than the above, it does work. If you decide to use it, be aware that the FCC has technically not approved the Nexus 4 for LTE operation and you'll most likely have to stick with the 2.0.1700.33 radio and some sort of unofficial Android build (CyanogenMod works) forever.
I recently went on a nice vacation in the Punta Cana area of the Dominican Republic.
I stayed at the Riu Palace Punta Cana, an all-inclusive resort on the beach. It was the first time I've stayed at an all-inclusive resort so it took awhile to get used to the fact that yes.. everything is included. The beach scene was fairly idyllic:
On the last day I took an excursion, which involved Snuba and driving a speed boat. The Snuba experience was pretty fun but it's too bad there wasn't much to see in the area where we were. Driving (piloting?) the speed boat was an interesting experience, one I would like to do again, given the opportunity!
One odd thing about the resort was its Internet connectivity. There was included Wi-Fi powered by a bunch of what looked to be WDS repeaters on a flat 172.21/16 IPv4 network uplinked to a single MikroTik router with several low-speed Internet connections a few hops away. As a result, it was horribly slow - I couldn't even break 1 Mbps. Here's some CDP from the wire showing the repeaters:
00:23:02.907300 CDPv1, ttl: 120s, checksum: 376 (unverified), length 70 Device-ID (0x01), length: 10 bytes: 'NANO1PCANA' Address (0x02), length: 13 bytes: IPv4 (1) 172.21.255.250 Capability (0x04), length: 4 bytes: (0x00000002): Transparent Bridge Version String (0x05), length: 9 bytes: XM.v5.5.2 Platform (0x06), length: 3 bytes: 'N2N' Port-ID (0x03), length: 3 bytes: 'br0'
The MikroTik router appeared to round-robin sessions through all of the Intenet connections, which resulted in my source IPv4 address changing constantly. Since the Wi-Fi was not encrypted, I was connected via a VPN most of the time, which reconnected every 5-10 minutes. I guess that is the cheap way of getting more bandwidth - I suspect the Internet connections were just low-speed DSL links instead of something more robust.
I managed to snag some bandwidth statistics from the MikroTik router through just following unauthenticated HTTP links:
The above is from the one "LAN" interface on the MikroTik box. There wasn't too much traffic considering the resort is pretty large. I guess the Internet connectivity was too slow that nobody bothered with it (or they were doing more vacation-ish things).
Anyway, I took a bunch of photos with my Nexus 4, Canon 60D, and GoPro HERO3. The HERO3 actually performed admirally during the Snuba and speed boat appearance considering I had 720p@60 video running most of the time. I was concerned the battery would die, but it didn't. One thing that sucked, though - I switched the video mode to 1080p@24 to get some more detail and was sorely disappointed when I played it back. For some reason the video exhibited very poor tearing like it was taken with 5-year old cellphone. I recall that didn't happen at 1080p@60, though. So, for some reason that low frame rate introduces some buffering problems on the HERO3.
Displaying page 7 of 121 of 965 results
     |
This HTML for this page was generated in 0.006 seconds. |