NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
GS108PEv3 and GS105PE work but not reachable
My topology:
AT&T Pace router -- IQrouter -- GS108PEv3 -- GS105PE - access points
Both GS devices are brand new. They work correctly, essentially plug-n-play out of the box. Devices wired to the 108 work fine. The 108 powers the 105 fine. Devices wired to the 105, and WiFi devices on the access points on the 105 work fine.
The IP addresses for both devices are visible in the IQrouter's listing but no hostname is associated.
The 108 can't be pinged, no matter where my Mac is plugged in. "request timeout for icmp_seq" even when plugged directly into it.
The 105 can be pinged.
Neither device will provide an admin page at https://ipaddress.
I installed the ProSAFE utility in Windows, and it cannot see any switches.
I plugged my Mac directly into the 108, did factory reset, tried static IP on my mac and tried the default .239 address. Cannot ping or https.
So they are working but I cannot reach them to manage them in any way.
rsworden wrote:AT&T Pace router -- IQrouter -- GS108PEv3 -- GS105PE - access points
Both GS devices are brand new. They work correctly, essentially plug-n-play out of the box. Devices wired to the 108 work fine. The 108 powers the 105 fine. Devices wired to the 105, and WiFi devices on the access points on the 105 work fine.
The IP addresses for both devices are visible in the IQrouter's listing but no hostname is associated.
This does read like both switches DHCP client are working and get an IP config from the DHCP server on the router. A hostname is not "associated" - a DHCP client does not have to provide a hostname with the request, so the hostname can remain empty. Nothing wrong to that point
rsworden wrote:
The 108 can't be pinged, no matter where my Mac is plugged in. "request timeout for icmp_seq" even when plugged directly into it.
The 105 can be pinged.
Potentially something wrong or broken on the 108. I would suggest to reset (restet button) and bring it up with jut a Mac or Windows system connected (without any other connection to the router or other systems). More below.
rsworden wrote:
Neither device will provide an admin page at https://ipaddress.
This switch class/models don't support https - use http on port 80.
rsworden wrote:
I installed the ProSAFE utility in Windows, and it cannot see any switches.
There is a nice Netgear Switch Discovery Tool available for both Windows and macOS - perfectly sufficient for the pure discovery (and much less intrusive than the ProSafe Plus Utility with the network capture driver).
rsworden wrote:
I plugged my Mac directly into the 108, did factory reset, tried static IP on my mac and tried the default .239 address. Cannot ping or https.
If you expect the router fall-back to it's default IP address, you must run it without any connection ie. to the router with the DHCP server. Disconnect all network cables, just keep a link to one computer (Mac or Win does not matter - except of that we would have the ProSafe Plus Utility available on Windows).
Both Windows and macOS systems will auto-configure ZeroConfig addresses on the network interface if there is no DHCP server resp. no fixed network config. Therefore, you need to manually apply a fixed (or alternate) network config into the 192.168.0.0/24 255.255.255.0 network - just use unique addresses (not .239).
Now you can try to ping the 192.168.0.239, discover it, or use a Web browser and call http://192.168.0.239/.
12 Replies
- Both switches have the same IP address out of the box, so you may have difficulty logging into them when they are connected together.
Remove one of the switches, then log into the other and change its IP address. Then you should be able to connect them together.
rsworden wrote:AT&T Pace router -- IQrouter -- GS108PEv3 -- GS105PE - access points
Both GS devices are brand new. They work correctly, essentially plug-n-play out of the box. Devices wired to the 108 work fine. The 108 powers the 105 fine. Devices wired to the 105, and WiFi devices on the access points on the 105 work fine.
The IP addresses for both devices are visible in the IQrouter's listing but no hostname is associated.
This does read like both switches DHCP client are working and get an IP config from the DHCP server on the router. A hostname is not "associated" - a DHCP client does not have to provide a hostname with the request, so the hostname can remain empty. Nothing wrong to that point
rsworden wrote:
The 108 can't be pinged, no matter where my Mac is plugged in. "request timeout for icmp_seq" even when plugged directly into it.
The 105 can be pinged.
Potentially something wrong or broken on the 108. I would suggest to reset (restet button) and bring it up with jut a Mac or Windows system connected (without any other connection to the router or other systems). More below.
rsworden wrote:
Neither device will provide an admin page at https://ipaddress.
This switch class/models don't support https - use http on port 80.
rsworden wrote:
I installed the ProSAFE utility in Windows, and it cannot see any switches.
There is a nice Netgear Switch Discovery Tool available for both Windows and macOS - perfectly sufficient for the pure discovery (and much less intrusive than the ProSafe Plus Utility with the network capture driver).
rsworden wrote:
I plugged my Mac directly into the 108, did factory reset, tried static IP on my mac and tried the default .239 address. Cannot ping or https.
If you expect the router fall-back to it's default IP address, you must run it without any connection ie. to the router with the DHCP server. Disconnect all network cables, just keep a link to one computer (Mac or Win does not matter - except of that we would have the ProSafe Plus Utility available on Windows).
Both Windows and macOS systems will auto-configure ZeroConfig addresses on the network interface if there is no DHCP server resp. no fixed network config. Therefore, you need to manually apply a fixed (or alternate) network config into the 192.168.0.0/24 255.255.255.0 network - just use unique addresses (not .239).
Now you can try to ping the 192.168.0.239, discover it, or use a Web browser and call http://192.168.0.239/.> use http on port 80
Yeah, somewhere in all the tech notes I thought it said https.
I disconnected all cables from the 108 except my Mac and factory reset it. When I reconnected it (alone) to the router, it got a new address from DHCP and after that it was pingable and answered properly to http.
Then I reconnected all the cables including the 105. I did NOT factory reset it, but it began answering properly to http.
I guess the original issue was that I had connected the 105 to the 108, then when I connected the 108 to the router they conflicted over the .239 address. That was not obvious, because each had also received an address from DHCP. But I guess they each had not fully abandoned the .239 address. So the lesson is to only hook up one at a time, since they are all hard-coded to use .239.
Thanks for mentioning the Mac discovery tool... I had not found that in the various tech notes. It would be nice if the paper Installation Guides included with the devices could be updated to mention it, instead of saying that only a Windows version is available. The Mac tool found both my switches and the names I assigned to them. The Windows tool still does not work, but now I don't need it.
Thank you all for the help!
rsworden wrote:I guess the original issue was that I had connected the 105 to the 108, then when I connected the 108 to the router they conflicted over the .239 address. That was not obvious, because each had also received an address from DHCP. But I guess they each had not fully abandoned the .239 address. So the lesson is to only hook up one at a time, since they are all hard-coded to use .239.
This is a typical default behaviour of many embedded systems. If the DHCP client does not succeed getting an IP configuration within a reasonable time, the config does fail back to a default IP address, here the .239.
Different, modern desktop and server OS fall-back to either a static configuration (if configured), or to a local-link address in the ZeroConf address space - IPv4 uses the special block 169.254.0.0/16 as per RFC 3927, while IPv6 hosts use the prefix fe80::/10. Now one could think about changing Netgear specs towards local-link addressing as the last resort (no static IP configured, no DHCP config). This would allow to connect a Windows or macOS network interface without having to temporarily reconfigure the interface to the 192.168.0.0/24 network - but then some additional discovery method would be required to find the "right" address. More and more device firmware is coming with UPnP and Bonjour device announcement - in some years we might see a change in tis direction.
rsworden wrote:
Thanks for mentioning the Mac discovery tool... I had not found that in the various tech notes. It would be nice if the paper Installation Guides included with the devices could be updated to mention it, instead of saying that only a Windows version is available. The Mac tool found both my switches and the names I assigned to them. The Windows tool still does not work, but now I don't need it.
The NETGEAR Switch Discovery Tool is rather new, thus it does not exist on the QSG and UG of products in the market already longer. In fact it's one of the results of community and user feedback sessions held the last year. And I'm happy Netgear listened to us.
Glad it helped to bring your switches under management control.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
