linux/include/net/route.h, branch v2.6.19

[IPV4]: route.h annotations

2006-09-29T01:02:10Z

ip_route_connect(), ip_route_newports() get port numbers net-endian Signed-off-by: Al Viro Signed-off-by: David S. Miller

[IPV4]: inet_addr_type() annotations

2006-09-29T01:01:07Z

argument and inferred net-endian variables in callers annotated. Signed-off-by: Al Viro Signed-off-by: David S. Miller

[IPV4]: ip_route_connect() ipv4 address arguments annotated

2006-09-29T00:54:06Z

annotated address arguments (port number left alone for now); ditto for inferred net-endian variables in callers. Signed-off-by: Al Viro Signed-off-by: David S. Miller

[IPV4]: annotate ipv4 addresses in struct rtable and struct flowi

2006-09-29T00:54:05Z

Signed-off-by: Al Viro Signed-off-by: David S. Miller

[IPV4]: ip_rt_redirect() annotations

2006-09-29T00:54:03Z

The first 4 arguments of ip_rt_redirect() are net-endian. Annotated. Signed-off-by: Al Viro Signed-off-by: David S. Miller

[IPV4]: ip_route_input() annotations

2006-09-29T00:54:02Z

ip_route_input() takes net-endian source and destination address. * Annotated as such. * arguments of its invocations annotated where needed. * local helpers getting the same values passed to by it (ip_route_input_mc(), ip_route_input_slow(), ip_handle_martian_source(), ip_mkroute_input(), ip_mkroute_input_def(), __mkroute_input()) annotated Signed-off-by: Al Viro Signed-off-by: David S. Miller

[MLSXFRM]: Add flow labeling

2006-09-22T21:53:27Z

This labels the flows that could utilize IPSec xfrms at the points the flows are defined so that IPSec policy and SAs at the right label can be used. The following protos are currently not handled, but they should continue to be able to use single-labeled IPSec like they currently do. ipmr ip_gre ipip igmp sit sctp ip6_tunnel (IPv6 over IPv6 tunnel device) decnet Signed-off-by: Venkat Yekkirala Signed-off-by: David S. Miller

Don't include linux/config.h from anywhere else in include/

2006-04-26T11:56:16Z

Signed-off-by: David Woodhouse

[IPV4]: Aggregate route entries with different TOS values

2006-03-25T09:38:55Z

When we get an ICMP need-to-frag message, the original TOS value in the ICMP payload cannot be used as a key to look up the routes to update. This is because the TOS field may have been modified by routers on the way. Similarly, ip_rt_redirect should also ignore the TOS as the router that gave us the message may have modified the TOS value. The patch achieves this objective by aggregating entries with different TOS values (but are otherwise identical) into the same bucket. This makes it easy to update them at the same time when an ICMP message is received. In future we should use a twin-hashing scheme where teh aggregation occurs at the entry level. That is, the TOS goes back into the hash for normal lookups while ICMP lookups will end up with a node that gives us a list that contains all other route entries that differ only by TOS. Signed-off-by: Ilia Sotnikov Signed-off-by: Herbert Xu Signed-off-by: David S. Miller

[IPV4]: Always set fl.proto in ip_route_newports

2006-02-01T01:35:35Z

ip_route_newports uses the struct flowi from the struct rtable returned by ip_route_connect for the new route lookup and just replaces the port numbers if they have changed. If an IPsec policy exists which doesn't match port 0 the struct flowi won't have the proto field set and no xfrm lookup is done for the changed ports. Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller