Anyone who knows me in person knows that I play darts. I’m proud to say that we won our division last year. This was a rea real accomplishment for me, it’s the first time I’ve won as Captain. The one flaw in this victory was pointed out by my friend Pete. At the final Captain’s meeting he congratulated me but then asked why I didn’t play a single leg in the finals. Well, the answer is that I spent the last three weeks of the regular season and all of the playoffs concetrating on winning. My team has made it to the playoffs with a good seed every season. We’ve made it to the finals three times. In each of those failed trips to the playoffs and finals I got out Captained. The other teams were usually better than us but not so much so that we would fail so easily. This was especially true last fall. The other team was good, (a special shout out to Gee) but even if we lost we should have had more points at the end of the night.
Concentrating so much on not getting out played at Captain cost me my focus on my game. I knew it during the finals. It really hit home at the last regional qualifier that I played. I think that I need to be where I was two or three years ago. For some reason I’ve gotten it into my head that I don’t need to practice at darts to be good in league. My friend Garry says that if I praticed I’d be deadly. Let’s see if he’s right….
I rode my bike today. It was the first time in a while which is bad. I went from Home to the yacht club to the beach and then back home. Maybe it was 10 miles. I’m gonna check with Google Earth later. I’m a little tired right now. Once I got to the yacht club I tried to figure out if I had spent 1/3 or 1/2 of my energy. I guess I was between 1/2 and 1/3 and figured that the extra three miles to Silver Sands Beach would probably fit in. I was barely right. Still you have sto stretch yourself once and again.
Life gives us constant reminders to go back to basics and in the computer world it’s no different. My laptop has two network interfaces built in, an intel gigabit interface that FreeBSD calls em0, and an intel 802.11b wifi interface that FreeBSD calls ipw0. Usually I need either the gigabit interface or the wifi interface. I’ve never needed both. When I move about the house I sometimes have to switch in between them. The architecture of my network makes that a little more complicated and when I switch without rebooting I have to remember to get back to basics or I could waste some serious coffee time.
It’s the network dummy
My network is a logical cidr/23 divided into two physical cidr/24’s by an OpenBSD bridge which does packet filtering. That gives me the classic firewall spaces: a DMZ network connected directly to the internet and a protected network which is behind both the filter on the internet gateway and the DMZ filter. Using a bridge allows me to make the DMZ filter transparent. As far as a node on the protected network is concerned there it’s on the same switch as the hosts that it talks to in the DMZ. If a host in the DMZ tries to connect to something in the protected network it only passes if the filter allows it. When the connection is blocked the filter responds as though the port is closed on the protected client.For most clients this design is pretty simple. They see a single LAN with a router that gets them to the internet. It’s nice from the outside also. I can build an IPSec tunnel to a partner without seriously compromising the security of my protected LAN. But the lesson here is that hidding complexity does have a cost.
The problem always starts the same way. I unplug the ethernet cable from my laptop. FreeBSD stops dhclient from running on the em0 interface but leaves the interface running. This is just in case I’m running downstairs to plug in at a different jack. Instead I load the kernel module for the ipw interface and then configure it with my WEP keys and fire off a new dhclient. The Dhclient finds the server, modifies the DNS configuration, and silently fails in the attempt to modify the routing table. Dhclient stalls in the protocal waiting for a packet and I think that it’s some sort of transient. Now’s the time to go back to basics.
Debugging simple ip connection problems.
I’ve moved to place where there isn’t a wired jack, switched from wired to wifi and my internet connection no longer works. Firefox gives me the “I can’t find your server screen.” Try these before a reboot.
- Start from the inside:Â Is the configuration correct on the wifi card? Check with ifconfig:
$ ifconfig ipw0
ipw0: flags=8843 mtu 1500
inet6 fe80::204:23ff:fe7a:c9d2%ipw0 prefixlen 64 scopeid 0x6
inet xxx.yyy.zzz.67 netmask 0xfffffe00 broadcast xxx.yyy.zzz.255
media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps)
ssid Vindaloo-WVLAN channel 10 bssid 00:04:5a:0f:34:fe
authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit wepkey 2:104-bit
wepkey 3:104-bit wepkey 4:104-bit txpowmax 100 bintval 100
Ok, that looks good.
- Cut out the resolver:Â The best thing one can do when trying to isolate tcp/ip connection problems is to cut out the resolver early in the process and come back to it when you know the lower levels are correct. We treat name resolution like its a part of the media (layer 2) but it’s not. The name resolver is an application (layer 7) and it’s subject to failure in all of the lower levels.
Memorize the addresses of a few hosts both on the internet and on the LANs that you connect to. When testing ping by address if pinging by name doesn’t work. Also be aware of the resolver’s timing. If something takes exactly 1 minute 15 seconds to fail your resolver configuration is probably corrupt.
In my case ping of all addresses failed.
- Really check the configuration:Â Understand that the configuration check in the first step was lightweight. If ifconfig says everything is all right the next place to look is probably the route table. In my case running the route program would have shown that the kernel was trying to get packets to the network through the em0 interface which is marked down but still has a route for my network. This happens on my network because the wifi network and the wired network are the same.
The DMZ gateway here becomes a single point of failure and that creates a rather big downside. The problem isn’t that if the DMZ fails that the clients can’t get to the internet. In that case discovering what the problem is will be easy. So having reliable hardware at that point will be critical. In the worse case that box is only a patch cord with filtering anyhow. The insideous problem is that your network has two protection plateaus: a somewhat protected DMZ; and a somewhat more protected plateau for clients and insecure services like smb/cifs. If you are thinking about security and you have this as your infrastructure there will be a great and proper temptation to locate some very useful services on the protected network. That generates more holes in your filter and means that even more is lost if the filter fails.
My Waterloo: LDAP
When I first met LDAP, the database that really isn’t a database, I turned my nose up at it. In my applications software engineering world the relational database was the Shangri-La of storage. From where I sat LDAP looked like an overcomplicated, X.500 based steaming pile of cruft. But as buzzwords go LDAP wasn’t going away. So in early October of 2001 on a somewhat nervous plane ride from Newark, NJ to San Diego, CA, I decided to use the incommunicato 6 hours flight to get to know openldap. After a couple of days I got the point where I could put data into the LDAP box, search for it and take it out but not much more. The problem of the day was authentication. Everyone did authentication differently which meant that every user had one a set of credentials for each application. And the help desk spent most of it’s time reaquanting people with those credentials. Furthermore every application had to have functions committed to updating those credentials. It was obvious then that this situation was not optimal. If you people to be in-secure the best way to go about it is to make security difficult for the users. My personal problem had to do with managing users on a Samba server. To change a password I had to log into a shell, su to root, and then use passwd program with the user present. I was also managing several web applications. One of these managed authentication and hashed it’s passwords into a relational database. In the long run this was just way too much work. The second problem is that nearly no one does authentication right. Back when I was a pup playing with AIX in Chicago I was a huge advocate of rsh instead of telnet. And the one reason that I liked rsh was because it didn’t pass your password in the clear on the ethernet hub environment of the time. And we did get cracked and the cracker got everyone’s password in the building except mine. Now we have switches, but we also have wifi, and we have ssh which puts the entire argument to bed. But eleven years later in 2006 when people write a new application and design their own authentication the best that they can come up with still passes a password on the wire. Thankfully most applications are smart enough to at least use SSL for that part of the transaction.
Welcome to the ~chris. Now is probably a good time for me to admit that doing this with wordpress would have been the right way to do this at the beginning. I’m a software engineer who works with open source systems. This journal is a place for me to write about some of the things that I’ve been doing with open source. My goal is to get to a level of detail that allows you, the reader, to be able to take on the same projects.
I’m old school as far as open source is concerned. I don’t mind using the source code and would rather not play with binaries. This probably comes from the fact that I’m a developer first and a sysadmin second so I’m comfortable with C/C++, make, etc. That preference leads me to use FreeBSD on i386 and NetBSD on sparc/sparc64 as my operating systems of choice. In most cases the descriptions here should be okay even if you prefer Linux but you may have to get your hands dirty on the occasional source rpm.