Felix Fietkau wrote: > Yes, enabling ebtables does create quite a bit of extra load. That's > also the reason why it is currently not compiled for the releases > (just compiling support for it already triggers the slowdown, even > when the module is not loaded)
Hmm, that's interesting. Does this slowdown occur with any layer2 matching? If I use an older kernel I could compile it without ebtables support but only with iptables physdev matching. Do you know if physdev matching on its own also triggers this slowdown? Older versions of iptables still support physdev-out matching so I don't really need ebtables. However this physdev-out matching is not perfect, as it breaks traffic shaping. > This particular patch was removed because it was causing problems, > even for people that weren't actually using physdev or ebtables > (something about neighbor cache overflow, iirc). Even more bad news :-( Is there any version of openwrt where physdev matching is known to work? I can live with degraded network performance or broken traffic shaping but the router shouldn't crash. I really depend on layer2 filtering. After all this feature has been in the linux kernel such a long time that there should be at least one single kernel version where it works. I would be willing to buy a better router with more performance, too. I just bought the WRT54GL because I read it was fully supported and it has a switch which I can configure into seperate VLANs. I don't need WLAN so I don't care if wireless works. Can you recommend any router with VLAN support which has more performance and works with openwrt (and hopefully the layer2 filtering patch)? Thanks, Alex _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel