Who said that?

My wife and I had run out for errands and had stopped at a D'Angelo sub shop. We were just about to get out of the car when the phone rang. My wife rolled her eyes but I took the call because, well, because that's what I do. Somebody has a problem, I try to answer the phone.

This was a long time customer. He explained that he had someone that needed remote access to an aplication running on port 7000 on a SCO machine. He said it was working fine within his office, but that he couldn't get remote access working. We did the usual things: telnet localhost 7000 (yup, that connected), ssh out to another box and try telnet back on 7000 (which just hung). I asked him to double check his router, and he did, but still no luck.

"Oh wait a minute,", I said, "you said this was a SCO box? You mean that old test box you've had for years?"

This guy sells accounting software and some of his customers still run on SCO. Most of them use Linux now, but he keeps the SCO up and running for testing and support. But I was pretty sure that box had never been connected to the internet.

"You need a default route. Packets can get to it, but it doesn't know how to send them back."

This comes up fairly frequently. It also happens sometimes with remote TCP printers: if you haven't given them a gateway address, they can't communicate back to you. Packets need routes.

But why? That's what my caller wondered. Why doesn't it just figure out where to send the packets?

Well, for starters, the only machines any box can talk to are machines on its local physical lan. So obviously it needs to send any other packets through a router. Is it supposed to guess where the router is?

No, of course not. Either somebody tells it (route add) or it finds out through some protocol like router broadcasts. But if it doesn't have either of those advantages, it's blind and dumb.

But is it really? Let's look at some tcpdump output.

On my Mac, I first ssh'ed to a local (on my network) Linux box. In another Window on the Mac, I typed "sudo tcpdump -e host redhat1". Over on the Linux box, I simply tapped the space bar (to avoid a lot of packets). Here's the result:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 96 bytes

07:55:59.946527 00:16:cb:8d:48:f7 (oui Unknown) > 00:c0:f0:6b:b4:18
(oui Unknown), ethertype IPv4 (0x0800), length 114: 192.168.4.21.50050
> redhat1.ssh: P 1320087778:1320087826(48) ack 1103513747 win 65535

07:55:59.947496 00:c0:f0:6b:b4:18 (oui Unknown) > 00:16:cb:8d:48:f7
(oui Unknown), ethertype IPv4 (0x0800), length 114: redhat1.ssh >
192.168.4.21.50050: P 1:49(48) ack 48 win 10336 
07:55:59.947565 00:16:cb:8d:48:f7 (oui Unknown) > 00:c0:f0:6b:b4:18
(oui Unknown), ethertype IPv4 (0x0800), length 66: 192.168.4.21.50050
> redhat1.ssh: . ack 49 win 65535 
 

Those hex digits following the date on each line should look familiar to you: those are MAC addresses. One of them is the address of the MacBook itself (00:16:cb:8d:48:f7) and the other is the RedHat box. Specifically, if I run "arp -a", I can see that, yes, that Mac address matches redhat1:

$ arp -a
redhat1 (192.168.4.237) at 0:c0:f0:6b:b4:18 on en0 [ethernet]
router (192.168.4.249) at 0:8:0:c0:fa:4 on en0 [ethernet]
$ 
 

Now what about if I go somewhere off-lan?

$ sudo tcpdump -e host website    
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 96 bytes

07:57:51.020660 00:16:cb:8d:48:f7 (oui Unknown) > 00:08:00:c0:fa:04
(oui Unknown), ethertype IPv4 (0x0800), length 106: 192.168.4.21.50027
> website.ssh: P 3652278386:3652278426(40) ack 193102205 win 65535

07:57:51.057326 00:08:00:c0:fa:04 (oui Unknown) > 00:16:cb:8d:48:f7
(oui Unknown), ethertype IPv4 (0x0800), length 106: website.ssh >
192.168.4.21.50027: P 1:41(40) ack 40 win 16752 
07:57:51.057409 00:16:cb:8d:48:f7 (oui Unknown) > 00:08:00:c0:fa:04
(oui Unknown), ethertype IPv4 (0x0800), length 66: 192.168.4.21.50027
> website.ssh: . ack 41 win 65535 
 

If you look carefully at those, you see that the packets are identified as coming from my router ( 0:8:0:c0:fa:4). We'd expect that - that is the only place they could come from.

So, back to our port 7000 problem. If the SCO box knows where the packets come from, why doesn't it just use that knowledge to route them back?

Well, I suppose it could. Someone could write an IP stack that configured routes from level 2 header information when there was nothing better to go by. That's pretty much what a switch does for its ports. I wouldn't want that feature on a computer, though: I like to be able to tear down routing entirely when I want to.

So I guess the answer to "Why?" is just "Because that's the way it is. Add the route, and my wife and I will go split a sub."

3 comments

More Articles by Anthony Lawrence - Find me on Google+

Click here to add your comments




Sat Apr 8 15:44:07 2006:   BigDUmbDinosaur


Add the route, and my wife and I will go split a sub."

That wouldn't work with my wife. She'd want the entire sub and I'd get nothing -- unless it was a really big sub. <Grin>



Sat Apr 8 17:35:38 2006:   TonyLawrence


We don't eat much usually.. a large sub is more than enough for both of us. Keeps the costs down too. She takes a third, I take the rsst, we share a juice.





Sun Apr 9 04:48:42 2006:   BigDumbDInosaur


Actually, we aren't real big eaters either (pun intended). I was just kidding about my wife hogging a sub. She does do a number on the (sugar-free) cookies, though. We're both type II diabetics, so we actually watch our diets pretty carefully. We eat a lot less red meat than in the past, and a lot more fish and poultry. Dunno that it'll make either of us live any longer, but it can't hurt.

Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.