5.22 released!

steen · Wed Nov 28, 2012 9:36 pm

Hello folks!

All our routers and accesspoints plus cpe:s successfully upgraded to ros5.22.
RB150, RB333, RB411, RB450G, RB600, RB750, SXT, SEXTANT
No problems observed, all working as stable as before, we use nv2 in wireless network for distribution and 802.11abgn in offices and some hotspots.

Thanks MT!

napismizpravu · Thu Nov 29, 2012 10:58 pm

napismizpravu, what do you see at /tool profiler?

again error:
proxy KO! uptime 1d

Segir · Fri Nov 30, 2012 7:09 am

Same bug in v5.22 and 5.21 (on v5.19 didn't met such problem):
can't log in through web-interface (more often from Safari browser, iPhone), there is a following message: "Internal server error".
As I read changelog, similar problem has already been solved in version 5.7, but now it seems to appear again in 5.21 and 5.22
Please fix this problem.
how often does it happen?
What happens if you manually open the IP address of the hotspot router - does it allow to login?
Please make a support output file right after you see that error message and send it to support@mikrotik.com

It happens almost every time I try to log in throuh web-interface (Safari) on iPhone. What do you mean by asking "What happens if you manually open the IP address of the hotspot router- does it allow to login?"? In address bar of Safari I enter IP-address of my RB750G, on logon screen I enter password (user "admin" automatically filled in) and press logon - after a few seconds I see the same logon screen with message "Internal Server Error" below password field.
Will try to send supout.rif soon.

Fri Nov 30, 2012 12:54 pm

Segir, have you tried to install a Chrome on IOS device, does it work with it?
With RouterOS v5.20 you didn't have such problem?

torjon · Fri Nov 30, 2012 5:37 pm

ROS: 5.22
00:00:13 system,error,critical System rebooted because of kernel failure
00:00:16 system,error,critical router was rebooted without proper shutdown
00:00:19 interface,info ether1 link up (speed 100M, full duplex)

RB433AH

After few hours again "rebooted because of kernel failure" and CPU 100% and 100MHz !!!

ROS 5.22 looks like early beta...

Hotz1 · Fri Nov 30, 2012 9:52 pm

Beginning on Nov 12, several devices on our network are having their (static) DHCP addresses deassigned and immediately reassigned every few hours, intermittently, despite the standard 3-day lease length. Here is the log of the most recent incident (MAC addresses changed, obviously):

Nov 30 08:47:56 33Comm LAN-DHCP deassigned 192.168.151.244 from aa:aa:aa:aa:aa:aa
Nov 30 08:47:56 33Comm LAN-DHCP assigned 192.168.151.244 to aa:aa:aa:aa:aa:aa
Nov 30 08:48:00 33Comm LAN-DHCP deassigned 192.168.151.247 from dd:dd:dd:dd:dd:dd
Nov 30 08:48:00 33Comm LAN-DHCP assigned 192.168.151.247 to dd:dd:dd:dd:dd:dd
Nov 30 08:48:00 33Comm LAN-DHCP deassigned 192.168.151.245 from bb:bb:bb:bb:bb:bb
Nov 30 08:48:00 33Comm LAN-DHCP assigned 192.168.151.245 to bb:bb:bb:bb:bb:bb
Nov 30 08:48:00 33Comm LAN-DHCP deassigned 192.168.151.246 from cc:cc:cc:cc:cc:cc
Nov 30 08:48:00 33Comm LAN-DHCP assigned 192.168.151.246 to cc:cc:cc:cc:cc:cc
...
Nov 30 12:48:56 33Comm LAN-DHCP deassigned 192.168.151.244 from aa:aa:aa:aa:aa:aa
Nov 30 12:48:56 33Comm LAN-DHCP assigned 192.168.151.244 to aa:aa:aa:aa:aa:aa
Nov 30 12:49:00 33Comm LAN-DHCP deassigned 192.168.151.246 from cc:cc:cc:cc:cc:cc
Nov 30 12:49:00 33Comm LAN-DHCP assigned 192.168.151.246 to cc:cc:cc:cc:cc:cc
Nov 30 12:49:00 33Comm LAN-DHCP deassigned 192.168.151.247 from dd:dd:dd:dd:dd:dd
Nov 30 12:49:00 33Comm LAN-DHCP assigned 192.168.151.247 to dd:dd:dd:dd:dd:dd
Nov 30 12:49:01 33Comm LAN-DHCP deassigned 192.168.151.245 from bb:bb:bb:bb:bb:bb
Nov 30 12:49:01 33Comm LAN-DHCP assigned 192.168.151.245 to bb:bb:bb:bb:bb:bb

At the same time that this occurs, current connections (e.g., VoIP, Skype) on these devices drop.

Relevant settings (export compact):

/ip pool
add name=LAN-pool ranges=192.168.150.100-192.168.151.249

/ip dhcp-server
add add-arp=yes address-pool=LAN-pool authoritative=yes disabled=no interface=\
    ether1-LAN name=LAN-DHCP

/ip dhcp-server network
add address=192.168.150.0/23 dns-server=192.168.150.1 gateway=192.168.150.1 \
    netmask=23 ntp-server=10.0.1.13

/ip dhcp-server lease
add address=192.168.151.244 client-id=1:c0:3f:e:10:21:7b mac-address=aa:aa:aa:aa:aa:aa server=LAN-DHCP
add address=192.168.151.245 client-id=1:0:e:8:d9:a9:11 mac-address=bb:bb:bb:bb:bb:bb server=LAN-DHCP
add address=192.168.151.246 client-id=1:0:e:8:d7:60:34 mac-address=cc:cc:cc:cc:cc:cc server=LAN-DHCP
add address=192.168.151.247 client-id=1:0:e:8:d8:4c:fb mac-address=dd:dd:dd:dd:dd:dd server=LAN-DHCP

Pretty straightforward, I think. I am not sure if this is caused by the dhcp-server system (e.g., changes made for 5.21) or something else; Hopefully, this will help someone track down the problem. If anyone has any insight into this, or this issue has been seen before, please let me know!

Since I am on the verge of losing a customer due to this behavior, I am going to try giving these devices static IPs (manually, not using dhcp-server) and see if that eliminates the drops. Since this will suggest whether the problem is within the dhcp-server system or elsewhere, I will follow up with my own results next week.

EDIT: This is on a RB750UP, currently running ROS 5.22. Upon further perusal of the logs, this deassign-reassign pattern goes back years--but this is the first time I have noticed it happening with static leases, and with devices for which it causes the user a real inconvenience.

steen · Fri Nov 30, 2012 10:51 pm

Hello Folks!

PROBLEM!!

Suddenly one by one our CPE:s stop working, no traffic on eth1 at all, DHCP offer we see only, nothing more.

Known affected devices so far RB411

Rollback to 5.20 solved the problem.

erebusodora · Sat Dec 01, 2012 10:17 pm

The scenario is Sextant AP ----> Sextant station bridge (protocol nv2) ... after 1 day trafic stoping. Enable disable wireless interface traffic comes. When ptotocol is nstream no problem. Downgrade to 5.18 NO problem too.

Halfeez92 · Sun Dec 02, 2012 5:23 am

I've installed NTP client before upgrade, but after upgraded the package was gone, and I tried to check the time thru logs, and it put the right time. I don't know what happen, but before this it need NTP client to syncronize time from the internet right? Do I need to reinstall NTP client package back?

BTW this version still not solve bug on SSL redirect address when using hotspot.

samotoka · Sun Dec 02, 2012 11:25 am

Yes, You need
It is quite easy

Lakis · Sun Dec 02, 2012 2:48 pm

The scenario is Sextant AP ----> Sextant station bridge (protocol nv2) ... after 1 day trafic stoping. Enable disable wireless interface traffic comes. When ptotocol is nstream no problem. Downgrade to 5.18 NO problem too.

Do u still have this problem with 5.22 because I have this problem with previous version
but now 2-3 days with 5.22 seam fine

bminish · Sun Dec 02, 2012 3:45 pm

There's an issue with 'export compact' feature

It does not include the SSID if the radio is in NV2 mode AP/bridge

This is from a 711GA-5HnD

/interface wireless
set 0 band=5ghz-a/n country=ireland default-forwarding=no disabled=no \
frequency=5660 ht-rxchains=0,1 ht-txchains=0,1 l2mtu=2290 mode=ap-bridge \
nv2-preshared-key=xxxxxxxxxxxxxxxxxxxx nv2-security=enabled \
security-profile=CPE wireless-protocol=nv2

tiggda · Sun Dec 02, 2012 10:03 pm

I came across memory usage reporting error using v.5.22 with web proxy enabled caching to RAM. "System -> Resources" claim to have 4GiB free memory on my RB450G, while graphs say for example "Max: 345.17MiB (137.4%); Average: 124.61MiB (49.6%); Current: 66.73MiB (26.5%);". When I clean out the proxy cache stored in RAM all goes back to normal. I've 50% of RAM allocated for proxy cache.

Ham · Mon Dec 03, 2012 12:44 am

Am I missing something in 5.22 but in Winbox, wireless settings, NV2 Tab a heap of settings missing, TDMA Period Cell radius etc only field there now is the security check box and entry..

Only accessible by terminal now ?

tiggda · Mon Dec 03, 2012 8:29 am

I came across memory usage reporting error using v.5.22 with web proxy enabled caching to RAM. "System -> Resources" claim to have 4GiB free memory on my RB450G, while graphs say for example "Max: 345.17MiB (137.4%); Average: 124.61MiB (49.6%); Current: 66.73MiB (26.5%);". When I clean out the proxy cache stored in RAM all goes back to normal. I've 50% of RAM allocated for proxy cache.

So here's how it looks from terminal:

> /system resource print
uptime: 1w13h59m17s
version: 5.22
free-memory: 4294958956KiB
total-memory: 257108KiB
cpu: MIPS 24Kc V7.4
cpu-count: 1
cpu-frequency: 680MHz
cpu-load: 0%
free-hdd-space: 435532KiB
total-hdd-space: 520192KiB
write-sect-since-reboot: 1117527
write-sect-total: 47863782
bad-blocks: 0%
architecture-name: mipsbe
board-name: RB450G
platform: MikroTik

and screenshot from winbox:

winbox522.png

Mon Dec 03, 2012 9:54 am

The scenario is Sextant AP ----> Sextant station bridge (protocol nv2) ... after 1 day trafic stoping. Enable disable wireless interface traffic comes. When ptotocol is nstream no problem. Downgrade to 5.18 NO problem too.

do you have 5.22 on both sides?
Please make support output file at the time when it is happening. Also if it is possible make support output file from the remote location.

Mon Dec 03, 2012 9:56 am

Am I missing something in 5.22 but in Winbox, wireless settings, NV2 Tab a heap of settings missing, TDMA Period Cell radius etc only field there now is the security check box and entry..

Only accessible by terminal now ?

most likely you are configuring the Nv2 station end. For Nv2 station you only need to check if you willl use security or not as all the other Nv2 settings are sent and configured by AP.

Mon Dec 03, 2012 10:01 am

There's an issue with 'export compact' feature

It does not include the SSID if the radio is in NV2 mode AP/bridge

This is from a 711GA-5HnD

/interface wireless
set 0 band=5ghz-a/n country=ireland default-forwarding=no disabled=no \
frequency=5660 ht-rxchains=0,1 ht-txchains=0,1 l2mtu=2290 mode=ap-bridge \
nv2-preshared-key=xxxxxxxxxxxxxxxxxxxx nv2-security=enabled \
security-profile=CPE wireless-protocol=nv2

Maybe you have the default ssid=MikroTik?

Mon Dec 03, 2012 10:02 am

Hello Folks!

PROBLEM!!

Suddenly one by one our CPE:s stop working, no traffic on eth1 at all, DHCP offer we see only, nothing more.

Known affected devices so far RB411

Rollback to 5.20 solved the problem.

we need support output file from that situation so we could understand what is causing that.

Mon Dec 03, 2012 10:03 am

ROS: 5.22
00:00:13 system,error,critical System rebooted because of kernel failure
00:00:16 system,error,critical router was rebooted without proper shutdown
00:00:19 interface,info ether1 link up (speed 100M, full duplex)

RB433AH

After few hours again "rebooted because of kernel failure" and CPU 100% and 100MHz !!!

ROS 5.22 looks like early beta...

please make a support output file from that router and send to support@mikrotik.com
What RouterOS version you were using before v5.22?

Beeski · Mon Dec 03, 2012 2:17 pm

Day 4 of 5.22 testing = no problems.
3 RB800 AP's with R52Hn wireless cards
1 RB493 switch
10 RB711 CPE's

Waiting for more feedback before we roll-out 5.22 to hundreds of AP's and thousands of CPE's.

Segir · Tue Dec 04, 2012 7:40 am

Segir, have you tried to install a Chrome on IOS device, does it work with it?
With RouterOS v5.20 you didn't have such problem?

Installed Chrome browser on iPhone - no problem with log in (tried several times - every time successfully). But with v5.19 and earlier versions - I have never met such problem with Safari browser on iOS.
As for v5.20 - didn't test this version (upgraded from v5.19 to v5.21, and later upgraded to v5.22 - on both 5.21 and 5.22 I met problem with "Internal Server Error" when trying to log in).
Yesterday I sent supout.rif to support@mikrotik.com (Ticket#2012120366000531)

napismizpravu · Wed Dec 05, 2012 9:31 am

RB433UAH power 24V 2A

system error critical System rebooted because of kernel failure
system error critical router was rebooted without proper shutdown by watchdog timer

a waste (lost,does not exist)) of active meterouteru

RB433UAH home router (NAT,samba,MetaRouter -opendchub,webserver) max uptime 3d
RB133 (bridge) currently 11d 18h

===Google translator===

patrickmkt · Wed Dec 05, 2012 2:24 pm

When removing an UPS, or changing the serial port of an UPS, the previous serial port is still assigned to the UPS and unable to be reused by any other process.

Am I the only one with this problem?

samotoka · Wed Dec 05, 2012 2:30 pm

Wed Dec 05, 2012 3:22 pm

When removing an UPS, or changing the serial port of an UPS, the previous serial port is still assigned to the UPS and unable to be reused by any other process.
Am I the only one with this problem?

what do you mean by "changing the port"? how many serial ports does your device have, and why are you changing them?

napismizpravu · Thu Dec 06, 2012 12:54 pm

RB433UAH again error v.5.22 uptime 1d max. 3d (supout.rif Unable to create)

demo2.mt.lv RB433UAH - turn on the services proxy, samba, MetaROUTER

patrickmkt · Fri Dec 07, 2012 3:34 am

When removing an UPS, or changing the serial port of an UPS, the previous serial port is still assigned to the UPS and unable to be reused by any other process.
Am I the only one with this problem?
what do you mean by "changing the port"? how many serial ports does your device have, and why are you changing them?

RB1100AH.
I had an issue with an UPS that doesnt want to be recognized after a reboot. I tried to assign the UPS to the second port, but the first serial port is still show in used by the UPS. Even after removing all UPS from the setup, I can't even use the terminal to serial as I get an error that the port is still assigned to the UPS even when there is no more UPS in the setup.

tiggda · Sat Dec 08, 2012 11:14 am

I came across memory usage reporting error using v.5.22 with web proxy enabled caching to RAM. "System -> Resources" claim to have 4GiB free memory on my RB450G, while graphs say for example "Max: 345.17MiB (137.4%); Average: 124.61MiB (49.6%); Current: 66.73MiB (26.5%);". When I clean out the proxy cache stored in RAM all goes back to normal. I've 50% of RAM allocated for proxy cache.
So here's how it looks from terminal:

> /system resource print
uptime: 1w13h59m17s
version: 5.22
free-memory: 4294958956KiB
total-memory: 257108KiB
cpu: MIPS 24Kc V7.4
cpu-count: 1
cpu-frequency: 680MHz
cpu-load: 0%
free-hdd-space: 435532KiB
total-hdd-space: 520192KiB
write-sect-since-reboot: 1117527
write-sect-total: 47863782
bad-blocks: 0%
architecture-name: mipsbe
board-name: RB450G
platform: MikroTik

and screenshot from winbox:
winbox522.png

I now have also problems with creating backup on 5.22. Backup file gets partially created and the router logs:

Dec  8 10:11:27 router error creating backup file: could not read all configuration files

I can do

/export file=filename

though with no problems.

honzam · Sat Dec 08, 2012 12:02 pm

802.11N + NV2. Cpu goes to 100%. Reboot did not help. With 5.21 no CPU problem. Supout.rif send to support

Lakis · Sat Dec 08, 2012 2:18 pm

The scenario is Sextant AP ----> Sextant station bridge (protocol nv2) ... after 1 day trafic stoping. Enable disable wireless interface traffic comes. When ptotocol is nstream no problem. Downgrade to 5.18 NO problem too.
Do u still have this problem with 5.22 because I have this problem with previous version
but now 2-3 days with 5.22 seam fine

I confirm this problem still occur.

erebusodora · Mon Dec 10, 2012 9:45 am

The scenario is Sextant AP ----> Sextant station bridge (protocol nv2) ... after 1 day trafic stoping. Enable disable wireless interface traffic comes. When ptotocol is nstream no problem. Downgrade to 5.18 NO problem too.
Do u still have this problem with 5.22 because I have this problem with previous version
but now 2-3 days with 5.22 seam fine
I confirm this problem still occur.

I have this problem after 5.18 version. With 5.18 no problem. (upgraded new versions (5.19-5.20-5.21-5.22 on both sides but same problems)

guille4 · Tue Dec 11, 2012 7:02 pm

Hi... RB450G in bridge mode, ports 1 y 2 bridged, rstp, fw on, when traffic comes through the bridge, the rb reboot all the time... like in loop... I diconnect from the lan the port 1 and rb becomes stable... BUT with no traffic at all... same config with 5.21 and earlier firmwares works fine... I probe it in 3 diferentes segments of my lan, in 3 differents RB with the same results. I'm going back to 5.21 and problem solved. It is a BUG ?

patrickmkt · Sun Dec 16, 2012 5:34 pm

When removing an UPS, or changing the serial port of an UPS, the previous serial port is still assigned to the UPS and unable to be reused by any other process.
Am I the only one with this problem?
what do you mean by "changing the port"? how many serial ports does your device have, and why are you changing them?

You can just make the following try:

add a UPS to serial0.
In port, you will see that serial0 is now used by UPS.
Delete the UPS.

Do a system serial-terminal serial0 and you will have the following error: failure: port's channel is already in use
If you go to port, you will see that serial0 is still used by UPS even if you don't have any UPS in the system.

My problem is that once a port has been used by a UPS, you can't reeuse that port for anything else until reboot.
I call that a bug.

mangust · Mon Dec 17, 2012 9:14 pm

HI
Occasionally, i have almost 90% cpu load on my RB1200 v 5.22 for the short period of time.
This is not related traffic, a number of connections, because everything stays constant.
Did anybody faced same issue?
I'm thinking about snmp issue , but Normis told that it was fixed several version ago.

http://forum.mikrotik.com/viewtopic.php ... management
THX.
P.S

Read in another post about someone who had a similar problem so i changed my dude settings on the specific device and unchecked the Router OS checkbox in the general tab in the dude. It seems to have solved the problem.

This helps me as well. So, it's dude or snmp issue?

bminish · Tue Dec 18, 2012 7:18 pm

Maybe you have the default ssid=MikroTik?

Definitely not. These are configured sites upgraded to 5.22 where we see this

5CardBaka · Thu Dec 20, 2012 7:17 pm

Is there a valid link to a non torrent DL? Work doesn't let me use torrents and the 5.22 file in the downloads section is missing a bunch of things and the upgrade fails. I have 15 or so client that all got caught with the firmware upgrade bringing their devices down and now I'm going to have them ship em all back so I can fix them.

I confirmed the file is not working my side as well and have a now useless device sitting on my desk.

http://download2.mikrotik.com/routeros/ ... e-5.22.zip

DOES NOT WORK unless repaired your side already.

james [Teksavvy Biz services]

honzam · Fri Dec 21, 2012 11:37 pm

The scenario is Sextant AP ----> Sextant station bridge (protocol nv2) ... after 1 day trafic stoping. Enable disable wireless interface traffic comes. When ptotocol is nstream no problem. Downgrade to 5.18 NO problem too.

The same probem. Configuration is AP BRIDGE with nv2. No trafic, no ping. Reboot solved problem.
Reported to support

coffeecoco · Wed Dec 26, 2012 3:07 am

Hi i have problem with KVM on x86
for bench testing I loaded 20 Ros KVM into a Dell Routeros Host

occasionally a kvm crash and get stuck and wont respond.

And more importantly i am able to crash the entire routeros host ( dell box )

if i start and stop the Traffic generator many times off and on in a short period

result the server does not recover and i must walk into the server room and manually reboot it.

p.s is there a know stable version of ROS kvm? I want to generate my lab with out these failures

tiggda · Thu Jan 03, 2013 7:32 pm

I came across memory usage reporting error using v.5.22 with web proxy enabled caching to RAM. "System -> Resources" claim to have 4GiB free memory on my RB450G, while graphs say for example "Max: 345.17MiB (137.4%); Average: 124.61MiB (49.6%); Current: 66.73MiB (26.5%);". When I clean out the proxy cache stored in RAM all goes back to normal. I've 50% of RAM allocated for proxy cache.
So here's how it looks from terminal:

> /system resource print
uptime: 1w13h59m17s
version: 5.22
free-memory: 4294958956KiB
total-memory: 257108KiB
cpu: MIPS 24Kc V7.4
cpu-count: 1
cpu-frequency: 680MHz
cpu-load: 0%
free-hdd-space: 435532KiB
total-hdd-space: 520192KiB
write-sect-since-reboot: 1117527
write-sect-total: 47863782
bad-blocks: 0%
architecture-name: mipsbe
board-name: RB450G
platform: MikroTik

and screenshot from winbox:
winbox522.png
I now have also problems with creating backup on 5.22. Backup file gets partially created and the router logs:
Code: Select all
Dec  8 10:11:27 router error creating backup file: could not read all configuration files
I can do
Code: Select all
/export file=filename
though with no problems.

Anyone else came across faulty memory usage reporting and broken configuration backup?

Hotz1 · Thu Jan 10, 2013 8:09 am

Beginning on Nov 12, several devices on our network are having their (static) DHCP addresses deassigned and immediately reassigned every few hours, intermittently, despite the standard 3-day lease length... At the same time that this occurs, current connections (e.g., VoIP, Skype) on these devices drop... I am not sure if this is caused by the dhcp-server system (e.g., changes made for 5.21) or something else; Hopefully, this will help someone track down the problem. If anyone has any insight into this, or this issue has been seen before, please let me know!

EDIT: This is on a RB750UP, currently running ROS 5.22. Upon further perusal of the logs, this deassign-reassign pattern goes back years--but this is the first time I have noticed it happening with static leases, and with devices for which it causes the user a real inconvenience.

NO COMMENT on dhcp-server deassigning and reassigning leases at odd times?! This isn't happening to anyone else?

Since the last time I reported this issue, I have replaced the RB750UP with an RB2011UAS-2HnD and created an all-new configuration, but this problem still happens. VoIP calls are disconnecting, remotely-mounted file systems are disconnecting, it's a mess.

Just today, the log shows DHCP being deassigned and reassigned to the same device twice: first at 11:24am, and again at 4:04pm:

Jan  9 11:24:05 33Comm LAN2-DHCP deassigned 192.168.152.20 from [hh:hh:hh:hh:hh:hh]
Jan  9 11:24:06 33Comm LAN2-DHCP assigned 192.168.152.20 to [hh:hh:hh:hh:hh:hh]
...
Jan  9 16:04:14 33Comm LAN2-DHCP deassigned 192.168.152.20 from [hh:hh:hh:hh:hh:hh]
Jan  9 16:04:15 33Comm LAN2-DHCP assigned 192.168.152.20 to [hh:hh:hh:hh:hh:hh]

Config:
/ip pool
add name=LAN2-Pool ranges=192.168.152.10-192.168.152.250

/ip dhcp-server
add add-arp=yes address-pool=LAN2-Pool authoritative=yes disabled=no interface=ether2-LAN lease-time=3d name=LAN2-DHCP

/ip dhcp-server network
add address=192.168.152.0/24 dhcp-option="" dns-server=192.168.152.1 gateway=192.168.152.1 ntp-server=10.0.1.13 wins-server=""

At the very least, I would expect these events to occur three days apart; i.e., the duration of the lease. And I certainly would not expect a DHCP renewal to cause connections to drop. Insights, anyone?

onnoossendrijver · Thu Jan 10, 2013 12:41 pm

At the very least, I would expect these events to occur three days apart; i.e., the duration of the lease. And I certainly would not expect a DHCP renewal to cause connections to drop. Insights, anyone?

This is probably normal behaviour. A DHCP client should renew its IP adress at half leasetime. Most clients do it more often in my expreience.

Hotz1 · Thu Jan 10, 2013 1:51 pm

At the very least, I would expect these events to occur three days apart; i.e., the duration of the lease. And I certainly would not expect a DHCP renewal to cause connections to drop. Insights, anyone?
This is probably normal behaviour. A DHCP client should renew its IP adress at half leasetime. Most clients do it more often in my expreience.

Renewing the lease might be normal behavior, but not dropping connections as a result! I found these deassign/reassign events because they coincide with the client reporting that an application's remote database connection closed unexpectedly. It has been happening several times a day. Not all of them trace back to one of these DHCP events, but the fact that two of them do makes me suspicious.

How would I go about confirming whether this is initiated by the client, rather than a bug in the dhcp server? What packet-sniffer settings will capture a DHCP release/renew from the client, and little else?

Hotz1 · Fri Jan 11, 2013 3:29 pm

This cannot be normal dhcp-server behavior, nor can this many different clients (owned by various individuals working in different organizations) be misconfigured in the same way. This isn't even the complete list for one day, just the more egregious examples:

DHCP deassigns/reassigns the same IP to the same MAC three times within fifteen seconds:

Jan 10 10:12:48 33Comm Hotspot-DHCP deassigned 10.1.150.82 from [mac1]
Jan 10 10:12:48 33Comm Hotspot-DHCP assigned 10.1.150.82 to [mac1]
Jan 10 10:12:57 33Comm Hotspot-DHCP deassigned 10.1.150.82 from [mac1]
Jan 10 10:12:57 33Comm Hotspot-DHCP assigned 10.1.150.82 to [mac1]
Jan 10 10:13:01 33Comm Hotspot-DHCP deassigned 10.1.150.82 from [mac1]
Jan 10 10:13:02 33Comm Hotspot-DHCP assigned 10.1.150.82 to [mac1]

Assigned, then 7 minutes later (de)assigned 4 times over the course of ~6 minutes:

Jan 10 14:23:06 33Comm Hotspot-DHCP assigned 10.1.150.60 to [mac2]
Jan 10 14:30:38 33Comm Hotspot-DHCP deassigned 10.1.150.60 from [mac2]
Jan 10 14:30:38 33Comm Hotspot-DHCP assigned 10.1.150.60 to [mac2]
Jan 10 14:32:23 33Comm Hotspot-DHCP deassigned 10.1.150.60 from [mac2]
Jan 10 14:32:23 33Comm Hotspot-DHCP assigned 10.1.150.60 to [mac2]
Jan 10 14:33:15 33Comm Hotspot-DHCP deassigned 10.1.150.60 from [mac2]
Jan 10 14:33:15 33Comm Hotspot-DHCP assigned 10.1.150.60 to [mac2]
Jan 10 14:37:00 33Comm Hotspot-DHCP deassigned 10.1.150.60 from [mac2]
Jan 10 14:37:00 33Comm Hotspot-DHCP assigned 10.1.150.60 to [mac2]

(de)assigned only 30 seconds after the initial assignment:

Jan 10 16:29:32 33Comm Hotspot-DHCP assigned 10.1.150.86 to [mac3]
Jan 10 16:30:04 33Comm Hotspot-DHCP deassigned 10.1.150.86 from [mac3]
Jan 10 16:30:05 33Comm Hotspot-DHCP assigned 10.1.150.86 to [mac3]

...and then half an hour later, most disturbingly, the same device is deassigned, and then reassigned a different IP:

Jan 10 17:02:27 33Comm Hotspot-DHCP deassigned 10.1.150.86 from [mac3]
Jan 10 17:02:30 33Comm Hotspot-DHCP assigned 10.1.150.66 to [mac3]

When would that ever be desired behavior?!

Assigned and deassigned twice over the course of one second--and left deassigned?!

Jan 10 23:40:46 33Comm Hotspot-DHCP assigned 10.1.150.46 to [mac4]
Jan 10 23:40:46 33Comm Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
Jan 10 23:40:46 33Comm Hotspot-DHCP assigned 10.1.150.46 to [mac4]
Jan 10 23:40:46 33Comm Hotspot-DHCP deassigned 10.1.150.46 from [mac4]

Interestingly, in this last case, the log file on the board itself shows this (de)assignment happening seven times in one second, and leaves it assigned. The above is taken from its remote log. On the board, the log file reads:

jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]

Clearly something is broken!

frankie · Fri Jan 11, 2013 9:53 pm

Still same problem on RB951-2n as with ROS 5.21, frequency dropped to 360MHz. Tested on two RB951-2n with Bootloader 2.41 and 3.0. Under v5.20 same boards shows 400MHz.

Wed Jan 16, 2013 1:09 am

NV2 is much better with 5.22. Some problematic links now run very smooth for a week. Good work MT!

n21roadie · Thu Jan 24, 2013 10:56 pm

This cannot be normal dhcp-server behavior, nor can this many different clients (owned by various individuals working in different organizations) be misconfigured in the same way. This isn't even the complete list for one day, just the more egregious examples:

DHCP deassigns/reassigns the same IP to the same MAC three times within fifteen seconds:
Jan 10 10:12:48 33Comm Hotspot-DHCP deassigned 10.1.150.82 from [mac1]
Jan 10 10:12:48 33Comm Hotspot-DHCP assigned 10.1.150.82 to [mac1]
Jan 10 10:12:57 33Comm Hotspot-DHCP deassigned 10.1.150.82 from [mac1]
Jan 10 10:12:57 33Comm Hotspot-DHCP assigned 10.1.150.82 to [mac1]
Jan 10 10:13:01 33Comm Hotspot-DHCP deassigned 10.1.150.82 from [mac1]
Jan 10 10:13:02 33Comm Hotspot-DHCP assigned 10.1.150.82 to [mac1]
Assigned, then 7 minutes later (de)assigned 4 times over the course of ~6 minutes:
Jan 10 14:23:06 33Comm Hotspot-DHCP assigned 10.1.150.60 to [mac2]
Jan 10 14:30:38 33Comm Hotspot-DHCP deassigned 10.1.150.60 from [mac2]
Jan 10 14:30:38 33Comm Hotspot-DHCP assigned 10.1.150.60 to [mac2]
Jan 10 14:32:23 33Comm Hotspot-DHCP deassigned 10.1.150.60 from [mac2]
Jan 10 14:32:23 33Comm Hotspot-DHCP assigned 10.1.150.60 to [mac2]
Jan 10 14:33:15 33Comm Hotspot-DHCP deassigned 10.1.150.60 from [mac2]
Jan 10 14:33:15 33Comm Hotspot-DHCP assigned 10.1.150.60 to [mac2]
Jan 10 14:37:00 33Comm Hotspot-DHCP deassigned 10.1.150.60 from [mac2]
Jan 10 14:37:00 33Comm Hotspot-DHCP assigned 10.1.150.60 to [mac2]
(de)assigned only 30 seconds after the initial assignment:
Jan 10 16:29:32 33Comm Hotspot-DHCP assigned 10.1.150.86 to [mac3]
Jan 10 16:30:04 33Comm Hotspot-DHCP deassigned 10.1.150.86 from [mac3]
Jan 10 16:30:05 33Comm Hotspot-DHCP assigned 10.1.150.86 to [mac3]
...and then half an hour later, most disturbingly, the same device is deassigned, and then reassigned a different IP:
Jan 10 17:02:27 33Comm Hotspot-DHCP deassigned 10.1.150.86 from [mac3]
Jan 10 17:02:30 33Comm Hotspot-DHCP assigned 10.1.150.66 to [mac3]
When would that ever be desired behavior?!

Assigned and deassigned twice over the course of one second--and left deassigned?!
Jan 10 23:40:46 33Comm Hotspot-DHCP assigned 10.1.150.46 to [mac4]
Jan 10 23:40:46 33Comm Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
Jan 10 23:40:46 33Comm Hotspot-DHCP assigned 10.1.150.46 to [mac4]
Jan 10 23:40:46 33Comm Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
Interestingly, in this last case, the log file on the board itself shows this (de)assignment happening seven times in one second, and leaves it assigned. The above is taken from its remote log. On the board, the log file reads:
jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP deassigned 10.1.150.46 from [mac4]
jan/10 23:40:46 dhcp,info Hotspot-DHCP assigned 10.1.150.46 to [mac4]

Clearly something is broken!

I have the same problem with many customers on 5.22 and DHCP leases, Yes there is something wrong with 5.22 DHCP

Hotz1 · Thu Jan 24, 2013 11:39 pm

This cannot be normal dhcp-server behavior, nor can this many different clients (owned by various individuals working in different organizations) be misconfigured in the same way... Clearly something is broken!
I have the same problem with many customers on 5.22 and DHCP leases, Yes there is something wrong with 5.22 DHCP

I'm glad to know it isn't just me or something flaky about our configuration. Are you also experiencing the breaking of persistent connections (VoIP, RDP) when this happens? Do you suppose downgrading to 5.21 might improve the situation?

n21roadie · Fri Jan 25, 2013 2:10 am

I'm glad to know it isn't just me or something flaky about our configuration. Are you also experiencing the breaking of persistent connections (VoIP, RDP) when this happens? Do you suppose downgrading to 5.21 might improve the situation?

I have downgraded some CPE's to 5.20 because the logs on cpe's running that version did not have dhcp issues and i needed a quick if temporary fix for this, on the AP's and a lot of cpe's which are still 5.22 until i downgrade is to remove any IP Services not being used for me i use only Winbox + Telnet the rest API,ftp,ssh,www-ssh and especially www are not used so i disabled not sure it will help.

Fri Jan 25, 2013 12:43 pm

Hotz1
we are interested in your problem about DHCP-server leases reassignments.

1) Please run /tool sniffer on DHCP-server interface, during assignment/deassigment;
2) Make support output file after clicking stop on /tool sniffer;
3) Send both files for us, we will research where could be the problem (I assume local network works fine and there is no problem with wireless disconnects, bad switch, etc.).

n21roadie · Fri Jan 25, 2013 9:37 pm

Hotz1
we are interested in your problem about DHCP-server leases reassignments.

1) Please run /tool sniffer on DHCP-server interface, during assignment/deassigment;
2) Make support output file after clicking stop on /tool sniffer;
3) Send both files for us, we will research where could be the problem (I assume local network works fine and there is no problem with wireless disconnects, bad switch, etc.).

@Sergis I have the same issue and will follow your instructions, in response to question about local network works fine and there is no problem with wireless disconnects, bad switch, etc.
Usually I check wireless registration and when it says uptime in days and customer says they have disconnects several times daily I had assumed it was being caused by some other device on the customers LAN and did find with one customer a rouge DHCP server which was taken down but then another customer asks are we having network issues and another then checking at random many customers CPE logs and DHCP leases reassignments - alarm bells rings? on checking customers with 5.20 they did not have these DHCP leases reassignments so i used DUDE to force upgrade to 5.20 ("force upgrade" which should be titled "force install"?) and I have disabled ports not used to access the routers and in my case i use only Telnet,winbox,
I will forward the support output file and /tool sniffer files to support

Below is just from one customer



Jan/08/2013 18:59:43 dhcp,info dhcp1 deassigned 192.168.1.198 from 8C:FA:BA:5D:39:97
Jan/08/2013 18:59:45 dhcp,info dhcp1 assigned 192.168.1.198 to 8C:FA:BA:5D:39:97
Jan/08/2013 19:11:47 dhcp,info dhcp1 deassigned 192.168.1.96 from 04:0C:CE:4C:95:2A
Jan/08/2013 19:11:49 dhcp,info dhcp1 assigned 192.168.1.96 to 04:0C:CE:4C:95:2A
Jan/08/2013 20:06:08 dhcp,info dhcp1 deassigned 192.168.1.198 from 8C:FA:BA:5D:39:97
Jan/08/2013 20:06:09 dhcp,info dhcp1 assigned 192.168.1.198 to 8C:FA:BA:5D:39:97
Jan/08/2013 21:54:51 dhcp,info dhcp1 assigned 192.168.1.33 to 60:67:20:AB:E8:4C
Jan/09/2013 11:33:58 dhcp,info dhcp1 deassigned 192.168.1.29 from 00:1B:B1:8B:2E:40
Jan/09/2013 18:18:40 dhcp,info dhcp1 deassigned 192.168.1.96 from 04:0C:CE:4C:95:2A
Jan/09/2013 18:18:42 dhcp,info dhcp1 assigned 192.168.1.96 to 04:0C:CE:4C:95:2A
Jan/09/2013 18:26:31 dhcp,info dhcp1 deassigned 192.168.1.198 from 8C:FA:BA:5D:39:97
Jan/09/2013 18:26:32 dhcp,info dhcp1 assigned 192.168.1.198 to 8C:FA:BA:5D:39:97
Jan/09/2013 21:32:10 interface,info ether1 link down
Jan/09/2013 21:32:34 interface,info ether1 link up (speed 100M, full duplex)
Jan/09/2013 21:32:43 interface,info ether1 link down
Jan/09/2013 21:32:44 interface,info ether1 link up (speed 100M, full duplex)
Jan/09/2013 21:32:51 interface,info ether1 link down
Jan/09/2013 21:32:53 dhcp,info dhcp1 deassigned 192.168.1.93 from 00:19:FB:24:BA:11
Jan/09/2013 21:32:53 dhcp,info dhcp1 assigned 192.168.1.93 to 00:19:FB:24:BA:11
Jan/09/2013 21:32:53 interface,info ether1 link up (speed 100M, full duplex)
Jan/10/2013 18:59:43 dhcp,info dhcp1 deassigned 192.168.1.198 from 8C:FA:BA:5D:39:97
Jan/10/2013 19:00:02 dhcp,info dhcp1 assigned 192.168.1.198 to 8C:FA:BA:5D:39:97
Jan/10/2013 19:01:30 dhcp,info dhcp1 deassigned 192.168.1.96 from 04:0C:CE:4C:95:2A
Jan/10/2013 19:01:31 dhcp,info dhcp1 assigned 192.168.1.96 to 04:0C:CE:4C:95:2A
Jan/10/2013 20:03:38 dhcp,info dhcp1 deassigned 192.168.1.33 from 60:67:20:AB:E8:4C
Jan/10/2013 20:03:39 dhcp,info dhcp1 assigned 192.168.1.33 to 60:67:20:AB:E8:4C
Jan/10/2013 20:44:25 dhcp,info dhcp1 deassigned 192.168.1.35 from 00:0C:43:CE:19:D6
Jan/10/2013 20:44:34 dhcp,info dhcp1 assigned 192.168.1.35 to 00:0C:43:CE:19:D6
Jan/10/2013 21:02:28 interface,info ether1 link down
Jan/10/2013 21:02:48 interface,info ether1 link up (speed 100M, full duplex)
Jan/10/2013 21:02:57 interface,info ether1 link down
Jan/10/2013 21:02:59 interface,info ether1 link up (speed 100M, full duplex)
Jan/10/2013 21:03:05 interface,info ether1 link down
Jan/10/2013 21:03:06 dhcp,info dhcp1 deassigned 192.168.1.93 from 00:19:FB:24:BA:11
Jan/10/2013 21:03:07 interface,info ether1 link up (speed 100M, full duplex)
Jan/10/2013 21:03:12 dhcp,info dhcp1 deassigned 192.168.1.198 from 8C:FA:BA:5D:39:97
Jan/10/2013 21:03:12 dhcp,info dhcp1 assigned 192.168.1.93 to 00:19:FB:24:BA:11
Jan/10/2013 21:03:13 dhcp,info dhcp1 assigned 192.168.1.198 to 8C:FA:BA:5D:39:97
Jan/11/2013 15:39:32 dhcp,info dhcp1 deassigned 192.168.1.96 from 04:0C:CE:4C:95:2A
Jan/11/2013 15:39:34 dhcp,info dhcp1 assigned 192.168.1.96 to 04:0C:CE:4C:95:2A
Jan/11/2013 21:13:11 dhcp,info dhcp1 deassigned 192.168.1.96 from 04:0C:CE:4C:95:2A
Jan/11/2013 21:13:13 dhcp,info dhcp1 assigned 192.168.1.96 to 04:0C:CE:4C:95:2A
Jan/12/2013 17:59:17 dhcp,info dhcp1 deassigned 192.168.1.198 from 8C:FA:BA:5D:39:97
Jan/12/2013 17:59:19 dhcp,info dhcp1 assigned 192.168.1.198 to 8C:FA:BA:5D:39:97
Jan/12/2013 18:11:42 dhcp,info dhcp1 deassigned 192.168.1.96 from 04:0C:CE:4C:95:2A
Jan/12/2013 18:11:46 dhcp,info dhcp1 assigned 192.168.1.96 to 04:0C:CE:4C:95:2A
Jan/12/2013 18:32:50 dhcp,info dhcp1 deassigned 192.168.1.37 from 00:0C:E7:01:62:4C
Jan/12/2013 18:33:24 dhcp,info dhcp1 assigned 192.168.1.31 to 00:0C:E7:01:62:4C
Jan/12/2013 18:35:24 dhcp,info dhcp1 deassigned 192.168.1.31 from 00:0C:E7:01:62:4C
Jan/12/2013 18:35:41 dhcp,info dhcp1 assigned 192.168.1.31 to 00:0C:E7:01:62:4C
Jan/12/2013 19:39:11 dhcp,info dhcp1 deassigned 192.168.1.31 from 00:0C:E7:01:62:4C
Jan/12/2013 19:39:15 dhcp,info dhcp1 assigned 192.168.1.31 to 00:0C:E7:01:62:4C
Jan/13/2013 13:23:27 dhcp,info dhcp1 deassigned 192.168.1.31 from 00:0C:E7:01:62:4C
Jan/13/2013 13:23:30 dhcp,info dhcp1 assigned 192.168.1.31 to 00:0C:E7:01:62:4C
Jan/13/2013 13:24:38 dhcp,info dhcp1 deassigned 192.168.1.31 from 00:0C:E7:01:62:4C
Jan/13/2013 13:30:25 dhcp,info dhcp1 assigned 192.168.1.31 to 00:0C:E7:01:62:4C
Jan/13/2013 13:30:31 dhcp,info dhcp1 deassigned 192.168.1.31 from 00:0C:E7:01:62:4C
Jan/13/2013 13:30:36 dhcp,info dhcp1 assigned 192.168.1.31 to 00:0C:E7:01:62:4C
Jan/13/2013 13:42:46 dhcp,info dhcp1 deassigned 192.168.1.31 from 00:0C:E7:01:62:4C
Jan/13/2013 13:42:46 dhcp,info dhcp1 assigned 192.168.1.31 to 00:0C:E7:01:62:4C
Jan/13/2013 17:32:01 dhcp,info dhcp1 deassigned 192.168.1.31 from 00:0C:E7:01:62:4C
Jan/13/2013 17:32:52 dhcp,info dhcp1 assigned 192.168.1.31 to 00:0C:E7:01:62:4C
Jan/14/2013 13:50:11 dhcp,info dhcp1 deassigned 192.168.1.30 from 08:60:6E:27:07:C9
Jan/14/2013 13:50:11 dhcp,info dhcp1 assigned 192.168.1.30 to 08:60:6E:27:07:C9
Jan/14/2013 19:45:31 dhcp,info dhcp1 deassigned 192.168.1.198 from 8C:FA:BA:5D:39:97
Jan/14/2013 19:45:38 dhcp,info dhcp1 assigned 192.168.1.198 to 8C:FA:BA:5D:39:97
Jan/14/2013 20:40:25 dhcp,info dhcp1 deassigned 192.168.1.31 from 00:0C:E7:01:62:4C
Jan/14/2013 20:40:42 dhcp,info dhcp1 assigned 192.168.1.31 to 00:0C:E7:01:62:4C
Jan/14/2013 21:37:38 dhcp,info dhcp1 deassigned 192.168.1.31 from 00:0C:E7:01:62:4C
Jan/14/2013 21:37:50 dhcp,info dhcp1 assigned 192.168.1.31 to 00:0C:E7:01:62:4C
Jan/14/2013 21:38:19 dhcp,info dhcp1 deassigned 192.168.1.31 from 00:0C:E7:01:62:4C
Jan/14/2013 21:38:29 dhcp,info dhcp1 assigned 192.168.1.31 to 00:0C:E7:01:62:4C
Jan/14/2013 23:16:31 dhcp,info dhcp1 deassigned 192.168.1.30 from 08:60:6E:27:07:C9
Jan/14/2013 23:16:31 dhcp,info dhcp1 assigned 192.168.1.30 to 08:60:6E:27:07:C9
Jan/14/2013 23:18:32 dhcp,info dhcp1 deassigned 192.168.1.30 from 08:60:6E:27:07:C9
Jan/14/2013 23:18:32 dhcp,info dhcp1 assigned 192.168.1.30 to 08:60:6E:27:07:C9
Jan/14/2013 23:20:09 dhcp,info dhcp1 deassigned 192.168.1.30 from 08:60:6E:27:07:C9
Jan/14/2013 23:20:09 dhcp,info dhcp1 assigned 192.168.1.30 to 08:60:6E:27:07:C9

Alessio Garavano · Tue May 21, 2013 1:28 am

I have this DHCP problem a lot of time and never can fix!

Many times the reassigned IP is different of the deassigned and the client figure like connected in the hotspot with the old IP and not allowed more sessions to the client and we need to remove the client manually to allow reconnect again!

In the last v6.0 of May 17th the problem persist...

Any help?

phendry · Mon Nov 04, 2013 1:08 pm

RB1100AH.
I had an issue with an UPS that doesnt want to be recognized after a reboot. I tried to assign the UPS to the second port, but the first serial port is still show in used by the UPS. Even after removing all UPS from the setup, I can't even use the terminal to serial as I get an error that the port is still assigned to the UPS even when there is no more UPS in the setup.

Did you ever get a resolution to this? Couldn't see anything acknowledging the bug in the v5 changelogs so guessing it's still an issue with v5.26?

phendry · Mon Nov 04, 2013 1:32 pm

I did note that this only seems to occur if you disable the UPS before removing. If you just remove then its seems to clear the "used by" state. We needed to access the UPS directly to update battery count at a couple of sites to give a more accurate run time.

asimko · Wed Nov 13, 2013 10:03 am

What's new in 5.22 (2012-Nov-23 09:28):

*) wireless - fixed rare nv2 link stall;
So, how serious is this? Every links goes down now and than. Should I now upgrade or not? (I just finished upgrading to 5.21...)

Did the links stall under certain conditions? Or in general.
In the first case I would like to know what these conditions/configs where.... In the second case I probably need to update again soon.... (after not too many issues are being reported here...)

I'd like some additional information on this as well. I've noticed a problem where some NV2 configured access points would just stop sending/receiving data and would not start again until the interface was disabled and then re-enabled.

Does this fix that issue? Is there a detailed bug report we can see?

We have still this issue on several APs! We have everywhere version 5.26 with newest firmware, APs are mostly RB433L or AH with SXT or RB711 all upgraded to 5.26. Is there a solution for this issue?

Who is online