Ok, I've read back through the messages on this thread, and I think I'm getting a handle on your layout. It looks like this, right?
1) WISP signal -> Ubiquity antenna
Antenna contains router with address 192.168.1.1, performing DHCP
2) Antenna -> POE -> Asus DSL-N55U
The DSL-N55U receives signal from Antenna, accepting DHCP-defined address on 192.168.1.x range
The DSL-N55U then performs routing on 192.168.0.x range (with its own address being 192.168.0.1).
DHCP is turned off for the 192.168.0.x range? (Not sure why you'd need to do this)
3a) Asus DSL-N55U -> wireless client (works correctly)
3b) Asus DSL-N55U -> wired client (fails)
Is this correct?
So, now I've got more questions.
One, I see no reason why you need to turn DHCP off on the Asus router. It should have no problem accepting a DHCP address from the antenna on 192.168.1.x, while at the same time serving DHCP on the 192.168.0.x range.
Two, I don't really understand why having a plex server demands a wired connection (although I don't use plex myself). Most media streaming tasks can be performed quite adequately over wifi these days.
But three, the error message "invalid IP address" now seems a bit more interesting to me. I would imagine you've already checked to make sure the addresses you are creating stay within the 192.168.0.x range, right?
Also, that you don't have two devices sharing the same address.
I took a look at the manual for the DSL-N55U; my own router provides the ability to partition the address range into some statically defined addresses, and some DHCP-controlled addresses. It looks like this router has that ability as well, but I guess it wouldn't be active if you have DHCP turned off.
In any case, I don't think it would hurt to try updating the firmware, but I think there may still be other avenues to explore before doing that...
EDIT: By the way, you wouldn't happen to have defined the same static IP address on your Mac for both wireless and wired connections, right?
YES - thank you! You have my setup 100% correct.
Re your questions:
1.)
Switching OFF DHCP on Asus: I have no idea - I simply followed the instructions of the ISP. They seem to stem from them having issues in the past, where DHCP was left on, on the device.
I popped up a query about it on one of my local tech websites - one kind soul who presumably also works at a local WISP, responded with this [
iBits is who I use]:
We know a little of what's going on, on their network as we speak with them at least once a day, every day.
iBits have a nice block of public IPv4 addresses. They also have a block of IPv6 addresses.
Like us, they spend most every night converting clients from "192.168" address to public IP addresses.
Like us, they use a combination of router on the roof and wireless AP in the house.
We mostly use Mikrotik on the roof, but also use Ubiquiti in some areas. They mostly use Ubiquiti.
If there's a Mikrotik on the roof, we'll either put a TPLink or a couple of Ubiquiti UniFis inside. This is a recipe we've used for years. It works.
The theory is that the radio on the roof does the PPPOE connection back to the ISP. All our new clients receive a static public IP address at this point.
Believe it or not, but iBits have a massive network. Switching all the users over is taking a very long time. The way I understand it, they have rolled out static publics to the towers / PPPOE concentrators, but are still rolling public IPs out to the clients. At this point the PPPOE should therefore receive a 192.168 address that is NATted. Now, if your router on the roof does all the DHCP and your router in the house is a dumb bridge, you don't have a double NAT situation.
You don't want a double NAT. This is bad.
We normally pop a RJ45 connector into the TPLink or Tenda AP's WAN port to block it. Then the AP receives a static ip of 192.168.1.1 with gateway 192.168.1.254 and DHCP is switched off.
The TPLink or Tenda is then a dumb bridge. It does no work, apart from wifi and network switch. These things don't have the fast processors you find in Routerboards. Switching from router to dumb bridge means our clients (and iBits' clients) can now have speeds of 30Mb+ over wireless on relatively inexpensive kit.
The router on the roof then does the DHCP and NAT's the 192.168.1.x network to the WAN IP address of the router.
For the techs... The other reason both us and iBits are doing this, is ease of implementation of IPv6. All we need to do is have a static IPv6 address in one /64 on the WAN port and another IPv6 address on another /64 that advertises on the LAN port of the router on the roof. This is a simple, but highly effective way of rolling out IPv6. All the client needs to do is ensure that IPv6 is enabled on his device.
I've highlighted two parts above, which is what he was getting at behind why switching off DHCP on my router is advisable. I don't know enough to counter any of that - but then again, I guess 'dummies' like me is the reason they do it. Maybe you might be able to comment on that - does this make sense?
2.)
Re Plex
The ATV2 down the far end of the house, in our main bedroom, was really struggling with playing some of our files off the Plex server. The media is on a DAS connected to the Mini. Both the Mini and ATV2 were/are connecting via Wifi.
I figured that a possible reason might be since the ATV2 was getting long in the tooth, it might be struggling with converting the media on device - although, AFAIK this is supposed to be done on the Server/Mini side?
Regardless, I convinced the SO that if we upgrade to ATV4, these problems would be solved. So imagine how popular I was, after buying the ATV4, when they seemed to get
worse!
So whereas we scored Netflix and related apps on the ATV4, trying to play our existing media through Plex or Infuse, was simply terrible - to the point of even being worse that the ATV2! We now stream the same media through Netflix etc., rather than fetching that from the local - which is surely ridiculous!
Someone suggested that if both the ATV4 pulling the media, and the DAS/Mini/Plex serving the media, are running through WiFi, I'm basically halving my Wifi throughput - so rather wire the Mini....
The deadspots around the house (including the weak signal for the ATV4 in the bedroom) led me to start investigating the Ubiquiti Unifi APs as a possible solution - which led me to first getting the Mini hardwired - and left me with this mess! I cannot possibly go mesh until I manage to get my locals connected via LAN, since the APs will also need to...
3.) Firmware and IPs.
It is running the latest firmware - still in Beta mode (as explained in one of my earlier posts) - but the latest.
I'm already being pushed just trying to get my head around the above - so nope, wouldn't have put it past me to get a basic like NOT allocating similar IPs to the same device! I'm not even sure where to go and check.
I think the major spanner in the works, was me tinkering with OSX Server. Wish I had never gone down that road. [Will check in the Take Control Book what is was that I actually switched on - and pop something up below in a minute.]
I'm pretty sure I've created a right-royal mess with that, which is potentially running the interference. I was about to pop something up in the Server sub-forum, to ask what the cleanest route would be to remove it, and restore everything to default.
About two hours ago, I managed to get the Ethernet to stay connected, for all of 10 minutes, after messing around with switching things off [Open Directory??] over in Server. I couldn't connect to the internet, but at least the Ethernet preference setting wasn't jumping around like crazy.... and then - it started again. I
think due to the Server software resetting something, and overriding my temporary IP settings in Preferences, to what I had specified in setting up that part inside Server.
I am embarrassed by how nonsensical the above must sound to someone who actually knows what they are doing. I always thought of myself as being quite proficient around a PC/Mac - but goodness, this has brought me down to earth with a bump! Really appreciate the help!
[doublepost=1484488679][/doublepost]
Was it ever working with the same router before on lan? Easiest way to check where the problem lies would be to try it on another router (preferably of another make/brand) or change a lan cable.
I've changed LAN cables, so doesn't appear to be that.
Cannot say whether it ever worked properly before, since I never had a reason to wire something via LAN - had always managed with Wifi - and unfortunately, do not have a spare router lying around.
That said, as mentioned above, I briefly had the ethernet working a while back for a few minutes, which increasingly points to the issue being with how things have been set up, rather than it being a hardware problem.
