v1.3.3 FINAL bug reports and comments

[jvince]

VLANs:

VLANs.png (47.45 KiB) Viewed 8116 times

Configuration:

Configuration.png (106.58 KiB) Viewed 8116 times

MAC Table before backup/restore:

MAC-Before.png (79.57 KiB) Viewed 8116 times

MAC Table after backup/restore:

MAC-After.png (47.96 KiB) Viewed 8116 times

[Eric Stern]

I have had problems with the MAC Table as well since upgrading from v1.3.2 to v1.3.3. When I go to the MAC table, there are no entries.

I reset my WS-24-400A to defaults and manually made my VLAN and configuration changes one at a time to see if a particular change caused the MAC table to break, but nothing did. I then backed up the config and uploaded it to my 2nd WS-24-400A, which had just been upgraded to v1.3.3 w/ default settings. The MAC table stopped functioning on the 2nd switch when I uploaded my config.

To test my theory that uploading a config somehow caused a problem with the MAC table, I uploaded the config onto the 1st switch; this should not have created any changes since the config was pulled from this switch a few minutes prior. After uploading the config, I no longer saw any entries in the MAC table.

I can't duplicate this either. If you could follow these steps and post the output it would be really helpful.

When the mac table is empty, open the console (Device tab -> Console) and enter the following commands:

Code: Select all

cmd
cat /tmp/mac_ip.txt
cat /tmp/mactable.json
 

Netonix Switch# cmd

BusyBox v1.19.4 (2015-08-14 15:50:44 EDT) built-in shell (ash)
Enter 'help' for a list of built-in commands.
admin@Netonix_Switch:/www# cat /tmp/mac_ip.txt
e0-3f-49-17-18-48 192.168.2.8
admin@Netonix_Switch:/www# cat /tmp/mactable.json
{ "MACTable": [
{ "MAC": "e0-3f-49-17-18-48", "Port": "1", "VLAN_ID": 1000, "Manufacturer": "ASUSTek COMPUTER INC.", "Last_IP": "192.168.2.8" }
] }
admin@Netonix_Switch:/www#

[jww]

OK, I give up trying to insert a screenshot on this forum.

Here is the text from the upgrade to 1.3.3:

Uploading firmware file ...Unpacking firmware ...
Error: Cannot downgrade past 1.3.4


Well, now that I'm looking at the switch status it shows that it shipped with 1.3.4. This is a WS-8-250-DC that arrived yesterday.

So the switched shipped with newer firmware than is available on the forums?

I'm OK, just checking... :)

[sirhc]

OK, I give up trying to insert a screenshot on this forum.

Here is the text from the upgrade to 1.3.3:

Uploading firmware file ...Unpacking firmware ...
Error: Cannot downgrade past 1.3.4


Well, now that I'm looking at the switch status it shows that it shipped with 1.3.4. This is a WS-8-250-DC that arrived yesterday.

So the switched shipped with newer firmware than is available on the forums?

I'm OK, just checking... :)

We had to upgrade the firmware on the DC switches we were building to facilitate a desired ability we "may" want in the future.

Basically v1.3.4 is v1.3.3 except that it has this ability built in for the DC switch power supply micro firmware and bootloader. If we ever decide to do it in the future. The first batch of DC switches shipped obviously will never have that ability if we even ever decide to do it. So v1.3.4 is an unpublished firmware, the next release will be v1.3.5 which all switches will be able to upgrade too.

Since this is not an advertised ability we are not going to disclose this "possible" ability that we "may" decide to implement in the future because it would tip our hat to our competition.

However if we ever do implement this ability we will offer people with one of the 200 first DC switches shipped in July/August the option to ship them back to us so we can flash the changes to the bootloader on the DC power supply FREE of charge which is the only way to change the bootloader on the DC Power supply Micro.

So since the switch firmware contains an APP (not the boot loader) for the DC power supply which we may change from time to time we had to make the DC switches unable to downgrade past what was shipped on them.


To upload a picture you click "Upload attachment" browse to file (.JPG) then put your cursor where in your post you want it then click "Insert image"

DC Switch.jpg (47.64 KiB) Viewed 8095 times

[menacers]

We have an issue with 1.3.2 regarding VLANS and mac address tables. When we are exempting a port from the VLAN using the VLANs tab gui, it shows that it is exempted but the behavior is that it is not actually exempted! I can still see mac addresses from the port which I exempted, they still exist in the mac address table. I noticed this several times when exempted a port from a vlan and enabled a different port on the same vlan with a client with the same IP address (different mac). I could never get this work properly unless I disabled the client on the exempt port. without doing so, the switch would send traffic to exempt port! This condition existed for days and did not fix itself until i actually disabled the client from the exempt port. Although there are times when i tried this same configuration and it worked within 15 minutes (perhaps the ageing timer timeout?)

I'm wondering if this issue would be fixed in 1.3.3, as its a real showstopper. When you exempt a port from a VLAN, it absolutely needs to be exempted! :) This caused us a lot of problems...

Thanks

[sirhc]

We have an issue with 1.3.2 regarding VLANS and mac address tables. When we are exempting a port from the VLAN using the VLANs tab gui, it shows that it is exempted but the behavior is that it is not actually exempted! I can still see mac addresses from the port which I exempted, they still exist in the mac address table. I noticed this several times when exempted a port from a vlan and enabled a different port on the same vlan with a client with the same IP address (different mac). I could never get this work properly unless I disabled the client on the exempt port. without doing so, the switch would send traffic to exempt port! This condition existed for days and did not fix itself until i actually disabled the client from the exempt port. Although there are times when i tried this same configuration and it worked within 15 minutes (perhaps the ageing timer timeout?)

I'm wondering if this issue would be fixed in 1.3.3, as its a real showstopper. When you exempt a port from a VLAN, it absolutely needs to be exempted! :) This caused us a lot of problems...

Thanks

Exempting the port or VLAN on the MAC table "display" Tab does not make traffic not go to the MAC addresses you chose not to display, those display filters are there just to filter out displaying the MAC addresses to better only see what MAC addresses you want to see to help find where MAC addresses are, traffic will still flow normally as those display filters will not affect traffic in any way.

NOTHING on the MAC address/table display Tab will affect traffic in anyway, the MAC address/table Tab is informative only NOT a control mechanism in any way.

[jvince]

When the mac table is empty, open the console (Device tab -> Console) and enter the following commands:

Code: Select all

cmd
cat /tmp/mac_ip.txt
cat /tmp/mactable.json
 

Here is my output:

admin@Netonix_Switch:/www# cat /tmp/mac_ip.txt
cat: can't open '/tmp/mac_ip.txt': No such file or directory
admin@Netonix_Switch:/www# cat/tmp/mactable.json
cat: can't open '/tmp/mactable.json': No such file or directory
admin@Netonix_Switch:/www#

[Eric Stern]

Here is my output:

admin@Netonix_Switch:/www# cat /tmp/mac_ip.txt
cat: can't open '/tmp/mac_ip.txt': No such file or directory
admin@Netonix_Switch:/www# cat/tmp/mactable.json
cat: can't open '/tmp/mactable.json': No such file or directory
admin@Netonix_Switch:/www#

Ok, I found the problem. This will be fixed in 1.3.5.

Basically it is unable to show the mac table until it has learned at least 1 IP address. If you wait for a while and keep refreshing it will eventually work. This slipped in during the mac table optimizations made in 1.3.3.

[menacers]

Can I call you to explain the problem?

Here is the setup:

router1
----> vlan1 ----> mac1 -----> netonix port1
----> vlan2 ----> mac1 -----> netonix port1

router2
----> vlan1 ----> mac2 ----> netonix port2
----> vlan2 ----> mac2 -----> netonix port2

NOTE: MAC1 and MAC2 both share the same IP address on vlan2. MAC1 is on the maangement vlan(1), not sure if its relevant.

we exempt vlan2 from port 1, and we tag vlan2 on port 2. The behavior is that all the items on vlan2 on other ports of the netonix, have their packets sent to port 1 (which is mac1) when they should be destined to mac2. The only solution (which we tried after days of this unwanted behaviour) was to actually disable vlan2 on router1 and we could not rely on the netonix to exempt vlan2 from port1.

[sirhc]

Can I call you to explain the problem?

Here is the setup:

router1
----> vlan1 ----> mac1 -----> netonix port1
----> vlan2 ----> mac1 -----> netonix port1

router2
----> vlan1 ----> mac2 ----> netonix port2
----> vlan2 ----> mac2 -----> netonix port2

NOTE: MAC1 and MAC2 both share the same IP address on vlan2. MAC1 is on the maangement vlan(1), not sure if its relevant.

we exempt vlan2 from port 1, and we tag vlan2 on port 2. The behavior is that all the items on vlan2 on other ports of the netonix, have their packets sent to port 1 (which is mac1) when they should be destined to mac2. The only solution (which we tried after days of this unwanted behaviour) was to actually disable vlan2 on router1 and we could not rely on the netonix to exempt vlan2 from port1.

From your 1st post you are referring to settings on the MAC Table Tab as though they would have an affect on the function of the switch which is not possible.
No settings on the MAC Table Tab have any affect on the behavior of the switch.
The MAC Table Tab is just there to display information as to know MAC addresses on


Please post up a screen grab of the VLAN Tab, that would be the relative information I need to see.