On Fri, 2009-10-16 at 12:57 +0200, Roderick Groesbeek wrote: > But the Android Mobile is down! > Attaching that IP to some other device (or faking arp) will indeed fix > the FLOODING issue, but I'm > more interested into solving this issue, so that it cannot occur. I see. Adding your own keepalive to the application isn't an option? > Something I can come up with is: automatic lower TCP KEEPALIVE > established time for NF_CONNTRACK_RTSP connections. > Currently it is 43200 seconds. > > But I would think that the tcp_keepalive_intvl > (http://www.frozentux.net/ipsysctl-tutorial/ipsysctl-tutorial.html#AEN37 > 5) > would have kicked in at every 75 seconds. But it looks like that is not > for NAT'ed TCP connections. AFAIK, these are end to end settings, i.e. they are only relevant when your Linux box is the target or source of the connection (your NAT box isn't). So if you want to use TCP keepalive, you'd need to tune Tiss or the Android device. If you want to tune the NAT/conntrack/netfilter behavior, you need to fiddle around with these settings: find /proc/sys/net | fgrep netfilter Dunno of a nice place where those are documented in detail, maybe someone else on the list can chime in. Don't know much about RTP (H323?) but also check out the module options "modinfo nf_conntrack_h323" maybe they can help you. > If the TCP connections breaks, TISS will stop sending UDP packets. > (It is not in the RTP/RTSP standard though, but quite common for RTSP > streaming servers, and we have implemented it so.) > > > But the NAT router is "keeping the TCP connection alive". > Result: 5 days (432100 seconds) of UDP floods inside our network :) > > > GR, > RG
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
