Unfortunately, currently SXT LTE does not support passthrough mode.
Is there a plan for this or even and ETA? SXT LTE is the ultimate platform to get this feature.irghost - What is the question about SXT LTE? Are you referring to Passthrough support? if you do, then take a look at this list:
https://wiki.mikrotik.com/wiki/Supporte ... and_modems
Still having the same problem with v6.41 rc21v6.41rc20 has some really cool stuff. I'm still having a problem with IGMP-Snooping where it drops an ACTIVE multicast group (after about 4-5 Min.). I'm not sure why it is doing this and to remedy it, I have to deactivate IGMP-Snooping and redeploy PIM (v6.40.2). I can't seem to find the ability to list the "Master Port" under Interface/Ethernet anymore. This might have been on purpose, just asking. I believe you folks are coming along nicely on IGMP-Snooping though it needs some tweaks (time will tell, right?). Would the ability to "Query" for IGMP Groups help in my case? Just spit-balling there..
Thanks,
-tp
+1 For SXT LTEUnfortunately, currently SXT LTE does not support passthrough mode.Is there a plan for this or even and ETA? SXT LTE is the ultimate platform to get this feature.irghost - What is the question about SXT LTE? Are you referring to Passthrough support? if you do, then take a look at this list:
https://wiki.mikrotik.com/wiki/Supporte ... and_modems
I gave the new rc a go because of the multiple VLAN option, however after upgrading from the previous rc21 now the link is not stable anymore.*) bridge - fixed connectivity issues when there are multiple VLAN interfaces on bridge;
.
Too late. My users complain that they are connected to the wifi, but there´s hardly any or only few traffic is getting through the connection.DANGER
If you are running CAPSMAN avoid 6.41rc23
6.41rc23 breaks CAP communication with CAPSMAN, at least when using a tunelled datapath. Downgrading to 6.41rc20 does not fix the problem
Mikrotik support are aware of this issue.
How are you connecting the CAP to the CAPsMAN? Are you using Local-forwarding or CAPsMAN forwarding? Are you using VLAN in our setup?Too late. My users complain that they are connected to the wifi, but there´s hardly any or only few traffic is getting through the connection.DANGER
If you are running CAPSMAN avoid 6.41rc23
6.41rc23 breaks CAP communication with CAPSMAN, at least when using a tunelled datapath. Downgrading to 6.41rc20 does not fix the problem
Mikrotik support are aware of this issue.
There is bug that after the downgrade from the newest RC you need to do a soft reboot of the board as the dhcp-client doesn't start in the first boot. Powercycle will not help, you need to do a sift reboot.You can download prior versions of the RC by manually adjusting the URL from the download page if you wanted to revert back to an RC that it still works at for you to retain the new bridge.
Hi Uldis, it is Layer3 with CAPsMAN forwarding.How are you connecting the CAP to the CAPsMAN? Are you using Local-forwarding or CAPsMAN forwarding? Are you using VLAN in our setup?
Well, it doesn't matter what older version I used. I downgraded and then "telnet-mac" into the access point to add an dhcp-client interface which took ~ 30 seconds to be added. After a reboot the access points worked again (I went back to 6.40.3).There is bug that after the downgrade from the newest RC you need to do a soft reboot of the board as the dhcp-client doesn't start in the first boot. Powercycle will not help, you need to do a sift reboot.
Can you elaborate on this feature? It applies solely when acting as a transit P router or when encapsulating/decapsulating l2circuit also?*) crs317 - added initial support for HW offloaded MPLS forwarding;
is there any news about SXT LTE?What's new in 6.41rc26 (2017-Sep-07 13:26):
Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.
Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.
Changes since previous 6.41rc release:
!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) chr - added KVM memory balloon support;
*) chr - added suspend support;
*) crs1xx/2xx - fixed 1 Gbps forced mode for several SFP modules;
*) crs317 - added initial support for HW offloaded MPLS forwarding;
*) dhcp - fixed unresponsive DHCP service caused by inability to read not set RAW options;
*) e-mail - auto complete file name on "file" parameter (introduced in v6.40);
*) eoip - made L2MTU parameter read-only;
*) hotspot - fixed missing "/ip hotspot server profile" if invalid "dns-name" was specified;
*) lte - added Passthrough support (CLI only);
*) lte - added support for ZTE ME3630 E1C;
*) lte - fixed mode initialization after reboot;
*) ppp - fixed missing PPP client interface after reboot (introduced in v6.41rc);
*) rb931-2nd - fixed startup problems (requires additional reboot after upgrade);
*) userman - fixed unresponsive RADIUS server (introduced in v6.40.3);
*) webfig - improved reliability of login process;
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.
Your question was already answered!is there any news about SXT LTE?
Unfortunately, currently SXT LTE does not support passthrough mode.
Sorry, I don't understand, what are you talking about?What about netcut and ip scanner for who using hotspot and not managed switch with ubnt AP's ?
Does SXT LTE Support passthrough in this version?Your question was already answered!is there any news about SXT LTE?
Unfortunately, currently SXT LTE does not support passthrough mode.Sorry, I don't understand, what are you talking about?What about netcut and ip scanner for who using hotspot and not managed switch with ubnt AP's ?
For the Verizon USB730L / Novatel Global Mode USB730L, would it work if plugged into USB slot of the RB750UPr2? If not, which MikroTik routers compatible? And if yes, please point me to the relevant chapters/sections of documentation, or tutorials?What's new in 6.41rc6 (2017-Aug-01 11:30):
[...]
*) ppp - added support for Sierra MC7750, Verizon USB730L;
[...]
Normis could you Elaborate.Your question was already answered!is there any news about SXT LTE?
Unfortunately, currently SXT LTE does not support passthrough mode.
strods, breaking hearts on a Monday. Love it.Passthrough is not currently supported on SXT LTE and we do not have plans to implement such functionality in near future.
Why? It would be really nice to have this functionality...Passthrough is not currently supported on SXT LTE and we do not have plans to implement such functionality in near future.
Thanks for the elaboration.Passthrough is not currently supported on SXT LTE and we do not have plans to implement such functionality in near future.
Yes!JimmyNyholm - Did this happen when you used 6.41rc28?
Is this gona be not bridged intefaces can hardware switch depending on label but ldp is running on ip so one would have to configure ip adresses and a routing protocol say ospf to get routes that would be hardware switched on labels without cpu. the cpu would only run routing protocol and ldp and the hardware chip would switch/route incoming mpls packes according to ldp. being a router no l2 domain but doing it true switching on ldp labels... Like the big guys....What's new in 6.41rc26 (2017-Sep-07 13:26):
*) crs317 - added initial support for HW offloaded MPLS forwarding;
should be 'out of range' or 'off-range', but not both, I thinkadded "allow-signal-out-off-range" option
Interesting how fast some options appear compared to others, cough useful IPv6 changes.
Good observation!Interesting how fast some options appear compared to others, cough useful IPv6 changes.
Yes, I'm heckling you because well it's apparently needed.
Side-note: It seems the pace is slowing on this RC. I imagine this means we'll be seeing 6.41rc moving to GA and 6.42 started? Will we see a general theme targeted in this next cycle like we say with the new bridge implementation?
Board: CRS326-24G-2S+bajodel - Can you please send to support@mikrotik,.com precise commands which you execute to reproduce this problem? We added all ports into bridge, added DHCP client on bridge, rebooted device and it is working just fine.
/interface ethernet
set [ find default-name=ether1 ] mac-address=CC:4E:24:00:EE:01
set [ find default-name=ether2 ] mac-address=CC:4E:24:00:EE:02
set [ find default-name=ether3 ] mac-address=CC:4E:24:00:EE:03
set [ find default-name=ether4 ] mac-address=CC:4E:24:00:EE:04
set [ find default-name=ether5 ] mac-address=CC:4E:24:00:EE:05
set [ find default-name=ether6 ] mac-address=CC:4E:24:00:EE:06
set [ find default-name=ether7 ] mac-address=CC:4E:24:00:EE:07
set [ find default-name=ether8 ] mac-address=CC:4E:24:00:EE:08
set [ find default-name=ether9 ] mac-address=CC:4E:24:00:EE:09
set [ find default-name=ether10 ] mac-address=CC:4E:24:00:EE:10
set [ find default-name=ether11 ] mac-address=CC:4E:24:00:EE:11
set [ find default-name=ether12 ] mac-address=CC:4E:24:00:EE:12
set [ find default-name=ether13 ] mac-address=CC:4E:24:00:EE:13
set [ find default-name=ether14 ] mac-address=CC:4E:24:00:EE:14
set [ find default-name=ether15 ] mac-address=CC:4E:24:00:EE:15
set [ find default-name=ether16 ] mac-address=CC:4E:24:00:EE:16
set [ find default-name=ether17 ] mac-address=CC:4E:24:00:EE:17
set [ find default-name=ether18 ] mac-address=CC:4E:24:00:EE:18
set [ find default-name=ether19 ] mac-address=CC:4E:24:00:EE:19
set [ find default-name=ether20 ] mac-address=CC:4E:24:00:EE:20
set [ find default-name=ether21 ] mac-address=CC:4E:24:00:EE:21
set [ find default-name=ether22 ] mac-address=CC:4E:24:00:EE:22
set [ find default-name=ether23 ] mac-address=CC:4E:24:00:EE:23
set [ find default-name=ether24 ] mac-address=CC:4E:24:00:EE:24
set [ find default-name=sfp-sfpplus1 ] mac-address=CC:4E:24:00:EE:25
set [ find default-name=sfp-sfpplus2 ] mac-address=CC:4E:24:00:EE:26
BootROM 1.41
Booting from SPI flash
BootROM: Image checksum verification PASSED
RouterBOOT booter 3.41
CRS326-24G-2S+
CPU frequency: 800 MHz
Memory size: 512 MiB
Storage size: 16 MiB
Press <delete> key within 4 seconds to enter setup....
loading kernel... OK
setting up elf image... OK
jumping to kernel code
Starting...
Starting services...
Rebooting...
Stopping services...
so, now it's available in 6.41rc?I am waiting until today for a simple reset counter:
viewtopic.php?f=1&t=108552&p=614961&hil ... er#p614961
Weak. Be brave!I'll just wait for the stable version.
It didn't work for me until I added the bridge1 itself to the tagged ports list....bridge1 doesn't need to be in a vlan for that vlan to forward frames to the member ports?.
interface bridge port
add interface=ether1 bridge=bridge1 pvid=1 frame-types=admit-all hw=yes
add interface=ether2 bridge=bridge1 pvid=1 frame-types=admit-all hw=yes
add interface=ether3 bridge=bridge1 pvid=1 frame-types=admit-all hw=yes
add interface=ether4 bridge=bridge1 pvid=1 frame-types=admit-all hw=yes
interface bridge vlan add bridge=bridge1 vlan-ids=100 tagged=bridge1,ether1,ether2,ether3,ether4 untagged=""
interface bridge set bridge1 vlan-filtering=yes pvid=1
strods, are we looking feature complete for 6.41 yet? I'm just curious if it's down to polishing and bug fixes or if there's more that's intending to be added.What's new in 6.41rc31 (2017-Sep-20 06:56):
Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.
Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.
Changes since previous 6.41rc release:
*) crs317 - added initial support for HW offloaded MPLS forwarding;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration) (CLI only);
*) lte - added Passthrough support (CLI only);
*) lte - added support for ZTE ME3630 E1C with additional "/port" for GPS usage;
*) lte - automatically add "/ip dhcp-client" configuration on interface;
*) lte - changed default values to "add-default-route=yes", "use-peer-dns=yes" and "default-route-distance=2";
*) ppp - fixed serial port loading (introduced in v6.41rc);
*) sfp - fixed temperature readings for various SFP modules;
*) snmp - fixed "/system license" parameters for CHR;
*) wireless - improved reliability on "rx-rate" selection process;
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.
one thing that i've never understood about mikrotik is why they add new features to RC.there should be testing or beta channel, rc channel (feature locked), stable(bugfix), mainline(current)
strods, are we looking feature complete for 6.41 yet? I'm just curious if it's down to polishing and bug fixes or if there's more that's intending to be added.
I know I'm not the only one very eager for it.
Which is why I won't touch updates with a 10 foot pole.One thing that I've never understood about MikroTik is why they add new features to the RC. There should be testing or beta channel, rc channel (feature locked), stable(bugfix), and mainline(current).
Which is why I won't touch updates with a 10 foot pole.One thing that I've never understood about MikroTik is why they add new features to the RC. There should be testing or beta channel, rc channel (feature locked), stable(bugfix), and mainline(current).
This is just a naming convention, you just have to get used to it.there should be testing or beta channel, rc channel (feature locked), stable(bugfix), mainline(current)
to you its a naming convention, but the rc are often very "alpha status", and rc can be misleading to new users who by norm perceive that rc's are "generally stable". why do you think cheeze asked if its down to polishing and bugfixes? its because rc naming convention makes it confusing for some users. no one would have to question if rc actually meant rc, alpha meant alpha, beta meant beta, and then we won't be having this discussion.This is just a naming convention, you just have to get used to it.there should be testing or beta channel, rc channel (feature locked), stable(bugfix), mainline(current)
In any case, please do NOT pollute this thread with the naming convention nonsense again. If you feel like you are in absolutely need to discuss, here is one of the many threads to reply to: viewtopic.php?f=2&t=123032.
We are aware of this, but in RouterOS world, "stable" is the only version you should use in important locations where you don't want new features. We update this branch rarely and only after long and rigorous testing. Current is more like RC (current = running release), and RC is more like Beta or "nightly build" in Windows land.to you its a naming convention, but the rc are often very "alpha status", and rc can be misleading to new users who by norm perceive that rc's are "generally stable"
/interface ethernet switch port
set ether6 learn-limit=1
set ether7 learn-limit=1
Not as faar as I can se for the moment..The previous switch settings supported MAC learning limits:
Is this feature still available with the new bridge implementation?Code: Select all/interface ethernet switch port set ether6 learn-limit=1 set ether7 learn-limit=1
What version you had before on your router where it was working ok?With v6.41rc31 my LTE connection was very slow, max. 7-10mbit/s and high pings >200ms. Also the E3372 LTE modem (still) loses connection when downloading larger amounts of data (via Steam for example) so you have to reboot the RB.
Yes, please. Cisco calls a learned MAC on reboot sticky (I think). Replace after a timeout is good too.While we are speaking about this, could we enhance it with ie: learn-limit=1 learn-clear-at-interface-down=no learn-replace-after-inactivity=15min
The previous switch settings supported MAC learning limits:
Is this feature still available with the new bridge implementation?Code: Select all/interface ethernet switch port set ether6 learn-limit=1
and or even cooler lear-radius-auth=yes (with all the magic options as answer properties in the radius answer?
Is it possible to get a better explanation or detail on the software based "igmp-snooping" ?What's new in 6.41rc32 (2017-Sep-21 13:51):
!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) bridge - added initial support for hardware "igmp-snooping" on CRS1xx/2xx;
*) bridge - implemented software based "igmp-snooping";
The bridge will perform IGMP snooping in a way that requires the CPU to process to packets instead of customized and often accelerated (faster) hardware that is meant to do it at line-rate or near line-rate.Is it possible to get a better explanation or detail on the software based "igmp-snooping" ?What's new in 6.41rc32 (2017-Sep-21 13:51):
!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) bridge - added initial support for hardware "igmp-snooping" on CRS1xx/2xx;
*) bridge - implemented software based "igmp-snooping";
Probably should of phrased the question better... How to "correctly" configure software based IGMP-Snooping .The bridge will perform IGMP snooping in a way that requires the CPU to process to packets instead of customized and often accelerated (faster) hardware that is meant to do it at line-rate or near line-rate.Is it possible to get a better explanation or detail on the software based "igmp-snooping" ?What's new in 6.41rc32 (2017-Sep-21 13:51):
!) bridge - general development of hw-offload bridge implementation (introduced in v6.40rc36);
*) bridge - added initial support for hardware "igmp-snooping" on CRS1xx/2xx;
*) bridge - implemented software based "igmp-snooping";
Very useful feature. Thank you. It could be possible to add the last signal when the state is disconnected?*) wireless - log "signal-strength" when successfully connected to AP;
Excelent idea!Very useful feature. Thank you. It could be possible to add the last signal when the state is disconnected?*) wireless - log "signal-strength" when successfully connected to AP;
That might be extremely useful, if the data correlates to client's disconnecting around full power. We could point blame at something other than coverage.Very useful feature. Thank you. Would it be possible to add the last signal when the state was disconnected?*) wireless - log "signal-strength" when successfully connected to AP;
Probably should of phrased the question better... How to "correctly" configure software based IGMP-Snooping .
interface bridge set bla-bla igmp-snooping=yes
I reverted back to 6.40.3 where speeds are normal, but that version too has the problem that the E3372 is unstable an looses LTE connection when there is some load. I hoped the latest RC would fix this...What version you had before on your router where it was working ok?
Please contact support@mikrotik.com for more information (include the modem number and revision). Also check what lte band it uses when you have normal speed and when you have slow speed.I reverted back to 6.40.3 where speeds are normal, but that version too has the problem that the E3372 is unstable an looses LTE connection when there is some load. I hoped the latest RC would fix this...What version you had before on your router where it was working ok?
careful now, forum police andyris might warn you to post in feature request thread.have you planned add HW offload with vlan-filtering function?
Updated to 6.41rc32 and everything works as expected. I can not tell what intermediate version fixed the issue though.The issue persists with 6.41rc16... Just downgraded to 6.41rc11 and wireless is up and running.I am having issues with CAPsMAN on 6.41rc13... Looks like cap interfaces with CAPsMAN forwarding do not pass any traffic.
this is not a feature request, it's a questioncareful now, forum police andyris might warn you to post in feature request thread.have you planned add HW offload with vlan-filtering function?
I had a similar issue with a 951G. First boot with upgrade, was still able to connect from port 5. Rebooted one more time and lost connection until I switched to port 2.I just put 6.41rc32 onto an RB2011UAS-2HnD and have a question.
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
# INTERFACE BRIDGE HW PVID PRIORITY PATH-COST INTERNAL-PATH-COST HORIZON
0 H ether1 bridge1 yes 1 0x80 10 10 none
1 I H ether2 bridge1 yes 1 0x80 10 10 none
2 I H ether3 bridge1 yes 1 0x80 10 10 none
3 I H ether4 bridge1 yes 1 0x80 10 10 none
4 I H ether5 bridge1 yes 1 0x80 10 10 none
5 I H ether6 bridge1 yes 1 0x80 10 10 none
6 I H ether7 bridge1 yes 1 0x80 10 10 none
7 I H ether8 bridge1 yes 1 0x80 10 10 none
8 I H ether9 bridge1 yes 1 0x80 10 10 none
9 I H ether10 bridge1 yes 1 0x80 10 10 none
10 I H ether11 bridge1 yes 1 0x80 10 10 none
11 I H ether12 bridge1 yes 1 0x80 10 10 none
12 I H ether13 bridge1 yes 1 0x80 10 10 none
13 I H ether14 bridge1 yes 1 0x80 10 10 none
14 I H ether15 bridge1 yes 1 0x80 10 10 none
15 I H ether16 bridge1 yes 1 0x80 10 10 none
16 I H sfp-sfpplus1 bridge1 yes 1 0x80 10 10 none
17 I ether17 bridge2 yes 1 0x80 10 10 none
18 I ether18 bridge2 yes 1 0x80 10 10 none
19 I ether19 bridge2 yes 1 0x80 10 10 none
20 I ether20 bridge2 yes 1 0x80 10 10 none
21 I ether21 bridge2 yes 1 0x80 10 10 none
22 I ether22 bridge2 yes 1 0x80 10 10 none
23 I ether23 bridge2 yes 1 0x80 10 10 none
24 I ether24 bridge2 yes 1 0x80 10 10 none
25 I sfp-sfpplus2 bridge2 yes 1 0x80 10 10 none
Not stating your board but from what I can tell wlan1 is a wlan interface right? this interface maybe is not connected in hardware to the same switch chip. Hence it's not hardware enabled. Look att the Block diagrams of your unit an you will se how it's built.Hw. Offload
After reboot I have this in log...
hardware offloading activated on bridge "bridge1" ports: wlan1,ether2
hardware offloading activated on bridge "bridge1" ports: wlan1,ether3
But port wlan1 status is inactive and not Hw. Offload... Is is correct?
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
0 XI ether1 bridge1 yes 1 0x80 10 10 none
1 H ether2 bridge1 yes 1 0x80 10 10 none
2 H ether3 bridge1 yes 1 0x80 10 10 none
3 XI ether4 bridge1 yes 1 0x80 10 10 none
4 wlan1 bridge1 yes 1 0x80 10 10 none
*) wireless - improved WPA2 key exchange reliability;
Thank you for this fix!What's new in 6.41rc37 (2017-Oct-02 06:47):
Changes since previous 6.41rc release:
*) fetch - accept all HTTP 2xx status codes;
[admin@CHR] > /tool fetch url="http://httpstat.us/204"
status: failed
action failed (6)
[admin@CHR] > /tool fetch url="https://httpstatuses.com/204"
status: finished
downloaded: 3KiBC-z pause]
duration: 1s
Try this:*) bridge - initial support for "/interface list" as a bridge port (CLI only);
/in bridge port add interface=all
What's new in 6.41rc31 (2017-Sep-20 06:56):*) lte - added Passthrough support (CLI only);
*) lte - added Passthrough support (CLI only);
If you see the same changelog entry in multiple rc versions then it is a new feature which is being implemented and changelog entry is simply moved up on each rc when additional work on it has been done.
Thank you!viewtopic.php?f=21&t=123936&start=100#p614799
If you see the same changelog entry in multiple rc versions then it is a new feature which is being implemented and changelog entry is simply moved up on each rc when additional work on it has been done.
We are constantly improving and fixing bugs for this feature.strods,
What is difference between earlier RC, for example:
What's new in 6.41rc38 (2017-Oct-03 11:51):What's new in 6.41rc31 (2017-Sep-20 06:56):*) lte - added Passthrough support (CLI only);*) lte - added Passthrough support (CLI only);
Then the correct should be:We are constantly improving and fixing bugs for this feature.
Connector Type SFP - LC
Fiber Type Reserved
Tx Central Wavelength 1310
Baud Rate 1G
Vendor OUI 00:00:00
Vendor Name Mikrotik
Vendor PN S-35LC20D
Vendor Rev 1.0
Vendor SN SK151211B35234
Date Code 151205
Temperature [Degrees Centigrade] 33.75
Vcc [Volt] 3.30
Mon1 (Bias) [mA] 1
Mon2 (TX PWR) [dBm] -5.19
Mon3 (RX PWR) [dBm] -17.42
[admin@BS568] > interface ethernet monitor sfp-sfpplus1
name: sfp-sfpplus1
status: link-ok
auto-negotiation: disabled
rate: 1Gbps
full-duplex: yes
tx-flow-control: yes
rx-flow-control: yes
sfp-module-present: yes
sfp-rx-loss: no
sfp-tx-fault: no
sfp-type: SFP-or-SFP+
sfp-connector-type: LC
sfp-link-length-9um: 20000m
sfp-vendor-name: Mikrotik
sfp-vendor-part-number: S-53LC20D
sfp-vendor-revision: 1.0
sfp-vendor-serial: SK151211B54444
sfp-manufacturing-date: 15-12-05
sfp-wavelength: 1550nm
sfp-temperature: 40C
sfp-supply-voltage: 3.296V
sfp-tx-bias-current: 0mA
sfp-rx-power: -9.752dBm
eeprom-checksum: good
eeprom: 0000: 03 04 07 00 00 00 02 00 00 00 00 01 0d 00 14 c8 ........ ........
0010: 00 00 00 00 4d 69 6b 72 6f 74 69 6b 20 20 20 20 ....Mikr otik
0020: 20 20 20 20 00 00 00 00 53 2d 35 33 4c 43 32 30 .... S-53LC20
0030: 44 20 20 20 20 20 20 20 31 2e 30 00 06 0e 00 e4 D 1.0.....
0040: 00 1a 00 00 53 4b 31 35 31 32 31 31 42 35 34 34 ....SK15 1211B544
0050: 34 34 20 20 31 35 31 32 30 35 20 20 68 f0 04 34 44 1512 05 h..4
0060: 1f a0 7b 0b 1a 66 2c 8c 00 00 52 52 52 52 00 52 ..{..f,. ..RRRR.R
0070: 00 40 52 52 00 40 52 52 52 52 52 ff ff ff ff 00 .@RR.@RR RRR.....
0080: 55 00 d8 00 46 00 00 00 8d cc 74 04 88 b8 79 18 U...F... ..t...y.
0090: af c8 00 00 88 b8 00 00 13 94 04 eb 13 94 04 eb ........ ........
00a0: 18 a6 00 10 13 94 00 10 00 00 00 00 00 00 00 00 ........ ........
00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00c0: 00 00 00 00 3f 80 00 00 00 00 00 00 01 00 00 00 ....?... ........
00d0: 01 00 00 00 01 00 00 00 01 00 00 00 00 00 00 40 ........ .......@
00e0: 28 64 80 c6 00 65 0b b3 05 89 7d 7d 7d 7d 00 7d (d...e.. ..}}}}.}
00f0: 00 00 7d 7d 00 00 7d 7d 7d 7d 07 ff ff ff ff 00 ..}}..}} }}......
[admin@BS568] > interface ethernet monitor sfp-sfpplus1
name: sfp-sfpplus1
status: link-ok
auto-negotiation: disabled
rate: 1Gbps
full-duplex: yes
tx-flow-control: yes
rx-flow-control: yes
sfp-module-present: yes
sfp-rx-loss: no
sfp-tx-fault: no
sfp-type: SFP-or-SFP+
sfp-connector-type: LC
sfp-link-length-9um: 3000m
sfp-vendor-name: UBNT
sfp-vendor-part-number: UF-SM-1G-S
sfp-vendor-serial: FT17012008409
sfp-manufacturing-date: 17-01-12
sfp-wavelength: 1550.32nm
sfp-temperature: 39C
sfp-supply-voltage: 3.263V
sfp-tx-bias-current: 19mA
sfp-rx-power: -7.271dBm
eeprom-checksum: good
eeprom: 0000: 03 04 07 00 00 00 40 00 00 00 00 01 0d 00 03 1e ......@. ........
0010: 00 00 00 00 55 42 4e 54 20 20 20 20 20 20 20 20 ....UBNT
0020: 20 20 20 20 00 00 00 00 55 46 2d 53 4d 2d 31 47 .... UF-SM-1G
0030: 2d 53 20 20 20 20 20 20 20 20 20 20 06 0e 20 37 -S .. 7
0040: 20 0a 00 00 46 54 31 37 30 31 32 30 30 38 34 30 ...FT17 01200840
0050: 39 20 20 20 31 37 30 31 31 32 00 00 68 90 01 79 9 1701 12..h..y
0060: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
0070: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
0080: 5a 00 d3 00 55 00 d8 00 94 70 69 78 90 88 6d 60 Z...U... .pix..m`
0090: c3 50 00 00 af c8 00 32 18 a6 03 e8 13 94 04 eb .P.....2 ........
00a0: 27 10 00 28 1f 07 00 32 00 00 00 00 00 00 00 00 '..(...2 ........
00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00c0: 00 00 00 00 3f 80 00 00 00 00 00 00 01 00 00 00 ....?... ........
00d0: 01 00 00 00 01 00 00 00 01 00 00 00 00 00 00 99 ........ ........
00e0: 27 c3 7f 78 25 76 0a 81 09 cd 00 00 00 00 22 00 '..x%v.. ......".
00f0: 00 40 00 00 00 40 00 00 00 00 00 ff ff ff ff 00 .@...@.. ........
On RB3011 sfp to a CRS326-24G-2S+ via DAC cable doesn't work if you set auto-negotiation , furthermore the RB3011 doesn't detect if link go down (CRS instead correctly detects it)...cut.. SFP transceiver, why do you have auto-negotiation disabled and what is connected to opposite side? Have you tried to turn auto-negotiation=on?
/interface ethernet
set [ find default-name=ether3 ] master-port=ether2
set [ find default-name=ether4 ] master-port=ether2
set [ find default-name=ether5 ] master-port=ether2
/interface vlan
add interface=ether2 name=ether2.vlan12 vlan-id=12
add interface=ether2 name=ether2.vlan19 vlan-id=19
add interface=ether2 name=ether2.vlan20 vlan-id=20
add interface=ether2 name=ether2.vlan24 vlan-id=24
add interface=ether2 name=ether2.vlan44 vlan-id=44
add interface=ether2 name=ether2.vlan58 vlan-id=58
/interface ethernet switch port
set 2 vlan-mode=secure
set 3 vlan-mode=secure
set 4 default-vlan-id=58 vlan-header=always-strip vlan-mode=secure
set 5 default-vlan-id=58 vlan-header=always-strip vlan-mode=secure
/interface ethernet switch vlan
add independent-learning=no ports=switch1-cpu,ether2,ether3 switch=switch1 vlan-id=44
add independent-learning=no ports=switch1-cpu,ether2,ether3,ether4,ether5 switch=switch1 vlan-id=58
add independent-learning=no ports=switch1-cpu,ether2 switch=switch1 vlan-id=20
add independent-learning=no ports=switch1-cpu,ether3 switch=switch1 vlan-id=19
add independent-learning=no ports=switch1-cpu,ether3 switch=switch1 vlan-id=12
add independent-learning=no ports=switch1-cpu,ether2 switch=switch1 vlan-id=24
Good evening,After upgrade to 6.41RC38, WAP R-2nD processor 100%, self nonstop reboot the system. I used Netinstall to run it.
The others Roterboard are work ok
Can confirm this, same new WAP LTE constant reboots, Critical process died, etc in logs, works fine with older version.Hello, after upgrading RBwAPR-2nD & R11e-LTE to version 6.41rc38, I received a critical error after which the router has been permanently rebooting.
if you want a relative version older than that, you need to log in with a static IP address, quickly roll over the main package, and quickly downgrade, or use netsintall
p.s. firmware version : 3.39.
Does upgrade to firmware up to version 3.41, does the RC start up normally?
What about configurations like mentioned in posting #275 in this topic? Are they supported now?What's new in 6.41rc44 (2017-Oct-11 08:21):
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
/interface bridge port set 0 frame-types=
FrameTypes ::= admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged
Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Specifying our own host instead of 8.8.8.8 and cloud.mikrotik.com, may be usefully in the future.Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?
Does in any way affect the functionality of other features in ROS?
My understanding is it will populate the interface lists you specify with the actual interfaces. Those lists can then be used in firewall filter, NAT, etc.Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?
Yes that would actually be cool IMHO.Specifying our own host instead of 8.8.8.8 and cloud.mikrotik.com, may be usefully in the future.Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?
Does in any way affect the functionality of other features in ROS?
Thank you!
Is the test IPv6 compliant. It needs to be. The address 8.8.8.8 is an IPv4 static, fail. The DNS name cloud.mikrotik.com only has an A record.!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
The defconf already changed in version 6.40! It now uses the "WAN" interface list in the firewall instead of ether1.My understanding is it will populate the interface lists you specify with the actual interfaces. Those lists can then be used in firewall filter, NAT, etc.Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?
I'd also expect this feature to be used in the defconf, but we'd better wait for an official announcement.
Well that setting is not so important, I think. I probably unchecked it once because it would be like the switches I am accustomed with, and then just copied the same setting over and over.Fairly in depth post, to highlight a few things (community and strods correct me if I'm wrong).
The independent learning = no option doesn't exist anymore. You're going to get independent MAC databases per VLAN. I'm curious as to why you weren't doing that before, was it a hardware limitation?
Are you sure? I do not yet see the option to restrict certain tagged VLANs to certain ports. And what about tagging untagged frames with a certain VLAN tag?Frame tagging exists in the implementation:
I'd argue that setting a PVID and "admit-only-untagged-and-priority-tagged" is better than VLAN mode secure and always-strip.Code: Select all/interface bridge port set 0 frame-types= FrameTypes ::= admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged
The rest of the configuration is just basic VLAN configuration which is well supported.
Well it hopefully will not be very different between models that have a switch chip so I could do some experiments on a RB750.The only two points I personally can't speak for is how well the automatic conversion will go during the upgrade and the state of each of those features on the RB2011. I don't own that hardware.
Normally there is a local network with DHCP service on port 10 for emergency maintenance and of course these routers also have a serial port, but unfortunately they are located on sites all over the country that have limited access. We will clearly have to be very careful when updating to 6.41Personally, I'd make sure I have a back-door after the upgrade. Maybe take a port out of the "switch-chip" by removing master-port and set it up as a routed interface that you can plug a laptop into and easily get access to the device.
Changing the hosts is not just useful, it's a requirement. Just imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!Specifying our own host instead of 8.8.8.8 and cloud.mikrotik.com, may be usefully in the future.Is this feature feature optional if someone does not want their router to contact cloud.mikrotik.com every minute?!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Is it just cosmetic (ie: "this interface is 'WAN' just FYI") or is it actually used somewhere (ie: in firewall rules as an interface list) ?
Does in any way affect the functionality of other features in ROS?
Thank you!
ports still will be 'WAN', so nothing terrible should happenJust imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
Opposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.ports still will be 'WAN', so nothing terrible should happenJust imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
PVID = Default VLAN (Primary VLAN ID).Well that setting is not so important, I think. I probably unchecked it once because it would be like the switches I am accustomed with, and then just copied the same setting over and over.Fairly in depth post, to highlight a few things (community and strods correct me if I'm wrong).
The independent learning = no option doesn't exist anymore. You're going to get independent MAC databases per VLAN. I'm curious as to why you weren't doing that before, was it a hardware limitation?Are you sure? I do not yet see the option to restrict certain tagged VLANs to certain ports. And what about tagging untagged frames with a certain VLAN tag?Frame tagging exists in the implementation:
I'd argue that setting a PVID and "admit-only-untagged-and-priority-tagged" is better than VLAN mode secure and always-strip.Code: Select all/interface bridge port set 0 frame-types= FrameTypes ::= admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged
The rest of the configuration is just basic VLAN configuration which is well supported.
My config does not use the untagged VLAN at the CPU port, but it does have untagged external ports. Those have to be in some VLAN.
Now, the switch easily manages that with the default-vlan-id=xx vlan-header=always-strip setting, but can the bridge do the same thing? And will it
be hardware accellerated? (I do not want traffic between an untagged port and the tagged VLAN with the same ID on another port to be CPU-bridged)Well it hopefully will not be very different between models that have a switch chip so I could do some experiments on a RB750.The only two points I personally can't speak for is how well the automatic conversion will go during the upgrade and the state of each of those features on the RB2011. I don't own that hardware.Normally there is a local network with DHCP service on port 10 for emergency maintenance and of course these routers also have a serial port, but unfortunately they are located on sites all over the country that have limited access. We will clearly have to be very careful when updating to 6.41Personally, I'd make sure I have a back-door after the upgrade. Maybe take a port out of the "switch-chip" by removing master-port and set it up as a routed interface that you can plug a laptop into and easily get access to the device.
Hmm.. Why do you guys think that "detect-internet" feature will do ANY of that?...Opposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.ports still will be 'WAN', so nothing terrible should happenJust imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
Dumb feature.
It's like VTP, was great on the drawing board and then it was used to wipe peoples VLAN databases. It took a few years but now Cisco disavows that feature.
/interface detect-internet state
The magic is in the other settings:Hmm.. Why do you guys think that "detect-internet" feature will do ANY of that?...Opposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.ports still will be 'WAN', so nothing terrible should happenJust imagine, you can DDoS cloud.mikrotik.com and every router using this feature goes offline!
Dumb feature.
It's like VTP, was great on the drawing board and then it was used to wipe peoples VLAN databases. It took a few years but now Cisco disavows that feature.
What I'm getting from wiki page, it's just an informational feature: you typeand you get some info, that this feature gathered..Code: Select all/interface detect-internet state
[admin@211-rtr1] > interface detect-internet set
Change properties of one or several items.
detect-interface-list --
internet-interface-list --
lan-interface-list --
wan-interface-list --
My understanding is detect-internet is aimed to be used on home-users' routers, which are definitely not supposed to be running any of the dynamic routing protocols (and are not by default). Honestly, I don't see anything wrong with it. Much better to have all ports protected, and treat some of them as WAN-facing (and others as LAN-facing) when certain criteria is met, than exposing your router to the DNS amplification attacks by simply adding PPPoE interface without also modifying the existing (default) firewall rules (a common problem that multiple people complained about up until recently).Opposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.
Ok, that sounds good. From earlier discussion I got the impression that from now on the bridge would be one big VLAN-transparent thing, whereas in my existing practice (not the above example) I would normally put VLAN subinterfaces on ports and make the subinterfaces part of a bridge, rather than putting entire ports in the bridge and adding VLAN subinterfaces to the bridge.PVID = Default VLAN (Primary VLAN ID).
So you can accomplish an untagged port by changing the PVID of a bridge port to whatever VLAN ID you need. You also have the /interface bridge vlan table. In that table you specify which ports have a VLAN tagged or untagged. So like secure mode, you set admit-only-tagged-frames and then only add that bridge port to the VLANs tagged lists that you want.
I enabled the detection for "all" interfaces on a CHR test system that has 2 ethernet interfaces that both have internet connectivity,!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
Another issue: although the interfaces have been setup with static addresses, after enabling this featureI enabled the detection for "all" interfaces on a CHR test system that has 2 ethernet interfaces!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
so, some peering partner injects a route to block himself? it's either bad or dumb peering partnerOpposite, inject a route to 8.8.8.8 into a dynamic protocol running on someones environment that relies on this feature. It'll toggle the interface to WAN, apply security policies, likely dropping all traffic until detect-interface flaps back to LAN. Then it flaps to WAN when it relearns the route and flap and flap and flap.
/interface vlan
add interface="WLAN1" name="WLAN1 VLAN1002" vlan-id=1002
add interface="WLAN1" name="WLAN1 VLAN3" vlan-id=3
/ip address
add address=192.168.88.3/24 interface="WLAN1 VLAN1002" network=192.168.88.0
add address=192.168.3.3/24 interface="WLAN1 VLAN3" network=192.168.3.0
/interface vlan
add interface="P05 Trunk R2" name="P05 R2 VLAN3" vlan-id=3
add interface="P05 Trunk R2" name="P05 R2 VLAN1002" vlan-id=1002
add interface="P05 Trunk R2" name="P05 R2 VLAN1013" vlan-id=1013
/ip address
add address=192.168.88.1/24 interface="P05 R2 VLAN1002" network=192.168.88.0
add address=192.168.89.1/24 interface="P05 R2 VLAN1013" network=192.168.89.0
add address=192.168.3.1/24 interface="P05 R2 VLAN3" network=192.168.3.0
/interface vlan
add interface="P2 Trunk R1" name="P2 R1 VLAN1002" vlan-id=1002
add interface="P2 Trunk R1" name="P2 R1 VLAN1013" vlan-id=1013
add interface="P2 Trunk R1" name="P2 R1 VLAN3" vlan-id=3
/interface bridge
add fast-forward=no igmp-snooping=no name="Bridge one4all" protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge="Bridge one4all" ingress-filtering=yes interface="P3" pvid=3
add bridge="Bridge one4all" interface="WLAN2 AP" pvid=3
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged interface="WLAN3 Bridge"
add bridge="Bridge one4all" interface="P2 R1 VLAN1002" pvid=1002
add bridge="Bridge one4all" interface="P2 R1 VLAN3" pvid=3
/interface bridge vlan
add bridge="Bridge one4all" tagged="WLAN3 Bridge" vlan-ids=3
add bridge="Bridge one4all" tagged="WLAN3 Bridge" vlan-ids=1002
/ip address
add address=192.168.89.2/24 interface="P2 R1 VLAN1013" network=192.168.89.0
add address=192.168.3.2/24 interface="P2 R1 VLAN3" network=192.168.3.0
/interface vlan
add interface="P2 Trunk R1" name="P2 R1 VLAN1013" vlan-id=1013
/interface bridge
add fast-forward=no igmp-snooping=no name="Bridge one4all" protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged ingress-filtering=yes interface="P2 Trunk R1"
add bridge="Bridge one4all" ingress-filtering=yes interface="P3" pvid=3
add bridge="Bridge one4all" interface="WLAN2 AP" pvid=3
add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged interface="WLAN3 Bridge"
/interface bridge vlan
add bridge="Bridge one4all" tagged="WLAN3 Bridge,P2 Trunk R1" vlan-ids=3
add bridge="Bridge one4all" tagged="WLAN3 Bridge,P2 Trunk R1" vlan-ids=1002
Long story short, read the bridge wiki page.I am stuck with new bridge implementation using VLAN's either. What I want to accomplish is to pass tagged traffic through the router while reaching the router through the same VLAN.
I am using RB2011's and a RB951G with v.6.41RC44.
R1 is connected via cable to R2. R2 is connected via wireless bridge to R3. I need connection from R1 to R2 on VLAN's 3 and 1013 and from R1 to R3 on VLAN's 3 and 1002.
R3 is configured as station bridge with VLAN's 3 and 1002. Both VLAN's are terminated with IP-Adresses at R3.Code: Select all/interface vlan add interface="WLAN1" name="WLAN1 VLAN1002" vlan-id=1002 add interface="WLAN1" name="WLAN1 VLAN3" vlan-id=3 /ip address add address=192.168.88.3/24 interface="WLAN1 VLAN1002" network=192.168.88.0 add address=192.168.3.3/24 interface="WLAN1 VLAN3" network=192.168.3.0
I can connect to both VLAN's from R1 but not from R2.
R1 is configured the same way using VLAN-interfaces.I can connect R3 from R1 on both VLAN's. Connection to R2 works only on VLAN1013 as this interface is not part of the bridge. VLAN1002 has no IP on R2.Code: Select all/interface vlan add interface="P05 Trunk R2" name="P05 R2 VLAN3" vlan-id=3 add interface="P05 Trunk R2" name="P05 R2 VLAN1002" vlan-id=1002 add interface="P05 Trunk R2" name="P05 R2 VLAN1013" vlan-id=1013 /ip address add address=192.168.88.1/24 interface="P05 R2 VLAN1002" network=192.168.88.0 add address=192.168.89.1/24 interface="P05 R2 VLAN1013" network=192.168.89.0 add address=192.168.3.1/24 interface="P05 R2 VLAN3" network=192.168.3.0
R2 is where I get stuck. I am trying to use a single bridge on this one as I am into using R2 as a CAP with local forwarding. So no parent VLAN interfaces will be possible.
Actually forwarding tagged traffic through R2 and connection to a Client physically connected to R2 (VLAN3) works fine.
But how do I reach R2 itself on VLAN3 ?
<1> If I use VLAN interfaces on Trunk port and bridge VLAN inferface I can not connect.<2> I tried it without VLAN inferfaces but I don't see any possibility to reach R2 then.Code: Select all/interface vlan add interface="P2 Trunk R1" name="P2 R1 VLAN1002" vlan-id=1002 add interface="P2 Trunk R1" name="P2 R1 VLAN1013" vlan-id=1013 add interface="P2 Trunk R1" name="P2 R1 VLAN3" vlan-id=3 /interface bridge add fast-forward=no igmp-snooping=no name="Bridge one4all" protocol-mode=none vlan-filtering=yes /interface bridge port add bridge="Bridge one4all" ingress-filtering=yes interface="P3" pvid=3 add bridge="Bridge one4all" interface="WLAN2 AP" pvid=3 add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged interface="WLAN3 Bridge" add bridge="Bridge one4all" interface="P2 R1 VLAN1002" pvid=1002 add bridge="Bridge one4all" interface="P2 R1 VLAN3" pvid=3 /interface bridge vlan add bridge="Bridge one4all" tagged="WLAN3 Bridge" vlan-ids=3 add bridge="Bridge one4all" tagged="WLAN3 Bridge" vlan-ids=1002 /ip address add address=192.168.89.2/24 interface="P2 R1 VLAN1013" network=192.168.89.0 add address=192.168.3.2/24 interface="P2 R1 VLAN3" network=192.168.3.0
Either way I can connect to R3 on both VLAN's and to a Client physically connected to R2 (VLAN3).Code: Select all/interface vlan add interface="P2 Trunk R1" name="P2 R1 VLAN1013" vlan-id=1013 /interface bridge add fast-forward=no igmp-snooping=no name="Bridge one4all" protocol-mode=none vlan-filtering=yes /interface bridge port add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged ingress-filtering=yes interface="P2 Trunk R1" add bridge="Bridge one4all" ingress-filtering=yes interface="P3" pvid=3 add bridge="Bridge one4all" interface="WLAN2 AP" pvid=3 add bridge="Bridge one4all" frame-types=admit-only-vlan-tagged interface="WLAN3 Bridge" /interface bridge vlan add bridge="Bridge one4all" tagged="WLAN3 Bridge,P2 Trunk R1" vlan-ids=3 add bridge="Bridge one4all" tagged="WLAN3 Bridge,P2 Trunk R1" vlan-ids=1002
R2 is reachable on VLAN1013, but this interface is not part of the bridge.
How can I reach R2 via VLAN3?!?
Any help is highly appreciated.
I'm blocking the provider port, because of the high number of requests on the WAN port. The provider is very unhappy with this!Another issue: although the interfaces have been setup with static addresses, after enabling this featureI enabled the detection for "all" interfaces on a CHR test system that has 2 ethernet interfaces!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
the router is sending DHCP requests at a rate of 1 per second.
Go to https://mikrotik.com/downloadHow to downgrade to an older rc? I cannot find a download-link.
I would advise keeping the detect-internet feature disabled until this problem is fixed.I'm blocking the provider port, because of the high number of requests on the WAN port. The provider is very unhappy with this!Another issue: although the interfaces have been setup with static addresses, after enabling this feature
the router is sending DHCP requests at a rate of 1 per second.
What should I do?
Based on experience with some previous RouterOS versions, I'd say that hitting the Current update channel and receiving WinBox support for some options are two unrelated things. It's possible that 6.41 becomes current with these options still being CLI-only.when v6.41rc will be as "current" ?
We bought 2 x CRS317-1G-16S+RM and couldn't set up harware vlan via winbox.
/interface add bridge auto-mac=no comment="main bridge" igmp-snooping=no name=bridge vlan-filtering=yes
/interface vlan
add interface=bridge name=bridge-vlan100 vlan-id=100
add interface=bridge name=bridge-vlan200 vlan-id=200
/interface bridge port
add bridge=bridge interface=eth2-PC
add bridge=bridge interface=eth3-notebook pvid=100
/interface bridge vlan
add bridge=bridge tagged=bridge,eth2-PC untagged=eth3-notebook vlan-ids=100
add bridge=bridge tagged=eth2-PC,bridge vlan-ids=200
/interface ethernet switch
port set eth2-PC vlan-mode=check
port set eth3-notebook vlan-mode=check vlan-header=always-strip default-vlan-id=100
vlan add switch=switch1 ports=eth2-PC,eth3-notebook,switch1-cpu vlan-id=100
vlan add switch=switch1 ports=eth2-PC,switch1-cpu vlan-id=200
Per a case I opened with MikroTik support, expect existing hardware features to slowly be turned on in the new environment. That said, any inter-VLAN traffic, traffic from VLAN100 to VLAN200 from a routing perspective will always be done across the CPU. I believe the reference platform they are using for development is the CRS3xx products. I'd expect to see other platforms covered over time. I run a 750Gr3 (hex) to perform inter-VLAN routing and it gets 300mbps+ throughput and has worked fine in my LAN considering everything else is constrained by a much slower Internet connection. Your mileage may very with other platforms and their CPU.Hi,
I am trying to set up VLAN bridge for upstream and access to the router on RB3011 running 6.41rc44 but also offload the switching to the hardware switch.
I am able to successfully do one or the other but if I combine both setups for local pings I get 3 DUPs.
Setup in question:
Main router: 3011 running 6.41.rc44 with PPPoE upstream. For simplicity two LAN ports: eth2-PC trunk port VLANs: 100 and 200, eth3-notebook access port VLAN 100.
Bridge setup:This works but traffic from eth2-PC to eth3-notebook always goes through CPU bridge (hardware offload is disabled as for the vlan-filtering=yes which is not supported on switch chip in 3011.Code: Select all/interface add bridge auto-mac=no comment="main bridge" igmp-snooping=no name=bridge vlan-filtering=yes /interface vlan add interface=bridge name=bridge-vlan100 vlan-id=100 add interface=bridge name=bridge-vlan200 vlan-id=200 /interface bridge port add bridge=bridge interface=eth2-PC add bridge=bridge interface=eth3-notebook pvid=100 /interface bridge vlan add bridge=bridge tagged=bridge,eth2-PC untagged=eth3-notebook vlan-ids=100 add bridge=bridge tagged=eth2-PC,bridge vlan-ids=200
This is true, switch chip in 3011 can't add VLAN tags to packets but it can use 'Default VLAN ID' for access ports.If I add this part of the setup I get 3 DUPs on pings between eth2-PC <-> eth3-notebook and it is generally unstable. This is because the RouterOS disabled hardware offloading and the host table of hardware switch is empty (and stays that way) and then it works as a hub (that is only explanation I have), thus pushing the packets through all connected interfaces.Code: Select all/interface ethernet switch port set eth2-PC vlan-mode=check port set eth3-notebook vlan-mode=check vlan-header=always-strip default-vlan-id=100 vlan add switch=switch1 ports=eth2-PC,eth3-notebook,switch1-cpu vlan-id=100 vlan add switch=switch1 ports=eth2-PC,switch1-cpu vlan-id=200
If I remove swich1-cpu from 'vlan add' statements connection between PC and notebook via VLAN 100 works (no DUPs) and is switched in hardware but packets are still broadcasted on every connected interface (same issue, hw-offload disabled, switch host table not populated). If I also remove VLAN filtering from the software bridge, which makes it enable hw-offload, the switch host table gets populated but then there is no separation in the software bridge.
This setup shows that switch chip in 3011 is able to perform basic VLAN filtering in hardware but using VLAN filtering on bridge makes in unusable (DUPs, loops or no hardware acceleration).
I really hope this can be resolved, this significantly cuts down on capabilities of 3011 which might as well have no VLAN aware switch chip/swich host table at this point.
I know that, but this is VLAN100<->VLAN100 which should be possible to be done in the switch.That said, any inter-VLAN traffic, traffic from VLAN100 to VLAN200 from a routing perspective will always be done across the CPU.
Let's hope in future it will allow to use 3011 switch capabilities with any VLAN.expect existing hardware features to slowly be turned on in the new environment
A "traditional" way in CRS317 not working. Switch menu shown all ports as Unknown.Based on experience with some previous RouterOS versions, I'd say that hitting the Current update channel and receiving WinBox support for some options are two unrelated things. It's possible that 6.41 becomes current with these options still being CLI-only.when v6.41rc will be as "current" ?
We bought 2 x CRS317-1G-16S+RM and couldn't set up harware vlan via winbox.
I'm wondering though, what stops you from staying on 6.40.x or 6.39.x and configuring what you need in a "traditional" way?
I'd have to see your configuration to be certain but it shouldn't be a problem as long as VLAN1 is only untagged or tagged not both on the port. Additionally, VLAN1 either needs to be untagged (default) or tagged for the bridge interface as well.Oh boy - you are right: RTFM!
The bridge itself is kind of an interface. Now everything works.
But I am still curious if I choose the correct way to work with untagged i.e. PVID1-traffic. Both trunk ports have PVID1. The whole configuration works only if I set both trunk ports as tagged in bridge vlan setting for PVID1.
As soon as I set both trunk ports as untagged in bridge vlan settings for PVID1 no connection is possible. This situation persists until I do a reboot or disable and enable the whole bridge. Is this meant to be like this?
this function is not available on winbox yet correct ?go to
/ip neighbor discovery-settings menu
and set discover-interface-list=all
Discovery packets are now sent with source 0.0.0.0 instead of interface address as before. Maybe due to this change?*) discovery - use "/interface list" instead of interface name under neighbour discovery settings;
Put a bridge in your bridge?Has anyone tested ROMON in 6.41rc47?
Seems that is not working.
Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?
Please make a support output file after the crash and send it to support@mikrotik.comI use 2011UiAS-2HnD with firmware 3.41.
After Urgrade to firmware v6.41rc44 and/or v6.41rc47 the router reboots every one to two hours.
in the log I have the following entry:
memory system,info router rebooted
memory system,error,critical router rebooted beause some critical program crashed
I go back to the current firmware 6.40.4.
rosi
and if I need a single service tag on packets ?Put a bridge in your bridge?Has anyone tested ROMON in 6.41rc47?
Seems that is not working.
Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?
I'm doing it. I install v6.41RC47 and wait for the next crash.Please make a support output file after the crash and send it to support@mikrotik.comI use 2011UiAS-2HnD with firmware 3.41.
After Urgrade to firmware v6.41rc44 and/or v6.41rc47 the router reboots every one to two hours.
in the log I have the following entry:
memory system,info router rebooted
memory system,error,critical router rebooted beause some critical program crashed
I go back to the current firmware 6.40.4.
rosi
Please make a support output file after the crash and send it to support@mikrotik.com
And if one do that all qinq switching will get software switched or what?In RouterOS v6.41 everything QinQ related has to configured with bridge "vlan-filtering=no" using VLAN interfaces and their "use-service-tag" option.
Wouldn't it have been in software before? Are their models that supported QinQ in hardware under the switch chip menu?And if one do that all qinq switching will get software switched or what?In RouterOS v6.41 everything QinQ related has to configured with bridge "vlan-filtering=no" using VLAN interfaces and their "use-service-tag" option.
Can you add a signal to the log and to the client when it was disconnected?*) wireless - log "signal-strength" when successfully connected to AP;
Do that for capsman too.Can you add a signal to the log and to the client when it was disconnected?*) wireless - log "signal-strength" when successfully connected to AP;
/interface bridge
add fast-forward=no igmp-snooping=no name=bridge-vlans vlan-filtering=yes
/interface vlan
add interface=bridge-vlans name=vlan40 vlan-id=40
add interface=bridge-vlans name=vlan41 vlan-id=41
add interface=bridge-vlans name=vlan42 vlan-id=42
/interface bridge port
add bridge=bridge-vlans interface=ether1 pvid=40
add bridge=bridge-vlans interface=ether24-Trunk
/interface bridge vlan
add bridge=bridge-vlans tagged="bridge-vlans,ether24-Trunk" vlan-ids=40
add bridge=bridge-vlans tagged="bridge-vlans,ether24-Trunk" vlan-ids=41
add bridge=bridge-vlans tagged="bridge-vlans,ether24-Trunk" vlan-ids=42
/ip address
add address=192.168.40.254/24 interface=vlan40 network=192.168.40.0
add address=192.168.41.254/24 interface=vlan41 network=192.168.41.0
add address=192.168.42.254/24 interface=vlan42 network=192.168.42.0
set name=R1
Yea sure that will work but cant see that that is the correct way to do this as you loose the hardware offload on this type off config.Put a bridge in your bridge?Has anyone tested ROMON in 6.41rc47?
Seems that is not working.
Also, can someone explain how QinQ vlans would be programmed in the new Bridge vlan implementation?
go to
/ip neighbor discovery-settings menu
and set discover-interface-list=all
It will be released when its ready.The support promised the next rc release will have a fix for my crash. That was one and a half week ago...
Will we have a release any time soon?
Hopefully a new RC early next week, but they pretty much shut down development during a MUM, which started Thursday.The support promised the next rc release will have a fix for my crash. That was one and a half week ago...
Will we have a release any time soon?
/inteface bridge vlan (here you define bridge vlan and member ports att taged or untaged. Here tag bridge self to.......Hardware offload for Vlans using the bridge ports on CRS212 does not seem to work?
/interface bridge
add igmp-snooping=no name=bridge1
add igmp-snooping=no name=bridge2
/interface vlan
add interface=sfp10 name=sfp10-vlan100 vlan-id=100
add interface=sfp10 name=sfp10-vlan101 vlan-id=101
/interface bridge port
add bridge=bridge1 interface=sfp2
add bridge=bridge1 interface=sfp10-vlan100
add bridge=bridge2 interface=sfp5
add bridge=bridge interface=sfp10-vlan101
The actual non-vlan members seems to be enabled for the hwoffload, but not the VLANS. Should this be done in another way?
Running 6.41rc47 on CRS212-1G-10S-1S+
/Mikael
do not do this, our system on average 1~5 seconds to process the radius packageWhat's new in 6.41rc50 (2017-Oct-30 10:13):
*) radius - limited RADIUS timeout maximum value to 3 seconds;
stop right there. this stuff above literally translates to wave2, right?What's new in 6.41rc50 (2017-Oct-30 10:13):
*) wireless - new driver with initial support for 160 and 80+80 MHz channel width;
I thought 802.11ac Wave2 was MU-MIMO as well as 160MHz / 80+80MHz channels? And to date, I believe all the the wireless chipsets that Mikrotik has shipped in products are Wave1. But maybe this is a little accidental show-of-hand towards new products, which of course would need software support.stop right there. this stuff above literally translates to wave2, right?
Wave2 you say... You mean like this:
stop right there. this stuff above literally translates to wave2, right?
What's new in 6.41rc50 (2017-Oct-30 10:13):
*) radius - limited RADIUS timeout maximum value to 3 seconds;
do not do this, our system on average 1~5 seconds to process the radius packageWhat's new in 6.41rc50 (2017-Oct-30 10:13):
*) radius - limited RADIUS timeout maximum value to 3 seconds;
please leave this field customizable
What's new in 6.41rc50 (2017-Oct-30 10:13):
*) radius - limited RADIUS timeout maximum value to 3 seconds;
Yup, seems like MT was overstepping. Seems like something that should be a default value adjustment that is still configurable.a very bad idea, this field generally needs to remove the limits, so that I myself can set the desired value, for example, even 15-20 secondsWhat's new in 6.41rc50 (2017-Oct-30 10:13):
*) radius - limited RADIUS timeout maximum value to 3 seconds;
having the same issue on CRS317. i use classic RouterOS vlan trunking on crs317 because i can not pass VLANs to routers with current version of RouterOSHi,
Is it just me or did the new bridge implementation just vanish in 6.41rc50 - On CRS212-1G-10S-1S+ Im back with masterports and no hardware offload in menu?
/Mikael
They've done that already. This was initially implemented in 6.40 (rc36 I believe) and and then pulled for 6.40 stable. I really don't think it will be necessary to that again.Just wanted to tell you guys implementing very good thing, but new RC seems to be very long in development so far. It is not common to see 50 (!) RCs per release (and not yet 6.41 released this far), and this looks like it will be just dangerous to install in into prod for too many changes (beside new bridge implementation).
Would you mind to hear if I ask you to introduce two releases at the end: say, 6.41 with all changes but without new bridge implementation (so new changes will be tested beside all mess that can be involved with new bridging) , and another one, say 6.42 (or 6.411) with just bridge 'revolution'? This appears to be wise to monitor the effect of new bridge implementation without any other changes. Just in case, you know!
+1 we are using OTP that validates a bit slow sometimes we want 10 seconds... Don't do this.do not do this, our system on average 1~5 seconds to process the radius packageWhat's new in 6.41rc50 (2017-Oct-30 10:13):
*) radius - limited RADIUS timeout maximum value to 3 seconds;
please leave this field customizable
Done what? In released version? With no roll back? Hey, you must be kidding me!They've done that already.
They had some of the new bridge code in 6.40rc and reverted it for the final 6.40, then put it back in for 6.41rc. At this point a lot of their new devices are starting to rely on it though.Done what? In released version? With no roll back? Hey, you must be kidding me!They've done that already.
Yes, look at the forum thread for 6.40rc, in 6.40rc36 the new bridge implementation was introduced. It was reverted in 6.40rc41 so that 6.40 could be released to stable without it. We are now in 6.41rc and it is here to stay. In that release you got exactly what you were asking for. The bridge was brought in, you should've installed it, tried out and then when 6.40 went into production you'd get the old master implementation back. The way this particular change works, it's very difficult to keep both implementations in the code base and swap between them especially without introducing new confusion and issues.Done what? In released version? With no roll back? Hey, you must be kidding me!They've done that already.
What I talk about is the we shoudl split new bridge implementation from all these other changes, for good reason: bridge change is BIG one so this alone should be tested very serious. When it comes to big RB-based network, we'd want to check any consequnces and react accordingly. 6.40rc36 introduced h/w bridging but then it was rolled back, so no tests in the wild was done.
6.42 is full of other changes. This is why if you just upgrade RB to 6.42, you'll never know whay caused problem should they arise: new h/w bridge code or any of these changes you can see in the changelog.
And yes, when it comes to upgrade, say, 100 remote devices, I'd prefer to turn on serious new feature one at the time, don't you like this approach?
I do appreciate MT for their passion to create better platform but big changes is something risky, so isolating BIG changes is kind of good idea, I think.
Yes, it has. It happened in 6.41rc47 (see here):Has the routerboot firmware version naming changed in 6.41rc?
!) routerboot - RouterBOOT version numbering system merged with RouterOS;
I'd rather vote for keeping it separate. I believe it's simply safer, and if you have a boot-loop you will at least have an idea of what failed- loader or OS.If routerboot firmware now follows the ROS version, I would very much like it to automatically get upgraded too during the upgrade of ROS.
Or at least give the user an option to do that in one go.
Having to do double reboots on every upgrade would not be very convenient
I know that. I'm awre of new bridge implementation and keep my eyes on it, but you missed the point: when MT ships the release I'd prefer to keep two releases, one with just new bridging, another one with the rest of current changelog but without bridging (or in reversed order, first one with just changes, then with just bridge).Yes, look at the forum thread for 6.40rc, in 6.40rc36 the new bridge implementation was introduced. It was reverted in 6.40rc41 so that 6.40 could be released to stable without it.
Good question. If you look at f/w changelog you'll notice there is not that many changes that affects your device. So apply each firmware upgrade released is an overkill, and should be bound to specific models.For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?
So, is this an updated driver (kernel module) from the ASIC vendor (e.g. Atheros) which has also some bugfixes/features from the vendor?What's new in 6.41rc50 (2017-Oct-30 10:13):
*) wireless - new driver with initial support for 160 and 80+80 MHz channel width;
I'd say we'll when 1) it'll be released and 2) when we'll live with it at least several releases.is the new bridge implementation without issues now?
It does scan but it isn't passive.*) wireless - added passive scan functionality (CLI only);
Any info on this?
MikroTik Support Number: 2017110722001161What's new in 6.41rc50 (2017-Oct-30 10:13):
Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface "master-port" configuration into new bridge configuration, and eliminate "master-port" option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore "master-port" configuration, so use backups to restore configuration on downgrade.
Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.
Changes since previous 6.41rc release:
!) bridge - general implementation of hw-offload bridge (introduced in v6.40rc36);
!) detnet - implemented "/interface detect-internet" feature;
https://wiki.mikrotik.com/wiki/Manual:Detect_internet
*) bridge - set "igmp-snooping=no" by default on new bridges;
*) crs3xx - added ingress/egress rate input limits;
*) dhcp-client - limited DHCP client "default-route-distance" minimal value to 1;
*) dhcp-server - added "option-set" argument (CLI only);
*) discovery - use "/interface list" instead of interface name under neighbor discovery settings;
*) health - fixed bogus voltage readings on CCR1009;
*) ike1 - fixed crash after downgrade if DH groups 19,20,21 were used for phase1;
*) ike1 - fixed crash on xauth if user does not exist;
*) ipv6 - fixed IPv6 addresses constructed from prefix and static address entry;
*) lte - added "/interface lte apn" menu (Passthrough requires reconfiguration);
*) lte - added Passthrough support;
*) lte - fixed user authentication for R11e-LTE when new firmware is used;
*) m11g - improved ethernet performance on high load;
*) netinstall - fixed missing "/flash/etc" on first bootup;
*) quickset - renamed router IP static DNS name to "router.lan"
*) radius - limited RADIUS timeout maximum value to 3 seconds;
*) sms - fixed minor problem for SMS delivery;
*) webfig - added favicon file;
*) webfig - fixed terminal graphic user interface under Safari browser;
*) winbox - do not show unnecessary tabs from "Switch" menu;
*) wireless - new driver with initial support for 160 and 80+80 MHz channel width;
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.
nov/06 18:36:22 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70
nov/06 18:37:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 18:37:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71
nov/06 18:37:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating
nov/06 18:37:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok
nov/06 18:37:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
nov/06 18:51:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 18:51:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60
nov/06 19:04:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout
nov/06 19:04:24 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, group key exchange timeout
nov/06 19:04:39 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -90
nov/06 19:04:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61
nov/06 19:35:22 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65
nov/06 19:35:22 wireless,info E8:DE:27:14:C5:39@wlan1: disconnected, registered to other interface
nov/06 19:54:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout
nov/06 19:54:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
nov/06 19:54:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 19:54:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67
nov/06 20:02:20 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 20:02:20 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -77
nov/06 20:05:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 20:05:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -68
nov/06 20:09:24 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, group key exchange timeout
nov/06 20:09:34 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -80
nov/06 20:09:36 wireless,info AC:18:26:4C:A6:EC@wlan1: reassociating
nov/06 20:09:36 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, ok
nov/06 20:09:36 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -75
nov/06 20:09:41 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, unicast key exchange timeout
nov/06 20:10:00 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -76
nov/06 20:10:15 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 20:10:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71
nov/06 20:10:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 20:10:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64
nov/06 20:10:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received deauth: class 2 frame received (6)
nov/06 20:10:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61
nov/06 20:19:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 20:19:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66
nov/06 20:19:24 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, group key exchange timeout
nov/06 20:19:29 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 20:20:47 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67
nov/06 20:20:50 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -82
nov/06 20:22:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 20:22:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -75
nov/06 20:27:05 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 20:27:11 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63
nov/06 20:27:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 20:27:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60
nov/06 20:29:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout
nov/06 20:29:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67
nov/06 20:31:39 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 20:31:44 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71
nov/06 20:34:24 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, group key exchange timeout
nov/06 20:34:44 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -79
nov/06 20:34:47 wireless,info AC:18:26:4C:A6:EC@wlan1: reassociating
nov/06 20:34:47 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, ok
nov/06 20:34:47 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -84
nov/06 20:34:52 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, unicast key exchange timeout
nov/06 20:35:28 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -76
nov/06 20:36:51 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 20:36:52 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67
nov/06 20:36:57 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating
nov/06 20:36:57 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok
nov/06 20:36:57 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
nov/06 20:39:11 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 20:39:11 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66
nov/06 20:48:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 20:49:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66
nov/06 21:33:26 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating
nov/06 21:33:26 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok
nov/06 21:33:26 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65
nov/06 21:44:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout
nov/06 21:44:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout
nov/06 21:44:27 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -72
nov/06 21:44:27 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -60, wants bridge
nov/06 21:44:31 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating
nov/06 21:44:31 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok
nov/06 21:44:31 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60
nov/06 21:45:54 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 21:45:54 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60
nov/06 21:49:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout
nov/06 21:49:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout
nov/06 21:49:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64
nov/06 21:49:26 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -59, wants bridge
nov/06 21:53:43 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 21:53:44 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60
nov/06 21:57:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 21:57:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66
nov/06 22:01:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 22:01:17 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
nov/06 22:01:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 22:01:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
nov/06 22:04:36 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 22:04:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71
nov/06 22:04:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating
nov/06 22:04:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok
nov/06 22:04:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67
nov/06 22:07:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 22:07:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
nov/06 22:11:45 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 22:11:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71
nov/06 22:11:51 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 22:11:51 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60
nov/06 22:11:51 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received deauth: class 2 frame received (6)
nov/06 22:12:04 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
nov/06 22:19:15 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 22:19:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -59
nov/06 22:19:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 22:19:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60
nov/06 22:31:40 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 22:31:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -75
nov/06 22:39:04 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 22:39:05 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -69
nov/06 22:39:10 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 22:39:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67
nov/06 22:51:22 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 22:51:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67
nov/06 22:59:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout
nov/06 22:59:24 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, group key exchange timeout
nov/06 22:59:40 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -76, wants bridge
nov/06 23:03:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 23:03:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70
nov/06 23:03:29 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 23:03:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61
nov/06 23:12:12 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 23:12:13 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -68
nov/06 23:12:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating
nov/06 23:12:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok
nov/06 23:12:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60
nov/06 23:12:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 23:12:31 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60
nov/06 23:15:43 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -71
nov/06 23:16:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 23:16:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70
nov/06 23:16:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 23:16:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -72
nov/06 23:16:29 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 23:16:48 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
nov/06 23:16:50 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -44
nov/06 23:17:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
nov/06 23:17:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating
nov/06 23:17:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok
nov/06 23:17:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -72
nov/06 23:17:11 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 23:17:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -75
nov/06 23:18:50 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 23:18:56 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66
nov/06 23:19:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 23:19:14 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66
nov/06 23:19:19 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 23:19:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
nov/06 23:19:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66
nov/06 23:20:15 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 23:20:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66
nov/06 23:20:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 23:20:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
nov/06 23:21:08 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 23:21:09 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
nov/06 23:24:49 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 23:24:53 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -52
nov/06 23:24:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61
nov/06 23:25:39 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -64
nov/06 23:28:13 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -52
nov/06 23:28:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 23:28:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64
nov/06 23:28:47 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
nov/06 23:29:04 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -50
nov/06 23:29:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout
nov/06 23:29:24 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, group key exchange timeout
nov/06 23:29:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
nov/06 23:29:36 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 23:29:58 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -69, wants bridge
nov/06 23:30:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70
nov/06 23:30:09 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -60
nov/06 23:30:12 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -79
nov/06 23:30:15 wireless,info AC:18:26:4C:A6:EC@wlan1: reassociating
nov/06 23:30:15 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, ok
nov/06 23:30:15 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -83
nov/06 23:30:17 wireless,info AC:18:26:4C:A6:EC@wlan1: reassociating
nov/06 23:30:17 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, ok
nov/06 23:30:17 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -79
nov/06 23:30:18 wireless,info AC:18:26:4C:A6:EC@wlan1: reassociating
nov/06 23:30:18 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, ok
nov/06 23:30:18 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -82
nov/06 23:30:23 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, unicast key exchange timeout
nov/06 23:30:43 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
nov/06 23:33:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 23:33:59 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64
nov/06 23:34:04 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 23:34:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout
nov/06 23:34:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
nov/06 23:34:29 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -59
nov/06 23:34:40 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -64, wants bridge
nov/06 23:35:01 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -78
nov/06 23:35:06 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, unicast key exchange timeout
nov/06 23:35:33 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -74
nov/06 23:35:34 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, received deauth: class 2 frame received (6)
nov/06 23:38:46 wireless,info AC:18:26:4C:A6:EC@wlan1: connected, signal strength -77
nov/06 23:38:53 wireless,info AC:18:26:4C:A6:EC@wlan1: disconnected, unicast key exchange timeout
nov/06 23:39:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
nov/06 23:40:18 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -64
nov/06 23:40:39 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67
nov/06 23:41:50 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -59
nov/06 23:42:22 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
nov/06 23:42:24 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -50
nov/06 23:43:00 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
nov/06 23:43:13 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64
nov/06 23:44:07 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 23:44:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
nov/06 23:44:30 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71
nov/06 23:45:29 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -64
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -64
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok
nov/06 23:45:49 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -67
nov/06 23:46:01 wireless,info E8:DE:27:14:C5:39@wlan1: connected, signal strength -66
nov/06 23:46:01 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, registered to other interface
nov/06 23:49:29 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 23:49:34 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
nov/06 23:52:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
nov/06 23:53:21 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -45
nov/06 23:54:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
nov/06 23:54:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70
nov/06 23:55:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 23:55:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64
nov/06 23:55:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
nov/06 23:56:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71
nov/06 23:58:28 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -44
nov/06 23:59:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
nov/06 23:59:31 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62
00:02:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:02:47 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66
00:02:53 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
00:02:54 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66
00:04:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:04:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63
00:06:40 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:07:22 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64
00:09:15 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -43
00:09:20 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, unicast key exchange timeout
00:09:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout
00:09:28 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -71, wants bridge
00:10:51 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -46
00:11:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:11:56 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67
00:12:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating
00:12:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok
00:12:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -73
00:12:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
00:12:28 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
00:12:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67
00:13:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:13:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67
00:13:28 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
00:13:59 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:14:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70
00:17:05 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -52
00:17:10 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, unicast key exchange timeout
00:17:19 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:17:44 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -87
00:17:44 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface
00:18:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -76
00:18:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
00:18:20 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71
00:20:29 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62
00:25:26 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3)
00:25:39 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
00:25:47 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -78
00:28:09 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:29:09 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62
00:31:50 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62
00:33:04 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:33:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62
00:34:43 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64
00:36:37 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
00:36:45 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:36:50 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71
00:36:58 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
00:41:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:41:47 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64
00:41:52 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
00:42:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63
00:43:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:43:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67
00:43:59 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62
00:44:06 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -75
00:44:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
00:44:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout
00:44:29 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:44:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70
00:44:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
00:44:42 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -69, wants bridge
00:44:43 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64
00:47:02 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:47:07 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67
00:49:05 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
00:51:33 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:51:39 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62
00:58:36 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63
00:59:20 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
00:59:25 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62
00:59:29 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -79
01:00:36 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
01:04:15 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
01:05:30 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
01:05:31 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -67
01:05:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating
01:05:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok
01:05:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -59
01:09:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
01:09:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61
01:09:51 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66
01:12:10 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
01:12:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64
01:14:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
01:16:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
01:16:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -60
01:16:53 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -65
01:19:15 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
01:19:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout
01:19:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout
01:19:24 wireless,info E8:DE:27:14:C5:39@wlan1: disconnected, group key exchange timeout
01:19:39 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -65, wants bridge
01:19:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64
01:20:00 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65
01:20:16 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -68
01:20:32 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
01:21:10 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66
01:21:15 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
01:21:33 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62
01:24:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
01:26:12 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
01:26:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -61
01:26:48 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64
01:26:58 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62
01:28:41 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
01:31:10 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66
01:31:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
01:32:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -58
01:32:06 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
01:32:33 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63
01:32:36 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
01:32:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: reassociating
01:32:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, ok
01:32:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70
01:32:40 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
01:34:36 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
01:34:37 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
01:35:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
01:35:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -68
01:37:39 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -67
01:39:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
01:39:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
01:39:26 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70
01:40:44 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
01:40:45 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71
01:41:44 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66
01:43:01 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
01:43:39 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
01:43:44 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
01:43:46 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
01:44:02 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71
01:51:20 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63
01:56:28 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
02:03:30 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63
02:07:27 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66
02:08:36 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
02:09:04 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
02:12:32 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64
02:13:26 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
02:13:35 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
02:13:40 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -59
02:16:29 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63
02:21:36 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
02:24:24 wireless,info 10:02:B5:B0:AD:47@wlan2: disconnected, group key exchange timeout
02:28:10 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -69
02:29:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
02:33:33 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66
02:34:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
02:41:05 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
02:41:10 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62
02:41:15 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62
02:44:55 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -63
02:46:23 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
02:47:47 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
02:47:53 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63
02:49:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
02:51:07 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
02:51:08 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -58
02:53:25 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63
02:54:24 wireless,info 00:0F:60:08:1F:5B@wlan1: disconnected, group key exchange timeout
02:54:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout
02:54:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66
02:56:09 wireless,info 00:0F:60:08:1F:5B@wlan1: connected, signal strength -53
02:56:14 wireless,info 00:0F:60:08:1F:5B@wlan1: disconnected, unicast key exchange timeout
02:56:15 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
02:56:38 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70
02:58:35 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
02:59:25 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -66
03:04:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout
03:04:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
03:04:36 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64
03:07:12 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62
03:10:22 wireless,info 00:0F:60:08:1F:5B@wlan1: connected, signal strength -55
03:12:23 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
03:15:39 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64
03:17:00 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
03:17:19 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63
03:22:30 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
03:31:02 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64
03:32:36 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
03:34:45 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62
03:36:05 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -70
03:39:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
03:39:50 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
03:46:38 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64
03:48:09 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
03:50:55 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
03:50:56 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
03:51:43 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64
03:52:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
03:52:48 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64
03:55:40 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
03:55:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63
04:04:20 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -61
04:04:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
04:04:24 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout
04:04:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
04:07:16 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -80
04:09:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
04:09:29 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
04:19:36 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -78
04:19:37 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface
04:28:35 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62
04:33:40 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
04:34:46 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -65
04:40:34 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3)
04:40:37 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -82
04:47:01 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62
04:52:10 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
04:56:33 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -65
05:01:40 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
05:10:05 wireless,info B8:A1:75:48:3C:29@wlan1: connected, signal strength -64
05:10:10 wireless,info B8:A1:75:48:3C:29@wlan1: disconnected, unicast key exchange timeout
05:10:42 wireless,info B8:A1:75:48:3C:29@wlan1: connected, signal strength -76
05:11:48 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -81
05:11:51 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface
05:14:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
05:14:37 wireless,info B8:A1:75:48:3C:29@wlan1: disconnected, received disassoc: sending station leaving (8)
05:14:38 wireless,info B8:A1:75:48:3C:29@wlan1: connected, signal strength -75
05:16:33 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -72
05:16:48 wireless,info B8:A1:75:48:3C:29@wlan1: disconnected, received disassoc: sending station leaving (8)
05:17:48 wireless,info B8:A1:75:48:3C:29@wlan1: connected, signal strength -69
05:17:53 wireless,info B8:A1:75:48:3C:29@wlan1: disconnected, unicast key exchange timeout
05:18:04 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
05:18:25 wireless,info B8:A1:75:48:3C:29@wlan1: connected, signal strength -86
05:19:48 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
05:19:48 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
05:20:17 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3)
05:20:26 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -77
05:22:44 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -63
05:23:35 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -75
05:25:54 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
05:25:54 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -62
05:27:52 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
05:31:33 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -84
05:31:33 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface
05:44:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
05:46:52 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -64
05:48:56 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -64
05:49:54 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3)
05:49:57 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -78
05:50:02 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3)
05:50:09 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -81
05:54:05 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
05:55:14 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
05:56:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -64
05:56:28 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
05:56:39 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -80
05:56:42 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -71
05:56:42 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface
05:56:45 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3)
05:56:47 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
05:56:48 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -78
05:56:49 wireless,info B8:A1:75:48:3C:29@wlan1: disconnected, extensive data loss
05:57:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -74
05:57:05 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
05:57:22 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
05:57:23 wireless,info DC:3A:5E:95:9B:BF@wlan2: connected, signal strength -77
06:01:07 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -78
06:01:07 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface
06:02:37 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -73
06:03:37 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
06:04:01 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -65
06:09:12 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
06:13:16 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62
06:16:31 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3)
06:16:39 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -79
06:17:02 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -73
06:17:03 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface
06:18:00 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -75
06:18:21 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
06:19:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
06:23:34 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -80
06:24:23 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3)
06:24:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
06:24:34 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -72
06:26:38 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, received deauth: sending station leaving (3)
06:26:41 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -83
06:33:36 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -87
06:41:37 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62
06:44:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout
06:44:29 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -65, wants bridge
06:46:41 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
06:49:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
06:49:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout
06:49:26 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -68, wants bridge
06:49:34 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -76
06:54:24 wireless,info 00:0F:60:08:1F:5B@wlan1: disconnected, group key exchange timeout
06:54:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
06:54:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout
06:54:28 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -67, wants bridge
06:54:54 wireless,info 00:0F:60:08:1F:5B@wlan1: connected, signal strength -55
07:00:00 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -72
07:00:32 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
07:00:33 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -73
07:01:08 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
07:01:21 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -79
07:08:28 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -62
07:09:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
07:09:25 wireless,info E8:DE:27:14:C5:39@wlan2: reassociating
07:09:25 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, ok
07:09:25 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65
07:11:52 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -70
07:13:59 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, received disassoc: sending station leaving (8)
07:16:38 wireless,info 68:C4:4D:EE:F0:DF@wlan1: connected, signal strength -84
07:16:41 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, registered to other interface
07:16:57 wireless,info 68:C4:4D:EE:F0:DF@wlan2: connected, signal strength -87
07:16:57 wireless,info 68:C4:4D:EE:F0:DF@wlan1: disconnected, registered to other interface
07:17:05 wireless,info 68:C4:4D:EE:F0:DF@wlan2: disconnected, extensive data loss
07:19:24 wireless,info 00:0F:60:08:1F:5B@wlan1: disconnected, group key exchange timeout
07:19:24 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout
07:19:24 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
07:19:26 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -58
07:19:26 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -66, wants bridge
07:19:56 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
07:19:58 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -55
07:20:10 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
07:20:18 wireless,info 00:0F:60:08:1F:5B@wlan1: connected, signal strength -54
07:20:55 wireless,info 2C:F0:A2:1F:56:4B@wlan2: connected, signal strength -61
07:24:24 wireless,info 2C:F0:A2:1F:56:4B@wlan2: disconnected, group key exchange timeout
08:52:30 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -65
08:53:11 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, received deauth: sending station leaving (3)
08:54:58 wireless,info 2C:F0:A2:1F:56:4B@wlan1: connected, signal strength -79
08:56:18 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -76
08:56:51 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, extensive data loss
08:57:22 wireless,info 10:02:B5:B0:AD:47@wlan2: connected, signal strength -70
08:57:30 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -62
09:39:09 system,info verified routeros-mipsbe-6.41rc52.npk
09:39:09 system,info installed routeros-mipsbe-6.41rc52
09:39:09 system,info router rebooted
09:39:12 bridge,info "br1" mac address changed to F6:20:18:E8:60:F6
09:39:15 wireless,info F4:30:B9:B3:0F:ED@wlan1: connected, signal strength -59
09:39:16 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66
09:39:16 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -69, wants bridge
09:39:21 wireless,info 00:0F:60:08:1F:5B@wlan1: connected, signal strength -54
09:39:23 wireless,info B8:3E:59:B3:9B:0B@wlan2: connected, signal strength -46
09:39:24 interface,info ether1 link up (speed 1G, full duplex)
09:39:33 wireless,info E8:DE:27:14:C5:39@wlan2: connected, signal strength -65
09:40:00 wireless,info E8:DE:27:14:C5:39@wlan2: disconnected, received deauth: sending station leaving (3)
09:40:11 system,info,account user admin logged in from 10.211.11.11 via ssh
09:40:13 wireless,info 10:02:B5:B0:AD:47@wlan2: connected, signal strength -70
09:41:47 system,info cloud change time Nov/07/2017-09:40:30 => Nov/07/2017-09:41:47
09:43:21 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, received disassoc: sending station leaving (8)
09:43:27 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -70
09:44:37 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -68
09:44:42 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, unicast key exchange timeout
09:44:46 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -70
09:44:51 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, unicast key exchange timeout
09:45:13 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -73
09:45:36 wireless,info F4:30:B9:B3:0F:ED@wlan1: disconnected, group key exchange timeout
09:45:36 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, group key exchange timeout
09:45:36 wireless,info 6C:3B:6B:EB:59:99@wlan1: disconnected, group key exchange timeout
09:45:36 wireless,info 84:10:0D:B0:12:8F@wlan1: disconnected, group key exchange timeout
09:45:51 wireless,info 6C:3B:6B:EB:59:99@wlan1: connected, signal strength -69, wants bridge
09:45:55 wireless,info 84:10:0D:B0:12:8F@wlan1: connected, signal strength -79
09:46:00 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -66
09:46:05 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
09:46:46 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63
09:46:51 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
09:48:18 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -72
09:48:23 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
09:49:04 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
09:49:09 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
09:49:22 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -63
09:49:27 wireless,info DC:3A:5E:95:9B:BF@wlan1: disconnected, unicast key exchange timeout
09:49:41 wireless,info DC:3A:5E:95:9B:BF@wlan1: connected, signal strength -65
RouterOS 6.41rc52 ships with firmware version 6.41rc50... So looks like nothing changed except the version bump.For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?
Or people had other RADIUS services (devices) connecting to it. You know, because that never happens. #genius. Depending on the IOS version Cisco will timeout at 5 seconds. MikroTik employees. If you are confronted with the choice between allowing something to be configurable with a sensible default vs a static unchanging value always choose configurable.RADIUS timeout value was reduced due to the fact that there is no point of higher value than 3s. Neither of RouterOS RADIUS services would wait more than 3s for a reply from RADIUS server. If you had value higher than 3 seconds, then either configuration will work with timeout set to 3s or it was not working properly even with higher value.
Anyway, RADIUS timeout (even set to 3s) is too high and requires debugging and network improvements since router should not wait so long for a reply from RADIUS server.
I've upgraded a mAP-Lite from 6.40.4 to 6.41rc52.RouterOS 6.41rc52 ships with firmware version 6.41rc50... So looks like nothing changed except the version bump.For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?
Oh, funny... I have a system that is running RouterOS 6.41rc52, with current and upgrade firmware at 6.41rc50. Started a firmware upgrade, after a reboot I can confirm your results.I've upgraded a mAP-Lite from 6.40.4 to 6.41rc52.RouterOS 6.41rc52 ships with firmware version 6.41rc50... So looks like nothing changed except the version bump.For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?
The firmware prior to the upgrade was on v3.41.
So it showed me that the upgrade firmware is 6.41rc50.
But after I upgraded the firmware I got this:
Current Firmware: 6.41rc52
Upgrade Firmware: 6.41rc50
http://prntscr.com/h7w38h
Forum police @andirys will probably ask you to post in feature request.When do we get LACP with Hardware offload in this new bridge implementation in routeros on switch devices such as CRS326-24G-2S+ and CRS-317-1G-16s+
Creating a bond and attaching it to the bride is done in software now and good know the cpu's in the switches is weak as hell.
How this works? Firewall is not using included list.*) interface - added option to join and exclude "/interface list" from one and another;
The default firewall is using lists now. When you have upgraded from versions previous to 6.40 all the time and neverHow this works? Firewall is not using included list.*) interface - added option to join and exclude "/interface list" from one and another;
you need to add your bridge interface to tagged ports.I tryed to configure VLANs using the bridge hw offloading feature (CRS326). Basically:
/interface bridge port
add bridge=bridge interface=ether2 pvid=200
...
add bridge=bridge tagged=... untagged=ether02,.. vlan-ids=200
...
/interface bridge set bridge vlan-filtering=yes
I stuck in two tasks.
A) How to I secure the ports like "/interface ethernet switch port set ether3 vlan-mode=secure vlan-header=always-strip" on https://wiki.mikrotik.com/wiki/Manual:S ... Offloading?
I tried
/interface bridge port add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether03 pvid=200
but I do not really understand if it does what I want.
B) I cannot access the RouterOS using a VLAN port. But I didn't found, how to configure VLAN for the switch host port?
Devices in the Wireless Wire kit come with Level 3 licenses - will it work with more than one client, or is it necessary to buy a Level 4 license to test 60GHz PtMP?*) w60g - general work on PtMP implementation for 60 GHz connections;
Same here, 951g2hndI've upgraded a mAP-Lite from 6.40.4 to 6.41rc52.RouterOS 6.41rc52 ships with firmware version 6.41rc50... So looks like nothing changed except the version bump.For me the more important question about boot firmware is: Will the firmware version change with every RouterOS release even if no changes are made? Suppose you installed RouterOS 6.41, then upgraded firmware to 6.41. RouterOS 6.41.1 ships with no changes to the firmware. Is the available firmware version 6.41 or 6.41.1?
The firmware prior to the upgrade was on v3.41.
So it showed me that the upgrade firmware is 6.41rc50.
But after I upgraded the firmware I got this:
Current Firmware: 6.41rc52
Upgrade Firmware: 6.41rc50
http://prntscr.com/h7w38h
routerboard: yes
model: 951G-2HnD
serial-number: 4F4********
firmware-type: ar9344
factory-firmware: 3.10
current-firmware: 6.41rc52
upgrade-firmware: 6.41rc50
Firmware type: ar7240
Factory firmware: 3.02
Current firmware: 3.33
Update firmware:
Possibly a read-only property "upgrade-available" is the easiest way to solve this?Oh, funny... I have a system that is running RouterOS 6.41rc52, with current and upgrade firmware at 6.41rc50. Started a firmware upgrade, after a reboot I can confirm your results.
Well, that will make my upgrade notification scripts go crazy... :-p
This makes no sense to me whatsoever. We have had it happen several times (in a particular scenario documented further below) where we had the timeout at first set to 3000 ms and the customer could not connect (due to the unusually high latency for bidirectional satellite Internet), but immediately after increasing the timeout, the customer connected successfully (after repeated automated connection attempts up until the instant of change). You are saying this is a coincidence? It seems really hard to believe given how many times it failed before making the change (several hours) and how immediately the change corrected the issue (after hours of trying to connect every minute and failing, the first connection after the change (30 seconds later) was successful).RADIUS timeout value was reduced due to the fact that there is no point of higher value than 3s. Neither of RouterOS RADIUS services would wait more than 3s for a reply from RADIUS server. If you had value higher than 3 seconds, then either configuration will work with timeout set to 3s or it was not working properly even with higher value.
Anyway, RADIUS timeout (even set to 3s) is too high and requires debugging and network improvements since router should not wait so long for a reply from RADIUS server.
It is not just one location - we have 15 such locations. We would need 15 RADIUS servers. These locations have no air conditioning and so the internal shelter goes up to 40C in the summer and down to -30C in the winter. Local RADIUS server is NOT a good idea.I would say your network could be redesigned so that the RADIUS requests do not have to go over the satellite. Apparently you are using the MikroTik as a local access concentrator for several customers that then use the same satellite link. It would help a lot to have the RADIUS service local to that location. Of course usermanager is very limited, but a small computer with a RADIUS server and maybe some other services for the customer (a webproxy, a local webserver, VoIP PBX, etc) could help the customers living with this high-latency link.
Ignoring the part about RADIUS taking more than 3 seconds being unacceptable for the time being, as described by strods, this change should not have resulted in a regression of functionality, as the RADIUS client inside routerOS was not honoring timeouts above 3 seconds to begin with. Based on what mducharme says above, this does not appear to be the case.RADIUS timeout value was reduced due to the fact that there is no point of higher value than 3s. Neither of RouterOS RADIUS services would wait more than 3s for a reply from RADIUS server. If you had value higher than 3 seconds, then either configuration will work with timeout set to 3s or it was not working properly even with higher value.
Anyway, RADIUS timeout (even set to 3s) is too high and requires debugging and network improvements since router should not wait so long for a reply from RADIUS server.
Regarding all this with firmware, i have found this in changelog in RC channel:I have installed it on an old RB750 I use for some test.
It shows:I.e. there is nothing after upgrade firmware and the upgrade button does nothing (no log entry).Code: Select allFirmware type: ar7240 Factory firmware: 3.02 Current firmware: 3.33 Update firmware:
Edit: I installed 6.40.5, upgraded the firmware to 3.41 from there, then went back to 6.41 (2 partitions on the router...) and
the issue is still the same.
Exactly, my own observations of the behavior of earlier versions do not jibe with what strods claims to be the case. It seems extremely unlikely that it was coincidental that the issue vanished when I made the change, given the circumstances.He reports that he's seeing different behavior with the timeout hard-set to 3sec, when compared to the 6sec available before. This is a regression in functionality and directly contrary to the information given by MT (strods) - in short, this is a bug. Either MT themselves are incorrect about the behaviour of the client when given timeouts above 3s (and mducharme's 6s timeout on older FW versions was making a difference), or something else has changed that otherwise breaks his admittedly unusual but completely valid configuration.
No I haven't, only because I would have to upgrade to 6.41 at one of those satellite sites (15 of our 45 sites are connected via satellite). However I don't need a test to tell me what effect limiting the maximum value will have when we are currently using 6000 ms, and given my previous experiences. We could maybe get by with 5000ms, possibly even 4000ms, but if the RADIUS server thinks the customer is still logged in, it will only authenticate in 3000ms if the stars are in perfect alignment due to the extra time required to pull the list of logged in customers. Due to the power requirements of the satellite amplifiers they cannot be connected to the UPS, so when the power goes down at the site (some sites are on unreliable diesel) the satellite feed goes down immediately. If customers log off during this time (common b/c they usually lose power as well), the RADIUS disconnect notification doesn't make it to the RADIUS server because, with the satellite link down, there is no way for the packet to reach its destination. When the site comes back up again, the RADIUS server sees the customers trying to log in again and it thinks they are already logged in, so before it sends the 'accept' or 'reject' it has to go to the router and check to see if they actually are still logged in. Customers sometimes share their PPPoE credentials with friends to try to give them free service, so this check is necessary to protect against that.mducharme: Have you opened a support ticket for this regression & provided supout.rifs etc? This isn't an official support channel, and it sounds like you should be talking to support if you aren't already.
You have 15 sites of a problematic type for which it costs $1000 to make a support visit and you don't have a way to test a similar site from home (a subscription to the same satellite service)?No I haven't, only because I would have to upgrade to 6.41 at one of those satellite sites (15 of our 45 sites are connected via satellite).
The dishes are 2.4 or 3.8 meters, so they are big (larger than a home satellite service). It is not easy like putting up an Xplornet dish on a home, these are very big and very heavy, they cannot be roof or wall mounted, unless maybe the roof was concrete and very thick, able to support the weight. So the dish would generally need to be on the ground with a concrete pad for stability and fencing to avoid people standing in front of the beam. Even if we had a place to install such a thing in our downtown urban office building, each dish has its own upload channel, so there would need to be one assigned to a "test dish" but all are in use since actual sites are priority. Therefore to operate a test dish with no channels we would need to shut down one of the 15 sites to free up a channel to bring up a test dish. It would be great to have a test system, it would make certain things easier, but it is just not feasible for all those reasons, so we have lived without it.You have 15 sites of a problematic type for which it costs $1000 to make a support visit and you don't have a way to test a similar site from home (a subscription to the same satellite service)?
Really? It all does not seem very professional...
Don't need a satellite dish to emulate the behaviour of a typical satellite link:You have 15 sites of a problematic type for which it costs $1000 to make a support visit and you don't have a way to test a similar site from home (a subscription to the same satellite service)?
125ms need to reach satellite and 125ms to reach earth. Why you need HUGE timeout ? You bounce signal multiple times to orbit and back?We could maybe get by with 5000ms, possibly even 4000ms, but if the RADIUS server thinks the customer is still logged in, it will only authenticate in 3000ms if the stars are in perfect alignment due to the extra time required to pull the list of logged in customers.
You need only ONE snmpget to understand what happens with equipment and connected users - check sysUpTimeInstance (.1.3.6.1.2.1.1.3.0) and if it goes back - assume "power lost, all users disconnected" and drop it manually in radius. it's not rocket science.Due to the power requirements of the satellite amplifiers they cannot be connected to the UPS, so when the power goes down at the site (some sites are on unreliable diesel) the satellite feed goes down immediately. If customers log off during this time (common b/c they usually lose power as well), the RADIUS disconnect notification doesn't make it to the RADIUS server because, with the satellite link down, there is no way for the packet to reach its destination. When the site comes back up again, the RADIUS server sees the customers trying to log in again and it thinks they are already logged in, so before it sends the 'accept' or 'reject' it has to go to the router and check to see if they actually are still logged in. Customers sometimes share their PPPoE credentials with friends to try to give them free service, so this check is necessary to protect against that.
We try to centralize as much as possible and minimize the equipment at the site, less equipment means less that can break - it is cheaper for me to fly to Hawaii than to go to some of our sites. The central RADIUS server is a necessity for us, and it is just not viable to optimize it more than we already have. We have already had to change some FreeRADIUS code to use snmpbulkwalk instead of snmpwalk to avoid needing 25-30 second timeouts, and I do not think we can reduce this any further given our previous efforts to provide QoS to prioritize RADIUS packets.
Ping to the site across the satellite link is at least 600ms round trip, so 300ms each way. I have never seen latency drop below that. You are suggesting that round trip latency should be 250 ms or slightly higher, but that is just not realistic.125ms need to reach satellite and 125ms to reach earth. Why you need HUGE timeout ? You bounce signal multiple times to orbit and back?
That requires extra programming, and won't work in some scenarios. The RADIUS server itself (FreeRADIUS) already has the SNMP check built in to poll the list of interfaces in event that it thinks the customer is already logged in - this did not need to be scripted as it is a built in feature, the RADIUS server does this SNMP check while the NAS is waiting for the 'accept' or 'reject'. What you are describing is an external script that would keep track of the uptime for each router and be able to tell if one went back and just disconnect the sessions for that router. It is certainly possible but such a script would have to be carefully tested. That also wouldn't help with a scenario where the router did not go down but the satellite lost power. A brief power outage would not knock the router offline, so the sysuptime would not go back. Unfortunately this also happens fairly frequently, so a solution that doesn't address this would not help.You need only ONE snmpget to understand what happens with equipment and connected users - check sysUpTimeInstance (.1.3.6.1.2.1.1.3.0) and if it goes back - assume "power lost, all users disconnected" and drop it manually in radius. it's not rocket science.
Sweet. No more Layer 7 for HTTPS blocking*) firewall - added "tls-host" firewall matcher (CLI only);
+1Sweet. No more Layer 7 for HTTPS blocking*) firewall - added "tls-host" firewall matcher (CLI only);
How it works? Which packet matches? Does it support wildcards?
I presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.Sweet. No more Layer 7 for HTTPS blocking*) firewall - added "tls-host" firewall matcher (CLI only);
How it works? Which packet matches? Does it support wildcards?
It could be an iptables module specific to that function instead of abstracting a L7 filter. Like this https://github.com/Lochnair/xt_tlsI presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.Sweet. No more Layer 7 for HTTPS blocking*) firewall - added "tls-host" firewall matcher (CLI only);
How it works? Which packet matches? Does it support wildcards?
Any info about this? passive scan has been implemented for a long time*) wireless - added passive scan option for wireless scan mode;
No need for SNI, CN of certificate is in plaintext whether SNI is used or not.I presume this is just a special case of a Layer 7 with some pre-defined pattern, and only works when SNI is used.Sweet. No more Layer 7 for HTTPS blocking*) firewall - added "tls-host" firewall matcher (CLI only);
How it works? Which packet matches? Does it support wildcards?
It's not clear, from the changelog, but: If I remember it right, Mikrotik didn't support passive scan with 802.11ac, only b, g, n. Maybe this is it, at long last.Any info about this? passive scan has been implemented for a long time*) wireless - added passive scan option for wireless scan mode;
At a guess, its based on xt_tls which can support wildcards, see https://github.com/Lochnair/xt_tlsSweet. No more Layer 7 for HTTPS blocking*) firewall - added "tls-host" firewall matcher (CLI only);
How it works? Which packet matches? Does it support wildcards?
If this is it, then we only now have to wait for spectral scan and power adjustment in 802.11ac and we will be seeing sweet dreams.It's not clear, from the changelog, but: If I remember it right, Mikrotik didn't support passive scan with 802.11ac, only b, g, n. Maybe this is it, at long last.Any info about this? passive scan has been implemented for a long time*) wireless - added passive scan option for wireless scan mode;
nkourtzis wrote:Can it possibly be that we approaching the end of v6 development? Just wondering...