Blargh

Recently some time ago (this blog post has also been lying in draft for a while) someone came to me with a problem they had with a Cisco 7600. It felt sluggish and "show proc cpu" showed that the weak CPU was very loaded. This is how I fixed it. "show proc cpu history" showed that the CPU use had been high for quite a while, and too far back to check against any config changes. The CPU use of the router was not being logged outside of what this command can show. "show proc cpu sorted" showed that almost all the CPU time was spent in interrupt mode. This is shown after the slash in the first row of the output. 15% in this example: Router# show proc cpu sorted CPU utilization for five seconds: 18%/15%; one minute: 31%; five minutes: 42% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 198 124625752 909637916 137 0.87% 0.94% 0.94% 0 IP Input [...] ...

I had this blog post lying around as a draft for a long time. I didn't think it was was "meaty" enough yet, but since I'm no longer a network consultant I don't think it'll become any meatier. So here it goes. Here I will describe the process of L3-to-L2 mapping, or next-hop resolution and how it works with point-to-point circuits like PPP, ATM and Frame relay. It's the process of finding out what to actually do with a packet once the relevant routing table entry has been identified. It's deceptively simpler than on a LAN segment, but since people generally learn Ethernet before they learn point-to-point nowadays I'm writing it anyway. When a packet is to be sent to an address on the same subnet a L3-to-L2 mapping is done to look up the L2 destination address (if any) to apply. The packet is then encapsulated in a L2 frame and sent out the interface. On a normal Ethernet LAN segment ARP is use...

Go has exceptions and return values for error Yes it does. Yes, it really really does. We can discuss this for hours but in the end it boils down to four points: In Go some errors cause stack unrolling, with the possibility to for each step in the call stack register code that runs before the stack is unrolled further, or for the unrolling to stop. In programming languages, that's called "exceptions". Idiomatic use in a language of the feature doesn't affect what the feature is . Saying that Go doesn't have exceptions is like saying Go doesn't have NULL pointers (it has nil pointers). There is no non-tautology definition of exceptions that includes the ones in Python, C++ and Java, but does not include panic/rescue in Go. Go on, try to language lawyer your way into a definition. In spoken/written lang...

I'm a big fan of hardware tokens for access. The three basic technologies where you have public key crypto are SSH, GPG and SSL. Here I will show how to use a Yubikey NEO to protect GPG and SSH keys so that they cannot be stolen or copied. (well, they can be physically stolen, of course). Let's hope pkcs11 support is coming, so that SSH support improves and SSL keys can also be protected. Parts of this howto are all but copied from YubiKey NEO and OpenPGP . I complete it with some details and the SSH parts. GPG GPG normally keeps your private key encrypted using your password. If your keyring is stolen someone can brute force your password and from there decrypt all your files. If someone steals your keyring you should revoke the key as soon as possible, but assuming this revokation gets to all interested parties this will only protect new messages from being encrypted to this key. Old encrypted files could be decrypted by ...

Last time I was at a hacker conference I for obvious reasons didn't want to connect to the local network. It's not just a matter of setting up some simple firewall rules, since the people around you are people who have and are inventing new and unusual attacks. Examples of this would be rogue IPv6 RA and NDs, and people who have actually generated their own signed root CAs. There's also the risk (or certainty) of having all your unencrypted traffic sniffed and altered. For next time I've prepared a SheevaPlug computer I had laying around. I updated it to a modern Debian installation, added a USB network card, and set it up to provide always-on VPN. This could also be done using a raspberry pi, but I don't have one. Always-on VPN is where you have NO network access unless your VPN is up, and then ALL traffic goes through the VPN. By setting up a plug computer as a VPN client you can just plug in an unprotected computer ...

To properly compile a static C++ binary on Linux you have to supply -static , -static-libgcc and -static-libstdc++ when linking. That's fucked up. Never EVER think that linking (at link time or runtime) is easy or obvious. I link my current pet project with: g++ -Wl,-z,now -Wl,-z,relro -pie -static-libstdc++ The binary then seems to work across the systems I currently want to run it on. Specifically it makes me able to run the binary compiled on Debian Testing on a Debian Stable installation. Skipping that whole dynamic libraries thing is something Go got right. Update: some clarification on why you'd want to compile statically Let's start with the reason for wanting to compile static in the first place. While shared libraries are better in some aspects, "save RAM" is no longer a good reason for always compiling dynamically. There are reasons why you'd want dynamic linking still, ...

A few months ago I was strolling in the Debian bug tracking system and found a curious bug filed against Arping , a program I maintain. It said that unlike Arping 2.09, in Arping 2.11 the ARP cache was not updated after successful reply. I thought that was odd, since there's no code to touch the ARP cache, neither read nor write. Surely this behaviour hasn't changed? I tried to reproduce the behaviour and sure enough, with Arping 2.09 the arp cache is updated, while with 2.11 it's not. $ arp -na | grep 192.168.0.123 $ # --- First try Arping 2.11 --- $ sudo ./arping-2.11 -c 1 192.168.0.123 ARPING 192.168.0.123 60 bytes from 00:22:33:44:55:66 (192.168.0.123): index=0 time=1.188 msec --- 192.168.0.123 statistics --- 1 packets transmitted, 1 packets received, 0% unanswered (0 extra) $ arp -na | grep 192.168.0.123 $ # --- Ok, that didn't change the ARP cache. Now try 2.09 --- $ sudo ./arping-2.09 -c 1 192.168.0.123 ARPI...