Here is information about this station-roaming:Would you be so kind and shed some light on this line in the changelog:
*) wireless - added "station-roaming" setting (cli only);
Hi Guys,
Can I please have more info on *) wAP ac - improved 2.4GHz wireless performance;
e.g. under what situations is performance "improved" ?
I ask as we have had issues with the wAP AC's 2.4Ghz radios and performance to Samsung android devices, as well as WPA group-key issues..
It is clarified in the manual: http://wiki.mikrotik.com/wiki/Manual:In ... on_RoamingStation Roaming feature is available only for 802.11 wireless protocol. when we use background scan on nv2 and use station roaming. is there any work for nv2.
I've requested this 2 years ago but the NAT Nazis say "it's wrong". Because some IPv6/end2end connectivity ideologists said so.are there plans to add NAT for IPv6 ?
at home i have dynamic ipv6 from the provider and a static ipv6 net with no flatrate at tunnelprovider.
the simplest solution is to NAT unknown networks und known networks without NAT for static firewall config.
Can you clarify if this adds any new features for PPP / MRRU? Does this mean that you have added (or will add) PPP Fragmentation reordering / buffering to fix the case where MRRU fragments come in our of order?!) ppp - completely rewritten internal fragmentation algorithm (when MRRU is used), optimized for multicore;
[benoga@HAP_AC] > /system leds setting set all-leds-off=immediate
missing values (5)
Rebinding or renewing? And only on startup?Version 6.39rc7 has been released.
Changes since previous rc:
*) dhcpv6-client - fixed dhcpv6 rebind on startup;
http://forum.mikrotik.com/viewtopic.php ... 16#p575316Rebinding or renewing? And only on startup?Version 6.39rc7 has been released.
Changes since previous rc:
*) dhcpv6-client - fixed dhcpv6 rebind on startup;
However, the new version solves my problem at least partially.
As I have already described in this thread, DHCPv6 is broken for me since v6.34, If the connection is lost, renewing and rebinding takes 20 minutes. Since v6.39rc this time has been reduced to 10 minutes.
Before v6.34:
PPPoE connected ---> status: bound
After v6.34:
PPPoE connected ---> status: rebinding ---> 10 minutes waiting ---> status: renewing ---> 10 Minutes waiting ---> status: bound
After v6.39rc:
PPPoE connected ---> status: rebinding ---> 10 minutes waiting --- status: bound
Can we use L2TP + MRRU over one WAN link of PPPoE provider 1492 MTU/MRU?Kalpar - Yes, that is exactly what was done! MRRU works in same way as it did before, but it is now adjusted/updated to multi core age
Thank you for your advice. It works indeed, but needs a delay between enabling PPPoE and dhcp-client release.http://forum.mikrotik.com/viewtopic.php ... 16#p575316Rebinding or renewing? And only on startup?Version 6.39rc7 has been released.
Changes since previous rc:
*) dhcpv6-client - fixed dhcpv6 rebind on startup;
However, the new version solves my problem at least partially.
As I have already described in this thread, DHCPv6 is broken for me since v6.34, If the connection is lost, renewing and rebinding takes 20 minutes. Since v6.39rc this time has been reduced to 10 minutes.
Before v6.34:
PPPoE connected ---> status: bound
After v6.34:
PPPoE connected ---> status: rebinding ---> 10 minutes waiting ---> status: renewing ---> 10 Minutes waiting ---> status: bound
After v6.39rc:
PPPoE connected ---> status: rebinding ---> 10 minutes waiting --- status: bound
I used this command when I scheduled a PPPoE reconnect: ipv6 dhcp-client release 0;
/interface pppoe-client disable [find name="pppoe-out1"];
/ipv6 dhcp-client disable [find interface="pppoe-out1"];
/interface pppoe-client enable [find name="pppoe-out1"];
/ipv6 dhcp-client enable [find interface="pppoe-out1"];
And on the new-style "only 16MB flash" models it is even more difficult...I had to downgrade to 6.36.4 instead of 6.37.3, since manual downgrade and reinstalling additional packages is not quite trivial and fast on a running system.
I checked how long it took to reconnect. I disconnected my PPPoE and stopped the DHCPv6 Client. Started my DHCPv6 Client and then again the PPPoE and the client got bound within two seconds. I have added a while ago the Prefix hint in the DHCPv6 and you can end it with "::" with /subnet then check what the reconnect time is.Version 6.39rc7 has been released.
Changes since previous rc:This script lacks elegance, but at least it works.Code: Select all/interface pppoe-client disable [find name="pppoe-out1"]; /ipv6 dhcp-client disable [find interface="pppoe-out1"]; /interface pppoe-client enable [find name="pppoe-out1"]; /ipv6 dhcp-client enable [find interface="pppoe-out1"];
Please make support output file and send it to support@mikrotik.com so we could see your configuration and reproduce this problemBroken:
DHCP over EOIP (no encription)
Some devices don't get IP's even directly connected - Panasonic VOIP phone. Works fine in 3.37.3
If you have more information we could ask Mike to look i to it if it can be changed on their side to make it more compatible besides the AVM routers.XS4ALL? It is a bug at their side.
You can work around it by setting up a tool->netwatch of some internet IP (e.g. the nexthop you get for the default route)
and putting this in the "UP script":
/ipv6 dhcp-client release [find status=bound]
This makes the client release and then request the IPv6 prefix when the interface comes up (within a minute).
Mike says it cannot be changed, and he thinks it is a bug in the router that it keeps the lease when the PPPoE goes down and doesIf you have more information we could ask Mike to look i to it if it can be changed on their side to make it more compatible besides the AVM routers.
Thanks and I have now added the Netwatch and I found that only this one worked for me: /ipv6 dhcp-client release [find status=rebinding...]Mike says it cannot be changed, and he thinks it is a bug in the router that it keeps the lease when the PPPoE goes down and doesIf you have more information we could ask Mike to look i to it if it can be changed on their side to make it more compatible besides the AVM routers.
not request a new release immediately when it comes back up. But this is only "common practice", it is not written in the standard.
My workaround with netwatch works, but I would prefer when MikroTik adds a specific "script run when interface comes up" feature.
So the behaviour (6.39RC7) is now to renew and if necessary to rebind and that is a I think the normal way. Then as an exception on this there could be a option to choose for release when renew does not fetch the address. Or to renew-->rebind-->release-->renew-->rebind-->release-->etc. as default fetch.It may be that the required command is different for 6.39rc because changes were made to try to fix it.
Maybe it is better to select on some other value as there usually will be only one entry and that is the one to be released.
Please tell me that this is the problem on the "hap AC" when the wireless interface is running but not visible or flapping?*) wireless - fixed rare wireless ac interface lockup;
yep, WinBox 3.8 doesn't allow to edit src/dst-port even on previous versions of ROSCan anyone confirm this viewtopic.php?f=21&t=116821&p=577546 ?
Stay at 6.36.4 or disable encryption in newer releases as workaroundwireless still broken. my old phone Lenovo A660 can't connect to AP after 6.37 migration anymore.
http://forum.mikrotik.com/viewtopic.php?f=14&t=116270mpls - fixed crash on active tunnel loss in MPLS TE setups;
Can we ask what this entails?
Not good that you stopped supporting 6.36.x and replaced it with 6.37.4!! Not at all!Stay at 6.36.4 or disable encryption in newer releases as workaroundwireless still broken. my old phone Lenovo A660 can't connect to AP after 6.37 migration anymore.
About Intel 2200bgHi
I have just tried 6.39rc7 on a RB2011UiAS-2HnD-IN. A lot of client equipment seem to connect fine with or without encryption. Unfortunately, an old Intel 2200BG client cannot connect to it no matter if I use WPA2 encryption on it or not. To confirm that the Intel 2200BG card worked, I tested it up against a Broadcom based access point and it connected fine with or without encryption.
I have debug logs turned on. The logs say "disconnected, extensive data loss" when I try with wpa2 encryption. If I use no encryption, the logs say "disconnected, received disassoc: unspecified (1)".
Qiet72
A Client has >50 IP-Cams which does not work with newer ROS, so they are all stuck at 6.36.4?Hi
About Intel 2200bg [..] WPA2 support workaround for this card won't be added!
Last supported version for Intel 2200bg 6.36.4
I'm sorry, but what is wrong with that? Very good and recent version. I have some applications that are restricted to v5.26 for similar reasons. Or all the mipsle devices that are stuck @ v6.32.4so they are all stuck at 6.36.4?
You might be right, but other vendors do support this devices. If they stop the support for 6.36.4 now,It is impossible to support all the legacy stuff all the time - at some time you have to move on.
im afraid that not true.You might be right, but other vendors do support this devices. If they stop the support for 6.36.4 now,It is impossible to support all the legacy stuff all the time - at some time you have to move on.
it will be old within a year at lest, exactly the timeframe i neew to switch to other hardware.
The only thing I'd like to hear is if MT plans to give some "enhanced" or "longterm" support to 6.36.4 or
if I do have to make plans about exchanging my AP-Devices.
Regular wAP doesn't have such problem. Please contact support@mikrotik.com with detailed explanation on your test, we will try to assist in your problem with wAP board.About
*) wap-ac - fixed performance problems with 2.4GHz wireless (additional reboot after upgrade required);
I have same issue with wAP (RBwAP2nD) - in the same place there are D-Link DAP-2310 and just buyed wAP. I connect from the same device and run iperf. D-Link gives about double speed above wAP. Of course there are only one AP (D-Link or wAP) switched on. And D-Link TX power and sensitivity lower, than wAP. I fighting second day , try all possible modes for wAP - no result.
Maybe there are similar solution for wAP as for wAP AC?
That's exactly what /export does.Hi, i need a function similar to "show running config", to be able show the config in CLI. It's possible?
I'm afraid, thats not the full truth aswell. It doesn't seem that MT did change the kernel in 6.37.x, as they planned to change the kernel in 7.x. If you know more, just tell me.im afraid that not true.
arches(either that was mips, arm, ppc or x86 branch)that marked "deprecated" ans phased-out from linux toolchain(and kernel thus not be updated as much or at all)aren't supported by, regardless vendor. and few one that still backporting thing trying to keep alive(cicsco/linksys, juniper, etc)doing it not for long.
heck, some vendors aren't properly support(with mission/time-citical security fixes atleast) their Current devices, let alone Legacy. google for example how frequent updates of say alpha or ubiquity or belkin, flextronix or oher ODM or OEM are done.
so nope despite "being pathetic" or "spend too much on PR"(esp compared with "engineering") other vendors usually not bring.
Yes, but for example, ssh admin@192.168.88.1 show-config | Grep ether1 is not possible with export, or yes?That's exactly what /export does.Hi, i need a function similar to "show running config", to be able show the config in CLI. It's possible?
This:Yes, but for example, ssh admin@192.168.88.1 show-config | Grep ether1 is not possible with export, or yes?
ssh admin@192.168.88.1 "/export"
I apologize, it's true, when I tried it a while back I had not worked but then I did not try again. Thank you.This:Yes, but for example, ssh admin@192.168.88.1 show-config | Grep ether1 is not possible with export, or yes?works like a charm for me. Have even bothered to try it yourself before asking?Code: Select allssh admin@192.168.88.1 "/export"
same on hap ac lite with 6.39rc19On device QRT AC, winbox 3.10, ROS 6.38 - 6.38.1 and 6.39rc19 release i don't see settings for HT MCS on wlan interface.
Any more detailed explanation on these? Is this the one that caused some configuration loss issues in v6 since the beginning?!) filesystem - fixed rare situation when filesystem went into read-only mode (some configuration might have gotten lost on reboot);
!) filesystem - fixed rare situation when filesystem failed to read all configuration on startup;
That is great! Even better would be when it lands on the Webfig page after login, maybe only on Quickset when no config has been done before.Version 6.39rc20 has been released.
*) webfig - added menubar to quickly select between Webfig, Quickset and Terminal;
We also observed exactly this with CRS125 24G-1S-RM and RB2011UiAS-RM routers. 6.38.1 did not fix it. We have reverted to 6.37.3 too. Should it be fixed in future patches?We have observed exactly this with a UniFi UAP-LR and a Soekris Engineering Net4801 board. We have reverted to 6.37.3 to restore correct DHCP behaviour.Yes. Mikrotik - DHCP server. Guest OS on HOST and HOST himself - clientsyour hyper-v client is a dhcp-client receiving the address from the DHCP server?
In addition - when described error is occurred, the affected clients remaining in "offering" state in DHCP server - Leases table with cycled 30s timeout. Seems like synthethic NIC dont answer on offer from DHCP, while real ones work as usual. In ROS 6.37 all work fine with both NIC.
Thanks
Giles.
:put [/ip ipsec remote-peers get 0 remote-address];
indices were never meant to be used without 'print'. correct form is the following:but not in script until I do a print again.
:put [/ip ipsec remote-peers get [find where something=blabla] remote-address];
Also, radio name and regulatory domain disappeared in 6.38, and tx power table is missing for 5 GHz.On device QRT AC, winbox 3.10, ROS 6.38 - 6.38.1 and 6.39rc19 release i don't see settings for HT MCS on wlan interface.
i did some tests with traffic generator on first board i could find (RB750Gr2) - ~20% increase in max throughput, not bad, not bad at all.fast-forward is an exciting development
This is normal when you do not pay special attention to the firewall.I have upgraded RB433 to 6.39rc25.
On the other side there is RB3011@6.37.3
I have defined GRE tunnel on both sides, assigned IPs, but only on RB433 I have specified IPSec Secret.
GRE tunnel is working despite the fact that on RB3011 there is no IPSecret specified.
Deactivated tunnels on one, the other, both sides ... no change.
Am I doing sth wrong or IPSec Secret is ignored ?
Yes, Advanced Mode or not, these fields do not appear.colanderman - Are you sure that Advanced Mode is enabled on wireless interface?
I do not understand. It is obvious that there should be proper firewall set of rules to pass GRE and IPSec connection but what is such firewall rule for? How it deals with password?This is normal when you do not pay special attention to the firewall.
The IPsec config is only a shortcut to IPsec to setup a Peer and Policy for GRE traffic, but as long as the...
So, make sure your firewall entries are correct. Like:
add action=accept chain=input ipsec-policy=in,ipsec protocol=gre
Thanks, however in that part there seems nothing can be found to hook with "find where" so I looked again into printing. I am now issuing now "/ip ipsec remote-peers print value-list;" before the line.indices were never meant to be used without 'print'. correct form is the following:but not in script until I do a print again.Code: Select all:put [/ip ipsec remote-peers get [find where something=blabla] remote-address];
You expect a lot, but it does not work like that!I do not understand. It is obvious that there should be proper firewall set of rules to pass GRE and IPSec connection but what is such firewall rule for? How it deals with password?This is normal when you do not pay special attention to the firewall.
The IPsec config is only a shortcut to IPsec to setup a Peer and Policy for GRE traffic, but as long as the...
So, make sure your firewall entries are correct. Like:
add action=accept chain=input ipsec-policy=in,ipsec protocol=gre
I assume that I am assigning IPs to secured connection so I assume that addresses are assigned not to pure GRE but to IPSec over GRE so if there is no matching password pair then the IPSec should not be established = no traffic from side to side.
I'm expecting sending data over encrypted tunnel not over simple GRE which carries IPSec traffic.
More, if I have no such rule then there should be no chance to make secured connection so traffic should be blocked.
Oh sorry! I mean in webfig, not winbox.colanderman - Before you connect to router go to Tools/Clear Cache on Winbox loader and try to test this afterwards.
If there's only one peer, then just use [find], without 'where' partThanks, however in that part there seems nothing can be found to hook with "find where" so I looked again into printing. I am now issuing now "/ip ipsec remote-peers print value-list;" before the line.indices were never meant to be used without 'print'. correct form is the following:but not in script until I do a print again.Code: Select all:put [/ip ipsec remote-peers get [find where something=blabla] remote-address];
Indeed that works and there is a problem is when the first IPSEC connect did not work and you had to reconnect. Then there are more connections active of which the invalid ones will timeout eventually. Only one remote-dynamic-address isn't working and I get than an error that the template is invalid.If there's only one peer, then just use [find], without 'where' partThanks, however in that part there seems nothing can be found to hook with "find where" so I looked again into printing. I am now issuing now "/ip ipsec remote-peers print value-list;" before the line.indices were never meant to be used without 'print'. correct form is the following:but not in script until I do a print again.Code: Select all:put [/ip ipsec remote-peers get [find where something=blabla] remote-address];
:put /ip ipsec remote-peers> :put [/ip ipsec remote-peers get [find] remote-address ];
invalid internal item number
Thank you for long explanation but I expect, seems that I am wrong at this point, that If I specify passwords, the tunnel will not pass traffic if there is no match of password for both ends. Traffic should not be carried without encryption despite the method of generating policies....You expect a lot, but it does not work like that!....
IPsec policies define what traffic is encrypted and all traffic that does not match the policies is simply sent unencrypted. ....
Just to echo colanderman, Frequency Mode, Country & Antenna Gain are missing from webfig Wireless details in Advanced Mode. This problem is present in v6.38 and continues in v6.39RC. If I open Winbox and go to wireless advanced mode before I open Webfig then they appear.Oh sorry! I mean in webfig, not winbox.colanderman - Before you connect to router go to Tools/Clear Cache on Winbox loader and try to test this afterwards.
Could you please write to support@mikrotik.com with the exact SN that experience this problem?- WAP AC 6.39rc26
- users reported that their clients get disconnected randomely
- I watched caps,info logging and found concurrent "disconnected, group key timeout" messages for multiple clients running on 2.4Ghz,
i.e. 5 clients (e.g. with different MAC addresses starting with: 3CE072, F48E92, E0DB10, 64CC2E,5CF7:E6) get dropped at once in this case. I do not know whether this is the reason for this problem...
- Note: This seems to be only on WAP AC devices with serial number starting with 711E06..... (with MAC address starting with 6C:3B:6B) I bought 10 of those last week. On older devices with serial number 65710/69A50/6CBA06 no problems have been reported so far.
Yay!!!*) dhcp-client - added "script" option which executes script on state changes (CLI only);
cool. now I can react to lease instead of scheduling script to do ddns, address-lists, etc. ?*) dhcp-client - added "script" option which executes script on state changes (CLI only);
Didn't know this was in the works. Looked through release notes. Happy to see it though!*) snmp - added SSID to CAPsMAN registration table;
# grabserial -T -b 115200 -d /dev/ttyUSB0 -v
Opening serial port /dev/ttyUSB0
115200:8N1:xonxoff=0:rtscts=0
Printing absolute timing information for each line
Use Control-C to stop...
[18:14:36.570195 0.000002] -=< Watchdog IRQ >=-
[18:14:36.593493 0.031310] Call Trace:
[18:14:36.593796 0.000305] <4>{c3ee1ae0} dump_stack+0x8/0x30
[18:14:36.594533 0.000736] <4>{c3ee1ba8} 0xc32742d8 [music_dog@0xc3274000]
[18:14:36.595548 0.001016] <4>{c3ee1bc0} handle_irq_event_percpu+0x64/0x25c
[18:14:36.596584 0.001036] <4>{c3ee1c00} handle_irq_event+0x38/0x68
[18:14:36.597481 0.000897] <4>{c3ee1c18} handle_level_irq+0xc8/0xe8
[18:14:36.598352 0.000871] <4>{c3ee1c30} generic_handle_irq+0x28/0x44
[18:14:36.599264 0.000912] <4>{c3ee1c48} do_IRQ+0xb0/0xc0
[18:14:36.599940 0.000676] <4>{c3ee1c60} music_irq_dispatch+0x50/0x7c
[18:14:36.600867 0.000927] <4>{c3ee1c88} handle_irq_event_percpu+0x64/0x25c
[18:14:36.601928 0.001061] <4>{c3ee1cc8} handle_percpu_irq+0x54/0x84
[18:14:36.602837 0.000909] <4>{c3ee1ce8} generic_handle_irq+0x28/0x44
[18:14:36.603763 0.000927] <4>{c3ee1d00} do_IRQ+0xb0/0xc0
[18:14:36.604461 0.000697] <4>{c3ee1d18} ret_from_irq+0x0/0x4
[18:14:36.605211 0.000750] <4>more trace (sp:c3ee1d80):
[18:14:36.605854 0.000643] <4>{c3ee1d80} addrlist_get_list+0x128/0x1f4 [packet_hook@0xc3000000]
[18:14:36.607333 0.001479] <4>{c3ee1dc0} 0xc24f0118 [music_gmac@0xc24f0000]
[18:14:36.608369 0.001036] <4>{c3ee1de8} 0xc24f0560 [music_gmac@0xc24f0000]
[18:14:36.609411 0.001042] <4>{c3ee1e28} 0xc24f2688 [music_gmac@0xc24f0000]
[18:14:36.610452 0.001041] <4>{c3ee1e68} process_one_work+0x2dc/0x484
[18:14:36.611412 0.000960] <4>{c3ee1ea0} worker_thread+0x23c/0x3e0
[18:14:36.612329 0.000917] <4>{c3ee1ee0} kthread+0x88/0x90
[18:14:36.613784 0.001455] <4>{c3ee1f18} kernel_thread_helper+0x10/0x18
[18:14:36.619372 0.005588] <4>
[18:14:39.089481 2.470104]
[18:14:39.089613 0.000136]
[18:14:39.089665 0.000053] RouterBOOT booter 3.22
[18:14:39.090193 0.000528]
[18:14:39.090243 0.000050] CRS226-24G-2S+
[18:14:39.092686 0.002442]
[18:14:39.092739 0.000054] CPU frequency: 400 MHz
[18:14:39.095527 0.002787] Memory size: 64 MiB
[18:14:39.100394 0.004867] NAND size: 128 MiB
[18:14:39.209472 0.109074]
[18:14:39.209592 0.000124] Press any key within 2 seconds to enter setup..
[18:14:41.241416 2.031820]
[18:14:41.241529 0.000118] loading kernel from nand... OK
[18:14:43.523657 2.282122] setting up elf image... OK
[18:14:43.664576 0.140921] jumping to kernel code
[18:14:47.950500 4.285923] Starting...
[18:14:59.544603 11.594102] Starting services...
[18:15:16.490655 16.946053]
[18:15:16.493766 0.003115] mtk-core-switch Login: -=< Watchdog IRQ >=-
[18:37:36.215519 1339.721749] Call Trace:
[18:37:36.218042 0.002527] <4>{c3ee1ad8} dump_stack+0x8/0x30
[18:37:36.221096 0.003054] <4>{c3ee1ba0} 0xc32882d8 [music_dog@0xc3288000]
[18:37:36.224452 0.003357] <4>{c3ee1bb8} handle_irq_event_percpu+0x64/0x25c
[18:37:36.229146 0.004694] <4>{c3ee1bf8} handle_irq_event+0x38/0x68
[18:37:36.232361 0.003215] <4>{c3ee1c10} handle_level_irq+0xc8/0xe8
[18:37:36.235556 0.003194] <4>{c3ee1c28} generic_handle_irq+0x28/0x44
[18:37:36.241172 0.005617] <4>{c3ee1c40} do_IRQ+0xb0/0xc0
[18:37:36.243154 0.001982] <4>{c3ee1c58} music_irq_dispatch+0x50/0x7c
[18:37:36.246397 0.003242] <4>{c3ee1c80} handle_irq_event_percpu+0x64/0x25c
[18:37:36.252114 0.005717] <4>{c3ee1cc0} handle_percpu_irq+0x54/0x84
[18:37:36.255332 0.003219] <4>{c3ee1ce0} generic_handle_irq+0x28/0x44
[18:37:36.257564 0.002232] <4>{c3ee1cf8} do_IRQ+0xb0/0xc0
[18:37:36.260583 0.003018] <4>{c3ee1d10} ret_from_irq+0x0/0x4
[18:37:36.266012 0.005429] <4>more trace (sp:c3ee1da8):
[18:37:36.267971 0.001959] <4>{c3ee1da8} 0xc339853c [music_gmac@0xc3398000]
[18:37:36.271336 0.003365] <4>{c3ee1de8} 0xc339853c [music_gmac@0xc3398000]
[18:37:36.277050 0.005714] <4>{c3ee1e28} 0xc339a688 [music_gmac@0xc3398000]
[18:37:36.280422 0.003372] <4>{c3ee1e68} process_one_work+0x2dc/0x484
[18:37:36.285009 0.004588] <4>{c3ee1ea0} worker_thread+0x23c/0x3e0
[18:37:36.288212 0.003203] <4>{c3ee1ee0} kthread+0x88/0x90
[18:37:36.291237 0.003025] <4>{c3ee1f18} kernel_thread_helper+0x10/0x18
[18:37:36.296519 0.005282] <4>
[18:37:38.768090 2.471566]
[18:37:38.768223 0.000137]
[18:37:38.768275 0.000053] RouterBOOT booter 3.22
[18:37:38.768736 0.000461]
[18:37:38.768782 0.000046] CRS226-24G-2S+
[18:37:38.771277 0.002494]
[18:37:38.771333 0.000057] CPU frequency: 400 MHz
[18:37:38.773122 0.001789] Memory size: 64 MiB
[18:37:38.777983 0.004860] NAND size: 128 MiB
[18:37:38.887068 0.109081]
[18:37:38.887186 0.000123] Press any key within 2 seconds to enter setup..
[18:37:40.919999 2.032808]
[18:37:40.920113 0.000119] loading kernel from nand... OK
[18:37:43.202189 2.282072] setting up elf image... OK
[18:37:43.342161 0.139971] jumping to kernel code
[18:37:47.629077 4.286916] Starting...
[18:37:59.209126 11.580047] Starting services...
[18:38:16.450197 17.241073]
[Sun Feb 5 09:46:53 2017] ------------[ cut here ]------------
[Sun Feb 5 09:46:53 2017] WARNING: CPU: 0 PID: 0 at /home/zumbi/linux-4.9.2/net/sched/sch_generic.c:316 dev_watchdog+0x220/0x230
[Sun Feb 5 09:46:53 2017] NETDEV WATCHDOG: eth1 (ixgbe): transmit queue 1 timed out
[Sun Feb 5 09:46:53 2017] Modules linked in: tun rfcomm bnep parport_pc bluetooth ppdev lp rfkill parport xt_multiport iptable_filter ip_tables x_tables fuse nfsd auth_rpcgss nfs_acl nfs lockd grace fscache sunrpc bridge 8021q garp mrp stp llc loop amd64_edac_mod amdkfd edac_mce_amd edac_core kvm_amd radeon kvm ttm irqbypass pcspkr k10temp drm_kms_helper evdev drm i2c_algo_bit tpm_infineon acpi_cpufreq tpm_tis button tpm_tis_core sp5100_tco tpm i2c_piix4 shpchp ext4 crc16 jbd2 fscrypto mbcache dm_mod raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic md_mod hid_generic usbhid hid sr_mod cdrom sg sd_mod ata_generic ohci_pci tg3 pata_atiixp libphy ixgbe ahci libahci libata ehci_pci ohci_hcd dca ptp pps_core mdio ehci_hcd scsi_mod fjes usbcore usb_common
[Sun Feb 5 09:46:53 2017] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-0.bpo.1-amd64 #1 Debian 4.9.2-2~bpo8+1
[Sun Feb 5 09:46:53 2017] Hardware name: HP ProLiant MicroServer, BIOS O41 07/29/2011
[Sun Feb 5 09:46:53 2017] 0000000000000000 ffffffffbe32a1f5 ffff97969fc03e38 0000000000000000
[Sun Feb 5 09:46:53 2017] ffffffffbe077884 0000000000000001 ffff97969fc03e90 ffff9796960e0000
[Sun Feb 5 09:46:53 2017] 0000000000000000 ffff979696ada740 0000000000000020 ffffffffbe0778ff
[Sun Feb 5 09:46:53 2017] Call Trace:
[Sun Feb 5 09:46:53 2017] <IRQ>
[Sun Feb 5 09:46:53 2017] [<ffffffffbe32a1f5>] ? dump_stack+0x5c/0x77
[Sun Feb 5 09:46:53 2017] [<ffffffffbe077884>] ? __warn+0xc4/0xe0
[Sun Feb 5 09:46:53 2017] [<ffffffffbe0778ff>] ? warn_slowpath_fmt+0x5f/0x80
[Sun Feb 5 09:46:53 2017] [<ffffffffbe51fc30>] ? dev_watchdog+0x220/0x230
[Sun Feb 5 09:46:53 2017] [<ffffffffbe51fa10>] ? dev_deactivate_queue.constprop.27+0x60/0x60
[Sun Feb 5 09:46:53 2017] [<ffffffffbe0e6210>] ? call_timer_fn+0x30/0x130
[Sun Feb 5 09:46:53 2017] [<ffffffffbe0e7085>] ? run_timer_softirq+0x215/0x4b0
[Sun Feb 5 09:46:53 2017] [<ffffffffbe333434>] ? timerqueue_add+0x54/0xa0
[Sun Feb 5 09:46:53 2017] [<ffffffffbe0e82c8>] ? enqueue_hrtimer+0x38/0x80
[Sun Feb 5 09:46:53 2017] [<ffffffffbe5fcce6>] ? __do_softirq+0x106/0x292
[Sun Feb 5 09:46:53 2017] [<ffffffffbe07db08>] ? irq_exit+0x98/0xa0
[Sun Feb 5 09:46:53 2017] [<ffffffffbe5fcaee>] ? smp_apic_timer_interrupt+0x3e/0x50
[Sun Feb 5 09:46:53 2017] [<ffffffffbe5fbe02>] ? apic_timer_interrupt+0x82/0x90
[Sun Feb 5 09:46:53 2017] <EOI>
[Sun Feb 5 09:46:53 2017] [<ffffffffbe5f9a22>] ? native_safe_halt+0x2/0x10
[Sun Feb 5 09:46:53 2017] [<ffffffffbe5f9748>] ? default_idle+0x18/0xd0
[Sun Feb 5 09:46:53 2017] [<ffffffffbe02fb48>] ? amd_e400_idle+0x58/0xd0
[Sun Feb 5 09:46:53 2017] [<ffffffffbe0bc070>] ? cpu_startup_entry+0x1f0/0x260
[Sun Feb 5 09:46:53 2017] [<ffffffffbed49f84>] ? start_kernel+0x46d/0x48d
[Sun Feb 5 09:46:53 2017] [<ffffffffbed49120>] ? early_idt_handler_array+0x120/0x120
[Sun Feb 5 09:46:53 2017] [<ffffffffbed495b9>] ? x86_64_start_kernel+0x152/0x176
[Sun Feb 5 09:46:53 2017] ---[ end trace 1b654a01d52cecd3 ]---
[Sun Feb 5 09:46:53 2017] ixgbe 0000:02:00.0 eth1: initiating reset due to tx timeout
[Sun Feb 5 09:46:53 2017] ixgbe 0000:02:00.0 eth1: Reset adapter
[Sun Feb 5 09:46:53 2017] ixgbe 0000:02:00.0 eth1: RXDCTL.ENABLE on Rx queue 0 not cleared within the polling period
[Sun Feb 5 09:46:53 2017] ixgbe 0000:02:00.0 eth1: RXDCTL.ENABLE on Rx queue 1 not cleared within the polling period
[Sun Feb 5 09:46:56 2017] ixgbe 0000:02:00.0 eth1: detected SFP+: 0
[Sun Feb 5 09:46:58 2017] ixgbe 0000:02:00.0 eth1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[Sun Feb 5 09:47:08 2017] ixgbe 0000:02:00.0 eth1: initiating reset due to tx timeout
[Sun Feb 5 09:47:08 2017] ixgbe 0000:02:00.0 eth1: Reset adapter
[Sun Feb 5 09:47:08 2017] ixgbe 0000:02:00.0 eth1: RXDCTL.ENABLE on Rx queue 0 not cleared within the polling period
[Sun Feb 5 09:47:08 2017] ixgbe 0000:02:00.0 eth1: RXDCTL.ENABLE on Rx queue 1 not cleared within the polling period
[Sun Feb 5 09:47:11 2017] ixgbe 0000:02:00.0 eth1: detected SFP+: 0
[Sun Feb 5 09:47:13 2017] ixgbe 0000:02:00.0 eth1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[Sun Feb 5 09:47:23 2017] ixgbe 0000:02:00.0 eth1: initiating reset due to tx timeout
[Sun Feb 5 09:47:23 2017] ixgbe 0000:02:00.0 eth1: Reset adapter
[Sun Feb 5 09:47:23 2017] ixgbe 0000:02:00.0 eth1: RXDCTL.ENABLE on Rx queue 0 not cleared within the polling period
[Sun Feb 5 09:47:23 2017] ixgbe 0000:02:00.0 eth1: RXDCTL.ENABLE on Rx queue 1 not cleared within the polling period
[Sun Feb 5 09:47:26 2017] ixgbe 0000:02:00.0 eth1: detected SFP+: 0
[Sun Feb 5 09:47:28 2017] ixgbe 0000:02:00.0 eth1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[Sun Feb 5 09:47:38 2017] ixgbe 0000:02:00.0 eth1: initiating reset due to tx timeout
[Sun Feb 5 09:47:38 2017] ixgbe 0000:02:00.0 eth1: Reset adapter
[Sun Feb 5 09:47:38 2017] ixgbe 0000:02:00.0 eth1: RXDCTL.ENABLE on Rx queue 0 not cleared within the polling period
[Sun Feb 5 09:47:38 2017] ixgbe 0000:02:00.0 eth1: RXDCTL.ENABLE on Rx queue 1 not cleared within the polling period
[Sun Feb 5 09:47:41 2017] ixgbe 0000:02:00.0 eth1: detected SFP+: 0
Happy to helpThank you very much for the report about capsman oid values.
And even more important (the terminal button was already in the left menu): finally the Quickset interface is hidden once youWhose ever idea it was to add a "Terminal" button to the top of the WebFig pages deserves a BIG PAY RAISE!
To be honest the left menu makes me NUTS because the items can be in different places even on 2 identical devices. Maybe it has something to do with the order packages are installed but IPv6 and PPP seem to be the biggest offenders. Sometimes IPv6 is above IP, sometimes below and on my ccr, it's between Tools and Radius.(the terminal button was already in the left menu)
Thanks for working on the Wiki to keep it up to date and it great to use to implement/lookup things and a must read before posting in the forum.It is possible to add a script that will be executed when a prefix or an address is acquired and applied or expires and is removed using DHCP client. There are separated sets of variables that will have the value set by the client depending on prefix or address status change as the client can acquire both and each of them can have a different effect on the router configuration.
Available variables for dhcp-client
pd-valid - value - 1 or 0 - if prefix is acquired and it is applied or not
pd-prefix - value ipv6/num (ipv6 prefix with mask) - the prefix inself
na-valid - value - 1 or 0 - if address is acquired and it is applied or not
na-address - value - ipv6 address - the address
What it means?capsman - added support for static virtual interfaces on CAP;
As I understand, now you should be able to create child (virtual) interfaces under the physical interface that's being managed by CAPsMAN. I have not tried it myself yet, though.What it means?capsman - added support for static virtual interfaces on CAP;
That function was alreadyAs I understand, now you should be able to create child (virtual) interfaces under the physical interface that's being managed by CAPsMAN. I have not tried it myself yet, though.
Nope. It was possible to added slave interface on CAPsMAN (controller), but you could not add slave interface locally on a CAP (managed board) itself. It appears to be possible now.That function was alreadyAs I understand, now you should be able to create child (virtual) interfaces under the physical interface that's being managed by CAPsMAN. I have not tried it myself yet, though.
When you connect CAP to CAPsMAN virtual interface on CAP becomes disabled. I just tested it, and it works same as 6.38.1. So it's not it, but would be awesome if it was thatNope. It was possible to added slave interface on CAPsMAN (controller), but you could not add slave interface locally on a CAP (managed board) itself. It appears to be possible now.
CAP supports static interfaces instead of dynamic ones, they do not disappear after reboot and count number is not changed all the time (recognised by mac-address).What it means?capsman - added support for static virtual interfaces on CAP;
I'm still getting the same incorrect output.Version 6.39rc33 has been released.
Changes since previous version:
...
*) snmp - fixed CAPsMAN registration table OID print;
...
I posted above (ignore the minor bug they're working on)Help people!
I have a script that was reading snmp individual mac address from capsman registration table. After upgrade I can not read any of them.
What is the SNMP oid to get all the wireless clients MAC on capsman (not the count)???!
I get the following which does not have any MAC address of the clientsI posted above (ignore the minor bug they're working on)Help people!
I have a script that was reading snmp individual mac address from capsman registration table. After upgrade I can not read any of them.
What is the SNMP oid to get all the wireless clients MAC on capsman (not the count)???!
`/caps-man registration-table print oid` reports 1.3.6.1.4.1.14988.1.1.1.4.1...
but snmpwalk shows that it is really 1.3.6.1.4.1.14988.1.1.1.5.1...
So if you walk that, you'll see stats for all registered capsman clients, including mac address. Does that make sense?
snmpwalk -c public -v 2c 192.168.10.1 1.3.6.1.4.1.14988.1.1.1.5.1
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.0.4.32.239.134.9.195 = Timeticks: (140225400) 16 days, 5:30:54.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.40.16.123.35.106.44.202 = Timeticks: (114602300) 13 days, 6:20:23.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.44.240.238.73.164.89.204 = Timeticks: (101436600) 11 days, 17:46:06.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.60.51.0.51.170.194.202 = Timeticks: (151901200) 17 days, 13:56:52.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.72.238.12.124.113.215.201 = Timeticks: (290717300) 33 days, 15:32:53.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.92.207.127.1.138.227.193 = Timeticks: (160445600) 18 days, 13:40:56.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.92.207.127.129.10.170.195 = Timeticks: (160445300) 18 days, 13:40:53.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.148.16.62.205.37.201.204 = Timeticks: (304600) 0:50:46.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.164.119.51.168.68.54.194 = Timeticks: (160439000) 18 days, 13:39:50.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.164.119.51.239.164.100.193 = Timeticks: (3174200) 8:49:02.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.168.129.149.141.101.106.195 = Timeticks: (160424800) 18 days, 13:37:28.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.176.197.84.1.85.60.200 = Timeticks: (26533200) 3 days, 1:42:12.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.176.197.84.2.156.36.201 = Timeticks: (290776200) 33 days, 15:42:42.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.176.197.84.3.112.103.201 = Timeticks: (290739400) 33 days, 15:36:34.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.176.197.84.5.105.150.202 = Timeticks: (131831600) 15 days, 6:11:56.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.238.34.128.108.26.145.206 = Timeticks: (271971200) 31 days, 11:28:32.00
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.0.4.32.239.134.9.195 = Counter32: 5821244
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.40.16.123.35.106.44.202 = Counter32: 73790913
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.44.240.238.73.164.89.204 = Counter32: 14501780
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.60.51.0.51.170.194.202 = Counter32: 3251847
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.72.238.12.124.113.215.201 = Counter32: 428737
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.92.207.127.1.138.227.193 = Counter32: 135337
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.92.207.127.129.10.170.195 = Counter32: 480132
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.148.16.62.205.37.201.204 = Counter32: 2090
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.164.119.51.168.68.54.194 = Counter32: 68642196
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.164.119.51.239.164.100.193 = Counter32: 498267
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.168.129.149.141.101.106.195 = Counter32: 72654044
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.176.197.84.1.85.60.200 = Counter32: 47798728
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.176.197.84.2.156.36.201 = Counter32: 230505304
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.176.197.84.3.112.103.201 = Counter32: 11839456
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.176.197.84.5.105.150.202 = Counter32: 11044643
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.238.34.128.108.26.145.206 = Counter32: 2126093
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.0.4.32.239.134.9.195 = Counter32: 1536484
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.40.16.123.35.106.44.202 = Counter32: 1608283769
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.44.240.238.73.164.89.204 = Counter32: 1464379
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.60.51.0.51.170.194.202 = Counter32: 3173338763
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.72.238.12.124.113.215.201 = Counter32: 829923
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.92.207.127.1.138.227.193 = Counter32: 104828
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.92.207.127.129.10.170.195 = Counter32: 511559
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.148.16.62.205.37.201.204 = Counter32: 4048
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.164.119.51.168.68.54.194 = Counter32: 6079397
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.164.119.51.239.164.100.193 = Counter32: 170935
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.168.129.149.141.101.106.195 = Counter32: 5243963
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.176.197.84.1.85.60.200 = Counter32: 1952933251
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.176.197.84.2.156.36.201 = Counter32: 908878507
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.176.197.84.3.112.103.201 = Counter32: 2161636
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.176.197.84.5.105.150.202 = Counter32: 541918651
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.238.34.128.108.26.145.206 = Counter32: 5897834
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.0.4.32.239.134.9.195 = Counter32: 17605
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.40.16.123.35.106.44.202 = Counter32: 1127441
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.44.240.238.73.164.89.204 = Counter32: 11616
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.60.51.0.51.170.194.202 = Counter32: 35534
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.72.238.12.124.113.215.201 = Counter32: 7080
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.92.207.127.1.138.227.193 = Counter32: 1268
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.92.207.127.129.10.170.195 = Counter32: 7985
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.148.16.62.205.37.201.204 = Counter32: 32
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.164.119.51.168.68.54.194 = Counter32: 64529
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.164.119.51.239.164.100.193 = Counter32: 1744
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.168.129.149.141.101.106.195 = Counter32: 61812
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.176.197.84.1.85.60.200 = Counter32: 878525
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.176.197.84.2.156.36.201 = Counter32: 4235450
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.176.197.84.3.112.103.201 = Counter32: 87886
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.176.197.84.5.105.150.202 = Counter32: 177603
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.238.34.128.108.26.145.206 = Counter32: 26254
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.0.4.32.239.134.9.195 = Counter32: 18520
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.40.16.123.35.106.44.202 = Counter32: 1360940
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.44.240.238.73.164.89.204 = Counter32: 12007
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.60.51.0.51.170.194.202 = Counter32: 5942883
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.72.238.12.124.113.215.201 = Counter32: 8389
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.92.207.127.1.138.227.193 = Counter32: 1323
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.92.207.127.129.10.170.195 = Counter32: 8088
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.148.16.62.205.37.201.204 = Counter32: 48
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.164.119.51.168.68.54.194 = Counter32: 49427
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.164.119.51.239.164.100.193 = Counter32: 1304
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.168.129.149.141.101.106.195 = Counter32: 64913
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.176.197.84.1.85.60.200 = Counter32: 4306854
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.176.197.84.2.156.36.201 = Counter32: 9719647
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.176.197.84.3.112.103.201 = Counter32: 33413
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.176.197.84.5.105.150.202 = Counter32: 3597021
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.238.34.128.108.26.145.206 = Counter32: 81421
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.0.4.32.239.134.9.195 = Gauge32: 120000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.40.16.123.35.106.44.202 = Gauge32: 65000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.44.240.238.73.164.89.204 = Gauge32: 104000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.60.51.0.51.170.194.202 = Gauge32: 150000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.72.238.12.124.113.215.201 = Gauge32: 150000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.92.207.127.1.138.227.193 = Gauge32: 48000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.92.207.127.129.10.170.195 = Gauge32: 72200000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.148.16.62.205.37.201.204 = Gauge32: 26000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.164.119.51.168.68.54.194 = Gauge32: 65000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.164.119.51.239.164.100.193 = Gauge32: 58500000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.168.129.149.141.101.106.195 = Gauge32: 72200000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.176.197.84.1.85.60.200 = Gauge32: 150000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.176.197.84.2.156.36.201 = Gauge32: 57700000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.176.197.84.3.112.103.201 = Gauge32: 65000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.176.197.84.5.105.150.202 = Gauge32: 108000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.238.34.128.108.26.145.206 = Gauge32: 270000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.0.4.32.239.134.9.195 = Gauge32: 54000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.40.16.123.35.106.44.202 = Gauge32: 72200000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.44.240.238.73.164.89.204 = Gauge32: 130000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.60.51.0.51.170.194.202 = Gauge32: 81000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.72.238.12.124.113.215.201 = Gauge32: 150000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.92.207.127.1.138.227.193 = Gauge32: 48000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.92.207.127.129.10.170.195 = Gauge32: 18000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.148.16.62.205.37.201.204 = Gauge32: 135000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.164.119.51.168.68.54.194 = Gauge32: 65000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.164.119.51.239.164.100.193 = Gauge32: 65000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.168.129.149.141.101.106.195 = Gauge32: 72200000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.176.197.84.1.85.60.200 = Gauge32: 150000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.176.197.84.2.156.36.201 = Gauge32: 52000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.176.197.84.3.112.103.201 = Gauge32: 65000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.176.197.84.5.105.150.202 = Gauge32: 27000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.238.34.128.108.26.145.206 = Gauge32: 243000000
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.0.4.32.239.134.9.195 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.40.16.123.35.106.44.202 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.44.240.238.73.164.89.204 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.60.51.0.51.170.194.202 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.72.238.12.124.113.215.201 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.92.207.127.1.138.227.193 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.92.207.127.129.10.170.195 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.148.16.62.205.37.201.204 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.164.119.51.168.68.54.194 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.164.119.51.239.164.100.193 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.168.129.149.141.101.106.195 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.176.197.84.1.85.60.200 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.176.197.84.2.156.36.201 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.176.197.84.3.112.103.201 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.176.197.84.5.105.150.202 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.238.34.128.108.26.145.206 = INTEGER: 0
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.0.4.32.239.134.9.195 = INTEGER: -60
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.40.16.123.35.106.44.202 = INTEGER: -39
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.44.240.238.73.164.89.204 = INTEGER: -65
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.60.51.0.51.170.194.202 = INTEGER: -49
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.72.238.12.124.113.215.201 = INTEGER: -66
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.92.207.127.1.138.227.193 = INTEGER: -69
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.92.207.127.129.10.170.195 = INTEGER: -55
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.148.16.62.205.37.201.204 = INTEGER: -66
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.164.119.51.168.68.54.194 = INTEGER: -59
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.164.119.51.239.164.100.193 = INTEGER: -41
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.168.129.149.141.101.106.195 = INTEGER: -44
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.176.197.84.1.85.60.200 = INTEGER: -61
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.176.197.84.2.156.36.201 = INTEGER: -57
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.176.197.84.3.112.103.201 = INTEGER: -51
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.176.197.84.5.105.150.202 = INTEGER: -55
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.238.34.128.108.26.145.206 = INTEGER: -62
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.0.4.32.239.134.9.195 = INTEGER: 4607184
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.40.16.123.35.106.44.202 = INTEGER: 4596448
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.44.240.238.73.164.89.204 = INTEGER: 4596072
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.60.51.0.51.170.194.202 = INTEGER: 4597208
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.72.238.12.124.113.215.201 = INTEGER: 4664576
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.92.207.127.1.138.227.193 = INTEGER: 4602992
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.92.207.127.129.10.170.195 = INTEGER: 4600792
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.148.16.62.205.37.201.204 = INTEGER: 4596960
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.164.119.51.168.68.54.194 = INTEGER: 4619216
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.164.119.51.239.164.100.193 = INTEGER: 4584736
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.168.129.149.141.101.106.195 = INTEGER: 4544520
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.176.197.84.1.85.60.200 = INTEGER: 4601120
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.176.197.84.2.156.36.201 = INTEGER: 4607384
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.176.197.84.3.112.103.201 = INTEGER: 4664208
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.176.197.84.5.105.150.202 = INTEGER: 4538888
SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.238.34.128.108.26.145.206 = INTEGER: 4542200
/caps-man registration-table print oid
0 uptime=.1.3.6.1.4.1.14988.1.1.1.4.1.3.176.197.84.2.156.36.201 tx-bytes=.1.3.6.1.4.1.14988.1.1.1.4.1.4.176.197.84.2.156.36.201 rx-bytes=.1.3.6.1.4.1.14988.1.1.1.4.1.5.176.197.84.2.156.36.201
tx-packets=.1.3.6.1.4.1.14988.1.1.1.4.1.6.176.197.84.2.156.36.201 rx-packets=.1.3.6.1.4.1.14988.1.1.1.4.1.7.176.197.84.2.156.36.201 tx-rate=.1.3.6.1.4.1.14988.1.1.1.4.1.8.176.197.84.2.156.36.201
rx-rate=.1.3.6.1.4.1.14988.1.1.1.4.1.9.176.197.84.2.156.36.201 tx-signal=.1.3.6.1.4.1.14988.1.1.1.4.1.10.176.197.84.2.156.36.201 rx-signal=.1.3.6.1.4.1.14988.1.1.1.4.1.11.176.197.84.2.156.36.201
ssid=.1.3.6.1.4.1.14988.1.1.1.4.1.12.176.197.84.2.156.36.201
Well, look at that. Not only did they not fix the misprint of oid, they did in fact remove mac from the tree. I'm guessing someone just removed they wrong thing by accident. They'll need to fix that clearly.I get the following which does not have any MAC address of the clientsI posted above (ignore the minor bug they're working on)Help people!
I have a script that was reading snmp individual mac address from capsman registration table. After upgrade I can not read any of them.
What is the SNMP oid to get all the wireless clients MAC on capsman (not the count)???!
`/caps-man registration-table print oid` reports 1.3.6.1.4.1.14988.1.1.1.4.1...
but snmpwalk shows that it is really 1.3.6.1.4.1.14988.1.1.1.5.1...
So if you walk that, you'll see stats for all registered capsman clients, including mac address. Does that make sense?
looking around I see that THERE IS NO oid for MAC address as there was before! Mikrotik fixed wrong entry issue removing the MAC entry?Code: Select allsnmpwalk -c public -v 2c 192.168.10.1 1.3.6.1.4.1.14988.1.1.1.5.1 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.0.4.32.239.134.9.195 = Timeticks: (140225400) 16 days, 5:30:54.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.40.16.123.35.106.44.202 = Timeticks: (114602300) 13 days, 6:20:23.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.44.240.238.73.164.89.204 = Timeticks: (101436600) 11 days, 17:46:06.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.60.51.0.51.170.194.202 = Timeticks: (151901200) 17 days, 13:56:52.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.72.238.12.124.113.215.201 = Timeticks: (290717300) 33 days, 15:32:53.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.92.207.127.1.138.227.193 = Timeticks: (160445600) 18 days, 13:40:56.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.92.207.127.129.10.170.195 = Timeticks: (160445300) 18 days, 13:40:53.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.148.16.62.205.37.201.204 = Timeticks: (304600) 0:50:46.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.164.119.51.168.68.54.194 = Timeticks: (160439000) 18 days, 13:39:50.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.164.119.51.239.164.100.193 = Timeticks: (3174200) 8:49:02.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.168.129.149.141.101.106.195 = Timeticks: (160424800) 18 days, 13:37:28.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.176.197.84.1.85.60.200 = Timeticks: (26533200) 3 days, 1:42:12.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.176.197.84.2.156.36.201 = Timeticks: (290776200) 33 days, 15:42:42.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.176.197.84.3.112.103.201 = Timeticks: (290739400) 33 days, 15:36:34.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.176.197.84.5.105.150.202 = Timeticks: (131831600) 15 days, 6:11:56.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.3.238.34.128.108.26.145.206 = Timeticks: (271971200) 31 days, 11:28:32.00 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.0.4.32.239.134.9.195 = Counter32: 5821244 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.40.16.123.35.106.44.202 = Counter32: 73790913 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.44.240.238.73.164.89.204 = Counter32: 14501780 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.60.51.0.51.170.194.202 = Counter32: 3251847 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.72.238.12.124.113.215.201 = Counter32: 428737 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.92.207.127.1.138.227.193 = Counter32: 135337 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.92.207.127.129.10.170.195 = Counter32: 480132 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.148.16.62.205.37.201.204 = Counter32: 2090 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.164.119.51.168.68.54.194 = Counter32: 68642196 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.164.119.51.239.164.100.193 = Counter32: 498267 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.168.129.149.141.101.106.195 = Counter32: 72654044 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.176.197.84.1.85.60.200 = Counter32: 47798728 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.176.197.84.2.156.36.201 = Counter32: 230505304 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.176.197.84.3.112.103.201 = Counter32: 11839456 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.176.197.84.5.105.150.202 = Counter32: 11044643 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.4.238.34.128.108.26.145.206 = Counter32: 2126093 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.0.4.32.239.134.9.195 = Counter32: 1536484 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.40.16.123.35.106.44.202 = Counter32: 1608283769 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.44.240.238.73.164.89.204 = Counter32: 1464379 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.60.51.0.51.170.194.202 = Counter32: 3173338763 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.72.238.12.124.113.215.201 = Counter32: 829923 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.92.207.127.1.138.227.193 = Counter32: 104828 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.92.207.127.129.10.170.195 = Counter32: 511559 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.148.16.62.205.37.201.204 = Counter32: 4048 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.164.119.51.168.68.54.194 = Counter32: 6079397 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.164.119.51.239.164.100.193 = Counter32: 170935 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.168.129.149.141.101.106.195 = Counter32: 5243963 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.176.197.84.1.85.60.200 = Counter32: 1952933251 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.176.197.84.2.156.36.201 = Counter32: 908878507 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.176.197.84.3.112.103.201 = Counter32: 2161636 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.176.197.84.5.105.150.202 = Counter32: 541918651 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.5.238.34.128.108.26.145.206 = Counter32: 5897834 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.0.4.32.239.134.9.195 = Counter32: 17605 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.40.16.123.35.106.44.202 = Counter32: 1127441 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.44.240.238.73.164.89.204 = Counter32: 11616 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.60.51.0.51.170.194.202 = Counter32: 35534 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.72.238.12.124.113.215.201 = Counter32: 7080 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.92.207.127.1.138.227.193 = Counter32: 1268 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.92.207.127.129.10.170.195 = Counter32: 7985 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.148.16.62.205.37.201.204 = Counter32: 32 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.164.119.51.168.68.54.194 = Counter32: 64529 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.164.119.51.239.164.100.193 = Counter32: 1744 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.168.129.149.141.101.106.195 = Counter32: 61812 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.176.197.84.1.85.60.200 = Counter32: 878525 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.176.197.84.2.156.36.201 = Counter32: 4235450 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.176.197.84.3.112.103.201 = Counter32: 87886 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.176.197.84.5.105.150.202 = Counter32: 177603 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.6.238.34.128.108.26.145.206 = Counter32: 26254 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.0.4.32.239.134.9.195 = Counter32: 18520 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.40.16.123.35.106.44.202 = Counter32: 1360940 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.44.240.238.73.164.89.204 = Counter32: 12007 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.60.51.0.51.170.194.202 = Counter32: 5942883 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.72.238.12.124.113.215.201 = Counter32: 8389 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.92.207.127.1.138.227.193 = Counter32: 1323 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.92.207.127.129.10.170.195 = Counter32: 8088 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.148.16.62.205.37.201.204 = Counter32: 48 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.164.119.51.168.68.54.194 = Counter32: 49427 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.164.119.51.239.164.100.193 = Counter32: 1304 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.168.129.149.141.101.106.195 = Counter32: 64913 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.176.197.84.1.85.60.200 = Counter32: 4306854 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.176.197.84.2.156.36.201 = Counter32: 9719647 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.176.197.84.3.112.103.201 = Counter32: 33413 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.176.197.84.5.105.150.202 = Counter32: 3597021 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.7.238.34.128.108.26.145.206 = Counter32: 81421 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.0.4.32.239.134.9.195 = Gauge32: 120000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.40.16.123.35.106.44.202 = Gauge32: 65000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.44.240.238.73.164.89.204 = Gauge32: 104000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.60.51.0.51.170.194.202 = Gauge32: 150000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.72.238.12.124.113.215.201 = Gauge32: 150000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.92.207.127.1.138.227.193 = Gauge32: 48000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.92.207.127.129.10.170.195 = Gauge32: 72200000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.148.16.62.205.37.201.204 = Gauge32: 26000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.164.119.51.168.68.54.194 = Gauge32: 65000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.164.119.51.239.164.100.193 = Gauge32: 58500000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.168.129.149.141.101.106.195 = Gauge32: 72200000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.176.197.84.1.85.60.200 = Gauge32: 150000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.176.197.84.2.156.36.201 = Gauge32: 57700000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.176.197.84.3.112.103.201 = Gauge32: 65000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.176.197.84.5.105.150.202 = Gauge32: 108000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.8.238.34.128.108.26.145.206 = Gauge32: 270000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.0.4.32.239.134.9.195 = Gauge32: 54000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.40.16.123.35.106.44.202 = Gauge32: 72200000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.44.240.238.73.164.89.204 = Gauge32: 130000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.60.51.0.51.170.194.202 = Gauge32: 81000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.72.238.12.124.113.215.201 = Gauge32: 150000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.92.207.127.1.138.227.193 = Gauge32: 48000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.92.207.127.129.10.170.195 = Gauge32: 18000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.148.16.62.205.37.201.204 = Gauge32: 135000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.164.119.51.168.68.54.194 = Gauge32: 65000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.164.119.51.239.164.100.193 = Gauge32: 65000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.168.129.149.141.101.106.195 = Gauge32: 72200000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.176.197.84.1.85.60.200 = Gauge32: 150000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.176.197.84.2.156.36.201 = Gauge32: 52000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.176.197.84.3.112.103.201 = Gauge32: 65000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.176.197.84.5.105.150.202 = Gauge32: 27000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.9.238.34.128.108.26.145.206 = Gauge32: 243000000 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.0.4.32.239.134.9.195 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.40.16.123.35.106.44.202 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.44.240.238.73.164.89.204 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.60.51.0.51.170.194.202 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.72.238.12.124.113.215.201 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.92.207.127.1.138.227.193 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.92.207.127.129.10.170.195 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.148.16.62.205.37.201.204 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.164.119.51.168.68.54.194 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.164.119.51.239.164.100.193 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.168.129.149.141.101.106.195 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.176.197.84.1.85.60.200 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.176.197.84.2.156.36.201 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.176.197.84.3.112.103.201 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.176.197.84.5.105.150.202 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.10.238.34.128.108.26.145.206 = INTEGER: 0 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.0.4.32.239.134.9.195 = INTEGER: -60 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.40.16.123.35.106.44.202 = INTEGER: -39 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.44.240.238.73.164.89.204 = INTEGER: -65 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.60.51.0.51.170.194.202 = INTEGER: -49 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.72.238.12.124.113.215.201 = INTEGER: -66 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.92.207.127.1.138.227.193 = INTEGER: -69 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.92.207.127.129.10.170.195 = INTEGER: -55 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.148.16.62.205.37.201.204 = INTEGER: -66 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.164.119.51.168.68.54.194 = INTEGER: -59 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.164.119.51.239.164.100.193 = INTEGER: -41 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.168.129.149.141.101.106.195 = INTEGER: -44 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.176.197.84.1.85.60.200 = INTEGER: -61 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.176.197.84.2.156.36.201 = INTEGER: -57 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.176.197.84.3.112.103.201 = INTEGER: -51 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.176.197.84.5.105.150.202 = INTEGER: -55 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.11.238.34.128.108.26.145.206 = INTEGER: -62 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.0.4.32.239.134.9.195 = INTEGER: 4607184 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.40.16.123.35.106.44.202 = INTEGER: 4596448 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.44.240.238.73.164.89.204 = INTEGER: 4596072 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.60.51.0.51.170.194.202 = INTEGER: 4597208 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.72.238.12.124.113.215.201 = INTEGER: 4664576 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.92.207.127.1.138.227.193 = INTEGER: 4602992 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.92.207.127.129.10.170.195 = INTEGER: 4600792 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.148.16.62.205.37.201.204 = INTEGER: 4596960 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.164.119.51.168.68.54.194 = INTEGER: 4619216 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.164.119.51.239.164.100.193 = INTEGER: 4584736 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.168.129.149.141.101.106.195 = INTEGER: 4544520 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.176.197.84.1.85.60.200 = INTEGER: 4601120 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.176.197.84.2.156.36.201 = INTEGER: 4607384 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.176.197.84.3.112.103.201 = INTEGER: 4664208 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.176.197.84.5.105.150.202 = INTEGER: 4538888 SNMPv2-SMI::enterprises.14988.1.1.1.5.1.12.238.34.128.108.26.145.206 = INTEGER: 4542200
Code: Select all/caps-man registration-table print oid 0 uptime=.1.3.6.1.4.1.14988.1.1.1.4.1.3.176.197.84.2.156.36.201 tx-bytes=.1.3.6.1.4.1.14988.1.1.1.4.1.4.176.197.84.2.156.36.201 rx-bytes=.1.3.6.1.4.1.14988.1.1.1.4.1.5.176.197.84.2.156.36.201 tx-packets=.1.3.6.1.4.1.14988.1.1.1.4.1.6.176.197.84.2.156.36.201 rx-packets=.1.3.6.1.4.1.14988.1.1.1.4.1.7.176.197.84.2.156.36.201 tx-rate=.1.3.6.1.4.1.14988.1.1.1.4.1.8.176.197.84.2.156.36.201 rx-rate=.1.3.6.1.4.1.14988.1.1.1.4.1.9.176.197.84.2.156.36.201 tx-signal=.1.3.6.1.4.1.14988.1.1.1.4.1.10.176.197.84.2.156.36.201 rx-signal=.1.3.6.1.4.1.14988.1.1.1.4.1.11.176.197.84.2.156.36.201 ssid=.1.3.6.1.4.1.14988.1.1.1.4.1.12.176.197.84.2.156.36.201
I could have sworn it was in there, but I downgraded to the last release (rc27) and still didn't see mac listed in oid tree. So either that changed in an earlier version (perhaps unintentionally) or this just needs to be a feature request. It's gotta be in there in the future though, right?Well, look at that. Not only did they not fix the misprint of oid, they did in fact remove mac from the tree. I'm guessing someone just removed they wrong thing by accident. They'll need to fix that clearly.
I do not know if there was on rc27 because I jumped to the latest (6.39rc33) from the 6.38. I hope to be fixed fast as the script I use to get mac address is a geo-location script that reports users availability on the network. fingers crossed!I could have sworn it was in there, but I downgraded to the last release (rc27) and still didn't see mac listed in oid tree. So either that changed in an earlier version (perhaps unintentionally) or this just needs to be a feature request. It's gotta be in there in the future though, right?Well, look at that. Not only did they not fix the misprint of oid, they did in fact remove mac from the tree. I'm guessing someone just removed they wrong thing by accident. They'll need to fix that clearly.
Yeah, I also jumped from 6.38rc to 6.39rc, so could have been lost in an earlier version. If we both thought it was there, maybe it was? Either way, I've asked in my ticket they make sure to add it.I do not know if there was on rc27 because I jumped to the latest (6.39rc33) from the 6.38. I hope to be fixed fast as the script I use to get mac address is a geo-location script that reports users availability on the network. fingers crossed!I could have sworn it was in there, but I downgraded to the last release (rc27) and still didn't see mac listed in oid tree. So either that changed in an earlier version (perhaps unintentionally) or this just needs to be a feature request. It's gotta be in there in the future though, right?Well, look at that. Not only did they not fix the misprint of oid, they did in fact remove mac from the tree. I'm guessing someone just removed they wrong thing by accident. They'll need to fix that clearly.
6.38.1 is a good version to downgrade and get back mac address oid. I just did it and all are back to normalI could have sworn it was in there, but I downgraded to the last release (rc27) and still didn't see mac listed in oid tree. So either that changed in an earlier version (perhaps unintentionally) or this just needs to be a feature request. It's gotta be in there in the future though, right?Well, look at that. Not only did they not fix the misprint of oid, they did in fact remove mac from the tree. I'm guessing someone just removed they wrong thing by accident. They'll need to fix that clearly.
Thanks for taking the time and effort to confirm that. Odds are in our favor they will add that back in then6.38.1 is a good version to downgrade and get back mac address oid. I just did it and all are back to normal
I hope for a quick fix as I had mentioned the wrong oid months ago on http://forum.mikrotik.com/viewtopic.php?f=13&t=107522Thanks for taking the time and effort to confirm that. Odds are in our favor they will add that back in then6.38.1 is a good version to downgrade and get back mac address oid. I just did it and all are back to normal
Looks like a 32 vs 64 bit counter rollover problem. Lots of info if you do a Google search on that. Here is one example:Hi everyone
I have 10g ports on my router and graphs look like this:
I am using version: 6.38.1
3G everything looks good, after exceeding this value, it begins to fall apart.
What could be the reason?
I will add that any problems with the link no The cacti looks normal.
ps: I apologize in advance for my English
Where else is it included that we aren't finding (I say we because others are posting about this being gone too, so it's not just me missing it)?OIDs for CAPsMAN will be fixed in next rc release. MAC-Address parameter is removed since it was already available and this was a duplicate entry,
Thank you!Version 6.39rc33 has been released.
*) chr - fixed problem when transmit speed was reduced by interface queues;
Thank you very much for your answer. I understand the question of whether and when the dude will support 64bit?Looks like a 32 vs 64 bit counter rollover problem. Lots of info if you do a Google search on that. Here is one example:Hi everyone
I have 10g ports on my router and graphs look like this:
I am using version: 6.38.1
3G everything looks good, after exceeding this value, it begins to fall apart.
What could be the reason?
I will add that any problems with the link no The cacti looks normal.
ps: I apologize in advance for my English
https://www.google.com/amp/s/gorthx.wor ... -like/amp/
Where is it available? I do not see the MAC address anywhere in TR-069 data returned from device, except for the MAC addresses for the WiFi interfaces. What I want is the ethernet interface MAC addresses, primarily ether1 so that I can see what MAC address the customer has on their WAN port. I have gone through the entire TR-069 data returned from my device and from what I can see this is not present.OIDs for CAPsMAN will be fixed in next rc release. MAC-Address parameter is removed since it was already available and this was a duplicate entry,
I think that is a reply regarding snmp, not tr-069Where is it available? I do not see the MAC address anywhere in TR-069 data returned from device, except for the MAC addresses for the WiFi interfaces. What I want is the ethernet interface MAC addresses, primarily ether1 so that I can see what MAC address the customer has on their WAN port. I have gone through the entire TR-069 data returned from my device and from what I can see this is not present.OIDs for CAPsMAN will be fixed in next rc release. MAC-Address parameter is removed since it was already available and this was a duplicate entry,
Ahh, thanks - I didn't realize there was another post about MAC addresses with SNMP in the thread that strods was probably replying to.I think that is a reply regarding snmp, not tr-069Where is it available? I do not see the MAC address anywhere in TR-069 data returned from device, except for the MAC addresses for the WiFi interfaces. What I want is the ethernet interface MAC addresses, primarily ether1 so that I can see what MAC address the customer has on their WAN port. I have gone through the entire TR-069 data returned from my device and from what I can see this is not present.OIDs for CAPsMAN will be fixed in next rc release. MAC-Address parameter is removed since it was already available and this was a duplicate entry,
In the same boat as well. I updated to the latest 6.39rc33 for the virtual static ap for capsmam feature, which works great! But it broke the snmp capsman registration table Mac address oid. Hopefully it can be fixed soon.Where else is it included that we aren't finding (I say we because others are posting about this being gone too, so it's not just me missing it)?OIDs for CAPsMAN will be fixed in next rc release. MAC-Address parameter is removed since it was already available and this was a duplicate entry,
So based on some of my own digging, I found that the entries for capsman can be looked up in the bridge mib.Where else is it included that we aren't finding (I say we because others are posting about this being gone too, so it's not just me missing it)?OIDs for CAPsMAN will be fixed in next rc release. MAC-Address parameter is removed since it was already available and this was a duplicate entry,
Thanks for the info. It looks like the mac entries are a lookup table. To see if a client is disconnected or connected, would have to check the client by the snmp id addresses and not the macs. Not super useful for my application as I used the snmp macs in the capsman registration table to determine if people are home or not for some home automation. Ideally they can bring this back. However I did some more digging and found macs (wired and wireless) are also listed in the 'ipNetToMediaPhysAddress' with the OID prefix of: 1.3.6.1.2.1.4.22.1.2.9. This so far seems to working for my application.So based on some of my own digging, I found that the entries for capsman can be looked up in the bridge mib.Where else is it included that we aren't finding (I say we because others are posting about this being gone too, so it's not just me missing it)?OIDs for CAPsMAN will be fixed in next rc release. MAC-Address parameter is removed since it was already available and this was a duplicate entry,
As an example, this client:
1.3.6.1.4.1.14988.1.1.1.5.1.[3-12].0.14.88.171.21.21.14
has a mac address here:
1.3.6.1.2.1.17.4.3.1.1.0.14.88.171.21.21 = Hex-STRING: 00 02 B3 AB C1 DE
Based on the conversation in my ticket so far, it seems as if they expect us to use that. I'm waiting on confirmation.
I see now, so what you mean is the mac address is part of the OID, just in decimal form instead of hexadecimal.This is an example about SNMP CAPsMAN registration table.
We run SNMPwalk to device. As a result we get different OIDs. For example:
iso.3.6.1.4.1.14988.1.1.1.5.1.12..587
In this case:
iso.3.6.1.4.1.14988.1.1.1.5.1.12 - CAPsMAN registration table specific entry;
xx.xx.xx.xx.xx.xx - MAC address in decimal system
587 - specific ID to avoid duplicates
That's additional data to be sent over the wire, which may be significant on a busy system with lots of registered clients. I believe keeping the SNMP traffic as low as possible by eliminating the duplicates is a good thing.While I can see this works, it does seem to be easier to have a Hex-String or String conversion automatically done for us in an additional OID. Since the code was there already and it makes things easier on folks, why not just leave it (put it back)?
It doesn't get sent over the wire unless requested. Having it there as an option doesnt seem bad. Just don't request it on those busy systems.That's additional data to be sent over the wire, which may be significant on a busy system with lots of registered clients. I believe keeping the SNMP traffic as low as possible by eliminating the duplicates is a good thing.While I can see this works, it does seem to be easier to have a Hex-String or String conversion automatically done for us in an additional OID. Since the code was there already and it makes things easier on folks, why not just leave it (put it back)?
I am asking myself, whether it is possible to get the values of the amount of users, connected to a specific SSID for a single CAP with SNMP polling the CAPSMAN controller?*) snmp - fixed CAPsMAN registration table OID print;
*) snmp - fixed CAPsMAN registration table SSID type;
Looks like you guys got it this time! Thanks for the quick fix.*) snmp - fixed CAPsMAN registration table OID print;
*) snmp - fixed CAPsMAN registration table SSID type;
IMHO the MAC should always be encoded in the OID as 6 decimal numbers, not as a binary string.So many standard MIBs, including ones you are using (like bridge mib) provide this even if the mac is encoded in the OID in decimal format.
Good call. We have a month to try it, but at least tell us where to search!Version 6.39rc38 has been released.
Changes since previous version:
!) routeros - added support for new products and RouterOS features which will be announced at MUM EU (https://mum.mikrotik.com/2017/EU/info/EN);
Yeah, it will be good to know WHAT we are having xDGood call. We have a month to try it, but at least tell us where to search!Version 6.39rc38 has been released.
Changes since previous version:
!) routeros - added support for new products and RouterOS features which will be announced at MUM EU (https://mum.mikrotik.com/2017/EU/info/EN);
Nice plug to get people to attend MUM EU?Yeah, it will be good to know WHAT we are having xDGood call. We have a month to try it, but at least tell us where to search!Version 6.39rc38 has been released.
Changes since previous version:
!) routeros - added support for new products and RouterOS features which will be announced at MUM EU (https://mum.mikrotik.com/2017/EU/info/EN);
I totally agree! we have to rebuild so many scripts, so many waste of time and many 3rd party software keep failing. Let them as it was!I see now, so what you mean is the mac address is part of the OID, just in decimal form instead of hexadecimal.This is an example about SNMP CAPsMAN registration table.
We run SNMPwalk to device. As a result we get different OIDs. For example:
iso.3.6.1.4.1.14988.1.1.1.5.1.12..587
In this case:
iso.3.6.1.4.1.14988.1.1.1.5.1.12 - CAPsMAN registration table specific entry;
xx.xx.xx.xx.xx.xx - MAC address in decimal system
587 - specific ID to avoid duplicates
for example, mac address 00:DB:9A:B0:E4:72 would be converted to 0.219.154.176.228.114 and it's stats would then be iso.3.6.1.4.1.14988.1.1.1.5.1.12.0.219.154.176.228.114.1
or, mac address DB:DB:DB:DB:DB:DB would become 219.219.219.219.219.219
While I can see this works, it does seem to be easier to have a Hex-String or String conversion automatically done for us in an additional OID. Since the code was there already and it makes things easier on folks, why not just leave it (put it back)?
This version (Edit: no necessarily this specific version, but rc4 is perfectly fine for example) completely broke DFS for me in Germany. My wAP AC resides on the top floor, sometimes no 5GHz clients connected. As soon as I come near it with a client (tested with iPhone 6s, multiple times) it logs something like pasted below. I'm pretty sure it interprets clients looking for WLAN APs as RADAR. Please fix this! It's the same for a hAP AC with the current stable version (v6.38.3).Version 6.39rc38 has been released.
Changes since previous version:
!) routeros - added support for new products and RouterOS features which will be announced at MUM EU (https://mum.mikrotik.com/2017/EU/info/EN);
*) capsman - fixed "/caps-man manager interface" compact export;
If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
Feb 26 10:06:12 mikrotik-wap-ac wireless,info wlan2: radar detected on 5580000
Feb 26 10:06:17 mikrotik-wap-ac wireless,debug wlan2: must select channel
Feb 26 10:06:17 mikrotik-wap-ac wireless,debug wlan2: radar reported on 5580000
Feb 26 10:06:17 mikrotik-wap-ac wireless,debug wlan2: radar reported on 5260000
Feb 26 10:06:17 mikrotik-wap-ac wireless,debug wlan2: radar reported on 5580000
Feb 26 10:06:17 mikrotik-wap-ac wireless,debug wlan2: selected channel 5500000
Feb 26 10:06:17 mikrotik-wap-ac wireless,debug wlan2: search for radars on 5500000
Feb 26 10:07:17 mikrotik-wap-ac wireless,debug wlan2: no radar detetected, start network
Feb 26 10:20:14 mikrotik-wap-ac wireless,info wlan2: radar detected on 5500000
Feb 26 10:20:19 mikrotik-wap-ac wireless,debug wlan2: must select channel
Feb 26 10:20:19 mikrotik-wap-ac wireless,debug wlan2: radar reported on 5580000
Feb 26 10:20:19 mikrotik-wap-ac wireless,debug wlan2: radar reported on 5260000
Feb 26 10:20:19 mikrotik-wap-ac wireless,debug wlan2: radar reported on 5500000
Feb 26 10:20:19 mikrotik-wap-ac wireless,debug wlan2: radar reported on 5580000
Feb 26 10:20:19 mikrotik-wap-ac wireless,debug wlan2: selected channel 5180000
It's there in the bridge table and i wouldn't mind it for the wireless registration table too, but I was focused on capsman here. Especially since it was there, then removed. Feel free to add it for the wireless registration table too.alexjhart, MAC-address is not present in /interface wireless registration-table print oid either, and it is calculated in the same way as for capsman table OIDs.
thanks for the report, the next RC will have fix for thisUpdate: The GenieACS developer says there is a bug in MikroTik's TR-069 client. Any SetParameterValues request that includes an ampersand in the value causes an empty reply to be sent to the ACS by the MikroTik. This in turn causes a problem in GenieACS which is not expecting an empty reply from the MikroTik and resends the request, causing a loop.
Great!thanks for the report, the next RC will have fix for thisUpdate: The GenieACS developer says there is a bug in MikroTik's TR-069 client. Any SetParameterValues request that includes an ampersand in the value causes an empty reply to be sent to the ACS by the MikroTik. This in turn causes a problem in GenieACS which is not expecting an empty reply from the MikroTik and resends the request, causing a loop.
Yes, either/or.. However I suspect that they haven't been switching the main package to IPv6 enabled because then they would need a default IPv6 firewall config (at least a basic one to block all input except from the local bridge so that people on the WAN subnet can't login with webfig or winbox via IPv6), and existing devices would not have this in their factory default config scripts. However at least putting up this package as an alternative main package for people who use NetInstall and replace the default config script anyway - that should be safe, and it strikes me as something that they could do almost immediately.Or it could be simply made enabled by default for everyone. It's 2017 already, about time...
Does this fix the IPSEC packet re-ordering problem?*) ipsec - updated tilera classifier for UDP encapsulated ESP;
as a workaround:I LOVE the new script property of DHCP client. But something very basic seems to be missing - in my case the DHCP server is _not_ the gateway. However I don't see the gateway-address or like variable available. Any chance this can be added soon?
:put [ /ip dhcp-server network get [ find $leaseActIP in address ] gateway ];
Awesome, thanks for the quick reply.soonwai - This seems to be an issue which we managed to reproduce locally. If it is the same problem, then it will be fixed in next rc release.
Details?*) ipsec - updated tilera classifier for UDP encapsulated ESP;
Many thanks*) snmp - added back MAC address OID in "/caps-man registration-table" (introduced in 6.39rc33);
No dude client on the MikroTik website for this release, and auto-update attempt from older dude gives error: bad http response from cloud. Help!Version 6.39rc40 has been released.
To which posting of Soonwai did you respond because I see the posting about the Variables and the one about PPPoE.soonwai - This seems to be an issue which we managed to reproduce locally. If it is the same problem, then it will be fixed in next rc release.
Here you can read about the lead up to this "trimming":I have a problem with ipsec and xauth. If the xauth user name is longer than 30 characters, in the log you can see "Trimming Xauth user name". The Xauth login fail. If I cut the Xauth name to 30 characters or less, the Xauth login succeed. The original Xauth user name was "Luedenscheid_luedenscheid-aussenstellen".
With RouterOS 6.37.4 there is no problem.
11:15:58 ipsec,info respond new phase 1 (Identity Protection): 111.11.56.87[500]<=>99.231.204.198[500]
11:15:58 ipsec,info ISAKMP-SA established 111.11.56.87[4500]-99.231.204.198[4500] spi:6a36407b8d013957:e691c0e0be04100d
11:15:58 ipsec,error Trimming Xauth user name
11:15:58 ipsec,info No mode-cfg configured
11:15:58 ipsec,info XAuth login failed for user: Luedenscheid_luedenscheid-auss
11:16:02 ipsec,info respond new phase 1 (Identity Protection): 111.11.56.87[500]<=>99.231.204.198[500]
11:16:02 ipsec,info ISAKMP-SA established 111.11.56.87[4500]-99.231.204.198[4500] spi:436a58d94cf6c650:75a152295ad122d1
11:16:02 ipsec,info XAuth login succeeded for user: Luedenscheid_luedenscheid-a
11:21:18 system,info device added by admin
Thanks, but I have the problem with the Xauth user and not with the password!Here you can read about the lead up to this "trimming":I have a problem with ipsec and xauth. If the xauth user name is longer than 30 characters, in the log you can see "Trimming Xauth user name". The Xauth login fail. If I cut the Xauth name to 30 characters or less, the Xauth login succeed. The original Xauth user name was "Luedenscheid_luedenscheid-aussenstellen".
With RouterOS 6.37.4 there is no problem.
11:15:58 ipsec,info respond new phase 1 (Identity Protection): 111.11.56.87[500]<=>99.231.204.198[500]
11:15:58 ipsec,info ISAKMP-SA established 111.11.56.87[4500]-99.231.204.198[4500] spi:6a36407b8d013957:e691c0e0be04100d
11:15:58 ipsec,error Trimming Xauth user name
11:15:58 ipsec,info No mode-cfg configured
11:15:58 ipsec,info XAuth login failed for user: Luedenscheid_luedenscheid-auss
11:16:02 ipsec,info respond new phase 1 (Identity Protection): 111.11.56.87[500]<=>99.231.204.198[500]
11:16:02 ipsec,info ISAKMP-SA established 111.11.56.87[4500]-99.231.204.198[4500] spi:436a58d94cf6c650:75a152295ad122d1
11:16:02 ipsec,info XAuth login succeeded for user: Luedenscheid_luedenscheid-a
11:21:18 system,info device added by admin
viewtopic.php?f=21&t=116354&p=576081&hi ... th#p576081
RB433UAH 6.39rc35 microSD, 2x USB Flash disk, (power 24V 2A)
one USB Flash disk lost (6.38.1. works)
Thanks! Can't yet try it; is the dhcp-server already configured by the time the script runs?as a workaround:I LOVE the new script property of DHCP client. But something very basic seems to be missing - in my case the DHCP server is _not_ the gateway. However I don't see the gateway-address or like variable available. Any chance this can be added soon?Code: Select all:put [ /ip dhcp-server network get [ find $leaseActIP in address ] gateway ];
Thanks for the hint, Chupaka, used it to make the code that actually works for the usecase.Code: Select all:put [ /ip dhcp-server network get [ find $leaseActIP in address ] gateway ];
:local gatewayAddress [/ip dhcp-client get [find dhcp-server=$"server-address"] gateway]
Huh, my bad, I was thinking about dhcp-server when I was writing the answer. Glad you still found it usefulThanks for the hint, Chupaka, used it to make the code that actually works for the usecase.Code: Select all:put [ /ip dhcp-server network get [ find $leaseActIP in address ] gateway ];
Code: Select all:local gatewayAddress [/ip dhcp-client get [find dhcp-server=$"server-address"] gateway]
What is the reason to drop it ?!) firewall - discontinued support for p2p matcher (old rules will become invalid);
I think that is because it not so much efficient in this days any moreWhat is the reason to drop it ?!) firewall - discontinued support for p2p matcher (old rules will become invalid);
RB493G - THE SAME - BRICKED! after update to 6.39rc45.CHR v6.39rc45 update error, the interfaces are missing.
console error- info failed: std failure: timeout (13)
system reboots at 16% when trying to run supout.
restored from backup (6.39rc41) and retried the package update, same results.
Three reasons:
1. None of the protocols in the p2p filter are used today. Limeware? Kazaa? Really ... ?
2. This matcher also caught non-p2p traffic and interrupted normal communcations
3. You can duplicate the functionality with l7 filters. In fact, p2p filter is the same as L7 filter, but L7 has more customisation
RB493G - THE SAME - BRICKED! after update to 6.39rc45.CHR v6.39rc45 update error, the interfaces are missing.
console error- info failed: std failure: timeout (13)
system reboots at 16% when trying to run supout.
restored from backup (6.39rc41) and retried the package update, same results.
Its...... loading and ...reboots ... loading and ...reboots ... loading and ...reboots ... loading and ...reboots
Only Netinstall to 6.38.3 - helped.
So - version 6.39rc45 have a BIG BUG!
you are searching for troubles messing with RC while being 250 miles away...RB1100aHX2 BRICKED, man, this is a RC, not an alpha, can't even think how this happend.
Trying to downgrade to earlier version, unfortunately at this time i'm 250 miles away from the RB, so only can connect through layer2 (MAC) and i'm lossing the connection every X seconds and I can't upload de 11MB system file.
Just checked, I got a 450g updated normal to 45,so this crash is very specific.I have 433,433ah, Chr, crs125, base no 2, upgrade to. 45 ok.
But I get 450g that I lost access after updating,
I think is some configuration, that cause the crash and not related to hardware
Enviado de meu XT1580 usando Tapatalk
By any chance, did you have PCQ simple queues on the affected 450G?Just checked, I got a 450g updated normal to 45,so this crash is very specific.I have 433,433ah, Chr, crs125, base no 2, upgrade to. 45 ok.
But I get 450g that I lost access after updating,
I think is some configuration, that cause the crash and not related to hardware
Enviado de meu XT1580 usando Tapatalk
Enviado de meu XT1580 usando Tapatalk
No,By any chance, did you have PCQ simple queues on the affected 450G?Just checked, I got a 450g updated normal to 45,so this crash is very specific.I have 433,433ah, Chr, crs125, base no 2, upgrade to. 45 ok.
But I get 450g that I lost access after updating,
I think is some configuration, that cause the crash and not related to hardware
Enviado de meu XT1580 usando Tapatalk
Enviado de meu XT1580 usando Tapatalk
Can you tell what is causing?Seems that we have managed to reproduce this crash which was introduced in last rc release. We will try to fix it as soon as possible and release new version with fix included.
Yeap, I'll prefer to name them like that.The trouble is, MikroTik's naming is not exactly what many people expect. Personally I'd call their "RC" beta if I'd like to be nice, or alpha if I want to be safe.
Lesson learned with Mikrotik.you are searching for troubles messing with RC while being 250 miles away...RB1100aHX2 BRICKED, man, this is a RC, not an alpha, can't even think how this happend.
Trying to downgrade to earlier version, unfortunately at this time i'm 250 miles away from the RB, so only can connect through layer2 (MAC) and i'm lossing the connection every X seconds and I can't upload de 11MB system file.
I was having issues with the DHCP offered lease without success, that is why I took the risk."Lesson lerned ...."
There are three branches: bugfix, current and RC (read it as beta/alpha/test version)
It should be obvious that production system should not go further than "current" despite the name of device manufacturer.
Good morning!!) www - fixed http server vulnerability;
please add more details!!!
version affected?
what type of vulnerability?
thanks.
Is it about the pppoe-server or just the client?!) pppoe - added fastpath support when MRRU and MLPPP are enabled;
I guess this is client only.Is it about the pppoe-server or just the client?
Try contacting support by email. They may know of a way to do this, or get you a custom package (especially if you're buying hundreds of CPEs).A friendly bump on my request to have the IPv6 package enabled by default in the main RouterOS package.
We want to get purchasing and rolling out hundreds of MikroTik TR-069 routers to our customers but are holding off until we are able to do this.
I think too much to MUMGood morning!!) www - fixed http server vulnerability;
please add more details!!!
version affected?
what type of vulnerability?
thanks.
viewtopic.php?f=21&t=119308
We also need a proper set of firewall rules, simply enabling ipv6 is not enoughA friendly bump on my request to have the IPv6 package enabled by default in the main RouterOS package.
We want to get purchasing and rolling out hundreds of MikroTik TR-069 routers to our customers but are holding off until we are able to do this.
Can you tell more about this?Version 6.39rc51 has been released.
!) tile - fixed IPsec hardware acceleration out-of-order packet problem, significantly improved performance;
This is specifically for the CCR series (both problem and solution). More information here: viewtopic.php?f=1&t=112545Can you tell more about this?Version 6.39rc51 has been released.
!) tile - fixed IPsec hardware acceleration out-of-order packet problem, significantly improved performance;
Does this also improve IPsec on other multicore platforms like RB750GR3?
Did anyone else experienced the issue that the complete NAT configuration was gone after rebooting into rc51?Version 6.39rc51 has been released.
Changes since previous version:
!) tile - fixed IPsec hardware acceleration out-of-order packet problem, significantly improved performance;
*) tr069-client - fixed write for "Device.ManagementServer.URL";
If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
No problem over here with the NAT or any other rules.Did anyone else experienced the issue that the complete NAT configuration was gone after rebooting into rc51?Version 6.39rc51 has been released.
Changes since previous version:
!) tile - fixed IPsec hardware acceleration out-of-order packet problem, significantly improved performance;
*) tr069-client - fixed write for "Device.ManagementServer.URL";
If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
I had to manually rebuild the whole NAT cfg :/
is any chance for fix for recent linux breach ?
eg this one:
https://security-tracker.debian.org/tra ... -2017-2636
... in the Linux kernel through 4.10.1...
I think the issues you mentioned may be related to what I mentioned in #260. Infuriating.CAPSMAN controller: CCR1009
Wifi CAPS: WAP AC + HAP AC
v6.36.4:
working fine, reference speed wireless: 250-260Mbit/s
v6.38.x :
- massive wireless issues with capsman (continous disconnects, slow speeds)
- RSTP causing forwarding issues (traffic not forwarding, DHCP not getting through)
v6.39rcXX-51:
- Wireless speed issue: speed only half (~ 140Mbit/s; half speed compared to v6.36.4; downgrading back to 6.36.4 results in higher speed)
well, since "3.2 and above(up to 4.11?)" listed as "vulnerable" unless "particular security fix" delivered - it IS VULNERABLE, i guess.is any chance for fix for recent linux breach ?
eg this one:
https://security-tracker.debian.org/tra ... -2017-2636RouterOS v6 uses v3.3.6 and don't have hdlc ...you are safe.Code: Select all... in the Linux kernel through 4.10.1...
have you seen HDLC protocol frames anywhere in RouterOS? I haven't...well, since "3.2 and above(up to 4.11?)" listed as "vulnerable" unless "particular security fix" delivered - it IS VULNERABLE, i guess.
how do you Know(!) that ROS lack "drivers/tty/n_hdlc" in it ?
do you had ROS source-code access ?
I have had issues like you on several of the networks I manage and learned the hard way to disable rstp on every mikrotik bridge in the network if using 6.38.x or later version ... guess something is severely broken in bridge rstp. It just doesn't work as expected and makes other devices disappear from network. You will find many posts regarding this issue on the forum. It is not a solution, because rstp is there for a reason but only a workaround if you really need IKEv2.6.38.x severe issues.
Alright, I'm very furious. So much wasted time and no profit. What's going on here? is 6.37.x = stable ; 6.38 = beta while 6.39 = alpha? Does Mikrotik warrant their users for such trouble? ALSO Lost a lot of credibility by my client here. I still look forward to IKEv2 so staying on 6.37 is really no solution.
I do not follow how this can be let to happen in a "current" version. My setup is fairly simple and I'm no veteran. I had always had the impression that Mikrotik devices are utilized in corporate environments, schools, banks, etc. and this issue caused major outages. Worst of all I was oblivious to it, not realizing it could be a version issue due to a certain sequence of events. If it had been a simple "I upgraded, and issue started appearing" then I would have suspected its a version issue.I have had issues like you on several of the networks I manage and learned the hard way to disable rstp on every mikrotik bridge in the network if using 6.38.x or later version ... guess something is severely broken in bridge rstp. It just doesn't work as expected and makes other devices disappear from network. You will find many posts regarding this issue on the forum. It is not a solution, because rstp is there for a reason but only a workaround if you really need IKEv2.6.38.x severe issues.
Alright, I'm very furious. So much wasted time and no profit. What's going on here? is 6.37.x = stable ; 6.38 = beta while 6.39 = alpha? Does Mikrotik warrant their users for such trouble? ALSO Lost a lot of credibility by my client here. I still look forward to IKEv2 so staying on 6.37 is really no solution.
JF.
Well here's the thing. I'm guessing 90% of those corporate, school, bank, whatever networks are definitely _not_ running "current" or "rc" code. In fact, I believe most of them aren't even running "bugfix" code, but even more well-proven, older releases (even if Mikrotiks standard response to literally every single problem report ever is "try current version to see if it is fixed"). I know of several decently-sized ISP networks even that still run on ROS 5.x for that reason.I do not follow how this can be let to happen in a "current" version. My setup is fairly simple and I'm no veteran. I had always had the impression that Mikrotik devices are utilized in corporate environments, schools, banks, etc. and this issue caused major outages.
Did you read the changelog before upgrading? The big warning they have? The issues you are having really sound like they are related to that change:I do not follow how this can be let to happen in a "current" version. My setup is fairly simple and I'm no veteran. I had always had the impression that Mikrotik devices are utilized in corporate environments, schools, banks, etc. and this issue caused major outages. Worst of all I was oblivious to it, not realizing it could be a version issue due to a certain sequence of events. If it had been a simple "I upgraded, and issue started appearing" then I would have suspected its a version issue.I have had issues like you on several of the networks I manage and learned the hard way to disable rstp on every mikrotik bridge in the network if using 6.38.x or later version ... guess something is severely broken in bridge rstp. It just doesn't work as expected and makes other devices disappear from network. You will find many posts regarding this issue on the forum. It is not a solution, because rstp is there for a reason but only a workaround if you really need IKEv2.6.38.x severe issues.
Alright, I'm very furious. So much wasted time and no profit. What's going on here? is 6.37.x = stable ; 6.38 = beta while 6.39 = alpha? Does Mikrotik warrant their users for such trouble? ALSO Lost a lot of credibility by my client here. I still look forward to IKEv2 so staying on 6.37 is really no solution.
JF.
Anyway, as mentioned in post #260, I would like to share what made me think the CRS went faulty.
Initially, the setup was 1x Hex, 1x CRS, 1x WAP AC. Everything was working. I had decided to upgrade to the latest version before deploying more WAP AC and HAP AC. I had upgraded the Hex & WAP AC and they worked. From winbox on the HEx router, I used mac telnet to access the CRS. I tried to initiate the upgrade on the CRS by doing /system package update download which I did on WAP AC and it says "downloading now or something".. but this time it complained being unable to connect and then /system package update install which also complained the same thing. It was only then I realized I had forgotten to set the DNS on the switch. Here's the thing, RIGHT AFTER doing a /ip dns set address=8.8.8.8, i lost connectivity to the switch. WAP AC and clients connected to the switch were still pingable however. It was only a bit later I realized by "neighbors" that the version had been upgraded to 6.38.5. HEre's where I thought I did a bad flash. After resetting the device configuration several times, the device was pingable which also led me to believe that it had a borked flash. The point is: Why the heck did the upgrade happen when it complained that it can't locate the download server which is understoodable because there was no DNS set. Why did upgrade happen on its own after setting DNS? I even thought that bad flash happened because I keyed in the command twice (in similarity)
In other words, you needed to upgrade the spoke device first (probably the WAP), followed by the CRS and then the Hex, or disable STP first.What's new in 6.38 (2016-Dec-30 11:33):
Important note!!!
RouterOS v6.38 contains STP/RSTP changes which makes bridges compatible with IEEE 802.1Q-2014 by sending and processing BPDU packets without VLAN tag.
To avoid STP/RSTP compatibility issues with older RouterOS versions, upgrade RouterOS to v6.38 on all routers in Layer2 networks with VLAN and STP/RSTP configurations.
The recommended procedure is to start by upgrading the remotest routers and gradually do it to the Root Bridge device.
If after upgrade you experience loss of connectivity, then disabling STP/RSTP on RouterOS bridge interface will restore connectivity so you can complete upgrade process on your network.
Actually I've been looking/waiting for you on IRC for two days.Did you read the changelog before upgrading? The big warning they have? The issues you are having really sound like they are related to that change:I do not follow how this can be let to happen in a "current" version. My setup is fairly simple and I'm no veteran. I had always had the impression that Mikrotik devices are utilized in corporate environments, schools, banks, etc. and this issue caused major outages. Worst of all I was oblivious to it, not realizing it could be a version issue due to a certain sequence of events. If it had been a simple "I upgraded, and issue started appearing" then I would have suspected its a version issue.I have had issues like you on several of the networks I manage and learned the hard way to disable rstp on every mikrotik bridge in the network if using 6.38.x or later version ... guess something is severely broken in bridge rstp. It just doesn't work as expected and makes other devices disappear from network. You will find many posts regarding this issue on the forum. It is not a solution, because rstp is there for a reason but only a workaround if you really need IKEv2.6.38.x severe issues.
Alright, I'm very furious. So much wasted time and no profit. What's going on here? is 6.37.x = stable ; 6.38 = beta while 6.39 = alpha? Does Mikrotik warrant their users for such trouble? ALSO Lost a lot of credibility by my client here. I still look forward to IKEv2 so staying on 6.37 is really no solution.
JF.
Anyway, as mentioned in post #260, I would like to share what made me think the CRS went faulty.
Initially, the setup was 1x Hex, 1x CRS, 1x WAP AC. Everything was working. I had decided to upgrade to the latest version before deploying more WAP AC and HAP AC. I had upgraded the Hex & WAP AC and they worked. From winbox on the HEx router, I used mac telnet to access the CRS. I tried to initiate the upgrade on the CRS by doing /system package update download which I did on WAP AC and it says "downloading now or something".. but this time it complained being unable to connect and then /system package update install which also complained the same thing. It was only then I realized I had forgotten to set the DNS on the switch. Here's the thing, RIGHT AFTER doing a /ip dns set address=8.8.8.8, i lost connectivity to the switch. WAP AC and clients connected to the switch were still pingable however. It was only a bit later I realized by "neighbors" that the version had been upgraded to 6.38.5. HEre's where I thought I did a bad flash. After resetting the device configuration several times, the device was pingable which also led me to believe that it had a borked flash. The point is: Why the heck did the upgrade happen when it complained that it can't locate the download server which is understoodable because there was no DNS set. Why did upgrade happen on its own after setting DNS? I even thought that bad flash happened because I keyed in the command twice (in similarity)
In other words, you needed to upgrade the spoke device first (probably the WAP), followed by the CRS and then the Hex, or disable STP first.What's new in 6.38 (2016-Dec-30 11:33):
Important note!!!
RouterOS v6.38 contains STP/RSTP changes which makes bridges compatible with IEEE 802.1Q-2014 by sending and processing BPDU packets without VLAN tag.
To avoid STP/RSTP compatibility issues with older RouterOS versions, upgrade RouterOS to v6.38 on all routers in Layer2 networks with VLAN and STP/RSTP configurations.
The recommended procedure is to start by upgrading the remotest routers and gradually do it to the Root Bridge device.
If after upgrade you experience loss of connectivity, then disabling STP/RSTP on RouterOS bridge interface will restore connectivity so you can complete upgrade process on your network.
1) RouterOS is not affectedwell, since "3.2 and above(up to 4.11?)" listed as "vulnerable" unless "particular security fix" delivered - it IS VULNERABLE, i guess.is any chance for fix for recent linux breach ?
eg this one:
https://security-tracker.debian.org/tra ... -2017-2636RouterOS v6 uses v3.3.6 and don't have hdlc ...you are safe.Code: Select all... in the Linux kernel through 4.10.1...
how do you Know(!) that ROS lack "drivers/tty/n_hdlc" in it ?
do you had ROS source-code access ?
Where can this be found?6.39rc54 has been released.
*) ipsec - show hardware accelerated authenticated SAs;
Thanks. Not sure how I missed that when printing before. Guess I was looking for a yes/no value, not flag. Makes sense.I don't see anything in WinBox, but CLI has new flag "H - hw-authenc" in "/ip ipsec installed-sa print".
Is there any possibility that WinBox could highlight the algorithms that are hardware accelerated on each platform?*) ipsec - show hardware accelerated authenticated SAs;
You mean putting this information into winbox? https://wiki.mikrotik.com/wiki/Manual:I ... encryption. Couldn't hurt. I could see it being useful to make that information more readily available in the data sheets/brochures on routerboard.com too.Is there any possibility that WinBox could highlight the algorithms that are hardware accelerated on each platform?*) ipsec - show hardware accelerated authenticated SAs;
Yes, exactly.You mean putting this information into winbox? https://wiki.mikrotik.com/wiki/Manual:I ... encryption. Couldn't hurt. I could see it being useful to make that information more readily available in the data sheets/brochures on routerboard.com too.Is there any possibility that WinBox could highlight the algorithms that are hardware accelerated on each platform?*) ipsec - show hardware accelerated authenticated SAs;
Probably best requested as new reply in viewtopic.php?f=1&t=45934 or topic in viewforum.php?f=1 (might already exist too)- Wireless + CAPSMAN: what about airtime fairness and bandsteering?
I have requested this a few times, and each time I get pointed at the Wiki..Is there any possibility that WinBox could highlight the algorithms that are hardware accelerated on each platform?*) ipsec - show hardware accelerated authenticated SAs;
This is not fixed, the problem still persists.6.39rc54 has been released.
*) wireless - fixed false positive DFS radar detection caused by iPhone 6s devices;
I had a problem on one of my WAP ac where the wlan interfaces are not added to the bridge. Clients can connect but there is no communication with the router. And the protocol mode was set to none...!) bridge - fixed BPDU rx/tx when protocol-mode=none
can we have more information on this? thanks
I´m in the same situation: throughput is rather low. I have CAPSMAN with WAP AC devices.CAPSMAN controller: CCR1009
Wifi CAPS: WAP AC + HAP AC
v6.36.4:
working fine, reference speed wireless: 250-260Mbit/s
v6.38.x :
- massive wireless issues with capsman (continous disconnects, slow speeds)
- RSTP causing forwarding issues (traffic not forwarding, DHCP not getting through)
v6.39rcXX-51:
- Wireless speed issue: speed only half (~ 140Mbit/s; half speed compared to v6.36.4; downgrading back to 6.36.4 results in higher speed)
We need more info how to reproduce this problem. Step by step so we could try to reproduce this problem.v6.39rcXX-51:
- Wireless speed issue: speed only half (~ 140Mbit/s; half speed compared to v6.36.4; downgrading back to 6.36.4 results in higher speed)
So I tested with CAPSMAN => Configuration => Distance set to indoors AND CAPSMAN => Configuration => Rates empty setting.We need more info how to reproduce this problem. Step by step so we could try to reproduce this problem.v6.39rcXX-51:
- Wireless speed issue: speed only half (~ 140Mbit/s; half speed compared to v6.36.4; downgrading back to 6.36.4 results in higher speed)
What wireless packages you used on the 6.36.4 and did you downgrade both CAPsMAN and CAP?
What does "all other RouterOS priorities" mean?*) ethernet - reversed poe-priority on hEX PoE and OmniTIK 5 PoE to make "poe-priority" consistent to all other RouterOS priorities;
Does this apply to upgrading from 6.38 as well? Currently it clears all configuration when upgrading as wellBackup should be restored to same version of ROS as i have been made.
You should try /export your configuration if you want to restore it to the newer version of ROS
I has this same issue. I think it may be from the addition of the partition support.A RB3011 with a regular configruation when upgraded from v6.38.5 to v6.39.55 or v6.39.58 device becomes unusable: reboots again and again until it is recovered with reset and netinstall.
I had this problem going from v6.38.4 to 6.38.5 on the RB3011 also. Unfortunantly the router is one of my main routers, and I didn't have a spare so I couldn't debug. I did have extra packages installed and was running dude.A RB3011 with a regular configruation when upgraded from v6.38.5 to v6.39.55 or v6.39.58 device becomes unusable: reboots again and again until it is recovered with reset and netinstall.
In that scenario it is not wise to run RC software... I hope at least you make backups and/or exports and store them on another computer.I had this problem going from v6.38.4 to 6.38.5 on the RB3011 also. Unfortunantly the router is one of my main routers, and I didn't have a spare so I couldn't debug.