I just installed a RB433AH, with ROS 3.18 on it, as a transparent bridge. ether1 and ether2 were the two bridge ports. This bridge is between PPPOE clients (various Linksys and netgear routers) and PPPOE Server (Mikrotik ROS 3.17). The following issues I noticed:

1. customers on non-wireless Linksys routers cannot browse web pages. They can ping out, but only if the ping packet is smaller than 1260 bytes.
2. running Torch on the RB433AH via Winbox, it quits updating and goes blank after the "Entry Timeout" passes.
3. running Packet Sniffer to a file stops gathering packets after about 1.5 seconds.

To troubleshoot issue number 1, I tried various manual MTU settings (1480, which is my default, 1456, and even as low as 1200). None helped.

I downgraded to version 3.17 on the bridge, and everything is working fine. Issues 1, 2 and 3 do not happen. There seems to be some problems with 3.18.

do you have the ipv6 package installed? just curious ... if so, disable and try it. could be totally unrelated.

ipv6 is installed but disabled. It was never enabled.

you say you have something like this:

(router with PPPoE server)----(RB433 with prots e1 and e2 bridged)-----pppoe client

and some clients over wired connection are not able to use anything beyond (router with PPPoE server).

This is how the connection goes:

Customer (pppoe client) -> Trango SU -> Trango AP -> 24 port ethernet switch -> RB433AH Bridge (ether1 and ether2) -> Orthogon P2P Backhaul -> 24 port ethernet switch -> x86 router (pppoe server - ROS 3.17) -> Internet

The pppoe client could be any number of residential grade routers. Linksys, Netgear, etc... We sell both a wireless Linksys (WRT54G) and wired only Linksys (BEFSR41) to our customers, so they represent a large percentage of installed pppoe clients and thus calls when there is an issue. Specifically the BEFSR41 is the model we had the trouble with on ROS 3.18. The WRT54G worked fine.

At first, I suspected a firmware issue with the BEFSR41. Checking it, we are on the latest firmware available.

So, also considering the issues I had with Torch and Packet Sniffer, I downgraded to ROS 3.17 on the bridge. That solved the problem with the BEFSR41 as well as Torch and Packet Sniffer. I was trying to get Packet Sniffer to give me some evidence as to what was happening with the BEFSR41's, but only getting 1.5 seconds of packets wasn't enough to work with.

Has this issue been fixed in 3.19 or 3.20? I see no mention of it in the changelog, and am wary of putting any version newer than 3.17 on my system due to this instability I noticed.

torch still have this problem in 3.19 and 3.20... written to support, will wait until it's fixed =)

Thanks for the update Chupaka. Have you heard anything back from MT support on this?

it's known problem, so I think we'll see reference to this issue in changelog if 3.21