Closed nworbnhoj closed 8 years ago
r45424 - iptables: remove layer7 support.....
Thanks for pointing this out I'll try to address this ASAP. I'll work on getting layer7 back in.
The number of times the OpenWRT devs just rip out a useful feature so that not only isn't it in there by default, but there's no way to build it at all... it's really irritating.
layer7 has its (increasing) limitations. I wonder if there is another way to address this particular issue without the need for layer7 support.
Also, pulling al the other layer7 support out of Gargoyle would save us a little space
layer7 functionality is significantly more important than saving space. I'd rather ditch all 4M routers than layer7 support.
one user on the forum a while ago suggested the use of nDPI as layer7 functionality. https://github.com/ntop/nDPI
It used to be available as a kmod.
nDPI includes an SSL decoder so it doesn't break with encrypted connections. I expect the library will be huge though.
Just a suggestion anyway.
Alternative non layer7 solution on forum by Spine
Also another approach would be to add the entire private subnet to the ipset already used by tor
If it were just the Tor hidden services, that solution would work great, but layer7 is absolutely required for qos and access restrictions.
And yet .... L7 was removed 8 months ago 2015-04-14 r45423 2015-04-26 Bump OpenWRT 44952
and almost no-one has noticed 2015-07-30 Spine post 2016-01-02 cs_privat post
And those that have are using Tor
Should now be fixed in 3209523b9e82fd0dd71468323855fac4d74dab37
Unfortunately not fixed https://www.gargoyle-router.com/phpbb/viewtopic.php?f=8&t=8299&p=35774#p35486 Could you please take another look at it?
[EDIT It seems that the issue is a little more far reaching than expected and also affects Tor Client: Enabled, Toggled By Each Host. I did not think that this option relied on L7, but maybe? I will look into replacing Tors use of L7 by some other method (see above) and see if the Tor issues is resolved. Then the L7 problems (QoS use of L7 causes reboot loop) can be dealt with independently]
[EDIT I now suspect these errors were limited to my build environment]
I recently cleared (most of) my downloads directory and now get build errors related to L7
net/ipv4/netfilter/ipt_layer7.c: In function 'total_acct_packets':
net/ipv4/netfilter/ipt_layer7.c:74:7: warning: assignment from incompatible pointer type [enabled by default]
acct = nf_conn_acct_find(ct);
^
net/ipv4/netfilter/ipt_layer7.c: In function 'match_no_append':
net/ipv4/netfilter/ipt_layer7.c:258:21: error: 'struct nf_conn' has no member named 'layer7'
if(master_conntrack->layer7.app_data != NULL) {
^
.........
net/ipv4/netfilter/ipt_layer7.c: At top level:
net/ipv4/netfilter/ipt_layer7.c:366:12: warning: 'layer7_read_proc' defined but not used [-Wunused-function]
static int layer7_read_proc(char* page, char ** start, off_t off, int count,
^
net/ipv4/netfilter/ipt_layer7.c:383:12: warning: 'layer7_write_proc' defined but not used [-Wunused-function]
static int layer7_write_proc(struct file* file, const char* buffer,
^
scripts/Makefile.build:263: recipe for target 'net/ipv4/netfilter/ipt_layer7.o' failed
make[8]: *** [net/ipv4/netfilter/ipt_layer7.o] Error 1
Setting the Tor client to "Enabled For All Hosts" or "Hidden Service Access Only" fails to set the required iptables rules. Reported by forum user cs_privat
tor.firewall
iptables -t nat -A tor_client -p udp --dport 53 -m layer7 --l7proto oniondns -j REDIRECT --to-ports $dns_port
iptables -t nat -A tor_client -p tcp --dport 53 -m layer7 --l7proto oniondns -j REDIRECT --to-ports $dns_port
fails with
iptables v1.4.21: Couldn't load match 'layer7':No such file or directory