| |
| |
| |
|
Comments:
<0> gug
<1> gugr
<2> hi, i have problem with conntrack, sometime happends that conntrack count jump from 100k tu 2m in few seconds, the router is after that very slow in routing, slowing speed and cannout handle all interupts, the conntrac -F someteme panic the kernel, have you any ideas ?
<2> can it be some type od DoS, or some bug in netfilter or something else ?
<3> could you perhaps pastebin the output of dmesg, logs and whatever else you have about this problem?
<2> a dont have the conntrack dump
<0> bryndza: conntrack -F panicking certainly sounds like a bug
<2> becouse userpsace conntrack utility crashes when dunmping the big conntrack
<0> bryndza: the rest could be a DoS, but it's impossible to tell more without knowing the details
<2> so it only dumps fww lines
<0> bryndza: do you have the kernel panic message?
<2> where can i past the dmesg output ?
<2> Hidden no, t i remeber sometling about
<3> http://pastebin.com/
<2> iptables_nat_someting
<0> bryndza: that's not too much... the next time you see this happen you should either take a photo of the screen or write down the contents manually
<0> bryndza: that would be really helpful for the developers
<4> hidden: the problem i was observing is in fact due to tproxy, as sad as it sounds
<0> jengelh: but what's the problem?
<0> jengelh: could you send it to me in email?
<0> jengelh: I don't have IRC logs, so it would be better to have it as mail
<4> well, Connection randomly refused to parent proxy, basically
<2> http://pastebin.com/585240
<2> this is the recently bug when flusshong the conntrack table
<3> yikes...
<2> and this is in dmesg when with the high count of conntracks : http://pastebin.com/585247
<2> the problem came out when with added more external ip addreses for NATING
<2> iptables -L -n -t nat | wc -l
<2> 1007
<4> 1007 rules wtf
<2> 1007 lines in nat table
<4> well, almost 1000 rules
<4> unless you have A LOT ofuser-defined chains
<2> not realy
<2> alltogether 12 Chains in nat table
<0> bryndza: do you have a vanilla 2.6.15.4, or do you have some extra patches applied?
<2> i don`t really know
<2> it is compiled for 64bit architecture
<2> netfilter patch
<2> thats all
<2> it this possible to DoS the machine ? what can of attack it would be ?
<2> can=kind
<0> basically anything which creates a lot of conntrack entries
<0> UDP flood, etc
<2> form inside or outsite the network ?
<4> Hidden: I'm still trying to figure out. Squid has had no COnnection refused failures since a week - surprisingly
<4> according to syslog
<4> nevermind, it's still
<4> i'll reproduce in vm, bbl
<0> jengelh: ok, let me know if you have found something
<0> bryndza: that's hard to tell, you should take a look at the conntrack entries when you're experiencing the problem
<0> bryndza: or try to tcpdump the incoming packets to be able to analyze the traffic later
<2> we try it, it is enourmous count of data over 200Mbit/s traffic over 10k clients
<3> svn is down...
<5> hmm
<6> looks up to me
<3> http://svn.netfilter.org/
<5> me too
<6> https://svn.netfilter.org/netfilter/
<5> ah, the webinterface
<3> ok let me rephrase, the webinterface to snv is down
<3> looks like someone deleted libswigpy.so.0
<5> use the url danieldg wrote
<5> you almost scared me, thought it stopped working after I merged my hashtrie repository into it :)
<5> but I had so vivid memories of testing it after that...
<3> lol
<3> sorry man :)
<3> .. and cigs for thoes so inclined
<6> How would I block 6to4 addresses whose IPv4 component does not match its IPv6 component? (2.6.16 state module sees them as valid)
Return to
#netfilter
or
Go to some related
logs:
ccd2iso dapper deb
kdirlist
Net::SSH::Perl slow
pysqlite2.dbapi2.OperationalError: near *: syntax error
yum-fastestmirror usage
#python
error sessreg emerge
#web
load luminance
#openzaurus
|
|