v1.5.11 Bug Reports and Comments

[JockGraham]

Thanks for that reply, i've had more success with the firmware not affecting the fan by updating to 1.5.5 first then going to 1.5.11. Not had any trouble if i follow that process. Thanks Jock

[dcshobby]

I just upgraded a WS-8-150-DC from 1.4.7 to 1.5.11 and see the same log entry "dropbear[1661]: Failed listening on '22': Error listening: Address already in use"

If it doesn't affect the functionality, I'm fine but just thought I would share I saw the same thing in logs after the upgrade.





Jan 1 00:00:14 system: Setting MAC address from flash configuration: EC:13:B2:E1:08:28

Jan 1 00:00:17 admin: adding lan (eth0) to firewall zone lan

Jan 1 00:00:17 dropbear[780]: Running in background

Jan 1 00:00:18 netonix: 1.5.11 on WS-8-150-DC

Jan 1 00:00:21 UI: web config OK

Dec 31 18:00:36 admin: removing lan (eth0) from firewall zone lan

Dec 31 18:00:39 admin: adding lan (eth0) to firewall zone lan

Dec 31 18:00:41 admin: removing lan (eth0) from firewall zone lan

Dec 31 18:00:44 admin: adding lan (eth0) to firewall zone lan

Dec 31 18:00:50 admin: adding lan (eth0) to firewall zone lan

Dec 31 18:00:51 dropbear[1661]: Failed listening on '22': Error listening: Address already in use

Dec 31 18:00:51 dropbear[1668]: Running in background

Dec 31 18:00:52 system: starting ntpclient

Feb 22 15:49:39 switch[1723]: temp sensor version 3

Feb 22 15:49:40 switch[1730]: Detected warm boot

[sirhc]

Code: Select all

Dec 31 18:00:51 dropbear[1661]: Failed listening on '22': Error listening: Address already in use
[color=#ff0000]Dec 31 18:00:51 dropbear[1668]: Running in background[/color]


What we are seeing is a failed attempt to load followed by a successful load of dropbear.
No idea, I did not see it in the lab even when I tried.
I would have to re-read all the above posts but maybe it is from upgrading from certain versions.
I also think it was reported it only happens on first boot after upgrade but he may have changed his observation again would have to re-read all the post.

My conclusion is it does not impeded the switch function as after the failed load it loads and works meaning dropbear as SSH works, if it was not loaded it would not accept SSH connections.

[avious]

Just wanted to add to this, from one of my switches:


Dec 31 18:00:52 dropbear[1669]: Failed listening on '22': Error listening: Address already in use
Dec 31 18:00:52 dropbear[1676]: Running in background
Dec 31 18:00:52 STP: msti 0 set port 1 to discarding
Dec 31 18:00:53 system: starting ntpclient
Dec 31 18:00:53 STP: msti 0 set port 9 to discarding
Dec 31 18:00:55 STP: msti 0 set port 9 to learning
Dec 31 18:00:55 STP: msti 0 set port 9 to forwarding
Dec 31 18:00:55 STP: msti 0 set port 1 to learning
Dec 31 18:00:55 STP: msti 0 set port 1 to forwarding
Dec 31 18:00:58 switch[1743]: temp sensor version 3
Dec 31 18:00:58 switch[1745]: Detected warm boot
Dec 31 18:01:01 system: starting ntpclient
Feb 24 13:09:28 system: time set by NTP server

WS-10-250-AC Board Rev F
Mac: ec:13:b2:c1:2f:c6
upgraded from 1.5.10

Can confirm that switch seems to be running fine and SSH login works just as expected.

[sirhc]

Code: Select all

 Dec 31 18:00:52 dropbear[1669]: Failed listening on '22': Error listening: Address already in use
Dec 31 18:00:52 dropbear[1676]: Running in background
 

Yea, the final word from our developers is that the service fails to load on the first attempt for whatever reason most likely due to timing which can be from many different factors but if a service fails to load it will attempt several times to load the service and in ever report it loads on the 2md attempt.

The first attempt failure could be happen stance, tolerance from board to board meaning not all CPUs perform the same as there are always +/- tolerances.

From all my testing I could not recreate the issue but again every CPU works a slightly different speed and there are always internal errors that are corrected but again this is a timing issue and between hardware correction and or software correction the issue is resolved.

I would consider this a non issue that is seen on a percentage of units but is not really an indication of a problem that will affect anything.

I just received code yesterday from Eric to allow us to resume production with the substitute (more expensive) flash but the models will still be the NCS version as we still have not received current censors on POs from over a year ago and we have not yet completed the code to deal with the newer (more expensive but should be better and tougher) current sensors.

We are supposed to receive a partial shipment of the original current sensor by the end of March. The number of units in that shipment is unknown all we are told is it should be at least 3,000 unit but could be 100,000 units. But keep in mind below is how many current sensors it takes for each model.

ws-6 = 6 sensors
ws-8-AC = 1 sensor
ws-12 = 16 sensors
ws-12-400-AC = 18 sensors
WS-26 = 30 sensors

So really if we only get 3,000 who cares.

We are also developing in parallel the ability to use the NEW current sensors with the old firmware but requires additional hardware/logic on the board but to do the circuit design, PCB changes, and spin off 10 proptype boards for testing your looking at 3,000 per board because it costs a ridiculous amount of money to build only 10 PCBs and setup a line to assemble 10 boards as it takes just as much labor from your SMT shop to setup the line to run 10 boards and 10,000 boards then you pay to remove your parts to clear the line for the next run of something else. Then if you find a problem do make changes and spin off another 10 boards and so on so RND and prototype boards are EXPENSIVE. Also due to the Biden inflation and low worker participation GOOD coders now cost between $125,000.00 to $250,000.00 + benefits and of you do not pay them that other companies will steal your developers. Again small company with limited resources trying to survive in a market that is unreal. We have not been able to run a production since October 2021 and since January of 2021 production has been limited due to parts and COVID crap. In fact through most of 2021 I kept our production running in violation of state orders. Thank GOD our state had a referendum to strip our Democrat Governor high on his new found powers from COVID of his emergency power a few months ago and we were legally allowed to be operating but had no parts by then. We also took ZERO COVID money from the government but until end of December keep all our works working and paid with medical with nothing to do but jobs we made up. I will say our assembly shop is SPOTLESS and you could eat off our toilets.

Do I think we (Netonix) will survive.....yes provided the CCP does not invade Taiwan again remember 60-65% off all semiconductors come from there.

I called Putin's invasion to happen within 48 hours of the end of the Olympics in China due to an agreement between Putin and Xi.

I also predicted Xi's invasion of Taiwan to happen between now and November 2022 (mid terms).

My real prediction that I feel is most likely is after Putin secures Ukraine and lines up his military on NATO boundaries which will scare the hell out of western countries fearing nuclear escalation and would then not want to get involved with China the 3rd largest nuclear arsenal. Also keep in mind we get most of our pharmaceuticals from China since the Clinton administration not to mention so many other products all Xi has to do is tell us to stay out or he will cut us off from medications and other products we need.

We live in the most dangerous times in the history of our nation and we are now not even energy independence and we depend on China for way too many things.

All I can say is I miss the mean tweets because I slept a lot easier then. Oh and be ready for $5 gas and double digit inflation is all we have to deal with is just what already happened which is Ukraine which right now if that is all that happens I will be thankful for.

I know this is a lot of information that is really my personal opinion and political but people really need to wake up and pay attention.

[KBrownConsulting]

Since you mentioned the current sensors...

The WS-8-150-AC page is very misleading. (Due to the fact that unless I'm completely mistaken, it's got blatantly incorrect information on it!) Specifically it says: "Passive PoE current sensors on each port". That should be removed, no? (refub page too)

Actually, IMHO the WS-8-150-AC should have a disclaimer on it similar to all the NCS devices about not reporting watts per port, as it seems that's actually the way it's always been, right?

Since we're on the topic, why was the decision made to exclude per port current sensors on the WS-8-150-AC from the beginning? (I've always been rather confused & disappointed by that since the WS-6-MINI includes them!)

[sirhc]

Since we're on the topic, why was the decision made to exclude per port current sensors on the WS-8-150-AC from the beginning? (I've always been rather confused & disappointed by that since the WS-6-MINI includes them!)

Yes when we updated the website about a couple months ago I guess I did a little to much cut and paste and missed it.

If you check the Spec sheet it states that it only reports total watts used, and there were tons of discussions on this forum when we came out with it. And our Distributor web sites also report this.

Originally the WS-8-150-AC competed with the ToughSwitch which did not offer any current sensors or even tell the total watts used but the WS-8-150-AC does report TOTAL watts used.

Before the Biden Inflation and the original price for the WS-8-150-AC was $199.95

viewtopic.php?f=6&t=185&p=477&hilit=toughswitch#p474

We stripped the current sensors ALL BUT ONE to report total watts used as early versions of the ToughSwitch had an issues that the user would overload the power supply and the units would randomly reboot 1 device. I know as I had this issue at my WISP.

UBNT fixed this issue by upgrading the power supplies in them in next release. NOw we put in a power supply that was medical rated which if you take a TS and a WS-8-150-AC power supply side by side the our power supply is twice as big and cost more. The WS-8-150-AC is "rated" at 150 watts and is all we say to use but will deliver more. We decided to report total watts used to insure users knew if they were over POE budget especially since it does offer 1 48VH port to power AF and the ToughSwitch does not offer any 48VH ports.

I did fix the site thank you for bringing to my attention. On the model the last line should have read Reports total watts used.

[jpmoller]

Hi,

I've just deployed 1.5.11 on two switches and ssh keys are not working on either of them. They were both fresh out of the box, loaded with 1.5.6 before the upgrade.
I have tried adding the keys via ssh, as well as the web UI, but every time I try to log in with a key, it asks for a password.

WS-26-400-IDC
MAC - ec:13:b2:11:e3:9a

Board Revision - B

WS-8-150-DC
MAC - ec:13:b2:e2:e8:30

Board Revision - F

I can confirm that both keys are currently loaded in /etc/dropbear/authorized_keys

I am about to load this firmware onto a WS-12-250-DC tonight that is running 1.5.0 on board revision F. SSH keys are currently working on that switch. If it stops working after the upgrade, I will report back

Worth noting, we also have SSH keys working on switches on 1.5.8 on our network

[jpmoller]

After upgrading the WS-12-250-DC to 1.5.11 overnight, ssh keys no longer work.

[sirhc]

After upgrading the WS-12-250-DC to 1.5.11 overnight, ssh keys no longer work.

To be honest I never tested KEYS in the rush to get TLS fixed as it affected everyone.

99%+ of users do not use KEYS including me so I never thought to check that, I am not saying it does not need to be fixed and I believe you that it is most likely broken and will have to be fixed in v1.5.12.

For now I would suggest you remove the SSH KEYS before upgrade to v1.5.11 and for now not use them so you can access your switches with updated browsers but that is your choice. This will effect all WS models.