v1.4.8 Bug reports and Comments

DOWNLOAD THE LATEST FIRMWARE HERE
User avatar
ste
Member
 
Posts: 84
Joined: Fri May 22, 2015 5:33 am
Location: Regensburg Germany
Has thanked: 2 times
Been thanked: 13 times

Re: v1.4.8 Bug reports and Comments

Wed Nov 29, 2017 4:39 am

ste wrote:
sirhc wrote:What is the MTU set on the radios in the bridge and the MT ?


Default settings. I look tomorrow. But as the Mikrotik Discovery packets aren't that big I guess this could not be the problem.



SIAE link is set to max packet size = 2048.

I removed all ports not used from vlan. vlan22 is the managment vlan of the SIAE link. There is one laptop attached to mangage both SIAEs from one side. This works. The link is configured to pass untagged traffic through. Vlan2 is used for this. Managment Vlan of Netonix switches is 1. This is used only to manage both netonix switches.

I cant see a problem why Netonix30 does not forward the Discovery packets of gw73 to the link. Replacing Netonix30 with a POE-Adapter make it work without any config change.
Attachments
gw73.png
gw66.png
N38_3.jpg
N38_2.jpg
N38_1.jpg
N30_3.jpg
N30_2.jpg
N30_1.jpg

IntL-Daniel
Experienced Member
 
Posts: 170
Joined: Mon Nov 02, 2015 5:07 pm
Location: Czech Republic
Has thanked: 7 times
Been thanked: 9 times

Re: v1.4.8 Bug reports and Comments

Wed Nov 29, 2017 3:53 pm

What is "Reset OCP" purpose in each port options? Thanks.

Ludvik
Experienced Member
 
Posts: 105
Joined: Tue Nov 08, 2016 1:50 pm
Has thanked: 15 times
Been thanked: 15 times

Re: v1.4.8 Bug reports and Comments

Thu Nov 30, 2017 6:36 am

Difference in uptime SNMP values:

Code: Select all
 #snmpget -v 1 -c public curve1.malin .1.3.6.1.2.1.1.3.0
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (879909896) 101 days, 20:11:38.96

#snmpget -v 1 -c public curve1.malin 1.3.6.1.2.1.25.1.1.0
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (3154353) 8:45:43.53


True is second value - in this time I upgraded this switch (WS-6-MINI).

Before upgrade first value had cca 135 days.

User avatar
sirhc
Employee
Employee
 
Posts: 7416
Joined: Tue Apr 08, 2014 3:48 pm
Location: Lancaster, PA
Has thanked: 1608 times
Been thanked: 1325 times

Re: v1.4.8 Bug reports and Comments

Thu Nov 30, 2017 12:08 pm

IntL-Daniel wrote:What is "Reset OCP" purpose in each port options? Thanks.


THats was a mistake, it should not have been visible in the UI.

We are working on replacing PolyFuses with active current sensing so as to be able to protect the switch from dead shorted cables or users drawing too many watts and thus damaging the switch.

Selecting the option will do nothing as the hardware that software feature controls is not present.

So call it a blunder and ignore it please.
Support is handled on the Forums not in Emails and PMs.
Before you ask a question use the Search function to see it has been answered before.
To do an Advanced Search click the magnifying glass in the Search Box.
To upload pictures click the Upload attachment link below the BLUE SUBMIT BUTTON.

User avatar
Eric Stern
Employee
Employee
 
Posts: 532
Joined: Wed Apr 09, 2014 9:41 pm
Location: Toronto, Ontario
Has thanked: 0 time
Been thanked: 130 times

Re: v1.4.8 Bug reports and Comments

Thu Nov 30, 2017 1:18 pm

Ludvik wrote:Difference in uptime SNMP values:

Code: Select all
 #snmpget -v 1 -c public curve1.malin .1.3.6.1.2.1.1.3.0
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (879909896) 101 days, 20:11:38.96

#snmpget -v 1 -c public curve1.malin 1.3.6.1.2.1.25.1.1.0
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (3154353) 8:45:43.53


True is second value - in this time I upgraded this switch (WS-6-MINI).

Before upgrade first value had cca 135 days.


After the clock is set by NTP it is supposed to restart snmp so that sysUpTime is correct, I guess it didn't happen for some reason. Restarting snmp or rebooting should fix it.

User avatar
KBrownConsulting
Member
 
Posts: 71
Joined: Wed Dec 14, 2016 3:29 pm
Has thanked: 15 times
Been thanked: 17 times

Re: v1.4.8 Bug reports and Comments

Fri Dec 01, 2017 5:05 am

@Eric

Unless I totally misunderstand what the "Startup" option does, the logs you posted appear to confirm the issue that was reported...

The log you posted shows that after bouncing the port the switch is not waiting the 300 seconds specified as the startup period before pinging the device again. The whole point of the Startup interval (at least my understanding of it) is to give the attached device enough time to reboot after a bounce in order to prevent a boot loop!





Eric Stern wrote:
Julian wrote:
jschroeter wrote:PING WATCHDOG

We are having issues with ping watchdog where it seems that the start up interval is not happening.

Settings are to ping an address Startup = 300 Interval = 10 Failures = 3 Action =Bounce

Upon testing I ping an address that I can turn off, and first port bounce happens at about 30 seconds, but then it bounces again about every 30 seconds. Watchdog is not waiting the 300 second startup interval.

Seems to have been working on 1.4.2.

Please Assist.


this has been duplicated and is being looked into.


Tested on 1.4.8, seems to work fine.

Code: Select all
Dec 31 19:00:06 netonix: 1.4.8 on WS-12-250-AC
Dec 31 19:00:10 system: Setting MAC address from flash configuration: EC:13:B2:FF:FF:BB
Dec 31 19:00:12 system: starting ntpclient
Dec 31 19:00:13 admin: adding lan (eth0) to firewall zone lan
Nov 23 10:27:32 dropbear[742]: Running in background
Nov 23 10:27:35 switch[783]: Detected warm boot
Nov 23 10:33:03 switch[777]: Watchdog 'Port 3' failure checking 192.168.2.12, watchdog triggered on port 3 (Port 3), action is Bounce
Nov 23 10:33:42 switch[777]: Watchdog 'Port 3' failure checking 192.168.2.12, watchdog triggered on port 3 (Port 3), action is Bounce
Nov 23 10:34:21 switch[777]: Watchdog 'Port 3' failure checking 192.168.2.12, watchdog triggered on port 3 (Port 3), action is Bounce
Nov 23 10:35:00 switch[777]: Watchdog 'Port 3' failure checking 192.168.2.12, watchdog triggered on port 3 (Port 3), action is Bounce


What is in your log?

User avatar
ste
Member
 
Posts: 84
Joined: Fri May 22, 2015 5:33 am
Location: Regensburg Germany
Has thanked: 2 times
Been thanked: 13 times

Re: v1.4.8 Bug reports and Comments

Fri Dec 01, 2017 6:31 am

ste wrote:
ste wrote:
sirhc wrote:What is the MTU set on the radios in the bridge and the MT ?


Default settings. I look tomorrow. But as the Mikrotik Discovery packets aren't that big I guess this could not be the problem.



SIAE link is set to max packet size = 2048.

I removed all ports not used from vlan. vlan22 is the managment vlan of the SIAE link. There is one laptop attached to mangage both SIAEs from one side. This works. The link is configured to pass untagged traffic through. Vlan2 is used for this. Managment Vlan of Netonix switches is 1. This is used only to manage both netonix switches.

I cant see a problem why Netonix30 does not forward the Discovery packets of gw73 to the link. Replacing Netonix30 with a POE-Adapter make it work without any config change.


Replaced with an EdgeSwitch. Works now. Some kind of incompatibility between WS-8-150-AC and SIAE (The WS-12-250-AC on the other side does not show this problem). As I cant get a solution I have to replace Netonix on sites where I want to use SIAE.

User avatar
sirhc
Employee
Employee
 
Posts: 7416
Joined: Tue Apr 08, 2014 3:48 pm
Location: Lancaster, PA
Has thanked: 1608 times
Been thanked: 1325 times

Re: v1.4.8 Bug reports and Comments

Fri Dec 01, 2017 9:57 am

Some kind of incompatibility between WS-8-150-AC and SIAE (The WS-12-250-AC on the other side does not show this problem).



There is "nothing" different between any of our switch models, they all use the exact same switch core, and exact same firmware.

If a WS-12-250-AC works and a WS-8-150-AC does not then there has to be something you missed?

ste wrote: SIAE link is set to max packet size = 2048.


Yet you have the Netonix MTU set to 1600 on your Ports TAB screen grab above ??????

Increase the MTU on the Netonix to 2048 or higher, I would set the Netonix switch higher, say 2048 + 6 = 2054 as some manufacturers add padding to their MTU setting for user error we do not.
Support is handled on the Forums not in Emails and PMs.
Before you ask a question use the Search function to see it has been answered before.
To do an Advanced Search click the magnifying glass in the Search Box.
To upload pictures click the Upload attachment link below the BLUE SUBMIT BUTTON.

User avatar
Eric Stern
Employee
Employee
 
Posts: 532
Joined: Wed Apr 09, 2014 9:41 pm
Location: Toronto, Ontario
Has thanked: 0 time
Been thanked: 130 times

Re: v1.4.8 Bug reports and Comments

Fri Dec 01, 2017 10:45 am

KBrownConsulting wrote:@Eric

Unless I totally misunderstand what the "Startup" option does, the logs you posted appear to confirm the issue that was reported...

The log you posted shows that after bouncing the port the switch is not waiting the 300 seconds specified as the startup period before pinging the device again. The whole point of the Startup interval (at least my understanding of it) is to give the attached device enough time to reboot after a bounce in order to prevent a boot loop!



Actually the Startup value is only used when the switch first boots, to allow time for the switch to establish full network connectivity before ping monitoring begins.

If the bounced device needs time to reboot etc you need to set the Interval high enough to allow for that. Actually as long as the device comes back up before (Interval * Failures) seconds have passed it should be ok.

User avatar
ste
Member
 
Posts: 84
Joined: Fri May 22, 2015 5:33 am
Location: Regensburg Germany
Has thanked: 2 times
Been thanked: 13 times

Re: v1.4.8 Bug reports and Comments

Sat Dec 02, 2017 2:05 am

sirhc wrote:
Some kind of incompatibility between WS-8-150-AC and SIAE (The WS-12-250-AC on the other side does not show this problem).



There is "nothing" different between any of our switch models, they all use the exact same switch core, and exact same firmware.

If a WS-12-250-AC works and a WS-8-150-AC does not then there has to be something you missed?

ste wrote: SIAE link is set to max packet size = 2048.


Yet you have the Netonix MTU set to 1600 on your Ports TAB screen grab above ??????

Increase the MTU on the Netonix to 2048 or higher, I would set the Netonix switch higher, say 2048 + 6 = 2054 as some manufacturers add padding to their MTU setting for user error we do not.


How should this help small cdp packets pass the switch? Siae distributor wanted me to check the routing table... I dont like this supporters telling me anything that comes to their mind just to keep me working and be quiet for a while. This is the reason we seized using cambium. When they have a problem support keeps you busy.

PreviousNext
Return to Hardware and software issues

Who is online

Users browsing this forum: No registered users and 67 guests