On Thu, Apr 04, 2002 at 04:22:23AM +0200, Filip Sneppe wrote: > Hi, > > Is anyone interested in giving this conntracker a little swing ?
well, as I don't play any computer games, I can't test it by myself. But thanks a lot for implementing this - lots of people will like it, I guess. I hope the next step will be NAT support :) > One thing I am not too sure about is the locking I used when > adding an expected connection. I've based this code on the tftp > helper, which does not lock anything, although I fail to understand > why... Also, I hope I followed the correct way to add expectations > within the newnat framework. I'll have a look ASAP. > to a master server on port 27950/UDP and requests a list of game > servers (IP address + UDP port pairs). The master server responds > with one or more packets, each containing a bunch of ip address-port > pairs. This module will track these responses and add the necessary > expectations. It's imperative to patch the kernel with newnat > support before applying this patch. I see. So now you can open only *.*.*.*:* -> master_server:27950 and all other stuff will be RELATED. > One more thing: since all traffic is originated by the client, > I did not write a NAT module, since imho the normal NAT > framework is able to cope with this protocol. mh. well, I'm not so convinced about this. What happens when you use NAT to an address range and your individual udp streams get NAT'ed to different IP addresses? btw: what about other cases like a netfilter firewall in front of a server (maybe even DNAT to a server in DMZ with private IP address ?) > Regards, > Filip -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
