Jump to content

Airport Express issues when plugged into Ethernet


Recommended Posts

Posted

No, not LAN IP address.

 

WAN INTERFACE LAN address.

 

I know it is confusing! I don't know exactly what they call it on Airport Extreme. In fact, it might not even be reported. And just checked is is NOT reported in the Arris modem status pages. Probably really irrelevant, forget that I asked! ;)

 

You don't need to know which cable is which. Go in the basement, disconnect the switch from the AC power.

 

Unplug the ISY. Begin at the beginning. One computer, plugged into the AE. The AE plugged into the cable modem. Nothing else plugged into router or cable modem. NO switch.  No mystery wires. That is it. See if it works. Move on from there. Next would be "two computers", and might as well introduce the office switch. Nothing else plugged into the office switch. Two computers.

 

Yes, it would be nice to trace your wires and label them. But not necessary to diagnose this. The wires are switches are extremely unlike to have anything to do with the problem.

Posted

Hi again- and thanks again!

 

Don't see a WAN.... still trying to figure out how to find it on the AE.

 

As far as stuff connected - everything working perfectly until I plug the Ethernet "wall line" in. However, as noted, what's happening downstream is unknown as I can't tell which line is which.

 

Just picked up a cable tester, though, so I should be able to find out.

Posted

Hi again- and thanks again!

 

Don't see a WAN.... still trying to figure out how to find it on the AE.

 

As far as stuff connected - everything working perfectly until I plug the Ethernet "wall line" in. However, as noted, what's happening downstream is unknown as I can't tell which line is which.

 

 

 

It doesn't matter.

 

Unplug every switch's AC cord, except the one in the office. Power-down every WiFi device. If portable, power it down. If wired, unplug it from the AC.

 

There is no reason to suspect a switch or wiring. If you do the above, and you have trouble, you have a switch with a problem - a very strange one that shouldn't be possible unless a managed switch. I don't think your 4-port switches are managed switches.

 

 

If the above fails, then, yes, you need to trace the wires. You have a "mystery wire" that is going to some switch you didn't know you had.

 

Maybe Putin put it there. ;)

 

If you passed "two computers", then plug the Airport into the wire going to the basement. If the switch is unplugged from the AC, it should still be OK. If it isn't the switch is bad, but I can't imagine the failure mode. It is a .000001% chance!

 

Now power-up ONE family-room device. (XBox or Playstation). You DID unplug and power-down everything right? Right? 

 

If you don't already have one, go get a label-maker too! Hint, if you already have one, and it is an old Brother, their old tapes faded badly. You won't be able to read them in a year. The newer ones that take TZe tape are great, and most have a special "cable mode". (Just prints two times, with a dashed line.) If you really want to go deluxe, Home Depot now sells a professional wire-marker labeler, but I think pretty expensive $100 or more.

 

Honestly, all it takes is a disciplined, step-by-step approach, and patience. One device at a time. EVERYTHING powered-down first. Power back up from office to basement to family room to living room. Each switch first, then one by one the devices the switches are connected to. When everything is working OK on one switch, move on and power-up the next switch. It does not matter which cable is which, because the cables are not the problem, and the switches are not the problem.

Posted

Ok - looks like the DirecTV DVR was causing the issue!

Not sure if we connect via wifi the issue will happen again, but will try it out.

 

For now, even if other devices cause trouble, I think we've ruled out the switches/cabling.

On to my next issue/topic... re-establishing remote access :)

thanks all!
Andrew

Posted

So, just what was the problem and the resolution?

 

Reading between the lines, I'm guessing everything is well, so long as the DirectTV is unplugged?

 

Rather baffled about this, as even a fixed-IP allocation on the DirectTV would not have caused the problem, because your old subnet and new subnet are different. So, if you had a fixed allocation of, say, 192.168.1.10, so what? On your new router, the DirectTV would simply be unreachable, since your new subnet is 1.0.1.0/255. I am assuming you did NOT set-up a fixed IP address on the DirectTV subsequent to installing the new router, right?

 

If DirectTV is causing troubles with the new router, it implies something is wrong with the unit or firmware, and you should contact DirectTV to have the problem fixed. Only thing I can think is that it is ignoring DHCP reservation expirations. That is, it's reservation expires, but it continues to respond to the expired address.

 

Am I correct in assuming that if you power the DirectTV DVR and plug it into the switch, the troubles start again? If so, to they start immediately, or does it take some time?

 

If you do get the problem again, it would be helpful to copy-and-paste the EXACT error message(s) you are seeing from your router log. They will probably include both the IP address and MAC address. From the MAC address, it may be possible to identify the manufacturer of the device(s) in conflict. Not always possible, as it may only identify the maker of the Ethernet chipset, but in many cases (e.g. Apple) will home-in on the device manufacturer.

Posted

Everything is good so far - as you note, with the DirecTV running without ethernet/wifi connected. (Obviously that has to change at some point..)

 

When I reconnected it (ethernet), after about a minute, maybe, the IP conflicts started popping up. I think my first try will be wifi to see if it happens that way. I assume it will if the IP is static.

If not, great, but either way I'll be calling DirecTV.
 

So, just what was the problem and the resolution?

 

Reading between the lines, I'm guessing everything is well, so long as the DirectTV is unplugged?

 

Rather baffled about this, as even a fixed-IP allocation on the DirectTV would not have caused the problem, because your old subnet and new subnet are different. So, if you had a fixed allocation of, say, 192.168.1.10, so what? On your new router, the DirectTV would simply be unreachable, since your new subnet is 1.0.1.0/255. I am assuming you did NOT set-up a fixed IP address on the DirectTV subsequent to installing the new router, right?

 

If DirectTV is causing troubles with the new router, it implies something is wrong with the unit or firmware, and you should contact DirectTV to have the problem fixed. Only thing I can think is that it is ignoring DHCP reservation expirations. That is, it's reservation expires, but it continues to respond to the expired address.

 

Am I correct in assuming that if you power the DirectTV DVR and plug it into the switch, the troubles start again? If so, to they start immediately, or does it take some time?

Posted

If the Direct TV has WiFi it will not use the same IP address as the tethered Ethernet connection. It will be handled out a new DHCP address unless you reserved one in the router via MAC address filtering.

Posted

... but if the DirectTV software has a bug, it will probably be manifested on WiFi as well.

 

The only way the DirectTV would have a fixed IP address is if you put it there! And if you put it there in the past, when you had your old router, it wouldn't be causing a problem now. (The the DirectTV wouldn't have any network access.) If you put it there since you got the new router, tsk, tsk, shame, shame, there's something you didn't tell us! ;)

 

I realize you are trying to take a pragmatic approach, but some of us might see it, instead, as "sweeping things under the rug" or "whatever works". That's usually a bad idea!

 

I would just call DirectTV. They have an incentive to keep you happy and keep paying a subscription fee.

 

Copy the EXACT errors message you get here.

Posted

... but if the DirectTV software has a bug, it will probably be manifested on WiFi as well.

 

The only way the DirectTV would have a fixed IP address is if you put it there! And if you put it there in the past, when you had your old router, it wouldn't be causing a problem now. (The the DirectTV wouldn't have any network access.) If you put it there since you got the new router, tsk, tsk, shame, shame, there's something you didn't tell us! ;)

 

I realize you are trying to take a pragmatic approach, but some of us might see it, instead, as "sweeping things under the rug" or "whatever works". That's usually a bad idea!

 

I would just call DirectTV. They have an incentive to keep you happy and keep paying a subscription fee.

 

Copy the EXACT errors message you get here.

 

Any network device that has more than one method to connect to the infrastructure has a MAC address. The Ethernet card on the Direct TV has one MAC address, the WiFi also has its own MAC address. 

 

The information offered up above is to clarify the question you posed in red.

Posted

Well, yes, the Ethernet interface will have a different MAC address, and IF the DVR has been configured to use DHCP, then it will get a new address from the router's pool.

 

And IF the DVR software has a bug (which is the only reason I can imagine this is happening) then after some minutes, hours, or days, the problem will recur. As the only thing I can think of that would cause the symptom described is that the DVR held on to a DHCP reservation past it's expiration time.

 

The problem SHOULD have been solved - at least for some time period - by simply power-cycling the DVR, which is one of the early things I suggested. ALL of the devices should have been power-cycled.

 

I hate problems that "solve themselves". They typically don't. They just eventually recur.

Posted

Of course, the Airport could have a bug, as well. It COULD be handing out duplicate addresses to multiple devices.

 

BOTH scenarios seem pretty unlikely. This is pretty baffling, but hard to diagnose with incomplete information. (Such as, lacking the exact error message.)

Posted

Well, yes, the Ethernet interface will have a different MAC address, and IF the DVR has been configured to use DHCP, then it will get a new address from the router's pool.

 

And IF the DVR software has a bug (which is the only reason I can imagine this is happening) then after some minutes, hours, or days, the problem will recur. As the only thing I can think of that would cause the symptom described is that the DVR held on to a DHCP reservation past it's expiration time.

 

The problem SHOULD have been solved - at least for some time period - by simply power-cycling the DVR, which is one of the early things I suggested. ALL of the devices should have been power-cycled.

 

I hate problems that "solve themselves". They typically don't. They just eventually recur.

 

You missed what I am saying - The OP indicated he would try to use the WiFi portion of the Direct TV assuming it has such hardware in place. My reply to you was (IF) he did in fact have WiFi in the Direct TV it would be handed out a new and different DHCP IP address from the router.

 

No bug on the Direct TV would impact a IP conflict in that scenario while using the WiFi card . . .

Posted

Tekken, I write software. I've written software for 40 years. I know a little about how software writers write software.

 

Do you think that the code in the DVR that deals with DHCP reservation expiration for Ethernet is different than the code for DHCP reservation for WiFi?

 

If it is, an idiot wrote the code.

 

Yes, if an idiot wrote the code, then perhaps the WiFi part doesn't have a bug that the Ethernet part does. One if the few cases where an idiot writing the code MIGHT result in a bug only affecting one scenario and not another. Of course, if could also mean that an idiot wrote the code, fixed a bug, but forgot to fix the bug in two places. Of course, the code should never have been in two places, but an idiot wrote the code!  Just speculating here!

 

BTW, one of the things that I kinda specialize in is re-writing code that idiots write. It's work that drives some people crazy, but I actually LIKE it. It is a kind of software forensics. A giant puzzle to unravel, and figure out what was really intended and where the intent was not implemented. One important principle - to paraphrase - TRUST NO COMMENT! Anyway, after doing so much of this kind of work, I have some intuition as to what can go wrong in software. I make no assumptions, rule nothing out. But there are common threads as to what can go wrong.

 

(OTOH, I don't really like fixing other people's bugs. Just let me do a re-write or re-factor and do it right. At least a refactor of the part(s) in trouble. Many managers see this as a risk, as they have past experience of re-writes and refactors being a disaster. I ALWAYS leave code better than what I started out with. Usually MUCH better.)

 

Run this scenario through your in-brain simulator:

 

1. DVR uses DHCP to request an IP address for the Ethernet interface.

2. Airport cheerfully hands-out an IP address. "It's good for 24 hours, don't over-stay your welcome!"

3. DVR ignores instructions, over-stays it's welcome. Chaos ensues, because the Airport assumed the DVR would obey instructions, and handed-out the expired address to another device after 24 hours.

4. User gets frustrated, switches DVR to WiFi.

5. DVR uses DHCP to request an IP address for the WiFi interface.

2. Oh, I mean 6. Airport cheerfully...

7. DVR ignores instructions, over-stays it's welcome. Chaos ensues.

8. User gets frustrated, switches DVR to Ethernet.

9. Rinse and repeat.

 

If some bug makes the DVR over-stay it's welcome, it's very unlikely it would affect ONLY the Ethernet interface.

 

BUT, we don't even know how the DVR is configured. Whether it uses DHCP, or if it has been manually configured for a fix IP address.

Posted

Tekken, I write software. I've written software for 40 years. I know a little about how software writers write software.

 

Do you think that the code in the DVR that deals with DHCP reservation expiration for Ethernet is different than the code for DHCP reservation for WiFi?

 

If it is, an idiot wrote the code.

 

Yes, if an idiot wrote the code, then perhaps the WiFi part doesn't have a bug that the Ethernet part does. One if the few cases where an idiot writing the code MIGHT result in a bug only affecting one scenario and not another. Of course, if could also mean that an idiot wrote the code, fixed a bug, but forgot to fix the bug in two places. Of course, the code should never have been in two places, but an idiot wrote the code!  Just speculating here!

 

Run this scenario through your in-brain simulator:

 

1. DVR uses DHCP to request an IP address for the Ethernet interface.

2. Airport cheerfully hands-out an IP address. "It's good for 24 hours, don't over-stay your welcome!"

3. DVR ignores instructions, over-stays it's welcome. Chaos ensues, because the Airport assumed the DVR would obey instructions, and handed-out the expired address to another device after 24 hours.

4. User gets frustrated, switches DVR to WiFi.

5. DVR uses DHCP to request an IP address for the WiFi interface.

2. Oh, I mean 6. Airport cheerfully...

7. DVR ignores instructions, over-stays it's welcome. Chaos ensues.

8. User gets frustrated, switches DVR to Ethernet.

9. Rinse and repeat.

 

If some bug makes the DVR over-stay it's welcome, it's very unlikely it would affect ONLY the Ethernet interface.

 

BUT, we don't even know how the DVR is configured. Whether it uses DHCP, or if it has been manually configured for a fix IP address.

 

Your reaching for the moon here - try to keep your foot planted on Earth. The odds the Direct TV will hold on to an existing DHCP address when connected with WiFi when it was originally connected via Ethernet is so remote its not worth discussing.

 

The fact you have stated a possible bug in both the Direct TV & AE gives me pause.

Posted

Your reaching for the moon here - try to keep your foot planted on Earth. The odds the Direct TV will hold on to an existing DHCP address when connected with WiFi when it was originally connected via Ethernet is so remote its not worth discussing.

 

The fact you have stated a possible bug in both the Direct TV & AE gives me pause.

 

I DID NOT SAY that the DVR would hold onto an EXISTING DHCP address when connected with WiFi when it was originally connected via Ethernet! Read my step-by-step.

 

I suggested that it might have over-stayed it's welcome. If switched to WiFi, it will get a NEW address, true. And then over-stay it's welcome on the new address. This will cause a problem when the router tries to recycle what it thinks is an expired address. Maybe minutes, hours, a day, or days later. (More likely longer than shorter, depending on number of devices in house.)

 

Given the information that has been given, it is the only possible scenario.

 

Either the DVR held onto a reservation too long, or the router handed out an address that had not yet expired.

 

The odds that the DVR held onto a DHCP reservation too long for Ethernet and then would NOT do the same for Wifi are remote! 

 

But we have incomplete information.

 

Critical is whether the DVR is, in fact, configured to use DHCP, or has been given a static IP address through it's settings interface.

Posted

With all due respect, I don't buy that argument.  Surely Apple is good enough to implement the standard DHCP collision avoidance technique -- which is designed for exactly this sort of problem.  That would ensure that it (the router) would check to see if someone still has that address (even if they shouldn't) and if so, it won't give it out.

 

The only reasonable exception to the above is if the router is starved for DHCP address range -- but surely you don't 64 devices active on your network (and I can't imagine that Apple uses less than that for the default range -- and probably uses more; they have >250 addresses possible to use).

 

I'm not telling anyone what to do - I'm observing this in case someone stumbles over this thread with similar symptoms and assumes the above explanation to be "gospel".

Posted

I'm not telling anyone what to do - I'm observing this in case someone stumbles over this thread with similar symptoms and assumes the above explanation to be "gospel".

 

I actually agree with you. 99% of the time, the symptom described is caused by a manually-configured static IP address that conflicts with a DHCP pool address.

 

Since Andrew (apparently) did not manually-configure a static IP address on the DVR, we are left to consider the improbable 1%.

 

I HAVE seen devices fail to renew their reservation, and then continue to attempt to use their previously-configured address. But they are almost always solved by rebooting or power-cycling the device. Few devices try to retain a DHCP-allocated address after a reboot/power cycle.

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...