RFC 826 is the one that says this:
If it does not, it probably informs the caller that it is throwing
the packet away (on the assumption the packet will be retransmitted
by a higher network layer)
Not worth fixing for the reasons you mention.
> On Aug 17, 2017, at 8:33 PM, Mike Karels <[email protected]> wrote:
>
> Another $.02 (inline):
>
> On 17 Aug 2017, at 18:39, Gopakumar Pillai wrote:
>
>> Thank You Bjoern. Could you please point me to the RFC?
>
> I don’t know if there is anything more recent than RFC1122 on this. IIRC, it
> requires queuing at least one packet. Queing one packet is what BSD has done
> essentially since ARP was implemented.
>
>> If this is not a MUST behavior in RFC, would my fix be good? I agree that
>> this would affect only ICMP/UDP traffic.
>
> People have been asking for queuing of multiple packets for years. That is a
> more general change. Consider another dumb application that starts out by
> sending multiple UDP packets back-to-back. However, well-designed
> application protocols don’t experience problems like this. I’ll quickly note
> that ping isn’t an application, but a network measuring tool. If you ask the
> question “what happens if I start off a session with a single large packet
> and I don’t support retransmission”, ping answers that question correctly.
>
> If badly-designed protocols get bad performance, that doesn’t seem like a bug
> to me, but a feature.
>
>> On 8/17/17, 2:40 PM, "Bjoern A. Zeeb" <[email protected]> wrote:
>>
>> On 17 Aug 2017, at 21:16, Gopakumar Pillai wrote:
>>
>> > Hi FreeBSD Networking Gurus,
>> > I came across an issue with an old version of FreeBSD and looking at
>> > the latest FreeBSD code, seems it exists even now. I am assuming that
>> > this issue is not reported.
>> >
>> > Observation:
>> > When a ping was performed with larger payload than MTU, the first ping
>> > failed when the ARP entry was absent for that IP.
>>
>> That is because ping/ICMP has no retransmit.
>>
>>
>> > Noticed on the wire that the last IP fragment was sent for the first
>> > request and then the subsequent requests were fine.
>> >
>> > Root Cause:
>> > * ip_output fragments the packets and loops through the fragments to
>> > send them to ether_output.
>> > * ether_output does an arpresolve and if there is no existing ARP
>> > entry it'll return EWOULDBLOCK after sending ARP Request.
>> > * ether_output ignores the error and propagates success to ip_output
>> > and it continues to send the remaining fragments.
>> > * llentry keeps only one mbuf and the last fragment is retained when
>> > the ARP Reply comes and the fragment is sent.
>>
>> Yes, according to the spec (RFC) we are supposed to throw the packet
>> away entirely and simply report that to the next upper layer. However
>> over the years people realised that this sucks for a TCP SYN packet with
>> a retransmit timer and hence we store one of them.
>>
>> A large UDP packet would btw see the same behaviour to your ping.
>> There’s no guarantee any of these packets will not be dropped anywhere
>> on the network, so we can as well.
>>
>> Just my 2ct
>>
>> /bz
>
> Mike
> _______________________________________________
> [email protected] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "[email protected]"
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[email protected]"
