v1.3.8 FINAL bug reports and comments

[sirhc]

I've reviewed the code and tested it and I don't see any way it could go wrong. I'm going to have to suggest that its not a bug and the AP is working enough that the ping check is successful, so the ping watchdog is not being triggered.

I'd recommend that the next time it happens before you manually bounce it, log into the switch and ping the AP from the command line. The actual command the ping watchdog uses is "ping -c 3 -W 1 <ip>", which pings 3 times and times out after 1 second. Unless there is 100% packet loss the script considers the ping successful.

I will test it, but I am 100% certain it is 100% packet loss as this is a known issue where XW Titanium rockets have the LAN port randomly "lockup" and stop passing data when running 1G.

Also my switch and APs are in different subnets/vlans so if the tower router cannot ping the AP I do not know how the switch would be able to ping it and get enough replies to not trip the watchdog.

Again I will do as you suggest and report back next time it happens.

Hey,

They did have this lockup (Titaniums) you speak of but I thought was fixed in firmware and you no longer need/want to hard code port speed duplex?

Are you hard coding speed duplex on the port and radio, if you are go back to Auto. I know this is a different topic then the ping watchdog failing which you will check but just wanted to interject on speed duplex issue.

[sbyrd]

I've reviewed the code and tested it and I don't see any way it could go wrong. I'm going to have to suggest that its not a bug and the AP is working enough that the ping check is successful, so the ping watchdog is not being triggered.

I'd recommend that the next time it happens before you manually bounce it, log into the switch and ping the AP from the command line. The actual command the ping watchdog uses is "ping -c 3 -W 1 <ip>", which pings 3 times and times out after 1 second. Unless there is 100% packet loss the script considers the ping successful.

I will test it, but I am 100% certain it is 100% packet loss as this is a known issue where XW Titanium rockets have the LAN port randomly "lockup" and stop passing data when running 1G.

Also my switch and APs are in different subnets/vlans so if the tower router cannot ping the AP I do not know how the switch would be able to ping it and get enough replies to not trip the watchdog.

Again I will do as you suggest and report back next time it happens.

Hey,

They did have this lockup (Titaniums) you speak of but I thought was fixed in firmware and you no longer need/want to hard code port speed duplex?

Are you hard coding speed duplex on the port and radio, if you are go back to Auto. I know this is a different topic then the ping watchdog failing which you will check but just wanted to interject on speed duplex issue.

No it has not ever been fixed. I am definitely not hard coding the duplex. It is full auto. As an aside have you put any thought into allowing the Netonix switch to have check boxes that define what link speeds the switch advertises. That way I could disable 1G and still have the switch auto neg 100full? UBNT has implemented it in the AC radios and Mikrotik on their routers.

[sbyrd]

I've reviewed the code and tested it and I don't see any way it could go wrong. I'm going to have to suggest that its not a bug and the AP is working enough that the ping check is successful, so the ping watchdog is not being triggered.

I'd recommend that the next time it happens before you manually bounce it, log into the switch and ping the AP from the command line. The actual command the ping watchdog uses is "ping -c 3 -W 1 <ip>", which pings 3 times and times out after 1 second. Unless there is 100% packet loss the script considers the ping successful.

I will test it, but I am 100% certain it is 100% packet loss as this is a known issue where XW Titanium rockets have the LAN port randomly "lockup" and stop passing data when running 1G.

Also my switch and APs are in different subnets/vlans so if the tower router cannot ping the AP I do not know how the switch would be able to ping it and get enough replies to not trip the watchdog.

Again I will do as you suggest and report back next time it happens.

Well it happened again today. AP went down around 4am and when I woke up at 7am it was still down and unpingable. I tried the command you gave me from the switch console and it would not run. Instead I ran a normal ping and the switch showed 100% packet loss.

I am certain the switch is not even receiving one ping from the AP during the outage as we ping the AP from our core in our SNMP monitor once a minute and it did not get a single hit. I cannot see how the switch during this ~3 hour outage did not miss 3 pings when the interval is 120 seconds and my SNMP monitor did not also record a hit.

[Eric Stern]

Well it happened again today. AP went down around 4am and when I woke up at 7am it was still down and unpingable. I tried the command you gave me from the switch console and it would not run. Instead I ran a normal ping and the switch showed 100% packet loss.

I am certain the switch is not even receiving one ping from the AP during the outage as we ping the AP from our core in our SNMP monitor once a minute and it did not get a single hit. I cannot see how the switch during this ~3 hour outage did not miss 3 pings when the interval is 120 seconds and my SNMP monitor did not also record a hit.

I changed how the ping watchdog works in 1.3.9rc13. If that doesn't help I also added some debugging code that should help track down the problem.

[lligetfa]

I changed how the ping watchdog works in 1.3.9rc13...

Are we going to get rc13 on Friday?

[maxbb]

I am using wispswitch-1.3.8 on a WS-12-250-AC and when I change the IP and click on Save/Apply it will reboot but reverts back to same IP that was on device. the only way i can change the IP on the device is to push and hold reset button to factory defaults and enter desired IP.

[sirhc]

I am using wispswitch-1.3.8 on a WS-12-250-AC and when I change the IP and click on Save/Apply it will reboot but reverts back to same IP that was on device. the only way i can change the IP on the device is to push and hold reset button to factory defaults and enter desired IP.

Changing the IP does not cause the unit to reboot, it does not work that way.

The only other thing I can think of is the reset/default button is stuck which you can check with a paper clip. If you push the button in and feel a click then the button is fine.

The other thing is to hook up a console cable and watch the unit boot. You will see where it asks for the default button to be pressed and if it reports the button was pressed and you did not press it then the button may be faulty.

If you have Team Viewer v11 I would be happy to call you later and Team View into your computer.

Also I moved your post to the appropriate thread, you sorta hijacked the last thread.

[maxbb]

ok that would be great!
Reboot may be the wrong term all i meant to say is when i click change/apply the switch appears to apply to switch meaning the browser redirects to ip i entered but the unit does not take ip change, and stays on same ip that was previously applied to switch. when i reset switch to factory it will take the first ip change from default 192.168.1.20 but after that first ip change it wont allow the ip to change.

[sirhc]

ok that would be great!
Reboot may be the wrong term all i meant to say is when i click change/apply the switch appears to apply to switch meaning the browser redirects to ip i entered but the unit does not take ip change, and stays on same ip that was previously applied to switch. when i reset switch to factory it will take the first ip change from default 192.168.1.20 but after that first ip change it wont allow the ip to change.

I am working on something else right now so I asked Eric to investigate your claim of a possible bug.

[Eric Stern]

ok that would be great!
Reboot may be the wrong term all i meant to say is when i click change/apply the switch appears to apply to switch meaning the browser redirects to ip i entered but the unit does not take ip change, and stays on same ip that was previously applied to switch. when i reset switch to factory it will take the first ip change from default 192.168.1.20 but after that first ip change it wont allow the ip to change.

Tested on my switches, works fine.

The only thing I can think of is that you need to login to the UI at the new address within 60 seconds or it will revert to the previous configuration. If this happens there will be a message in the log.