* Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter [not found] <20020925.224001.99456805.davem@redhat.com> @ 2002-09-26 15:27 ` James Morris 2002-09-26 16:46 ` James R. Leu 2002-09-26 20:52 ` David S. Miller 0 siblings, 2 replies; 7+ messages in thread From: James Morris @ 2002-09-26 15:27 UTC (permalink / raw) To: David S. Miller; +Cc: Rusty Russell, nf, linux-kernel, netdev On Wed, 25 Sep 2002, David S. Miller wrote: > If you have things that must happen in a sequence to flow through > your path properly, that's where the "stackable" bit comes in. You > do that one bit, skb->dst = dst_pop(skb->dst), then your caller > will pass the packet on to skb->dst->{output,input}(). > > Is it clearer now the kind of things you'll be able to do? > So, this could be used for generic network layer encapsulation, and be used for GRE tunnels, SIT etc. without the kinds of kludges currently in use? Sounds nice. - James -- James Morris <jmorris@intercode.com.au> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter 2002-09-26 15:27 ` [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter James Morris @ 2002-09-26 16:46 ` James R. Leu 2002-09-26 16:19 ` James Morris 2002-09-26 20:52 ` David S. Miller 1 sibling, 1 reply; 7+ messages in thread From: James R. Leu @ 2002-09-26 16:46 UTC (permalink / raw) To: netdev I missed the original post. Is there a patch availble for testing? Jim On Fri, Sep 27, 2002 at 01:27:41AM +1000, James Morris wrote: > On Wed, 25 Sep 2002, David S. Miller wrote: > > > If you have things that must happen in a sequence to flow through > > your path properly, that's where the "stackable" bit comes in. You > > do that one bit, skb->dst = dst_pop(skb->dst), then your caller > > will pass the packet on to skb->dst->{output,input}(). > > > > Is it clearer now the kind of things you'll be able to do? > > > > So, this could be used for generic network layer encapsulation, and be > used for GRE tunnels, SIT etc. without the kinds of kludges currently in > use? Sounds nice. > > > - James > -- > James Morris > <jmorris@intercode.com.au> > > -- James R. Leu ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter 2002-09-26 16:46 ` James R. Leu @ 2002-09-26 16:19 ` James Morris 0 siblings, 0 replies; 7+ messages in thread From: James Morris @ 2002-09-26 16:19 UTC (permalink / raw) To: James R. Leu; +Cc: netdev On Thu, 26 Sep 2002, James R. Leu wrote: > I missed the original post. Is there a patch availble for testing? I don't think so, you can follow the lkml thread from http://marc.theaimsgroup.com/?l=linux-kernel&m=103299391126734&w=2 (Jamal asked for the discussion to be cc'd to netdev). - James -- James Morris <jmorris@intercode.com.au> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter 2002-09-26 15:27 ` [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter James Morris 2002-09-26 16:46 ` James R. Leu @ 2002-09-26 20:52 ` David S. Miller 2002-09-27 3:00 ` Michael Richardson 2002-09-27 14:12 ` jamal 1 sibling, 2 replies; 7+ messages in thread From: David S. Miller @ 2002-09-26 20:52 UTC (permalink / raw) To: jmorris; +Cc: rusty, nf, linux-kernel, netdev From: James Morris <jmorris@intercode.com.au> Date: Fri, 27 Sep 2002 01:27:41 +1000 (EST) So, this could be used for generic network layer encapsulation, and be used for GRE tunnels, SIT etc. without the kinds of kludges currently in use? Sounds nice. Such IPIP tunnels have very real problems though, since only 64-bits of packet quoting are required in ICMP errors, it is often impossible to deal with PMTU requests properly, see "#ifndef I_WISH_WORLD_WERE_PERFECT" in net/ipv4/ip_gre.c ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter 2002-09-26 20:52 ` David S. Miller @ 2002-09-27 3:00 ` Michael Richardson 2002-09-27 14:12 ` jamal 1 sibling, 0 replies; 7+ messages in thread From: Michael Richardson @ 2002-09-27 3:00 UTC (permalink / raw) To: David S. Miller; +Cc: jmorris, rusty, nf, linux-kernel, netdev -----BEGIN PGP SIGNED MESSAGE----- >>>>> "David" == David S Miller <davem@redhat.com> writes: David> From: James Morris <jmorris@intercode.com.au> David> Date: Fri, 27 Sep 2002 01:27:41 +1000 (EST) David> So, this could be used for generic network layer encapsulation, and be David> used for GRE tunnels, SIT etc. without the kinds of kludges currently in David> use? Sounds nice. David> Such IPIP tunnels have very real problems though, since only 64-bits David> of packet quoting are required in ICMP errors, it is often impossible David> to deal with PMTU requests properly, see "#ifndef David> I_WISH_WORLD_WERE_PERFECT" in net/ipv4/ip_gre.c IPsec tunnels are even worse, because, not only is there not enough info returned, but, being paranoid, one should really not even trust it. ICMP Port not reachable for UDP port 500 are even more nasty, because sometimes they indicate a REAL problem :-) Eons ago, I proposed a way to deal with this problem, see: http://www.sandelman.ottawa.on.ca/SSW/ietf/draft-richardson-ipsec-pmtu-discovery-00.txt I think that now that Linux doesn't linearize skbuff's prior to passing them to protocol handlers, that I actually could get the fragment info from the skb chain. Excerpt from document: Gateway G2 upon receiving an ESP or AH packet that needs to be reassembled, MUST take note of the size largest fragment received. This value is compared to the previous largest fragment size. If this size has changed by more than 10%, or more than 2*MSL time (i.e. 2 minutes) has passed since the previous ICMP message, then an ICMP Datagram Too Big message is generated. The largest fragment size is initialized to 576 bytes. The ICMP datagram is addressed from gateway G2 to the originating node C, and gives a size that is based on the maximum fragment size (above), minus the IPsec overhead. The ICMP datagram is sent via the tunnel on which the IPsec packet was a member. I.e. the ICMP is encapsulated. A packet arriving at G1 with the DF bit set, does not cause the DF bit to be set on the encapsulating datagram. (proposal two changes the destination IP of the ICMP message) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPZPJt4qHRg3pndX9AQGqYwP+JtDyOhQwV2kiFWqxs8H8QbU0OJmV/krd rNhapv6/qzxcqHHPWHiypxQLZ3uYHcNKfwdoQFhOgVxdZXivkOnvn9bjoKDIp+EL JKNNvSrHNZMJ9yQCqUnsI+2XknkR9bCOOK9DfTcJ9e2lSFlH7H1vSTnRo6GOJhVh arQUa22xoc8= =VAyj -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter 2002-09-26 20:52 ` David S. Miller 2002-09-27 3:00 ` Michael Richardson @ 2002-09-27 14:12 ` jamal 2002-09-28 1:30 ` David S. Miller 1 sibling, 1 reply; 7+ messages in thread From: jamal @ 2002-09-27 14:12 UTC (permalink / raw) To: David S. Miller; +Cc: jmorris, rusty, nf, linux-kernel, netdev Dave, now that i followed the thread on lk (slrn is great; thanks Jason); I am actually interested to find out how you are going to pull what you propose ;-> There are not that many things that will work well with a dst-cache like idea. I actually considered the stacking idea when i first was trying to prototype code that i posted. It is much harder to make use of in practise. At least this is my experience. If you look at the scheme i posted, youll see that the policy could be to direct the packets to a IPV4-forwarding block or totaly bypass it etc (i just didnt wanna jump into that step yet sicne it is quiet involved architecturaly) In any case we need to encourage people like the hipac authors to be putting out things (i only wish theyd incorporate it into the tc framework!); whatever changes made should consider that there is more than one way to do things and people will always come with better ways to do certain portions of the packet path. cheers, jamal On Thu, 26 Sep 2002, David S. Miller wrote: > From: James Morris <jmorris@intercode.com.au> > Date: Fri, 27 Sep 2002 01:27:41 +1000 (EST) > > So, this could be used for generic network layer encapsulation, and be > used for GRE tunnels, SIT etc. without the kinds of kludges currently in > use? Sounds nice. > > Such IPIP tunnels have very real problems though, since only 64-bits > of packet quoting are required in ICMP errors, it is often impossible > to deal with PMTU requests properly, see "#ifndef > I_WISH_WORLD_WERE_PERFECT" in net/ipv4/ip_gre.c > > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter 2002-09-27 14:12 ` jamal @ 2002-09-28 1:30 ` David S. Miller 0 siblings, 0 replies; 7+ messages in thread From: David S. Miller @ 2002-09-28 1:30 UTC (permalink / raw) To: hadi; +Cc: jmorris, rusty, nf, linux-kernel, netdev From: jamal <hadi@cyberus.ca> Date: Fri, 27 Sep 2002 10:12:26 -0400 (EDT) whatever changes made should consider that there is more than one way to do things and people will always come with better ways to do certain portions of the packet path. Of course. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-09-28 1:30 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20020925.224001.99456805.davem@redhat.com>
2002-09-26 15:27 ` [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter James Morris
2002-09-26 16:46 ` James R. Leu
2002-09-26 16:19 ` James Morris
2002-09-26 20:52 ` David S. Miller
2002-09-27 3:00 ` Michael Richardson
2002-09-27 14:12 ` jamal
2002-09-28 1:30 ` David S. Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).