Messages in this thread | | | Date | Sat, 10 Jul 2010 00:18:28 -0300 | Subject | Re: [PATCH] tproxy: nf_tproxy_assign_sock() can handle tw sockets | From | Felipe W Damasio <> |
| |
Hi Mr. Dumazet,
2010/7/9 Eric Dumazet <eric.dumazet@gmail.com>: > Reviewing tproxy stuff I spotted a problem in nf_tproxy_assign_sock() > but I could not see how it could explain your crash. > > We can read uninitialized memory and trigger a fault in > nf_tproxy_assign_sock(), not later in tcp_recvmsg()... > > David, Patrick, what do you think ?
But do you think that the bug that squid triggered was caused by the TProxy code?
Or is related to the network-stack in some other point.
I don't know if this helps, but I'm using ebtables to remove the packets from the bridge, and iptables to redirect the traffic to squid.
ebtables rules are:
-p IPv4 -i eth0 --ip-proto tcp --ip-dport 80 -j redirect --redirect-target DROP -p IPv4 -i eth1 --ip-proto tcp --ip-sport 80 -j redirect --redirect-target DROP
iptables -t mangle -L -n is:
iptables -t mangle -L -n Chain PREROUTING (policy ACCEPT) target prot opt source destination DIVERT tcp -- 0.0.0.0/0 0.0.0.0/0 socket extrachain tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ctstate NEW TPROXY tcp -- 0.0.0.0/0 !201.40.162.5 tcp dpt:80 connmark match 0x0 TPROXY redirect 127.0.0.1:3127 mark 0x1/0x1 TPROXY tcp -- 0.0.0.0/0 !201.40.162.5 tcp dpt:80 connmark match 0x1 TPROXY redirect 127.0.0.1:3128 mark 0x1/0x1 TPROXY tcp -- 0.0.0.0/0 !201.40.162.5 tcp dpt:80 connmark match 0x2 TPROXY redirect 127.0.0.1:3129 mark 0x1/0x1
Chain DIVERT (1 references) target prot opt source destination MARK all -- 0.0.0.0/0 0.0.0.0/0 MARK xset 0x1/0xffffffff ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
Chain extrachain (1 references) target prot opt source destination CONNMARK all -- 0.0.0.0/0 0.0.0.0/0 statistic mode nth every 35 CONNMARK and 0x0 CONNMARK all -- 0.0.0.0/0 0.0.0.0/0 statistic mode nth every 35 packet 1 CONNMARK xset 0x1/0xffffffff CONNMARK all -- 0.0.0.0/0 0.0.0.0/0 statistic mode nth every 35 packet 2 CONNMARK xset 0x2/0xffffffff
Don't know if the code on these can be traced back to tcp_recvmsg() accessing some wrong memory address...
Cheers,
Felipe Damasio
| |