v1.5.22 Bug Reports and Comments

[Flo]

do you have any updates about the pppoe/vlan trunk problem?

The firmware coming out today has a fix in it that we think may be responsible. But testing this locally has proven difficult so we are relying on the community for feedback. However, we were able to confirm a bug that was related to multicast that in theory could be the cause. We'll be relying on everyone to let us know if the behavior improves after it's out.

That are good news.

Seems to me that v1.5.2x versions are blocking any outbound multicast packets on SFP ports, if these are Vlan tagged.
That's the result of my findings using WS-12-250-AC with stock configuration.

[sirhc]

do you have any updates about the pppoe/vlan trunk problem?

The firmware coming out today has a fix in it that we think may be responsible. But testing this locally has proven difficult so we are relying on the community for feedback. However, we were able to confirm a bug that was related to multicast that in theory could be the cause. We'll be relying on everyone to let us know if the behavior improves after it's out.

That are good news.

Seems to me that v1.5.2x versions are blocking any outbound multicast packets on SFP ports, if these are Vlan tagged.
That's the result of my findings using WS-12-250-AC with stock configuration.

I feel your pain and Stephen is working on it, but my entire OSPF ring relies on the SFP ports as seen in my post detailing my network seen here:
Netonix Forums • View topic - This works well for us


Every single customer goes through the SFP ports at each tower, and I am using VLANs in every tower switch.

With most of my customers using streaming services which can be multicast is watching live streams I would think people would be screaming at me.

Plus some gaming voice services like Team speak I think use multicast?

I am not saying you're wrong, I am just stumped.

I think this has more to do with PPPoE or MTU than multicast.

But you say if you bypass SFP it works.
You say you tried different SFP modules.
You say you bumped up MTU. Did you bump up MTU on SFP ports extra high for shits and giggles?

Makes no sense.

I know Stephen is looking to push v1.5.23 soon so let hope.

[KBrownConsulting]

There is still bug in SMTP but different one... curretnly it uses field "From Address" in "helo" command and the reply from SMTP is then

[<-] 501 5.5.4 Invalid domain name

...because it expects some FQDN domain, not an "email" format. Previously you ignored this field and used name "localhost" and then the same as "Mail From:" command and that was a bug. So the solution is to use "helo" only and nothing else (or the Local Host Name field) and "Form Address" field use in "Mail From:" command only. Thanks for fix.

I too am having problems with email.

Worked fine in 1.5.17rc2 but is broken in 1.5.22.

Below is the error I get if I fill in the "From Address" and run the SMTP test from the Configuration page:

[<-] 220 <redacted mail server> ESMTP [c]
[->] EHLO <redacted my email account>
[<-] 501 5.0.0 Invalid domain name
SSL_connect: Success
ssmtp: Cannot open <redacted mail server>


If I leave the "From Address" blank I get this error:

[<-] 220 ESMTP [c]
[->] EHLO localhost
[<-] 250 HELP
[->] STARTTLS
[<-] 220 2.0.0 Ready to start TLS
[->] EHLO localhost
[<-] 250 HELP
[->] AUTH LOGIN
[<-] 334
[->]
[<-] 334
[<-] 235 2.0.0 OK Authenticated
[->] MAIL FROM:<admin@localhost>
[<-] 553 5.5.4 <admin@localhost>... Real domain name required for sender address
ssmtp: 553 5.5.4 <admin@localhost>... Real domain name required for sender address


I have tried putting a bunch of different things in the "From Address" and the "Local Hostname" option boxes but so far have been unable to find anything that works.


Same behavior on 2 different model switches: WS-8-150-AC & WS-24-400A

If I downgrade back to 1.5.17rc2 it works again. (Have upgraded & downgraded several times to test. Also fully defaulted switch after one of the upgrades & manually reconfigured just to make sure config wasn't corrupted and it still didn't work.)

Hoping this can be looked into and addressed as SMTP notification is completely broken for me in 1.5.22

Another related issue: If you put the wrong port into the SMTP settings and run the SMTP test, the switch GUI becomes completely unresponsive for a long time. After about 2min & 30sec you get the "Attempting to reestablish communication with the device ..." banner and then shortly after that it reconnects and you get a "SMTP Test Results" error that claims the test "Timed out after 60 seconds", even though in reality it took several minutes. And when I say the GUI becomes completely unresponsive, I mean completely to the degree that if you open a separate Private/Incognito browser and try to log into the switch it shows you the Login page but won't actually load anything until the test has completed.

In the FromAddress input, does it work if you just use the domain itself?

For example if you want the switch's email to contain the from address admin@thisswitch.com then the FromAddress input box should be "thisswitch.com"

Doing it that way, does it work better?

Thanks for the reply. I have confirmed that if I simply put a domain in the "From Address" field that it does allow the email to send and arrives from admin@domain.com

Is this intended behavior? I expected and would prefer being able to specify a complete email address in the "From Address" field so I can filter emails from different switches based on the from email address.

Also, by forcing the email to come from admin, the only way to pass SPF & DKIM is if I put in my ISP's domain, and claiming the email is being sent from admin@myisp.com definintely isn't accurate.

[oeyre]

With most of my customers using streaming services which can be multicast

It wouldn't actually be multicast unless you the network operator is participating though, would it? Do you do IPTV as part of your offering?

You say you bumped up MTU. Did you bump up MTU on SFP ports extra high for shits and giggles?

Going on a bit of a tangent here, but is there any particular rationale on why the port/bridging MTU isnt defaulted to max? Tweak the IP MTU all you want but I personally don't understand why some vendors keep the default bridge MTU down. Cisco would have to be one of the worst perpetrators of this.

We run max MTU on all our Netonix and still had the PPPoE/OSPF issue on our SFP port.

I know Stephen is looking to push v1.5.23 soon so let hope.

Sounds great, I'm very curious about this "comical" error and would love to read some tech gore about how it happened and was fixed, if you're willing to share.

[Stephen]

...
Thanks for the reply. I have confirmed that if I simply put a domain in the "From Address" field that it does allow the email to send and arrives from admin@domain.com

Is this intended behavior? I expected and would prefer being able to specify a complete email address in the "From Address" field so I can filter emails from different switches based on the from email address.

Also, by forcing the email to come from admin, the only way to pass SPF & DKIM is if I put in my ISP's domain, and claiming the email is being sent from admin@myisp.com definintely isn't accurate.

So, this is presently the intended behavior. To be honest, I wasn't certain if this was what we wanted either, the code that was in there was attempting to work this way but didn't quite work before. I actually went through the same troubleshooting steps you're going through now when I was working on it.

However, another tidbit that maybe helpful. It is actually generating the email that the switch use's from:

<Credentials Name>@<From Address>

If you go to the Configuration tab, 2 panel's down from the SMTP config panel the Credentials tab is available, if you change the default name "admin" here, it will update the from address accordingly.

I'm aware this isn't exactly intuitive. But frankly. I'm not sure what the reasons were for setting it up this way. We need to discuss internally to see if there was any concrete reasoning behind this.

In the mean time, I hope that info above is helpful.

Let's continue the discussion in the next release thread.

[Stephen]

v.1.5.23 is now out.

We had a bit of a delay so didn't quite make it out yesterday, but it is now generally available as of this morning.

Among the fixes include:
- NTP
- SSH Keys (up to 1000 characters)
- webui session management
- multicast bug (see note below)

On the Multicast Bug, while we do know for certain this bug is related to multicast configurations, we cannot be certain it is related to the various, and somewhat inconsistent, networking issue's that have been reported with SFP's and PPPoE/OSPF.
However, based on feedback, it is the most likely candidate we've found so far. So we will be monitoring feedback on 1.5.23 to see if it helps resolve this troubling issue. Please let us know what you find.


Like normal, this thread will be locked, please direct new feedback here:
viewtopic.php?f=17&t=8141

And you can download the new firmware here:
viewtopic.php?f=17&t=240