(fwd) Odd problem with new Apple...

Wed Feb 5 10:59:34 PST 2003

Can someone help Jon?  [Please reply to him, or Cc him on replies--he's
not on the baylisa list.  Thanks!]

----- Forwarded message from "J. Lasser" <jon at lasser.org> -----

Date: Wed, 5 Feb 2003 12:24:48 -0500
From: "J. Lasser" <jon at lasser.org>
To: DC SAGE <dc-sage at dc-sage.org>
Subject: [dc-sage] Odd problem with new Apple...
User-Agent: Mutt/1.4i
Reply-To: "J. Lasser" <jon at lasser.org>

Wondering if anyone else has run into this yet... or if I'm missing
something obvious...

Our story:

We have a PowerBook 12" with an Airport Extreme card installed that
can't access the Internet via wireless.

We have a slightly complicated network:  Attached to our wireless
hub we have a 10baseT hub. Attached to that 10baseT hub is a Turtle
Beach Audiotron and a network cable. When the network cable is
plugged into the Powerbook, it picks up a DHCP address and talks
on the 'net without incident.

Our subnet is 216.181.177.184/255.255.255.248. Our gateway to the
Internet is 216.181.177.185, which is another box on the wireless
network. Other systems can access the gateway, and hence the
Internet, without incident. When we're hooked up with a wire, we
have no problem. But it doesn't seem happy with the wireless.

The laptop has worked fine via wireless on at least one other
wireless network. That network used a Linksys WAP11 wireless hub.
My network used a Netgear ME102, though I swapped that out for a
Linksys BEFW11S4 with no change in behavior. (An incompatibility
there was my first guess...)

We have freshly rebooted the system, though these problems occurred
before that reboot as well.  We have our default-DHCP-has-failed
IP address from OS X, but nothing else. Our signal meter shows all
bars, and our correct wireless network is selected.

Let's see what happens when we try to ping something else on the
wireless network:

> This is our TCPDump Window

>> This is our other terminal

> [jon at gumball jon]$ sudo tcpdump -v -i en1
> Password:
> tcpdump: listening on en1

>> [jon at gumball jon]$ ping 216.181.177.190
>> PING 216.181.177.190 (216.181.177.190): 56 data bytes

> 11:08:26.744487 arp who-has 216.181.177.190 tell gumball.local
> 11:08:26.748550 arp reply 216.181.177.190 is-at 0:4:32:0:1d:34

OK, so ARP is working...

> 11:08:26.748596 gumball.local > 216.181.177.190: icmp: echo request (ttl 255, id 3416, len 84)
> 11:08:26.752732 216.181.177.190 > gumball.local: icmp: echo reply (ttl 32, id 52424, len 84)

We send the request; the reply is sent.

>> 64 bytes from 216.181.177.190: icmp_seq=0 ttl=32 time=8.683 ms
>> 64 bytes from 216.181.177.190: icmp_seq=1 ttl=32 time=4.65 ms

We see the packets, and report them as delivered.

> 11:08:26.775745 snap 0:0:f8:8:0 216.181.0.17 > 216.181.177.190: icmp: host gumball.local unreachable (ttl 252, id 6872, len 56)

Someone upstream reports that they can't route the packets to our
imaginary Apple-provided IP address...

> 11:08:27.200422 gumball.local.49155 > 224.0.0.251.5353: [udp sum ok] udp 46 (ttl 255, id 3426, len 74)
> 11:08:27.201158 gumball.local.5353 > 224.0.0.251.5353: udp 67 (ttl 255, id 3428, len 95)

Mysterious Apple traffic that I don't know what it means.

> 11:08:27.744703 gumball.local > 216.181.177.190: icmp: echo request (ttl 255, id 3439, len 84)
> 11:08:27.749219 216.181.177.190 > gumball.local: icmp: echo reply (ttl 32, id 52680, len 84)

More of these until we stop our ping process.

Now let's ping 216.181.177.185.  That machine is our Internet gateway,
DHCP server, file server, etc. The .185 address is its wireless card.
(It has a non-wireless address of .177, but that's a different subnet.)

>> [jon at gumball jon]$ ping 216.181.177.185
>> PING 216.181.177.185 (216.181.177.185): 56 data bytes

> 1:12:06.361116 arp who-has 216.181.177.185 tell gumball.local
> 11:12:06.535906 snap 0:0:f8:8:6 arp reply 216.181.177.185 is-at 0:2:2d:8:58:99
> 11:12:06.536845 snap 0:0:f8:8:6 arp reply 216.181.177.185 is-at 0:2:2d:8:58:99
> 11:12:07.361340 arp who-has 216.181.177.185 tell gumball.local
> 11:12:07.457486 snap 0:0:f8:8:6 arp reply 216.181.177.185 is-at 0:2:2d:8:58:99
> 11:12:07.458719 snap 0:0:f8:8:6 arp reply 216.181.177.185 is-at 0:2:2d:8:58:99

[ . . . several more of these . . . ]

So .185 is sending out its ARP. It's arriving at our PowerBook. But our network stack isn't really happy to deal with it.

> 11:12:35.335616 0.0.0.0.bootpc > 255.255.255.255.bootps:  xid:0x328f9bb0 file ""[|bootp] (ttl 255, id 16480, len 328)

This is our box, requesting a DHCP address. I've not asked for one, so
presumably it's just something that happens at intervals...

> 11:12:35.415966 snap 0:0:f8:8:6 arp who-has 216.181.177.187 tell 216.181.177.185
> 11:12:35.721286 snap 0:0:f8:8:6 arp who-has 216.181.177.187 tell 216.181.177.185
> 11:12:36.405988 snap 0:0:f8:8:6 arp who-has 216.181.177.187 tell 216.181.177.185

Our server pings a potential address; nobody responds. Good, the server can hand this address out.

> 11:12:36.416478 snap 0:0:f8:8:0 216.181.177.185.bootps > 255.255.255.255.bootpc:  xid:0x328f9bb0 Y:216.181.177.187 S:216.181.177.185 ether 0:3:93:e8:5f:b5 [|bootp] (DF) (ttl 64, id 0, len 328)

The given ethernet address is, in fact, the address of our PowerBook's
Airport Extreme card. So we've been assigned 216.181.177.187.

> 11:12:36.642021 snap 0:0:f8:8:6 arp who-has 216.181.177.187 tell 216.181.177.185
> 11:12:36.643765 snap 0:0:f8:8:0 216.181.177.185.bootps > 255.255.255.255.bootpc:  xid:0x328f9bb0 Y:216.181.177.187 S:216.181.177.185 ether 0:3:93:e8:5f:b5 file ""[|bootp] (DF) (ttl 64, id 0, len 328)
> 11:12:36.796179 0.0.0.0.bootpc > 255.255.255.255.bootps:  xid:0x328f9bb1 secs:1 [|bootp] (ttl 255, id 6248, len 328)
> 11:12:36.952087 snap 0:0:f8:8:0 216.181.177.185.bootps > 255.255.255.255.bootpc:  xid:0x328f9bb1 secs:1 Y:216.181.177.187 S:216.181.177.185 ether 0:3:93:e8:5f:b5 [|bootp] (DF) (ttl 64, id 0, len 328)
> 11:12:37.258038 snap 0:0:f8:8:0 216.181.177.185.bootps > 255.255.255.255.bootpc:  xid:0x328f9bb1 secs:1 Y:216.181.177.187 S:216.181.177.185 ether 0:3:93:e8:5f:b5 [|bootp] (DF) (ttl 64, id 0, len 328)
> 11:12:37.405842 snap 0:0:f8:8:6 arp who-has 216.181.177.187 tell 216.181.177.185
> 11:12:37.563575 snap 0:0:f8:8:6 arp who-has 216.181.177.187 tell 216.181.177.185

[ . . . repeat this a whole lot . . . ]

Unfortunately, though we've seen the packets on the interface, our box
doesn't recognize that it was assigned this address, and doesn't
respond to an ARP (and, presumably, a ping) asking us to confirm our
new address.

Other experiments tried:

I swapped the server's wireless card with one in a laptop here that
I was able to ping. Afterwards, I was still able to ping the laptop
and still unable to ping the server. Both laptop and server run
Red Hat Linux. Both wireless cards were Lucent Orinoco cards of
differing vintages.

I manually put 216.181.177.185 in our ARP table on the powerbook.
Though I saw the echo requests being sent via TCPDump, there were
no echo reply messages. Note that earlier, prior to my
let's-clean-everything-up-for-a-real-test reboot, I *swear* I saw
echo reply messages with this configuration, but (a) the system
didn't report responses to its pings and (b) I'm unable to reproduce
this at present.

I manually set our address and netmask as per our (ignored) DHCP
response. Still able to ping systems on our subnet (both wireless boxes
a la the laptop and boxes plugged into the wireless hub) but not .185.
And so I'm unable to get out to the Internet from the box, as that's our
gateway.

As mentioned far, far above, I swapped my wireless hub with no change.

And, also as mentioned above, the laptop has worked fine on other
wireless networks... I'm at a total loss as to how to proceed. It seems
to me that it's something at the kernel level: we're seeing the packets
on the interface when we run TCPDump (yes, the problems also occur when
we're not monitoring the network), but the system isn't processing them
properly --- we're not taking the DHCP address assigned to us, we're not
even dealing properly with ARP for one host.

The DHCP server shouldn't be the problem, as the same server works fine
when we're plugged into the same subnet. It's not the wireless card in
the one box we can't talk with, since we've swapped that out. It's not a
reception problem, again, as we can see the packets on the local system.
But what is it?

-- 
Jon Lasser	
Home: jon at lasser.org		|    Work:jon at cluestickconsulting.com
http://www.tux.org/~lasser/     |    http://www.cluestickconsulting.com
   Buy my book, _Think_Unix_! http://www.tux.org/~lasser/think-unix/
======================================================================
+ This message was forwarded by the dc-sage at dc-sage.org mailing list +
+ To unsubscribe or make subscription changes, send an E-mail to:    +
+   mladmin at dc-sage.org  with an English description of your request.+
======================================================================

----- End forwarded message -----

-- 
Live in a world of your own, but always welcome visitors.
                                 ***
Come to sig-beer-west!     http://www.extasia.org/sig-beer-west/
Unix sysadmin available:   http://www.extasia.org/resume/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://www.baylisa.org/pipermail/baylisa/attachments/20030205/2e75bd15/attachment.bin>