> On Wed, 18 Aug 1999, Richard Guy Briggs wrote:
> > Richard Guy Briggs wrote:
> > > James Morris wrote:
> > > > If you still suspect that the value of skb->dst->output is going astray
> > > > somewhere, you could assert that it's pointing to ip_output() at key
> > > > points in the code.
> > >
> > > It is pointing to ip_output(), but still doesn't work. I will find
> > > out more. Thanks for your sleuthing.
> >
> > On examining ip_ouput(), I can't use it because one of the things it
> > does is set skb->dev to the value of skb->dst->dev, which we expressly
> > changed before calling the output function. Another function at a
> > lower level will have to be used.
>
> I'm not sure there is a suitable function. Even if there was,
> ip_fragment() also re-vectors the device:
>
> struct rtable *rt = (struct rtable*)skb->dst;
> ....
> dev = rt->u.dst.dev;
I have added a patch to ip_fragment to check if skb->dev is not NULL
and not equal to skb->dst->dev and if so, use skb-dev instead. It
also uses the skb->dev->mtu instead of the one from the dst cache.
> I've tried a quick workaround by re-implementing ip_output() &
> ip_fragment() within klips and making sure that skb->dev is left pointing
> to the physical device. Unfortunately, this is causing another problem
> with corrupted registers which I haven't been able to solve yet.
I am seeing some occasional severe Oopses towards the end of
ip_fragment, either just before, during or just after the call to
output().
I have been using neigh_compat_output() as the output function
parameter to ip_fragment() with this behaviour. I have also shut off
the NOARP flag to the virtual devices to be able to pass the pointer
to dev_queue_xmit() in the place of neigh_compat_output() to
ip_fragment. Both mostly work, with, as you describe as 'corrupted
registers'.
I am able to call either of the above-mentioned output funcitions from
t,he end of ipsec_tunnel_start_xmit when we don't need to fragment
without any crashes. Why?
> I'll start looking at the other tunnels (ipip, gre, sit) in the 2.2 kernel
> to see if there's anything simple we can try, as they use standard ip
> output functions without any of these problems.
I will look at them carefully again, IPIP has changed considerably
in 2.2,, merging drivers/net/new_tunnel.c in with net/ipv4/ipip.c.
> - James.
Thanks for helping to track this down!
> --
> James Morris
> <jmorris@intercode.com.au>
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
iQCVAwUBN8BQ2t+sBuIhFagtAQH6MgQAmnYZTfheKHpz9lXBs+j8s9m7cEwZo1/k
85Kc9rDuK8kQs5yQx4Te/Xi+IXonFKhG0Zp70P0chgSSLr0n1jZ14HN/bEzfxzg3
0Jj9Vdj8KdoC2pbVy3OK8h6VXB9FiwP/e+wld9pGr8Y1WlHyu7iXYtLOK6Ev4mcx
MScEpwD4qpM=
=NS3F
-----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/