BUG: Bridge filtering in 5.0RC1 is broken?

RouterOS General
1

Hi,

In testing an RB411 with a single bridge containing the wlan1 and ether1 interfaces with the following bridge settings/filters:
[user@host] /interface bridge> port print
Flags: X - disabled, I - inactive, D - dynamic

INTERFACE BRIDGE PRIORITY PATH-COST HORIZON

0 ether1 bridge1 0x80 10 none
1 wlan1 bridge1 0x80 10 none
[user@host] /interface bridge> settings print
use-ip-firewall: no
use-ip-firewall-for-vlan: no
use-ip-firewall-for-pppoe: no
[user@host] /interface bridge> filter print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=forward action=accept in-interface=ether1 mac-protocol=pppoe-discovery packet-type=broadcast

1 chain=forward action=drop packet-type=broadcast

2 chain=forward action=drop packet-type=multicast

3 chain=forward action=accept mac-protocol=pppoe-discovery

4 chain=forward action=accept mac-protocol=pppoe

5 chain=forward action=drop


(Rule 0 should allow PADI PPPoE discovery packets to originate on the ethernet and flow through the bridge. Rules 1 and 2 block all remaining broadcast/multicast packets on any interface. Rule 3 allows PADO/PADR/PADS/PADT packets and rule 4 allows the PPPoE session traffic. Obviously rule 5 drops everything else.)

Next I connect my Mac notebook directly to ether1 running Wireshark to capture traffic. In theory, the ONLY traffic that makes it through the bridge should be PPPoE traffic (discovery or session).

So I'm shocked to see ARP traffic originating from a router on the other side of the 802.11 AP this 411 board connects to wirelessly, IPv6 packets, ICMP IP traffic, DHCP traffic, etc. TONS of traffic! All of it bridged. (I filtered out traffic sourced by the 411 directly since that wouldn't be bridged.)

Note that IP filtering is OFF--that does NOT disable BRIDGE filtering (or it shouldn't).

So, MikroTik, what's going on here? I rely on bridge filtering to prevent unsanitized traffic from cluttering my network. If it doesn't work, I can't use RouterOS.

Shocked and puzzled,
Aaron out.

2

I just dropped back to 4.11 to be sure it wasn’t something in my configuration and the bridge filtering worked as expected. So this DEFINITELY is a bug. A showstopper!

Aaron out.

3

The problem does certainly come from here :

Sample from the last changelog :

"What’s new in 5.0rc1 (2010-Sep-17 13:58):
…
…

  • updated drivers and kernel (to linux-2.6.35)"


    I can’t understand that Mikrotik did change the Router OS kernel for a Release Candidate… Without full internal regression testing.

This is clearly suicidal and the forum reports on 5.0RC1 confirm this…

If Mikrotik had a serious test suite for Router OS, they would not have been released such unusable crap software.

QOS is broken, SSH, Bridge filtering… What else ?

They need to write a serious test suite or they will be slower and slower at programming and debugging as soon as complexity will rise with IPv6 and Ethernet Provider new protocols.

Another possibility is to open the source code so that a community of experts programmers can watch at the code and correct it faster.

4

Edit: I don’t think it’s necessarily crap, just very untested, and leaves users spending much unnecessary time testing.

I completely agree. It might be too late however, RouterOS is already extremely complicated with no test suite or consistency (change log problems, CLI inconsistency). I’ve been thinking of creating some kind of test suite from an external stance (auto config, auto enable/disable, auto monitor, etc…). If you have any ideas, I would love to get something together. Internally to Mikrotik source, we can’t change that, there’s nothing we can do there, but externally I think we could make something happen in regards to a test suite.

With webfig, swos, and hardware, the routeros platform (i believe) is being put on the back-burner with testing. This is a community supported software, yet me pay it to be closed source (not that I mind paying, I just wish us users were more involved with the software decisions and progress).

5

I fully agree. It’s not crap but it’s so complicated now that it’s difficult to manage testing and programming because there isn’t a very strong internaly mastered basis.

This is a known problem : trying to mix opensource (Linux) and closed source, becomes very complicated as soon as the private code rise a to a high percentage.

According to forum messages version 3.25 was the latest correctly mastered by Mikrotik.


I hope this will change in the near futur because router OS is a very nice system, mostly because of a nice and fast GUI, but as well because it is the only low cost system with a quite complete functions set compared to expensive commercial solutions.

If this does not change, router OS will stay at the actual market level, instead of going one step higher.

6

I am glad they did update the kernel in -rc, not in final release. This is what pre-release software is for. Testing, innovating, improving and so on. I don’t care whether it is called ‘alpha’, ‘beta’, ‘release candidate’, they can do whatever they feel will be good in the long term. If you don’t want the risk - don’t use it. Stick with 4.11. And 2.6.35 is good release, so we all will benefit from that. The most important is that devices upgrade without problem (no physical intervention required).

So stop yelling, you got the most amazing piece of networking software for such a low price.

7

+1
Looking forward for RC2. :stuck_out_tongue:

8

I don’t mean to argue, but it’s really not about the word “beta” or “rc”. It’s the meaning behind it. beta usually means more bugs to work out (or at least more testing time). rc usually means code is just about ready for stable release in the next few versions.

More testing, never a bad thing. Beta by it’s meaning kind of implies that it should be tested and all bugs reported. If it didn’t matter what it was called, the words “alpha,beta,rc” wouldn’t exist. They have a meaning in software development.

I think rc1 should’ve be beta7, some people think different. In the end, a stable, bug trimmed v5.0 release is all that matters.

9

I think that RC1 is far from being stable.

It’s not a good thing to give RC attribute to a beta version, because in the end clients think they can trust a new version, and have a final release in a couple monthes, when in reality it will take 6 monthes or more to get the final.


I will add that the actual testing is done by clients. This is ok for simple systems or software, but Router OS is not a simple system in its actual state.

So testing should be done more seriously internaly at Mikrotik, specialy for advanced functions, rarely tested in the field by beta testers (MPLS, BGP, IPv6…).

10

please email support with the supout.rif file and the description of the problem, so we can test and fix this issue.