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

Reply via email to