Probs with AirPort and Cable DHCP Lease Renewals
 

(Forgive me for the below being rather verbose, but I'd rather offer extraneous detail than omit something important.)

I recently noticed a change in the behavior of my wireless Internet access. (Specifically, as of last Sunday, the 17th. It may be important to note that I believe my ISP renews cable modem leases on Sundays, I think.) I tend to think it may be related to my AirPort Extreme base station and not my Internet provider, for reasons described below.

After a prolonged period of time in which the computer has been turned off -- and by this, I mean a period of several hours, such as while I sleep overnight or while I am at work -- my Internet access is seemingly lost. In other words, when I turn on the computer after this time being off, Internet access does not appear.

Now, when I go into the Terminal during this "Internet-less" existence, I appear to still have a connection to my ISP's DNS servers. I say this because I can tell it to ping a website, and 'ping' knows the IP address of that website. (In other words, a 'ping www.google.com' is able to tell me that Google is at such-and-such an IP address.) The 'ping' result does not yield any results -- 100% packet loss -- but it does know IP addresses.

The problem is, oddly enough, solved by going into AirPort Admin Utility. I go to 'Show All Settings' and select the 'Internet' tab, where I change 'Using DHCP' to 'Manually' and back again, and then hit 'Apply Now.' AirPort Admin Utility then uploads the new settings to the AEBS, and Internet access is almost always restored at that point.

I spoke with my Internet service provider (after an excruciatingly long wait of 40+ minutes, punctured with brief silences where I thought someone was going to be picked up only to hear a recorded voice say 'your call is important to us, and we apol... ', etc.), and I actually got someone fairly intelligent and knowledgeable for a change.

This person examined my DHCP leases, and he indicated that it looked as if my AirPort base station was frequently requesting new leases from my cable modem and that the problem might be originating there.

After hearing that, I went back to the Admin Utility, where I did notice that the "DHCP lease" entry on the "Distribute IP addresses" page (forgive me, I'm typing this from work and can't remember the name of the tab) was initially set for its default of four hours. I tried modifying that to 30 days. I got rather hopeful that this was the magic bullet. Unfortunately, it seemingly did not seem to affect things at all.

Any guidelines or troubleshooting for considering whether the AirPort Express Base Station has a mechanical difficulty would be appreciated, too, although I do not believe that is the case.

I would appreciate any and all advice you might offer. If you believe that this question is answered elsewhere, if you would be kind enough to provide a link, I would appreciate it -- there is a staggering breadth of discussion going on here and on the World Wide Web, and it has been quite hard to sift through it for information relevant to this particular problem.

(Also being posted to an Apple Discussions forum thread.)

One thing I am going to try when I get home ... and I would very much appreciate people's correlating advice on this ... is this advice given to someone with a similar problem:

http://forums.macrumors.com/archive/topic/34189-1.html

"Sounds like it might be a DHCP lease issue. You change IP addresses whenever you log in and if you stay connected for a long time your isp probably changes your ip address. If the base station holds onto that ip it won't get any internet. Open Airport Admin Utility and set your DHCP lease to something shorter than what it's at now. I'm thinking this should take care of your problem."

Thoughts?

DHCP lease time
 

When you do that, you are forcing the base station to get a new DHCP lease from your ISP.
The DHCP lease time in the Airport Admin is for the leases that it gives to the computers on your local network. It is nothing to do with the lease that the basestation gets from your ISP. DHCP lease time is usually governed by the DHCP server - not the client. Your basestation acts as a DHCP server for the computers on your local network.

Before going much further, please give us more info on your setup - i.e. are all your computers connected only via Airport? Is the Airport basestation connected directly to your cable modem?

Let's try to get straight whether it is your basestation or your Mac which is having trouble.
When you first open up the Airport Admin utility, it shows you the name and IP address of your basestation. What IP address does it show? Is it a correct IP address as obtained from your ISP?

This may be the case. I do note, however, that the IP address doesn’t appear to be changing most of the time after that happens; the summary screen in Airport Admin Utility usually shows the same IP address.

Forgive me, but I’m slightly confused after reading the above. Does the DHCP server at my Internet service provider give out the IP addresses, or does the base station do that? I would have thought the former.

I have one iBook with an AirPort card in it. I then have one AirPort Extreme Base Station which is hooked via Ethernet cable to a cable modem.

I’m not certain which screen you’re speaking of. There is first a sort of ‘browser’ screen which shows the various AirPort base stations in range. In that screen, I see a 10.0.1.1 IP address.

When you click on the base station, and then the ‘Configure’ button, that brings up the more detailed configuration screen. The IP address there is indeed a valid IP address (24.something.something -- it’s a format I recognize as valid) as obtained from my ISP.

DHCP servers usually try to give you the same IP address that you had last time if possible.
Both give out IP addresses and that is why you are confused.
Your ISP has a DHCP server which gives your basestation its 24.x.x.x address.
Your basestation has a DHCP server which gives your iBook (and any other wireless client in range) an IP address - these are the 10.x.x.x addresses.

if you see the usual sort of 24.x.x.x address in the summary window of Airport Admin, that seems to indicate that it still has a valid DHCP lease from your ISP.

Does your iBook show a 10.x.x.x address in Network Preferences when you have this problem?

That explains it. Thanks.

Yes, I do usually see it there.

Yup.

ping
 

Next time you have the problem, try using 'ping' (in Terminal) to see if you can connect to
1) your basestation
2) some outside machine (e.g. www.apple.com)

E.g.:
ping 10.0.1.1
ping www.apple.com

I'll try pinging the base station next time. But I can tell you right now -- see original post -- that when I have had the problem, I've been unable to ping an outside machine. I can get a DNS entry (i.e., ping knows that Google is at a particular IP address), but 100% packet loss -- no response.

Mike

I'm sorry but I don't have an airport, but if it works like most routers then the following should apply:

1. The airport should keep track of the lease time of the address it gets from the ISP. If this is so (usually a status tab of some kind), is the time decrementing? When it reaches 0 it should request a new lease.

2. I have seen this scenario u describe when the ISP boots or restarts its DHCP servers and u no longer have a valid lease. The router doesn't detect this happening. I've had to reset both the modem and router. next time it happens, if it does, try resetting just the modem to see if the airport detects this and reacquires the lease. If not I suspect something is amiss in the airport. Are u at the latest firmware revision of the router?

unfortunately there's not much u can do to control this part of the protocol.

apologize for following up on my own reply. Another tack is when this happens is call the cable company abd ask the support person to look at what values are in your modem. this might help u debug the problem.

A shot in the dark..
 

allow udp from any 67 to any 68 in

You could try and make sure that the basestation allows DHCP request replies in.

Eeep. That was a LOT of stuff at once. Okay, let’s go through stuff one at a time ... =-)

I’ve explored the Airport Admin Utility pretty thoroughly. I’ve seen no such indicator; I think a descending countdown would be especially noticeable, so I feel fairly certain in saying it doesn’t offer it.

I’ve actually experienced that in the past, and while the phenomena are similar, this isn’t that. For one thing, I still have DNS access when things are “down”; even though ping experiences 100% packet loss, it is still able to tell me that Google is at a certain IP address. The thing is, it appears that the cable modem still has its old IP address; it’s just that the base station is acting oddly. Of course, perhaps the ISP expired the lease, and the IP address was renewed, and that’s why.

Well, doing the steps described in my original post to the base station (essentially changing the settings and telling the base station I did it) reacquires the lease easily enough, whereas unplugging the modem, waiting 20-30 seconds, and plugging it back in seems to occasionally flummox stuff up.

I should point out that I’m hoping more for preventative than restorative techniques. In other words, it’s not a problem at this point reacquiring Internet access; I’m mostly seeking to get things back to normal, so that after any prolonged period (anything over several hours) of not using the computer, I don’t “lose” my Internet access.

Yes, very much so. They just updated both the AirPort software (to 3.1.x) and the base station firmware (to 5.1.1) as of August 8 (about one week prior to these problems arising) and things are up to date.

(Before anyone asks: I tend not to think the firmware is at fault. Reviews of the firmware on VersionTracker as well as in other places aren’t mentioning problems like mine, and I have re-uploaded the firmware from my iBook via Ethernet cable so that wireless transmission had no chance to introduce errors.)

Already done ... please see original post. He examined the DHCP leases and the modem and saw nothing amiss, and indeed pointed that what he was able to observe indicated that the base station might be the source of the difficulty.

I’m sorry, yellow, but I have absolutely no idea whatsoever how to do either of these things. I tend to think the latter is already enabled, but can you tell me how I can do these things or check to see that they are already being allowed?

well, as a last resort then go back to the previous firmware rev. it seems too coincidental that it stopped working shortly thereafter.

I was going to say I couldn't find it, but I did find it here:

http://search.info.apple.com/?btnG=S...eme%20firmware

I highly, highly doubt that's at fault. But it is worth considering as a last resort.

Mike

Just discovered something ... when I picked "AirPort" off "Show:" in the Network preference panel, the "Make AppleTalk Active" checkbox in the AppleTalk tab wasn't checked. Could that be influencing this problem?

I checked it on ... it'll be interesting to see if the problems continue. I already noticed that the Configure screen seems to be coming up easier, quicker.

Keep yer fingers crossed!

Re: ping
 

To answer the posed question ... yes, I can ping 10.0.1.1 successfully. Pinging Google yields nothing, although it does recognize Google and puts it with an IP address, i.e.

Re: Re: ping
 

That could be cached data from when the rig was online and you accessed Google in some way. Use arp -a to list the cached addresses and sudo arp -d hostname.or.ip.address to remove them. Then try to do the ping and see if the DNS is picking up the address and correctly resolving the IP.

Next time it's down, I'll do that. Right now, arp -a just lists:

No. You don't need AppleTalk unless you have some AppleTalk device (e.g. an old printer or OS 9 Mac, etc). I would turn it back off.

From the fact that you can ping the basestation, it seems like the problem is not with your iBook anyway. It seems to me that it is a problem with the basestation.

In the Airport Admin, on the "Internet Connection" page, do you have the DNS servers filled in?
Whatt about Submask? These normally get filled in automatically by the ISP's DHCP server.

Back on your iBook, you could try the following command to see where your network connection breaks down:

traceroute www.google.com

This may start to fail as it gets closer to google (where sys admins might have disabled the packets it uses) but it should show the path of machines from your iBook through your basestation, your ISP, and beyond. I suspect it isn't getting past the basestation but don't know what might be wrong.

Done.

Yeah, but I think the warranty has expired. I'll have to double-check. Anyone know if I have to take this where I bought it (Comp USA) or whether I can take it to the Apple Store, since it's an Apple-made product? :)

At the moment, yes, but everything's up and functioning. I'll put this on my list of things to check when it's down again, with the 'arp -a' thing.

You should be able to take it to any Authorized Apple Repair Center.

Okay, looks like it happened around 10:30 pm or so tonight, so was able to get the answers for you guys for when it's in a Internet-less state.

I wouldn't be surprised, by the way, to find that it crapped out at about 10:38 pm or shortly thereafter. My system log advises me that I turned on the computer at 6:38 pm ... so add four hours to that ...

Anyway.

No, it definitely is not cached data. Here's what I got when it was down:


Yes. In the 'down' state, I am still seeing IP Address, Subnet Mask, and Router as white boxes with greyed-out filled-in numbers. The DNS servers are two empty boxes, but to their right, there are grey numbers. My domain name has something automatically filled in, my DHCP Client ID is an empty box, and the WAN Ethernet Speed is set to "Automatic (Default)."

(Am I right in saying that there would be some grevious security problem if I posted those numbers flat-out in a public forum?)

It appears to fail immediately:

2 more things I'd like to add to your already long list..
1) Do you have a firewall running on the iBook that might be blocking the DHCP request replies?
2) Just to confirm it's not the Mac, have we tried hooking the iBook directly to the cable modem?
Sorry if you already answered/did these, I didn't see them in earlier posts, but I read so many and have a terrible memory.

No firewall, and I did try a direct connection with success. Good ideas both.

dnstracer
 

From all that you have reported so far, it seem that the basestation has lost its connection to your ISP. It seems like this might be a problem with the DHCP lease that it gets from your ISP.

There are, however, a few strange data points.
1) I would have expected to see your basestation there in the first line of responses from your 'traceroute'. It seems odd not to have it respond when it apparently responds to 'ping'. You do get responses back from pinging the basestation ? (You didn't show what you got, so I have to ask.)

2) It is very odd that you apparently have DNS service from your ISP on your iBook even when the basestation connection seems "down".

I'm guessing that your iBook is caching the DNS info from earlier. By the way, I don't think that the 'arp' command will show you any possible DNS caches held by the OS. I believe that 'arp' is concerned only with your local network. This is corroborated by the fact that after doing a successful ping to my basestation and to www.google.com, 'arp -a' only shows this machine and my basestation.

To check on the DNS, the easiest way I know of is to use the command-line utility 'dnstracer'. You can download it via fink. Here's an example of using it:
The "206.47.244.79" you see at the beginning of that output is one of the two DNS servers that I get via my DHCP connection to my ISP.
You can see what DNS servers are currently used by your iBook by looking at the file /var/run/resolv.conf
(e.g. 'more /var/run/resolv.conf')
Check the date on that file too - it should correspond to the time when your iBook got that info from your basestation.

Re: dnstracer
 

Hmm... traceroute on OS X (or BSD in general -- I don't know) uses UDP instead of ICMP -- might make a difference. Unlike the version on linux there's no option to select UDP or ICMP. Try running it again next time with '-v' to get verbose output.

You're absolutely right about arp. It just gives you a mapping of IP addresses to hardware addresses. For all non-local IPs the hardware address is that of the appropriate gateway.

(Thanks for the pointer to DNSTracer. I'll have to take a look at it.)

Breen

Re: dnstracer
 

Before I go any farther, I should mention to everybody that I spoke with Apple this morning. Because it sounds like the problem is with the base station (since plugging the cable into the iBook yields no problem whatsoever, and the fix comes solely through resetting the base station), they're replacing it, since it's under warranty.

Both they and my ISP were pretty impressed with the level of troubleshooting you guys were able to help me with. THANK YOU!

They're sending a new one out, and I'm sending the old one back. I had heard that a batch of the AEBSs that were released around the time I bought this had gone bad, so perhaps this might just be bad hardware.

True enough, although I think it's the AEBS, and not the iBook, experiencing the problem.

Yes, I did, both in 'Net-less and okay positions.

I'm not so sure. I hardly ever visit some of the sites it was able to give me DNS info for. I'll try coming up with some really exotic URL, if I can, next time it's down.

However, I did download dnstracer. However, right now, even while I have active Internet, it doesn't appear to work. Perhaps it doesn't work through AirPort? Here's what I get:

Can anyone else with AirPort confirm that it doesn't work through it, or tell me of a differing experience? (Do you have AirPort, Hayne?)

As for:

I get:

It's dated Aug 23 10:01.

Those don't match up with the DNS servers which AirPort shows me in the Admin Utility.

Re: Re: dnstracer
 

Yes, I have Airport and the example dnstracer I showed above was via Airport. It shouldn't make a difference Airport or not. But my basestation is connected to a router which connects to my ISP, and so my basetstation is configured in "bridge" mode - so it just hands things over to my router, it doesn't do any DHCP or DNS.

The fact that 'dnstracer' fails to get anything from your basestation (which is your iBook's DN server) seems to mean that the basestation's DNS capability is not working.
As I mentioned above, this means that your iBook has been configured (automatically) to send DNS queries to your basestation. The "domain" entry is not DNS related - it sets the domain name for your machine.

You might try changing the Network Preferences on your iBook to have the DNS servers that you were given by your ISP.

Re: Re: Re: dnstracer
 

I don't understand what you're saying. When I'm in the "'Net-less" problematic mode, the DNS capability seems to be the only thing working, i.e., ping tells me the IP address of google.com, even if it doesn't connect. So how can this problem mean that the DNS is not working?

You seem to have a slightly atypical setup, with the base station bridging to your router connected to your cable modem. Are you sure that my setup should have identical capabilities/reactions to yours?

Re: Re: Re: Re: dnstracer
 

As discussed above, I don't really believe that your DNS is working when you are in the 'Net-less' state. I think you are just using cached information.
I think that if dnstracer shows a problem, there likely is one.
No - your setup is much more complicated as far as the basestation goes and hence is much more dependent on the basestation being properly configured and much more dependent on the basestation software working properly.

Have you tried what I suggested - entering the DNS servers in the (optional) box in Network Preferences?

[edit] Something else I should have asked much earlier:
Are you sure you have the cable modem connected to the correct port on the basestation? It is supposed to go into the WAN port. (see basestation docs)[/edit]

Re: Re: Re: Re: Re: dnstracer
 

Please note, Hayne, that any challenges I make to your assumptions aren't meant as discouragement or ingratitude ... but simply as part of the problem-solving process, and also my way of clarifying and learning where you're coming from. Hope you take it that way! :-)

The only reason I find that hard to believe is because I can get an IP address for almost any website in this "down" state. Tell you what: give me the name of a very obscure website you know of that you'd think it'd be unlikely I visited. I'll try pinging that when/if it next goes down, and I'll see if I get IP information. Would that be a good test, do you think? It could hardly cache an IP address for some place I've never been, right?

See, the thing that I'm not that certain about -- and please do excuse my doubt -- is whether this problem arises from a "problem" or our differing setups.

If anyone else is monitoring this thread, and has a simple cable-modem-to-AirPort connection, could you try installing the 'dnstracer' application and see what your results are?

If you don't mind the question, how is my setup more complicated? You actually seem to have the extra step of the router between your AirPort base station and cable modem, whereas mine is just a direct connection.

Not yet ... I'm trying to take things one at a time. ;-) My question relating to that, actually, was going to be: which of the various "DNS Servers" boxes?

Should I put it in the DNS servers box for the "AirPort" configuration? For "built-in Ethernet"? The DNS server entries in AirPort Admin Utility?

My ISP never actually gave me DNS server entries to put in, and I've never had to before. However, I note that AirPort Admin Utility is reporting 207.229.143.1 and 207.229.143.2 in greyed-out text to the right of the DNS server boxes.

Interestingly enough, when I use those as a value in dnstracer, it works ...

Is that particularly significant, do you think?

For a short time, yes, I was being stupid enough to have plugged it into the LAN and not WAN slot. However, that error was rectified and the problem persisted despite numerous reboots, etc. of the affected equipment after that.

BTW, a quick addition to this note:

New hardware is now on its way from Apple (as per earlier post), so it will be interesting (although quite disheartening) to see if the problem is reproduced with the new AEBS.

I am particularly suspicious of it being a hardware problem because I (again, only occasionally) cannot get in to configure the base station. I highlight the station and hit the configure button. A long pause ensues, and I'm then asked for a password -- which I shouldn't be, since the password's in my Keychain. I then type it in, and a slight pause continues. I'm then told that the Admin Utility can't configure the selected base station, and that an error occurred while attempting to configure it.

That problem actually pre-existed this one, and it makes me suspicious of whehter there are hardware problems involved in this routing/IP address problem ... and why I'm going to be keeping my fingers crossed that this new AEBS is a problem-solver ...

Re: Re: Re: Re: Re: Re: dnstracer
 

Of course. No problem. Best to not take anything that people say as gospel - verify it for yourself with test on your equipment and by googling the topic.
Okay - try www.hayne.net (very obscure)
I had said that your setup is more complicated as far as the basestation goes. You are relying on the basestation to do much more than I am.
Since your iBook is connected only via Airport, the "builtin Ethernet" section is not relevant. Put it in the Airport section on your iBook.
Your basestation seems (from the text to the right of the DNS server boses in Airport Admin) to already be getting the correct DNS servers from your ISP. So no need I think to put them in there - I think that would be redundant. But it is certainly something to try if it still doesn't work otherwise.
Was that when you were 'Net-less' or not?
That error is what you get if your Airport Admin password is incorrect. I do not have my A.A. password in my keychain (for security reasons since my Airport network is a more valuable target than merely this one machine - I have several machines on my LAN). Try removing the password from Keychain just to see if this fixes the problem of sometimes not being able to get to A.A.

And just to double-check on another thing - you said earlier that you din't have the firewall active on your iBook. But have you ever had any firewall software runnig on your iBook? (The firewall might be active even though Apple's preference pane doesn't know about it if it was done via 3rd-party software.)

Re: Re: Re: Re: Re: Re: Re: dnstracer
 

Thanks for understanding. I can't remember which famous Greek philosopher is the proper adjective ... maybe Socrates ... but there's a method of learning based on questions being asked and answered. I want to say it's the Socratic method. Anyway, I'm of the firm mind that the only dumb question is the unasked one, and when it comes to my Mac and related equipment, I'm especially inquisitive and wanting to make certain I understand as much as I can.

Okay -- I'll try pinging that next time I'm down, and I'll see if I can get a reaction. I've never been there, so I shouldn't have it cached. [Although based on the URL, I think I know who owns it. ;-)]

Oh, I see. Your router, in other words, takes some of the burden off of what your AirPort base station has to do.

That makes sense. Okay, the two values I got from the AirPort Admin Utility are now also in that slot in Network Preferences. We'll see if it prevents things from going "down" again.

That particular readout was when things were up. I will try it again when/if things go down.

I understand -- but the password I'm typing on these occasions is most definitely correct. Which is why I find the error odd.

(For reference's sake, by the way, the exact wording is: "The AirPort Admin Utility was unable to read the configuration of the selected base station. An error occurred while reading the configuration."

*shrug* Worth a try, and done. I do note that unplugging and replugging the base station also seems to solve the problem ... again, a reason why I suspect hardware origin for that problem.

A very long time ago, I may have downloaded Brickhouse ... but I don't even remember turning anything on, and hell, that might've even been on my iMac, not my iBook, it mentally feels so long ago.

In short, I'd say the likelihood of this particular one is very small, but if there's any diagnostic you want me to check to make sure that a firewall isn't currently active, let me know.

As a side note, by the way, it turns out that the second sentence of that error message is different when your password is incorrect ...

What I had been getting: "The AirPort Admin Utility was unable to read the configuration of the selected base station. An error occurred while reading the configuration."

Bad password message: "The AirPort Admin Utility was unable to read the configuration of the selected base station. The password you entered is not correct."

Re: Re: Re: Re: Re: Re: Re: Re: dnstracer
 

If you used Brickhouse then you can easily find out if it's running. Hit the Terminal and type:
If there's anything other than:
Then you're internal firewall (ipfw) is actively blocking ports. There are other firewalls out there that don't use ipfw (which is built into the OS X install). So if you used (later versions, v2 and up I think) Firewalk X or NetBarrier X, then ipfw won't show it.

Re: Re: Re: Re: Re: Re: Re: Re: Re: dnstracer
 

I'm good. And I definitely never used Firewalk or NetBarrier. So I'm firewall-free.

Well those were just two examples that I can think of, there may be more. But at least you're not using ipfw. The mystery continues... Where's Scooby when you need him?

Let me be more generic, then ... fairly certain I've never tinkered with any firewall software, period ...

My only hope is that as we rule out more and more things here, it becomes more and more likely that it's the one thing we ourselves can't test, a hardware issue, which would then be resolved with the new hardware arriving soon.

(God bless Apple Customer Service ... so far, nothing but compliments for 'em!)

It didn't.

And, indeed, nothing was found:

So the preceding successful IP addresses must have been cached.

As for running dnstracer when things are down:

Interestingly enough, with the DNS code typed into that panel, it automatically uses that address and not 10.0.1.1 for dnstracer, I suppose? But no result whatsoever; it just times out.

So, hayne, forgive me: what does this mean (i.e., what does all this data come together as)? Is this new data able to lead you to a successful diagnosis of what you think is wrong?

I don't really have a diagnosis.
It is somewhat comforting to have the DNS no longer mysteriously working.

It seems as though the packets being sent out by the iBook are not being forwarded by the basestation at all. I don't know why that would be.

One idea for something to try:
Connect the iBook with an Ethernet cable to the basestation's LAN port and turn off the Airport card on the iBook by using the Airport menu. See if it works that way.

Packets sent out by the iBook, or by the cable modem?

It sounds as if the problem with this entire situation does focus on the base station. Thus, I am hoping that it is a hardware problem which would thus be solved by the new base station coming within the next day or two.

Well, let me tell you what I've done in the past and you tell me if this answers whatever question that would pose. To re-upload the firmware, I have removed the Ethernet cable from the cable modem, left the other end plugged into the WAN port on the AirPort, and plugged the other end into the Ethernet port on my iBook. I am able to get a connection to the base station, although, since I disconnected it from the cable modem, it is of course disconnected from the Internet at that point ...

from the iBook. You can ping the basestation but you can't seem to get past that.
First of all, I would have used the LAN port for updating the basestation firmware, not the WAN port.

But anyway, what I was aksing about is not answered by what you have done. I suggest that you connect your iBook by Ethernet to the basestation (LAN port) and turn off Airport on your iBook. Then the Airport (radio) capabilities of the basestation will not be relevant. You will be using the basestation merely as a router. So try using this setup and see if you experience the problem.

By the way, you started this thread by saying that the problem occurs when you don't use the iBook for a while - but I would guess that the problem would occur after a certain number of hours whether or not you use the iBook. I.e. my guess is that it is just a matter of time, not usage.

Okay, that makes sense. But I imagine in that case, the problem would still lie with the base station.

I'm not 100% sure which port I used. I want to say WAN, but I very well may have made LAN.

Forgive the confusion, but in that case, what would be gained using the base station as a router? If I was going to a wired connection as I was pre-AirPort, wouldn't I just want to hook it up directly from the iBook to the cable modem? Would something diagnostic be gained by doing so?

I've discovered that is indeed the case, although I wouldn't have known it except on a weekend (where I'm using the laptop for a more prolonged period of time). The connection does peter out simply as a function of time, not of usage.

As a corollary note, I'm becoming more suspicious that this is a hardware failure, because the disconnections seem to be coming more frequently. It's 3:31 pm, for example, and I just experienced it going "down" again, and I think I experienced one previously no less than an hour to an hour and a half ago. Before, they had been coming more like three or fours apart. The fact that the intervals are decreasing seems to me to possibly be indicative of a hardware problem ...

Hayne, it just occurred to me ... I actually don't have the equipment to follow that last suggestion of yours. I don't have two Ethernet cables. So to the cable modem plugged into the base station via the WAN port, and then the base station plugged into the iBook through the LAN port, would require two Ethernet cables, which I don't have ... I'd have to go out and buy one. I'd prefer not to, since I don't know the expense involved and I have new hardware coming from Apple which might solve the problem.

Ethernet cables are relatively cheap - much less than a dollar per foot. It is a good idea to have an extra on hand in any case since cables can go bad (e.g. if you roll a chair over it) and damage to a cable can result in intermittent problems or just lowered bandwidth. So it is always nice to have an extra that you can try swapping with.

By the way, the diagnostic advantage of connecting your iBook via Ethernet to the basestation is that we cut out all questions about wireless transmission. It seems to me that the problem is with the basestations router capabilities and this would be a way to ensure that the problem still existed even if we take wireless out of the equation.

diagnostic tool
 

Not directly related to your problem, but might give some useful info, is a diagnostic tool (a Java applet) available at:
http://miranda.ctd.anl.gov:7123/

Not a bad idea; I'll have to remember to pick one up one of these days soon.

Okay, I now see how it would be of value and get your point. I'll probably pass this one time, however. Apple is sending out a new base station and taking back the old one, since it is still under warranty, so I'll think I'll pass on buying the cable ... since the purpose of that would be to specifically diagnose what within the hardware is wrong, when that'll be Apple's problem in a few days. ;-)

At least, that's assuming that the hardware is at fault, which I sincerely hope (and strongly suspect) it is! :-)

Thanks for the link!

lights
 

Okay - be sure to let us know if the new basestation fixes the problem. I.e. give us the news - good or bad.

Another thing to amuse yourself with in the meantime:
The lights on the basestation indicate when there is traffic (packets) on the LAN and on the WAN. (The third light just means it has power.) You could watch the lights to see if you are getting any WAN activity when you do things like pinging google. (I mean of course when you are in the 'Net-less' state.)

Similarly you could look at the lights (if any) on your modem.

Re: lights
 

Will do. At the very least, having the base station replaced will give me ammunition in other locales, if it isn't the fix. In other words, I can tell my ISP, "Look, this is a brand new base station, and I'm still having the same problem. The problem has to be with your cable modem (or your IP address, or your lease, or whatever)."

But I think so far the signs are pretty strong that the base station is the fault point.

Something to be on the lookout, for sure. I'll keep an eye out for it!

For reference's sake, when it's active, my lights appear to be left: dark; middle: solid white; right: white blinking.

Re: lights
 

I'm not handy to the manual right now but the meaning of the lights (there is more than jsy one & off - they have patterns when you are updating the firmware etc) is explained in the Airport basestation manual.

Re: Re: lights
 

Embarrassingly, I appear to have lost it ...

Okay, the new AirPort base station is here and set up. All appears to be working, and I've not experienced the disconnections I have in the past, although not much time has passed. The real test will be when I wake up tomorrow morning, whether I find it connected or not ...

One thing I am curious about is that ping is just flat not working, neither natively nor in Network Utility. However, things like dnstracer and whois are working ... ping is just the lone non-cooperating gunman.

Of course, a quick jaunt over to my ISP's status webpage indicates that Chicago cable modems were experiencing problems this afternoon. They say the problems are resolved, but perhaps I should just hang on a day or two.

Could be that your ISP is blocking pings because of all the Nachi infected machines out there. I've gotten 1516 pings denied by my firewall in 6 days and my machine is only on for 4 or 5 hours a day.

Good point. Especially given that tons of other stuff is working, i.e., traceroute, etc.

my two cents...
 

Hey there,

Great to see the fantastic level of support here! I can't match Hayne or Yellow in experience, but just wanted to offer the following:

I've had exactly the same problem; strange disconnection at seemingly random intervals using an iBook with Airport card, a wireless access point and a firewall router.

In this case, I was using a Netgear access point; not an Airport base station, but I should imagine that it makes little difference.

After about a month of battling with it and countless phone calls between myself and my ISP, I simply changed the Network settings on my iBook from "Using DHCP" to "Using DHCP with manual IP address".

I then entered an IP address that was high enough up not to be assigned to any of the Windows boxes on my network that request auto IPs through DHCP. (In this case 192.168.0.50)

I haven't been mysteriously disconnected since.

The solution came to me when I realised that the communication problem was between the iBook and the wireless access point, and not between the access point/cable modem and my ISPs servers. I couldn't access any shares on the local network when I was "disconnected". Similarly though, I could seemingly obtain IPs from DNS hosts, like google.com; just as you mention. On trying a site that I would never have visited I found that these IP addresses must have been cached, as was suggested here.

Sorry for the lack of technical mumbo jumbo, and the presence of waffle; just offering my round-about solution. I really hope the new basestation solves it for you...

Thanks for the thoughts, webmonkey ...

As for the new base station, it looks like this solved the problem. When I turned on my computer this morning, Internet access was up. So I'm going to go ahead and consider this problem solved, knock on wood!

There's this odd inability to ping, but I tend to think that might have been an external imposition based no some of the virii going around ... I'm not too concerned given that things like dnstracer and traceroute seem to be functioning fine from the command line.

I am very grateful to everyone here for their help, most especially hayne!

Just a final note to say that so far, the new base station is not exhibiting the same problems the other one was, and, knock on wood and God willing, it won't do so in the future.

My sincere thanks to everyone who helped me out in this thread ...