v1.5.25 Bug Reports and Comments

[mfwbooks]

Found the problem

In main.html, you've missed a > character which stops the popper and bootstrap scripts from loading. Have edited main.html manually and confirmed that it all works properly now.

<script src="scripts/jquery-2.2.0.min.js"></script>
<script src="scripts/jquery.validate.min.js"></script>
<script src="scripts/moment.min.js"></script>
<script src="scripts/popper.min.js"</script>
<script src="bootstrap/js/bootstrap.min.js"></script>
<script src="scripts/bootstrap-datetimepicker.min.js"></script>
<script src="scripts/bootbox.min.js"></script>
<script src="scripts/knockout-3.4.0.js"></script>
<script src="scripts/knockout-mapping.js"></script>
<script src="scripts/require.js"></script>
<script src="Frontend.js"></script>

I updated to manager 1.0.22 and had this same issue. I added the missing > and all my previous issues with manager appear to be fixed.

[RebusCom]

I updated to manager 1.0.22 and had this same issue. I added the missing > and all my previous issues with manager appear to be fixed.

Also confirm. That resolves the issue. What mystifies me though is how such an obvious problem with the programs operation could have been missed in even the most rudimentary testing prior to release. Essentially nothing but the main screen was operational. Do some configurations ignore such a syntax error in javascript?

[Stephen]

I updated to manager 1.0.22 and had this same issue. I added the missing > and all my previous issues with manager appear to be fixed.

Also confirm. That resolves the issue. What mystifies me though is how such an obvious problem with the programs operation could have been missed in even the most rudimentary testing prior to release. Essentially nothing but the main screen was operational. Do some configurations ignore such a syntax error in javascript?

Sorry, that is a pretty wild one to get through.
Looks like one of the older parts of the build script performs a few regex operations that were probably responsible for that.
Will have 1.0.23 out shortly with the fix (and fixed build scripts)

[RebusCom]

Quick question regarding the E-mail notices on 1.5.25. After upgrade I'm getting sending error as follows:

[<-] 220 and/or bulk e-mail.
[->] EHLO rebus.biz
[<-] 250 HELP
[->] AUTH LOGIN
[<-] 334 VXNlcm5hbWU6
[->] cmVidXNjb20rcmVidXMuYml6
[<-] 334 UGFzc3dvcmQ6
[<-] 235 Authentication succeeded
[->] MAIL FROM:<admin@rebus.biz>
[<-] 250 OK
[->] RCPT TO:<rebuscom@rebus.biz>
[<-] 550 Sender verify failed
ssmtp: RCPT TO:<rebuscom@rebus.biz> (550 Sender verify failed)

The problem appears to be the MAIL FROM address of admin@rebus.biz. The "From address" in the GUI is rebuscom@rebus.biz (same as "Address"). The mail server doesn't know who admin@rebus.biz is. Mail worked prior to upgrade to the new firmware, but upgrade was all the way from v1.5.8. Why is the From address being changed by the firmware?

Edit: To compensate for this bug, I've created an admin user account (alias) on my mail server so it won't reject Emails due to the overridden From address.

[joeyr-stc]

Sorry, that is a pretty wild one to get through.
Looks like one of the older parts of the build script performs a few regex operations that were probably responsible for that.
Will have 1.0.23 out shortly with the fix (and fixed build scripts)

I upgraded our Manager to 1.0.23 and did not have any issues.
- Launch Web UI works
- Launch console works
- Tooltips work
- Displays all models & firmwares correctly

Linux with 80+ devices.
Firmware's 1.5.16 - 1.5.25

The 'Name' & 'Model' fields still don't sort properly for us when you click on the column headers but this has always been the case.

Thanks Stephen for the quick turn around on this.

[RTGLW]

So I found a bug with the port settings.

Changing it from auto (was at 1G) to 100 Auto works as expected.

Setting the link back to auto will not bring the port back up to 1G.

Only way to get it to revert is to hard set it to 1G then back to auto.

I can replicate this. Doesn't appear to happen on older FW (tested 1.5.15rc3 or 1.5.17rc2). Thankfully rectifiable, add it to the fix list for next version

FWIW - Logs from my 1.5.25 switch I replicated this on, which indicates a 'port down' happens after setting it from 100M-F to Auto though I'm not sure it actually does:

Code: Select all

Jan 21 17:00:02 UI[1572]: Configuration changed by admin
Jan 21 17:00:02 UI[1572]: PORT 10 Link: Auto => 100M-Auto
Jan 21 17:00:03 Port: link state changed to 'down' on port 10
Jan 21 17:00:03 STP: msti 0 set port 10 to discarding
Jan 21 17:00:06 Port: link state changed to 'up' (100M-F) on port 10
Jan 21 17:00:06 STP: msti 0 set port 10 to discarding
Jan 21 17:00:07 STP: msti 0 set port 10 to learning
Jan 21 17:00:07 STP: msti 0 set port 10 to forwarding
Jan 21 17:00:19 UI[1572]: Configuration changed by admin
Jan 21 17:00:19 UI[1572]: PORT 10 Link: 100M-Auto => Auto
Jan 21 17:00:20 Port: link state changed to 'down' on port 10
Jan 21 17:00:20 STP: msti 0 set port 10 to discarding
Jan 21 17:00:22 Port: link state changed to 'up' (100M-F) on port 10
Jan 21 17:00:22 STP: msti 0 set port 10 to discarding
Jan 21 17:00:22 STP: msti 0 set port 10 to learning
Jan 21 17:00:22 STP: msti 0 set port 10 to forwarding
Jan 21 17:01:28 UI[1572]: Configuration changed by admin
Jan 21 17:01:28 UI[1572]: PORT 10 Link: Auto => 1G
Jan 21 17:01:29 Port: link state changed to 'down' on port 10
Jan 21 17:01:29 STP: msti 0 set port 10 to discarding
Jan 21 17:01:31 Port: link state changed to 'up' (1G) on port 10
Jan 21 17:01:32 STP: msti 0 set port 10 to discarding
Jan 21 17:01:34 STP: msti 0 set port 10 to learning
Jan 21 17:01:34 STP: msti 0 set port 10 to forwarding
Jan 21 17:01:36 UI[1572]: Configuration changed by admin
Jan 21 17:01:36 UI[1572]: PORT 10 Link: 1G => Auto
Jan 21 17:01:37 Port: link state changed to 'down' on port 10
Jan 21 17:01:37 STP: msti 0 set port 10 to discarding
Jan 21 17:01:40 Port: link state changed to 'up' (1G) on port 10
Jan 21 17:01:40 STP: msti 0 set port 10 to discarding
Jan 21 17:01:40 STP: msti 0 set port 10 to learning
Jan 21 17:01:40 STP: msti 0 set port 10 to forwarding


[JeffreyS]

Sorry, that is a pretty wild one to get through.
Looks like one of the older parts of the build script performs a few regex operations that were probably responsible for that.
Will have 1.0.23 out shortly with the fix (and fixed build scripts)

I upgraded our Manager to 1.0.23 and did not have any issues.
- Launch Web UI works
- Launch console works
- Tooltips work
- Displays all models & firmwares correctly

Linux with 80+ devices.
Firmware's 1.5.16 - 1.5.25

The 'Name' & 'Model' fields still don't sort properly for us when you click on the column headers but this has always been the case.

Thanks Stephen for the quick turn around on this.

When I upgraded to 1.0.22 from Manager the service kept restarting after the upgrade. Even after system reboot, the service still kept restarting. Downloaded 1.0.23 from browser and installed. No issues since. I am running on a Windows 10 Pro VM.

[oeyre]

I just upgraded my problem unit with the SFP. OSPF/BFD is up and so are the PPPoE customers.

So what was it?

[sirhc]

I just upgraded my problem unit with the SFP. OSPF/BFD is up and so are the PPPoE customers.

So what was it?

That's not an easy answer.

Remember we basically rewrote 60+ THOUSAND lines of code to remove PHP.

We also fixed long standing issues like SFP modules not always coming back up after warm boots, that in itself was 2 weeks of coding and many many hours if testing of many different brands of SFPs.

Fixed memory leaks.

Upgraded SSL, lighttpd, and other dependencies.

We tackled it all. 4 months of 7 days a week.

Stephen worked many nights till sunrise. We all read spec sheets, brain stormed, testing, testing testing.

The last known issue with PPPoE SFP was a mapping issue that did not effect ws-24 or WS-26.

It is our best code ever, faster, cleaner....

The only bugs known now are doing with hard coding port speed/duplex then setting to auto. It has an easy work around and really 99% of users wont see it so for now we are moving on to WS3. But its on list.

Manager is pretty solid and also stable.

All I can tell you is WS3 which was delayed will blow your mind especially once we activate routing later after initial release.

[RebusCom]

The only bugs known now are doing with hard coding port speed/duplex then setting to auto. It has an easy work around and really 99% of users wont see it so for now we are moving on to WS3. But its on list.

Only? What about the "From address" in the E-mail alerts being ignored and replaced with a default "admin@{}"? That should be on the list too.