Im testing some of the C6x’s and cant get access to the GUI if its connected to the AP. This is a test setup so im abloe to find the DHCP address with ease. Itll respond to pings yet will NOT connect. There are no VLANS on either the AP or the CPE. I can access it via the ethernet port upon a reboot, yet as soon as it connects and gets an address i loose coms and the gui locks up. If tried accessing it across the link from the AP side and from the ethernet port on the C6x, outcome is the same regardless. Like i said, im able to easily find the address that its receiving and it responds to pings, yet the gui is not accessable via this address. What am i missing???
1 Like
Seriously can someone please help! im about to loose my crap on this gear! The damn antenna is set to DHCP, it pulling an address of 10.10.10.3 with no VLANS. I can ping that address all day long, yet the GUI will not load! a complete lack of app or anything means that we have no way to align these antennas once they connect.
1 Like
Just guessing, but it doesn’t take much throughput to get the pings to work. Can you access the GUI through the C6x’s Ethernet interface? That’s what may need to be done until you get it aligned close enough to get the throughput needed for the web interface.
No, that’s what I’m saying is that the GUI to the C6X is not accessible via the ethernet port, nor via the wireless link. I can plug directly into the ethernet port on the C6x and still not be able to access the GUI. This is all in a test environment so I’m 100% positive of the ip address, it’s literally the only address taken out of the DHCP pool.
Also, I’m able to speedtest out to the internet around 700 mbps up and down so it’s not a throughput issue.
OK. When you said you couldn’t connect when connected to the AP, I though maybe it was just the unaimed wireless link. Sorry.
I was having the same problem. I gave up on it.
Please put " https:// " before ip address in your browser
1 Like
That actually solved the problem! Thank you!
1 Like
We had this problem three days ago and will try the https tomorrow.
But there is another issue. The B5c does not allow a connect via browser over the RF path unless there is something plugged into the far Ethernet (POE) port and it is working. This prevents any config changes from being made from the AP end in PTP. For example, changing the static IP address so the far end will connect to a network. Or changing TX power.
So it you don’t have working Ethernet on the station end in PTP you can’t change parameters from the AP end. This makes us drive the 45km to the other end. Time consuming and costly when you are paying tower climbers by the hour. We did not try from the station to the AP but I assume it works the same way.
It would be really helpful (and work like other brands) if this problem was fixed.
Jim
@Jim10 this is the first time I’ve ever heard of this. I have a multitude of PTP and PTMP radios setup without anything connected to the Ethernet port and can get to it and configure it just fine.
I stand corrected.
What actually happened is the radio got set to DHCP + static. We had been talking to it at the far end using the static IP but it kept failing to answer using the web interface. We could ping the static so we assumed it was working and we could browse to it, but that didn’t work, or only worked for a few seconds then stopped answering. We were swapping browsers and computers for quite a while before we gave up for the day. The next day we finally were able to see from the AP end that the far radio had pulled a DHCP address when we plugged it into our network. We could browse to that both over the link and locally. I changed that setting to static only and it has been fine.
I don’t know how the radio got set to that. I had set both ends to static on the bench and had them running for a couple of days before we did the install.
Very confusing. I supposes there is a condition when DHCP + static would make sense, but I don’t know what that would be. I guess I don’t understand which takes precedence or which address is used at any given moment.
Jim
From what I’ve seen, the DHCP+Static defaults to a DHCP address, if it can get one, and uses the set Static address, instead of an APIPA address, if DHCP fails. It doesn’t appear to be 2 simultaneous addresses. I guess it’s so that you could set an address to work on the device on the bench, but have it pick up a DHCP address in the field without having to change anything (or vice-versa).
If set to DHCP, without getting a DHCP address, it should default to its built-in default address (i.e. it doesn’t use APIPA anyway), but if you’re bench testing, you can’t have them all on the same default address, so you could set one, but have DHCP work when the device got to the field.
Thanks Wayne. I’m guessing we just didn’t get DCHP+static set to static on the bench. We entered a static and used it, but it was not connected to a DHCP server so this issue didn’t pop up until we installed it.
Lesson learned.
Jim