> You cannot change the IP address or L4 port without making conntrack > very unhappy. In the simplest case, you're "just" voiding any state > matching and flow accounting. In the worst case, iph->daddr (and > other fields) does not match skb->nfct->....->daddr (respectively) > anymore and cosmic rays could catalyze up, er, undefined behavior > could arise. Hmm. Well, maybe that's my problem? Something that I could get away with in the 2.4 kernel, which I can't any longer? It is true that in order for this to work for me on RH3 I had to build a custom kernel that had a small change to net/ipv4/fib_frontend.c: --- net/ipv4/fib_frontend.c Sun Mar 21 07:22:00 1999 +++ net/ipv4/fib_frontend.c Wed Dec 29 20:29:38 1999 @@ -233,8 +233,13 @@ if (fib_lookup(&key, &res)) goto last_resort; +#ifdef CONFIG_ALLOW_SPOOFING + if (res.type != RTN_UNICAST && res.type != RTN_LOCAL) + goto e_inval_res; +#else if (res.type != RTN_UNICAST) goto e_inval_res; +#endif *spec_dst = FIB_RES_PREFSRC(res); fib_combine_itag(itag, &res); #ifdef CONFIG_IP_ROUTE_MULTIPATH I've made the same change on the 2.6 kernel I am trying to get running with. This is all in the context of a single-purpose, specialized server that I build which does a very specific packet forwarding task. I control the whole server (no other software needs to run on it) so hopefully I can somewhat control interactions. Regardless of the fact that it is non-standard, it does what I need and I need to somehow create that same functionality under 2.6, if possible. Do you think I should be looking at some sort of alternative approach? The simplest way to describe what I need to do is that I need to receive UDP packets on a specified set of ports and send them to a specified remote address:port after changing the source ip address:port to my local address and a specified port. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
