Switches Not Passing Packets

[mhoppes]

Just re-upgrading to 1.5.5 fixed it.

[sirhc]

Just re-upgrading to 1.5.5 fixed it.

This was my thought that might fix it when talking to Stephen last week.

Recently we made changes to our testing serialization stations to accommodate the new RMA web portal. Sometimes the new testing station software messes up and the tech must restart things half way through the testing and I am thinking this is when some units get a corrupted config file.

Now a power on factory default should also fix it? This is where you press the default button at power up for 20 seconds.

To be honest you would also think a standard default via the CLI or UI would do the same but might not????

Would appreciate it if someone comes across one of these units if they could do the following:
1) Export / Backup config file from UI and send to Stephen <= VERY IMPORTANT
2) Try a simple default in UI or CLI
3) Try a power on default
4) Upgrade to v1.5.5 even if already v1.5.5, keep in mind it is the process of upgrade that recreates the config file.

Again I think this is something with our testing / serialization stations new software which is web based and sometimes messes up and the operator is forced to restart components which is where I think this happens. Also we have been building many more units and now have 3-4 techs doing this over 2 shifts verses previously mostly 1 tech did all testing/serialization.

[JDH51086]

We just had two WS-12-250-AC's that came with 1.5.5 on them. Could access the switch, but it would not pass any traffic at all between ports(tagged or untagged). A reflash from a downloaded version of 1.5.5 resolved the issue.

[eguzman@vpnet.net]

Well, in our case, it seems to be not related to VLAN but switch not forwarding at all.

SW: Two new SS-12-250-DC (received last week) with 1.5.5 preloaded. We spent nearly 6 hours yesterday troubleshooting at site without success.

However, today on the Lab, we connected a Laptop to port 1 and a utik on port 12. utik is being powered by Switch.

This is what we observed after many trials. initially the devices did not communicate. If we set the port 12 to ISO, then laptop can ping and communicate with utik. If we uncheck ISO, the laptop continues to communicate. If we reboot the switch, same thing happens. When the SW boots up, there is no communication. We set ISO on port 12, it start communicating. We un check ISO and continues to communicate.

So it looks like it is something related to ISO. Rolling back to 1.5.3 is the workaround?

Have other SWs with 1.5.5 with no issues.

Thanks.

UPDATE: Like mentioned before, reloading the 1.5.5 FW seems to solve the issue. At least at the Lab, it did.

[Stephen]

Right now, it's been confirmed that downgrading to 1.5.3 and upgrading back to 1.5.5 should fix it.
Also, just re-installing 1.5.5 should fix it.
Or you could upgrade to 1.5.6rc2 and that should do it as well.

[eguzman@vpnet.net]

Yes. Only FYI.., In our case, we didnt roll back to 1.5.3. We just reloaded 1.5.5 and seems to be working ok now.

[Stephen]

My bad, started reading your post before the edit.

[wirelesscon]

Hello we got 2x Netonix 400W IDC 24 Port Switches, with 1.5.5 pre-loaded
the both seemed to forward traffic at first, they were loaded with identical template configs and then had their management IPs changed for commissioning.

One switch did act a little funny (not forwarding traffic but I thought nothing of it was left powered on for about 5 or 6 days...

I started to commission the switch (turning on POE naming ports and all seemed fine) traffic forwarding ...

the last operation that I can recall that caused the stop was changing the management IP of the switch once it was fully live.


a warm reboot didn't resolve the issue
a power cycle didn't resolve the issue
management IP of the switch was accessible locally via an untagged port,
management IP of the switch was accessible via a router on a tagged port

devices connected seemed not to be receiving traffic on the tagged vlans



Re -applying the 1.5.5 firmware on top of 1.5.5 firmware did resolve the issue for us.

Thanks
Tom Smyth

[wirelesscon]

Switch that had the issue
MAC Address ec:13:b2:11:d2:70

Switch that didnt have the issue ( or at least didnt stop forwarding yet )
MAC Address ec:13:b2:11:d2:22


By the Way ... It would be good to notify customers of this issue if they have ordered switches proactively... I appreciate you acknowledging the issue publically but ... emailing customers who ordered switches with 1.5.5 pre-loaded would help reduce pain in the field
Thanks
Tom Smyth

[JustJoe]

...
By the Way ... It would be good to notify customers of this issue if they have ordered switches proactively... I appreciate you acknowledging the issue publically but ... emailing customers who ordered switches with 1.5.5 pre-loaded would help reduce pain in the field
Thanks
Tom Smyth

Also, there are the standard forum post announcements for v1.5.5 that have a "known issues" section. It would be nice to have a note in there as well. :)