tech-net archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: PR 44508: UNREACH_NEEDFRAG ICMPs use the wrong mtu
>> [...] PR kern/44508 [...]
> I'm curious about what happens when a big packet arrives without the
> DF bit set (but I can't look since I only have email access right
> now). Does it get fragmented down to the route MTU or is it
> forwarded without doing that if it fits through the interface?
I think it's fragmented to the route MTU, but I'd have to try it to be
sure. I certainly think it should be.
> That said, I always thought that the route MTU and the other fields
> in the same structure were intended as a host path characteristics
> cache to be consulted when packets were originated by the local host
> but not necessarily when packets were forwarded through the box
Conceptually, that may be a defensible stance, but I think it runs into
the unpleasant fact that forwarded packets do use those routes to make
forwarding decisions; it does not make sense to me to use a route's MTU
for locally generated packets using the route but not for packets
forwarded using route.
> It seems to me that it would clearly be a bug if the box reported a
> different MTU in ICMP packets sent in response to packets with the DF
> flag set than it used to fragment packets sent with the DF flag
> clear.
I'm not certain it does that. However, I _am_ sure that the behaviour
I saw, the behaviour I've been calling a bug, leads PMTU-D-capable
senders to repeatedly try packet sizes that do not actually get
through. In terms of the test setup sketched in the PR, host B tries
generating packets based on an MTU 1500, but gets told the packets are
too large and it should use-- 1500, the very MTU it did use. In the
case that led me to file the PR, host B believes this and tries MTU
1500 again, failing again, repeatedly, until it gets fed up and kills
the connection with ETIMEDOUT (the cases I was working with were TCP
connections).
This seems broken to me, regardless of the behaviour with DF clear
(though I agree the DF-clear behaviour should fragment based on the
same MTU that it uses as the "drop and send ICMP" threshold for DF-set
packets).
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index