Intermittent wi-fi connection

A couple years ago when I moved to the new house I set up a wi-fi network because the entry point into the house was some distance from where I wanted to set up the desktop. Although it was perfectly fine for the smartphones, it proved inadequate for DesertRoomie’s favorite game so, with some grumbling, the very same day I strung a cable across the room and left it at that.

All was fine until last night when The Puppy found the one place the cable was within reach and chewed through it.* While waiting for the store to open to get a new cable, I dug out the hub, plugged it into the desktop’s NIC and voila, we had connectivity again (although still inadequate for the game)… for about five minutes.

The hub is rather simple, just the power light and another with the wi-fi logo on it; power was on, wi-fi was out. No muss, no fuss, no warnings pop up, except “cannot connect” on the browser. I cycled power on the hub and the power light came back on right away, went out several seconds later, blinked a few times then came back with the wi-fi light and I had the world at my fingertips again.

The longest the connection has lasted is twenty minutes, the shortest about two. Meantime the phones are fine, even streaming something, so I don’t think it’s the router. One of the problems is, I’m at that certain age where if I don’t use something for a while, it goes down the memory hole so, without looking it up, I don’t remember how to log into the router’s admin panel, never mind the hub’s.

Any ideas what might be going on?

*It’s a good thing puppies are cute; I guess the uncute ones were deleted from the gene pool some 8,000 years ago.

What, I’m the first? OK, I’m going to re-state what you’ve written to make sure I understand.

You have a router provided by your ISP. It does not have wi-fi capability. You also have a separate wi-fi router (which you call a “hub”) that you want to use as a wireless access point. You do not want to use it as a true router.

My very first guess would be that the wi-fi router may be trying to provide DHCP service, which is causing a conflict with the ISP’s router that is already providing DHCP. I’d go online and check the wi-fi router’s instructions to see what you should do to set it up as an access point only. (Should be very simple.) You will probably have to wire the wif-fi router directly to a computer to set it up, but you may be able to log into it using wi-fi.

As far as the ISP’s router, many ISPs put a label on the side or bottom of the router with the router’s IP and the admin password on it. Check for that. If you have the IP, enter it in the address bar of a browser on a computer connected to the router. You should get the log-in page for the router, from which you can log-in and manage the router.

If I got some part of this wrong, let me know.

I have a cable modem that I bought from my ISP (after the one from Fry’s didn’t work so good). It has only the one output so I have a wi-fi router as well. Into two of the four hard ports on it are plugged my smart TV* and – until it was dog-chewed – the desktop computer. Two years ago when everything was being set up, I did gain access to the router’s admin (hard connection of course) and set up two wi-fi connections, one with full access to the LAN and the other for guests with internet-only access, both password protected.

At the same time I had set up a hub intending to use it for the desktop’s connection but when it proved unsatisfactory, plugged the box in directly instead. When the disaster happened Friday evening I dug out the hub, plugged it into the desktop’s NIC and was connected to the internet again, sort of. The speed was slower than the hard connection and, as I said in the OP, it was intermittent.

The cable was replaced yesterday (out of reach of The Puppy) and everything is back the way it was. If I am interpreting your post correctly, you are thinking I dug out a wireless router on Friday and plugged that into the ethernet-connected “router” (in reality a modem) and that started causing DHCP conflicts between the old “router” and the new. In reality, the modem and the router have been working together for a couple years and any DHCP assignments were between the modem and the router pair, which had not been changed.

Something else was going on. As I said in the OP, the two smartphones in the household have not had any issues with the wi-fi network dropping out every few minutes nor did the smart TV (which had a hard connection).
*The mfr recommended a hard connection and, anyway, they’re right next to each other.

First, I’m glad that you were able to resolve your problem. If everything is working, thumbs up!

Second, of course, that was exactly why I was asking about your set-up. It wasn’t clear to me, since I have very definite ideas about what a switch, hub, modem, and router are, and how the functions are combined into individual devices. I was a bit confused.

You’re up and running and that’s what’s important.

This is interesting in that a friend of mine had a similar problem - although the order of events was different - the symptom and cure were much the same. For him it was simply that the WiFi connection to a device stopped working properly out of the blue six months ago. The device was on the network from some points of view but not others, and phones could always see it. Fixed with a hard connection. Further, I have fixed other related problems by setting a fixed DHCP mapping.
I have a feeling, but have not taken the time to really look into things, that for some devices under some network topologies - with a mix of wired and WiFi, the DHCP leasing becomes unstable. At home I now fix all of the DHCP mappings for every device. Sure, this should not really be needed, but anecdotally, I have cured a number of problems by doing this.
Phones (well iPhones, my circle have been Apple fanatics since before they were doomed) will use a range of protocols to bind to devices, and often go directly to a WiFi device, and don’t traverse the network via your anointed WiFi base station.

Hmmm…Francis Vaughan, some of those things are unlikely to be actually happening. I’ll try to clear the air here just so others aren’t confused.

While competing DHCP servers can bring a network to its knees, a single DHCP server really doesn’t care about mixing wired and wireless media. In fact, DHCP happens at the application layer, while ethernet and wireless ethernet are part of the link layer. (This is a reference to the OSI “7-layer burrito” model of telecommunications). In other words, since DHCP is encapsulated within the transport, internet and link and physical (“network topology” in this case) it is indifferent to whether its being sent wirelessly or not.

This is all to say that although you might have had DHCP problems, mixing wired and wireless connections doesn’t cause “DHCP leasing to become unstable.”

With that said, it’s totally true that flaky DHCP servers exist, as do flaky DHCP clients. There’s no such thing as “fixed DHCP mappings” because DHCP stands for “Dynamic Host Configuration Protocol.” But that’s just a terminology thing…the conventional term here is “static IP address.” And you’re right: static IP addresses avoid DHCP servers/clients altogether, and a device with a static IP address won’t be bothered by a network with a flaky DHCP server.

Regarding your point about phones doing an end-run around wi-fi access points: well, it doesn’t happen. What you’re suggesting would require a separate ad-hoc device-to-device network. I suspect you’re thinking of zeroconf, a protocol devices use to advertise their services on a network.

Apple’s implementation of zeroconf, called Bonjour, sort of fits your description of Apple phones “binding devices” directly. Zeroconf/Bonjour absolutely traverses the WiFi access point, but one could totally think that it does not based on a description of the protocol written for non-networking-geeks.

To the OP: I’m with ZonexandScout on the terminology here…it’s pretty unclear what you mean by “hub.” (I also agree that these definitions are secondary to the fact that you’re back up and running). It’s unlikely to be a true wired ethernet hub…those haven’t been widely available for a long time. Switches are nearly all you can buy these days, and it’s been that way for almost a decade.

Hubs broadcast all packets (well, ethernet frames) to all their ports. This is like having everyone in a giant room, all talking at once. Switches “know” which devices are on which ports, and only send the relevant packets to the relevant ports. This increases throughput because it’s analagous to a bunch of small, quiet rooms with separate conversations going on. No one gets interrupted by an unrelated conversation.

Your modem is truly a modulator/demodulator and not a router, yes. What I don’t follow is how, following the death of the ethernet cable between your desktop and your wireless router, you used a hub to connect your desktop to the router. That would require an additional two ethernet cables: one between the desktop and the hub, and another from the hub to the router.

I can only guess that what you’re calling a “hub” is really something like a USB wi-fi network interface. That’s something one could use to put a desktop computer on a wireless network. You might also have had a wireless bridge, which contains both a wireless interface and one or more ethernet ports. You could connect the wireless part to your wi-fi network and then use a short ethernet cable to connect the bridge to the desktop’s ethernet port.

As ZonexandScout mentioned, this is now all immaterial. But Zonex is also being a little bit polite when saying “I have very definite ideas” about the definitions of switches, hubs, routers, etc. It’s not so much that Zonex has certain ideas about these things, but rather that they’re clearly and universally defined terms.

Non-experts can’t be expected to know all of this, of course. But just as your mechanic will look at you quizzically if you say that you replaced the distributor on your Tesla or said that you thought another car had a problem somewhere between the carburetor and the fuel injectors, networking people can’t help if you’re using largely ambiguous or incorrect terms.

I keep adding more paragraphs to try to avoid sounding like a scold, but I don’t think it’s working. Here’s the deal: when I try to help my parents with their computers, they seem to believe that because I “know computers,” I must know exactly what they mean even if they’re not quite using the right words. In fact, the words they use often point away from the actual problem. So I’m supposing that non-networking-geeks can’t quite tell how confusing their descriptions can be, and I’m trying to make that clear here.

Just to be slightly pedantic - you can most certainly fix a devices IP address in a DHCP server’s mapping config. It still uses DHCP, but the server always returns the same address for the device. Normally once a lease is provided a dynamically allocated address is kept for the same device each time it requests a new lease, so such a step shouldn’t be needed. However, I have found that simply providing a fixed mapping from Mac Address to IP address in the DHCP server’s config that previous problems suddenly vanish. The smoking gun is a problem in the DHCP leasing, possibly a race condition, or some other implementation quirk.
A device that thinks it has not been allocated an IP address by a DHCP server (and has no router address set) will participate in a Zeroconf negotiated connection that does not use any other network components, and will communicate directly. So if you had say an Apple TV that was for some reason failing to see the network properly, a phone would see it, even though nothing else will.

I don’t think you’re being pedantic…I think you’re right. Now I see what you meant by “DHCP mapping;” I’m sorry I didn’t understand you correctly the first time. I obviously underestimated your understanding here, and I apologize. I didn’t mean to patronize you.

But now my curiosity is piqued: what do you mean when you say that the physical layer “causes DHCP leasing to become unstable?” That really, really doesn’t make sense to me. DHCP has no idea about the physical layer. If, say, RF interference were causing DHCP clients to fail, setting a static mapping wouldn’t help: the flaky physical layer would affect everything else at the application layer as well. You say that a smoking gun would be a race condition or some other implementation problem…well, OK, but how would mixing wired/wireless topologies induce this? I’m not saying it’s impossible…I’m suggesting that a topological effect seems less likely than a plain old intermittently-borked implementation at the client, the server or both.

Regarding direct networking: your original post said that Apple devices “often” establish ad-hoc connections and “don’t traverse the network via your annointed WiFi base station.” I took “annointed” to mean “properly configured at both the AP and the clients.”

So I first understood you to be saying that Apple devices often ignore a properly-configured wireless network and communicate directly instead. I disagreed with that assertion.

Now I understand you to be saying that when there’s no common infrastructure network, Apple devices will attempt to connect directly to one another. That I agree with.

I’ll still argue that both Zeroconf and Bonjour are primarily for service discovery within an established network. (WiFi Direct and Apple’s Multipeer Connectivity are dedicated tools for establishing ad-hoc networks). Yes, one can use Bonjour to establish a peer-to-peer WiFi or Bluetooth connection between two Apple devices, but if they’re both already on the same infrastructure network, they’ll use that rather than establishing a new ad-hoc network. Do you agree?

At any rate, I appreciate your clarification.

I think we pretty much agree on things.
I’m really only making odd suggestions about possibilities of where the problems might exist. Once you have some sort of implementation defect anything might be a trigger for things going wrong. What I have observed is that a mixed environment of WiFi and wired seems to exhibit more problems. Perhaps that is indicative of a problem in a router/WiFi base station messing up having to manage two networks.
In one situation I spent some time looking at how the DHCP server was behaving, and it did seem that something went wrong about the time a lease was up. Perhaps the rule about reallocating the same IP address to the current lease holder went awry, or some other silliness. The borking of the implementation may simply because of the mixed wired/wireless environment not being handled properly, rather than the mixed environment being a true causative agent.
The smoking gun has been that defining a fixed IP allocation magically fixes the instability. I will confess that after tearing what little hair I have left out over these problems I have had little inclination to dig too much deeper. But the trick has enabled me to quickly fix instabilities in other networks, so it seems to be a useful tactic, albeit one without a really firm underpinning.

OK; thanks for explaining. Yes, I also think we agree.

On my own home network, I assign static IPs (not static mapping at the DHCP server) whenever I can, simply because (a) I run my own DNS server internally and (b) it incrementally reduces the time required to get on the network when, say, I turn on my laptop. I’m running Tomato firmware on an old Asus router and a Ubiquiti access point…they’ve always played really well together. But if fixed mapping makes your life easier, I can totally see why you wouldn’t want to dig into it more deeply than you have.

Yes, I guess it was a bridge, then. The connection to the router was wireless and there were four CAT ports on the rear, marked Highest, High, and two Medium; I figured the multiple ports made it a hub. Only Highest was in use and it would obtain about 15-Mbps vs. 40-Mbps when the desktop was hard wired into the router. The fix was to replace the puppy-chewed cable and make the replacement puppy [del]proof[/del] resistant. The bridge is back in the drawer it’s been in for the past two years.

Still scratching my head, I plugged in the bridge(?) again and after a couple disconnects, it stabilized just fine. It ran all night without a single disconnect and when I checked the speed just now, it clocked 71.2 MPS download, about 30 upload. Whatever was causing the trouble is no longer. I tell ya, Clarke’s Law has it right. :dubious: