Well, there can be an option to choose the desired behaviour: to leave a running flag no matter what, or to monitor the state of slave interfaces.Bridge always worked that way and if suddenly bridge with inactive (no ports) will not have running flag, it will break all configurations with loopbacks and other configurations where bridge is used as dummy interface.
Re: v6.42.9 [long-term] is released!
Re: v6.42.9 [long-term] is released!
Exactly, that's why I called that an option. Not default oneBridge always worked that way and if suddenly bridge with inactive (no ports) will not have running flag, it will break all configurations with loopbacks and other configurations where bridge is used as dummy interface.
Re: v6.42.9 [long-term] is released!
amazing how launch long-term version and you guys introduce a failure of these.Unfortunately, it looks like default configuration is not properly generated on 6.42.8 and 6.42.9 versions. A workaround is to upgrade your router to the latest stable or testing builds and reset configuration then. We will definitely resolve the issue in the next long-term version. Sorry for any inconvenience.
Re: v6.42.9 [long-term] is released!
I put one bridge on the whole chip, created 2 VLANs with the same subnet, but DHCP does not work for one of them (DHCP server on the bridge).
-
-
vodokotlic
just joined
- Posts: 16
- Joined:
Re: v6.42.9 [long-term] is released!
This is my first version running a new bridge, don't know if it's a known bug.
RB951G-2HnD running as just a Switch/AP (all ethernet+wlan ports under one switch/bridge, no vlans, no nat).
If I change the mac address of an ethernet port while it's a member of a switch/bridge, most of the OS will hang. Switch will continue to pass traffic (on other ports) and the system clock runs but pretty much everything else is frozen.
Device does not respond to /system reboot or reboot via winbox and needs to be power cycled to restore full function. (Crappy situation if the device is on a remote location)
RB951G-2HnD running as just a Switch/AP (all ethernet+wlan ports under one switch/bridge, no vlans, no nat).
If I change the mac address of an ethernet port while it's a member of a switch/bridge, most of the OS will hang. Switch will continue to pass traffic (on other ports) and the system clock runs but pretty much everything else is frozen.
Device does not respond to /system reboot or reboot via winbox and needs to be power cycled to restore full function. (Crappy situation if the device is on a remote location)
Re: v6.42.9 [long-term] is released!
Does it happen when you change MAC address of just any member port or does it happen only when you change MAC address of a port which previously had same MAC address as bridge?
-
-
nescafe2002
Forum Veteran
- Posts: 897
- Joined:
- Location: Netherlands
Re: v6.42.9 [long-term] is released!
I have reported this issue earlier and it has been fixed in 6.44beta14.
Sadly it has not been merged to stable yet.
Edit: This issue => referring to device lockup when changing MAC address.
Sadly it has not been merged to stable yet.
Edit: This issue => referring to device lockup when changing MAC address.
Last edited by nescafe2002 on Fri Oct 26, 2018 5:05 pm, edited 1 time in total.
Re: v6.42.9 [long-term] is released!
Bridge always worked that way and if suddenly bridge with inactive (no ports) will not have running flag, it will break all configurations with loopbacks and other configurations where bridge is used as dummy interface.
In the migration from master to bridge you have break an always working configuration that really makes sense.
Create an option the the bridge with default to keep running anyway, and selection to stop running if no attached port is running.
-
-
vodokotlic
just joined
- Posts: 16
- Joined:
Re: v6.42.9 [long-term] is released!
Quote original post:
Quote nescafe2002:
Quote mkx:This is my first version running a new bridge, don't know if it's a known bug.
RB951G-2HnD running as just a Switch/AP (all ethernet+wlan ports under one switch/bridge, no vlans, no nat).
If I change the mac address of an ethernet port while it's a member of a switch/bridge, most of the OS will hang. Switch will continue to pass traffic (on other ports) and the system clock runs but pretty much everything else is frozen.
Device does not respond to /system reboot or reboot via winbox and needs to be power cycled to restore full function. (Crappy situation if the device is on a remote location)
Just a member port, not previous master. It does that even when the port is not running (cable not connected). It has to be removed from the bridge, MAC address changed and then added back to the bridge. Fix could be as simple as preventing the change if port is bridge member. Just return an error and not hang the OS.Does it happen when you change MAC address of just any member port or does it happen only when you change MAC address of a port which previously had same MAC address as bridge?
Quote nescafe2002:
Assuming you're replying to my post; Good to know, it'll trickle down eventually.I have reported this issue earlier and it has been fixed in 6.44beta14.
Sadly it has not been merged to stable yet.
Re: v6.42.9 [long-term] is released!
After changing the MAC have you tried flushing arp table on your computer? After all you are vodokotlicThis is my first version running a new bridge, don't know if it's a known bug.
RB951G-2HnD running as just a Switch/AP (all ethernet+wlan ports under one switch/bridge, no vlans, no nat).
If I change the mac address of an ethernet port while it's a member of a switch/bridge, most of the OS will hang. Switch will continue to pass traffic (on other ports) and the system clock runs but pretty much everything else is frozen.
Device does not respond to /system reboot or reboot via winbox and needs to be power cycled to restore full function. (Crappy situation if the device is on a remote location)
...Re: v6.42.9 [long-term] is released!
Hello everyone,
So I work for an ISP and have been using 42.9 (long term) as the standard for my current Router OS version in deployment and it works great for the RB2011's, the Cloud Core units, the hAP AC's and the hAP AC^2's, however I have discovered in which if you upgrade a hAP AC^2 to Router OS 42.9, the unit will be bricked if you perform a hard reset while on that version. I have replicated this on 5 different units in total. You are able to still use Netinstall to restore this unit to its former glory, but this is problematic for times in which a field hard reset is necessary during unit deployment. I suspect this is actually related to the ARM version of Router OS 42.9 and thus would impact other units running on it, but the only unit we deploy here that uses an ARM processor is the AC^2, so I'm unable to test other units that share this version. Is there anything that can be done about this?
Thank you so much!
Update:
It's not related to the ARM release, as hard resetting a hAP AC1 on 42.9 has the same result. Will post back again after testing with an RB2011.
Update 2:
Hard reset of configuration with an RB2011 on 42.9 does indeed brick that device as well, so this seems to be across the board.
So I work for an ISP and have been using 42.9 (long term) as the standard for my current Router OS version in deployment and it works great for the RB2011's, the Cloud Core units, the hAP AC's and the hAP AC^2's, however I have discovered in which if you upgrade a hAP AC^2 to Router OS 42.9, the unit will be bricked if you perform a hard reset while on that version. I have replicated this on 5 different units in total. You are able to still use Netinstall to restore this unit to its former glory, but this is problematic for times in which a field hard reset is necessary during unit deployment. I suspect this is actually related to the ARM version of Router OS 42.9 and thus would impact other units running on it, but the only unit we deploy here that uses an ARM processor is the AC^2, so I'm unable to test other units that share this version. Is there anything that can be done about this?
Thank you so much!
Update:
It's not related to the ARM release, as hard resetting a hAP AC1 on 42.9 has the same result. Will post back again after testing with an RB2011.
Update 2:
Hard reset of configuration with an RB2011 on 42.9 does indeed brick that device as well, so this seems to be across the board.
Re: v6.42.9 [long-term] is released!
What is your definition of "bricked"? No longer boots, you can no longer access it, or what?
There have been reports that this version does not install the familiar default config with DHCP server, NAT, firewall etc, but it merely puts address 192.168.88.1/24 on one of the ports as already was the standard on "business" routers like the CCR.
Did you try connecting from a system with address 192.168.88.10/24 or similar? Did you try connecting to the MAC address? (with winbox)
There have been reports that this version does not install the familiar default config with DHCP server, NAT, firewall etc, but it merely puts address 192.168.88.1/24 on one of the ports as already was the standard on "business" routers like the CCR.
Did you try connecting from a system with address 192.168.88.10/24 or similar? Did you try connecting to the MAC address? (with winbox)
Re: v6.42.9 [long-term] is released!
By "bricked", I mean that I can no longer get the router to hand out an IP to anything resulting in loss of access, though admittedly I don't recall which LAN ports I used. Does this behavior you mention assign 192.168.88.1/24 to a single port or to the bridge?What is your definition of "bricked"? No longer boots, you can no longer access it, or what?
There have been reports that this version does not install the familiar default config with DHCP server, NAT, firewall etc, but it merely puts address 192.168.88.1/24 on one of the ports as already was the standard on "business" routers like the CCR.
Did you try connecting from a system with address 192.168.88.10/24 or similar? Did you try connecting to the MAC address? (with winbox)
I tried pulling an IP via DHCP first and could not, then I set my NIC to a static address of 192.168.88.5 and still could not pull the address from the router on any of the tested devices.
Most of my Mikrotik units don't have console ports, so I haven't tried that yet (though I could on an RB2011 if necessary). As to Winbox, I have never used the application, but I can give this a test as well.
Update:
I consoled into a "bricked" RB2011 from this process. Turns out, the device doesn't apply the usual default config if you do this other than the following:
[admin@MikroTik] > /exp
# jan/02/1970 00:02:56 by RouterOS 6.42.9
# software id = 25GR-X6TN
#
# model = 2011UiAS
# serial number = XXXXXXXXXXXX
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip address
add address=192.168.88.1/24 comment="default configuration" interface=ether1 \
network=192.168.88.0
/system routerboard settings
set silent-boot=no
Which is why I have no access. So it doesn't brick the device per se, it just doesn't apply any default router configuration like other versions do, and since it applied the IP pool to Eth 1, which is normally expected as the WAN port, I couldn't get an IP on anything, as I was plugged into the typical LAN ports.
Re: v6.42.9 [long-term] is released!
This was definitely my issue all along. Thanks for the assistance!Unfortunately, it looks like default configuration is not properly generated on 6.42.8 and 6.42.9 versions. A workaround is to upgrade your router to the latest stable or testing builds and reset configuration then. We will definitely resolve the issue in the next long-term version. Sorry for any inconvenience.
Re: v6.42.9 [long-term] is released!
Yes, that is the problem I described, only 192.168.88.1 on a single port and no DHCP etc. I did not know which port it would use on RB2011 but apparently ether1 like on CCR which is indeed unfortunate as your PC normally would not be connected to that.
Well, good that you found out. On the 2011UiAS you have you could have used the LCD to find what was happening.
Well, good that you found out. On the 2011UiAS you have you could have used the LCD to find what was happening.
Re: v6.42.9 [long-term] is released!
I contacted support multiple times. They refused to accept that it is an issue. Oh well, Juniper likes the extra business.Good point, we definitely need some option to stop bridge if all bridge ports are down (or to run it only if there are active ports). Someone just needs to contact support@mikrotik.com with that request
Re: v6.42.9 [long-term] is released!
How about using a script with a scheduler?I contacted support multiple times. They refused to accept that it is an issue. Oh well, Juniper likes the extra business.Good point, we definitely need some option to stop bridge if all bridge ports are down (or to run it only if there are active ports). Someone just needs to contact support@mikrotik.com with that request
Code: Select all
:foreach bridge in=[ / interface bridge find ] do={
:local brname [ / interface bridge get $bridge name ];
:local inactive true;
:foreach port in=[ / interface bridge port find where bridge=$brname ] do={
:if ([ /interface bridge port get $port inactive ] != true) do={
:set inactive false;
}
}
:if ($inactive = true) do={
/ ip address disable [ find where !dynamic interface=$brname ];
} else={
/ ip address enable [ find where !dynamic interface=$brname ];
}
}Re: v6.42.9 [long-term] is released!
I would even simplify it a bit
Or, if you need only 1 bridge, even shorter:
Code: Select all
:foreach bridge in=[ /interface bridge find ] do={
:local brname [ /interface bridge get $bridge name ];
:if ([/interface bridge port print count-only where bridge=$brname and inactive=no] = 0) do={
/ ip address disable [ find where !dynamic interface=$brname ];
} else={
/ ip address enable [ find where !dynamic interface=$brname ];
}
}Code: Select all
/ip address set [ find dynamic=no interface=bridge-local ] \
disabled=([/interface bridge port print count-only where bridge=bridge-local and inactive=no] = 0)
Re: v6.42.9 [long-term] is released!
Any change of an updated long-term version soon that fixes the bridge VLAN filtering memory leak bug?
