Wednesday, October 21, 2009

Howto get your windows boot option back after grub2/Squeeze nukes it!

I hate bootloaders, they either work fine, or they're a royal pain. And just when I was really starting to understand grub, they go ahead and release grub2. I mistakenly upgraded to grub2 on my desktop a while ago, and learned that grub2 has a tendency to forget about Windows. This was irritating, but not the end of the world, I just didn't use windows for almost a year.

More recently, Debian Squeeze didn't give me much of a choice about installing grub2, and promptly disappeared Windows on my notebook. This got me doing a little more digging to figure out why a "new and improved" version of grub would actually be less capable. Could this be some stallmanesque scheme to force me into the freedom orgy?

Nope, something far less insidious. Apparently there is now an extra package that grub2 requires to find operating systems besides linux. That package is os-prober. So if you've pwned your windows install like I did, just do an 'apt-get install os-prober', then run 'grub-update'. Your Windows option will magically reappear!

Saturday, October 10, 2009

Cisco ICMP6 strange behavior on neighbor solicitations.

I noticed some strange behavior while I was playing with IPv6 on my Cisco lab. I have a Debian server hanging off one of the router interfaces acting as a name server. I found that I could ping and resolve against the name server from the router that is directly attached. However, if I try to ping or resolve from a router further away I get no luck. After I corrected the prefix length on the name servers route to the lab network (off by one bit) I still had no luck; even though I could ping another Debian box on the same subnet without a problem. A little investigation with tcpdump yielded this:

11:23:19.360378 IP6 fe80::215:63ff:fe56:cf1d > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:4978:34a::1, length 32
11:23:22.315487 IP6 2001:4978:34a::ff > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:4978:34a::1, length 32
11:23:22.315645 IP6 2001:4978:34a::1 > 2001:4978:34a::ff: ICMP6, neighbor advertisement, tgt is 2001:4978:34a::1, length 32

What we have here are two NDP Neighbor Solicitation messages. Both messages come from the edge router on the Cisco lab. The first message was sent when I pinged from inside the lab network; the second was sent when I pinged from the edge router directly. The difference is that when the edge router needed the name server MAC address for the routed packet it used its link local address. When it needed it for its own packet it used the global unicast packet on the interface. Why does this make a difference? Because the default INPUT policy on the name server ip6tables is DROP, and I had not thought to explicitly allow the link local subnet, causing the first neighbor solicitation to be dropped.

Repeating the experiment, this time pinging from the edge router first, both routers' pings succeed, since by the time the inside routers packets come through there is already a neighbor/ARP entry.

I'm not sure why Cisco would do things this way, maybe there is a logical reason. Maybe it is a bug and no one does goofy things like I do so it has gone unnoticed. Maybe it has been corrected in a more recent version of firmware (the edge router runs 1841 Software (C1841-ADVIPSERVICESK9-M), Version 12.4(12)).