However, when connecting via IPv4, I’m certain that it remains on https://192.168.0.2. I’ve tried the IPv6 address and of course that didn’t work either.
URIs are codified because I’m a new user.
Any solutions or enquiries that might assist diagnosis? I don’t want to have to reset this router if I don’t have to, since it contains important WOL information that I don’t want to have to manually add again.
Perhaps you could expand a little more on what was configured on the device? Was the LAN zone set to a static IP, or set to obtain the address using DHCP?
Are you able to access the Web interface of the new modem? Perhaps it is currently configured in bridge mode and the only available address is being assigned to the RUTXR1?
Finally, perhaps you have a RJ45 Console → USB cable available? This way you could access the device CLI and edit the LAN zone to run its own DHCP server.
I’m confident that the AP’s IP was static, because I would have had to port scan to connect to its GUI if I’d rebooted the gateway since the previous time, right? Devices connecting to it were set to use DHCP IPv6 (and 4, I think).
I can’t imagine it would be doing so, since TNCAPD0390D, the gateway and modem, shouldn’t recognize SKYAD09C, the Teltonika RUTXR1 AP, as anything except a separate, unrelated network.
I’ve never heard of an RJ-35 to USB cable. I only have RJ-45 male to male available. Must one end be USB? By the way, I’ve been connecting via LAN1 to LAN4, not the Console (nor WAN, obviously) port.
Do you have any information about what that would entail? I’m no network expert, as you might have surmised.
If the RUTXR1 was configured with static IPv6 entry, they most likely do not match the current LAN IP. You’ll need to set a static IP (either in IPv4 or IPv6) in the same range as the previous modem was configured in, then you should be able to reach the WebUI of the router. Set the LAN zone to DHCP (or change to a different static entry within the new network), and remove the static IP from your PC. On the ISP provided modem, you should see a DHCP lease for the RUTXR1, and should be able to reach the WebUI using this address.
That is correct.
In the future, if the gateway address changes, the RTUXR1 will simply receive a lease from the new network and will remain reachable. How to discover the RUTXR1 address depends on the gateway used, however, most of them show a list of DHCP leases, and RUTXR1 should advertise it’s hostname, so it shouldn’t be hard to identify it.
Connecting via the hostname can be tricky. Since the RUTXR1 is not the DNS resolver within your network, the gateway will not know the IP address of the rutxr1.lan hostname. However, if the RUTXR1 is used as the main router, it will be possible to resolve the name:
However, Google Chrome simply performs a search if you only enter rutx50.lan, you need to use http://rutx50.lan, at which point it may be easier to just use the IP address.
If I’m connected via the AP, would that be different? I expect it would intercept the packet and verify that the hostname does not correlate to one on it, but perhaps that would be too easy. Is there no way to let the gateway know what subnets have defined domains of local?
The problem with DHCP is that I want a standard way to programmatically access the device too, and unless I can connect using a MAC address, the hostname seems the only way to do so.
The RUTXR1 is configured in your network as the “dumb AP”. To put it simply, it does not intercept the data it receives, but rather it sends it straight to the gateway.
If you’d like it to perform DNS resolution, etc., you’ll need to configure the RUTXR1 in L3 mode, where WAN and LAN ports are being utilized.
Apologies for not clarifying.
What I meant by L3 (Layer 3) mode, is that the RUTXR1 should do the routing and assigning the DHCP leases, not the ISP gateway. This is what people most commonly associate with routers. Simply plug your gateway into the RUTXR1 WAN port, enable the DHCP server on LAN and that’s it!
If your gateway supports it, you could also configure it in Bridge mode to avoid double-NATing.