Hi All, Mr. Pascal, I'm sorry, I'm not subscribed to this list...so I just saw your reply on the archives. The thing is, I narrowed down the problem: - The traffic is passing through the bridge just fine; - When I plug a single client everything works great; - When I plug in the CMTS (all the cable modem clients, then), everything stops. So, first I thought that the CMTS must be doing something to the net to upset ebtables. But I added a rule: iptables -A INPUT -p tcp --dport 80 -j LOG --log-level 1 --log-prefix "iptables " And I got _a lot_ of these: Dec 29 20:05:16 hyper kernel: iptables IN=eth0 OUT= MAC=00:ea:01:02:7b:a2:00:21:a0:ce:9d:24:08:00 SRC=200.250.249.216 DST=201.49.208.251 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=40080 DF PROTO=TCP SPT=2959 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x1 So it's not VLAN-related. So now I'm thinking: If squid isn't seeing anything, couldn't be that when I plug all the clients (around 6000) some buffer overflows (maybe a proc entry?) and ebtables/iptables stop routing? I still get the logs on /var/log/messages, but squid doesn't get anything. Is there some proc entries I should check out? So far, the only one I changed to get the bridge up and running size-wise was: echo 1000000 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max Anything else is pretty much vanilla-default. If you guys could please CC me on the reply, I'd appreciate it. Thanks! Felipe Damasio 2009/12/24 Felipe W Damasio <felipewd@xxxxxxxxx>: > Hi, > > 2009/12/23 Felipe W Damasio <felipewd@xxxxxxxxx>: >> But when I plug eth0 on the production environment network (which >> uses multiple VLANs, one for the users and another for the internet), >> http traffic stop working (ie. doesn't get routed to squid). > > One other thing: I tried using --log-level debug --log-ip log--arp > on the ebtables rules, and had several entries on my syslog such as > this: > > Dec 23 19:24:47 hyper kernel: ebtables-broute IN=eth0 OUT= MAC source > = 00:21:a0:ce:9d:24 MAC dest = 00:1a:a2:5d:70:8d proto = 0x0800 IP > SRC=189.10.205.122 IP DST=189.73.192.220, IP tos=0x00, IP proto=6 > SPT=3774 DPT=80 > Dec 23 19:24:47 hyper kernel: ebtables-broute IN=eth0 OUT= MAC source > = 00:21:a0:ce:9d:24 MAC dest = 00:1a:a2:5d:70:8d proto = 0x0800 IP > SRC=189.10.204.12 IP DST=64.233.163.86, IP tos=0x00, IP proto=6 > SPT=1260 DPT=80 > Dec 23 19:24:47 hyper kernel: ebtables-broute IN=eth0 OUT= MAC source > = 00:21:a0:ce:9d:24 MAC dest = 00:1d:71:b0:23:11 proto = 0x0800 IP > SRC=189.58.246.156 IP DST=72.21.81.133, IP tos=0x00, IP proto=6 > SPT=2253 DPT=80 > Dec 23 19:24:47 hyper kernel: ebtables-broute IN=eth0 OUT= MAC source > = 00:21:a0:ce:9d:24 MAC dest = 00:1d:71:b0:23:11 proto = 0x0800 IP > SRC=189.58.247.99 IP DST=69.175.26.18, IP tos=0x00, IP proto=6 > SPT=49392 DPT=80 > Dec 23 19:24:47 hyper kernel: ebtables-broute IN=eth0 OUT= MAC source > = 00:21:a0:ce:9d:24 MAC dest = 00:1a:a2:5d:70:8d proto = 0x0800 IP > SRC=201.66.236.140 IP DST=174.140.128.6, IP tos=0x00, IP proto=6 > SPT=2060 DPT=80 > > I suppose it means that the ebtables rules are working. But why > aren't they seen by the iptables rules? > > Again, I tried using a single cross-cable connected machine and > these rules worked (and got logged just the the above). > > Could this be a kernel bug? > > Cheers, > > Felipe Damasio > -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
