>> - ip_output calls icmp_error
> I don't see how ip_output() would call icmp_error()
itself. If the
> packet size exceeds MTU and can't be fragmented,
ip_output() simply
> drops the packet and returns EMSGSIZE to ip_forward().
It is
> ip_forward() that calls icmp_error() when ip_output()
returned an
> error.
Yes, I miswrote.
> But ip_forward() makes a copy of the packet (header)
before calling
> ip_output() on the original packet. If it later does
generate an
> ICMP error, it is based on that copy. Since the copy
is
> pre-ip_output(), it is not NATed, and the ICMP error
should not refer
> to the NATed packet at all.
Hm, that's true. (And - I just checked - it's equally
true of the
source I've been working with, so this isn't just a
version issue.)
> So, I'm puzzled at how you can actually see what you
describe.
Well, I put a debugging printf in icmp_reflect, and the
reflected
packet is being passed to ip_output with ip_src set to the
"inside"
address of the gateway and ip_dst set to the
"outside" address, as
described.
You're right that I got myself confused about input and
output NAT
processing; this theory doesn't look as plausible in view
of the code
as it did when I wrote that last night (ENOSLEEP or some
such). But
I'm not sure how to explain the addresses the packet bears,
then. I
suppose I need to throw in a bunch more debugging info.
> Are you doing some encapsulation, where NAT happens on
the
> decapsulated layer and MTU fails on the encapsulated
layer or
> something like that?
I would be, except that I set the MTU on the decapsulated
interface as
appropriate to compensate. (Think userland PPPoE and
you'll be close
enough for these purposes.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3
27 4B
|