APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Who said that?

© April 2006 Anthony Lawrence

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:
> 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 > 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:
> 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 ( at 0:c0:f0:6b:b4:18 on en0 [ethernet]
router ( 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:
> 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 > 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:
> 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."

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Who said that? Router forwarding and default routes


Inexpensive and informative Apple related e-books:

Take Control of iCloud

Take Control of Preview

Take Control of OS X Server

Take Control of iCloud, Fifth Edition

Are Your Bits Flipped?

More Articles by © Anthony Lawrence

Sat Apr 8 15:44:07 2006: 1876   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: 1877   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: 1878   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.


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

There are only two things wrong with C++: The initial concept and the implementation. (Bertrand Meyer)

Linux posts

Troubleshooting posts

This post tagged:



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode