> Hello!
>
> > For 2.2.x, we had planned to get away from all this silly virtual
> > device stuff and route stealing and routing table mucking about.
>
> This plan was CORRECT.
We are moving in that direction... but not until we get a satisfactory
solution to this problem. We need to be able to support 2.0.x for the
short term.
> > Later he concludes that our processing should be done before
> > ip_build_xmit(), which echoes some of our previous instincts. He also
> > suggests that our eroute lookup should happen when the dst stuff does
> > now, and suggests that we should store a per-eroute pmtu.
>
> It is not my suggestion. It is evident that ip_build_xmit is useless
> for IPsec. Just look at it, factor out fragmentation code and you will see,
> that it reduces to several lines of the dumbest code.
At this point, I agree, it is not correct because it takes an upper
layer buffer, with/without IP header, acquires an skb, then sends it
on its way, checking to see if it needs to allocate more than one skb
for fragments. We may need to put something in here to deal with
fragmentation decisions when we move to the Better Way (tm), but the
bulk of our code should be called from a firewall chain. This does
not help us now.
> > "Ah, this sounds like you are encapsulating packets in another
> > protocol before sending them, like ip_gre.c for example.
>
> Exactly. If you use virtual devices, you will have whole
> bucket of silly problems. Certainly, the way to workaround all them exists,
> look at another virtual devices (teql, shaper). If you will be enough
> accurate you will stop to see all those miracles, which you said above 8)
Right, I had another look. They call dev_queue_xmit(), after changing
skb->dev. The difference is they do not increase the packet size in
the process, which we do. We need to be able to deal, dynamically,
with packets that grow in size after processing. dev_queue_xmit()
does not check mtu size to see if it needs fragmenting.
neigh_compat_output(), neigh_resolve_output() and
neigh_connected_output() are similarly too low level. It is too
late at this point. Conversely, ip_queue_xmit() ip_build_xmit() are
too high, since it does not have the IP header in place yet. The
firewall chains are exactly where it belongs.
- From all the other code I have examined, it looks like I need to call
ip_fragment(skb, skb->dst->output) and modify ip_fragment() to check
to see if skb->dst->dev still equals skb->dev and take a new MTU if
they are different.
> But it is way to nowhere. Do not try to invent the wheel, just follow
> specs. All the construction is described in details in IPsec docs, actually
> we have nothing to add to them without reducing functionality.
It is time to go back and do another thorough re-read...
> Well, take as example any other IPsec implementation.
The only ones I can use as a reference are KAME and OpenBSD. The
former should be interesting. Both use mbufs!
> Alexey
slainte mhath, RGB
- --
The first Ottawa Linux Symposium was a huge success! <ottawalinuxsymposium.org>
This SunRayce was a wet one! DroughtRelief_99? -- <www.sunrayce.com/sunrayce/>
Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada
<http://www.conscoop.ottawa.on.ca/rgb/> </www.flora.org/afo/>
Prevent Internet Wiretapping! -- FreeS/WAN:<www.xs4all.nl/~freeswan>
Thanks for voting Green! -- <green.ca> Marillion:<www.marillion.co.uk>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQCVAwUBN69LlN+sBuIhFagtAQHghwQAjtV5/2cRAJcJL15pY2mh0TDTQOcCPTm6
Ivg0B2Ifv9IDJ0tKMFgCGdR0i4jN0PfNxHb33poBkyjkPobcd0e0pTsK89+cwYCd
CpEU4C7zMq6PiGkSnspGwXjWxnp6rNIhfWZTAQ/hdInvm/leZlHPlq1xexPMiUiu
2yfqRT9O76k=
=ZErZ
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/