v1.3.3 FINAL bug reports and comments

[Eric Stern]

After lab'ing our WS-12-250-AC we finally deployed it. I hadn't tested the email feature since 1.2.4 or so. Now testing shows that ssmtp actually uses the mail host name as the client host name while EHLO 'ing. Our server will drop the connection as it detects this as a forged host name - and rightly so.

I checked both /etc/ssmtp/ssmtp.conf and /jffs/etc/ssmtp/ssmtp.conf. They both have the the same value for the two different variables:

Code: Select all

mailhub=[mail.ourdomain.com]:25
hostname=mail.ourdomain.com

AFAIK, hostname should be the actual host name assigned to the switch, not the name of the mail server.

We are running version 1.3.3

Maybe this has already been addressed, but I thought I'd report it anyway.

You are right, this isn't technically correct, but it has been like this since 1.0.0 and until now I haven't had any reports that it was a problem.

At some point pre-1.0.0 the host name was set to the Switch Name, but we do not enforce any particular format for the Switch Name, and some mail servers were complaining about the EHLO not containing a valid looking host name. The mail host name was the only configuration option I had that I could be pretty sure would be a valid host name, so I used that and all the mail servers we have tried were happy with it. Even Gmail. I suspect since almost all mail servers use secure login they don't bother validating the EHLO value anymore.

I guess I could add a configuration option to the SMTP section that would let you specify the host name to use if its a problem.

[designweb]

when looking at the MAC address table when first installed 1.3.3 the table was empty, try after try, now many hours later it is working perfectly well.

[bmv]

Have a problem upgrading WS-8-250-DC from 1.3.1 to 1.3.3. (updated I though it was 1.3.2, actually we were running 1.3.1)

Switch is not coming back online after the following prompt "The interface will reload when the reboot is complete"
Can't ping it.

This switch is remotely backhauled by a NanoBeam N400 and the switch is powering the remote NanoBeam, and I can get onto this, but I can't ping the switch or contact it via SSH from the remote NanoBeam just to rule out some craziness.

Switch was recently installed on Tuesday. Worked fine until this upgrade.

port 1: 24v Nanobeam N400 backhaul in
port 2: 24v RocketM5
port 3: 24v RocketM5
port 8: site monitor

Management VLAN is: 115 and tagged on port 1 (the uplink).

I previously upgraded a 12 port AC and a 24 port A version without a hitch.

Any ideas?

Truck roll needed I think to get this back online.
Fortunately this is a new site - only 2 customers offline.

[sirhc]

So the tower is up and all the radios are up you just can not access the switch anymore?

[bmv]

So the tower is up and all the radios are up you just can not access the switch anymore?

As this is a remote switch, we can see the remote backhaul dish up. Nothing else is showing up.
Potentially the base stations are powered, but no comms to the switch or through it via the upstream link.

- Dotted line is a 2km wireless link.
- BS-xxx-x are our Rocket M5 base stations
- BH-AP is the AP end of the backhaul link.
- BH-ST is the Station end of the backhaul link.
- NX is the WS-8-250-DC
- The greyed out base station is not yet commissioned.

BRY network down after netonix upgrade.PNG (10.65 KiB) Viewed 7950 times

We have tested to see if the management IP address has jumped onto VLAN1, or the native VLAN rather than tagged. No luck.
We have tested to see if the management IP have jumped back to 192.168.1.20 default. No luck.

I guess we need a site visit?

[sirhc]

Please let us know what you find

[bmv]

Please let us know what you find

Will do.
Is it worth trying to console onto the switch or just disconnect DC power cables and reboot?

We upgraded from 1.3.1 to 1.3.3, NOT 1.3.2 to 1.3.3.
Updated original post.
board rev; D

(have the page still loaded in Chrome and inspecting the elements to see the details!)

[sirhc]

It is always worth while using the console cable to see what's going on!

[jvince]

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.

[sirhc]

I just exported and imported my config here at RF Armor and I did not see this behavior?

It has to be something with your configuration?

Possible VLANs so please Post up your VLAN Tab.

I am guessing but maybe it works for me as I have no VLANs defined and my management VLAN is default ID of 1 and Untagged?

Click HERE to watch video of MAC table after config restore.