Only last IP frag sent if ARP entry absent
Mike Karels
mike at karels.net
Tue Aug 22 04:18:11 UTC 2017
On 21 Aug 2017, at 1:11, Gopakumar Pillai wrote:
> Looks like later FreeBSD already has some amount of queueing from what
> Oleg has pointed out:
>
> $ sysctl net.link.ether.inet.maxhold
> net.link.ether.inet.maxhold: 1
>
> As Mike mentioned, my fix looks into a logical IP packet. And it keeps
> only one logical IP packet – i.e 64K bytes – 43 packets. I did
> test it in my code, didn’t see any issues yet.
>
> Latest FreeBSD code would keep the specified number of physical IP
> packets, possible to have more than one logical IP packet, but could
> possibly break a logical IP packet too.
>
> I do now understand its not a big deal, especially since there’s a
> way to configure that in latest FreeBSD code. I shall fix my code one
> of the above 2 ways.
Why not just set maxhold to your favorite value (e.g. 43?).
> Thank You all for your support and help.
>
> --Gopu
>
>
> On 8/19/17, 9:56 AM, "Mike Karels" <mike at karels.net> wrote:
>
>
>
> On 19 Aug 2017, at 4:00, Julian Elischer wrote:
>
> > On 18/8/17 11:33 am, Mike Karels 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.
> >
> > This asks the question: One physical packet or one logical
> packet?
> > Gopakumar's change effectively changes the queuing from one
> physical
> > packet to the logical one.
> > The next question becomes "how much extra work do we do to
> achieve
> > this and does it affect anything else"?
>
> That isn’t the whole question. It’s one physical packet, one
> logical packet, or multiple frames?
> It makes more sense to me to support multiple frames rather than
> just
> one logical packet. However,
> I don’t see a good reason to change from the current code.
>
> >>> 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"
> >>> <bzeeb-lists at lists.zabbadoz.net> 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
> >> _______________________________________________
> >> freebsd-net at freebsd.org mailing list
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freebsd.org_mailman_listinfo_freebsd-2Dnet&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=SPMIiiJNfXk7ujuip5qobK77LnnVM8kVNC-LzM_0RWk&m=gVqPCwvWs-eO0Y8jGefr8abxlnmG_GklVISDsn3solU&s=_748SiGYexZf7oZMSG2ZVDkzcelyZECM0lFMpbojDWA&e=
> >> To unsubscribe, send any mail to
> >> "freebsd-net-unsubscribe at freebsd.org"
> >>
> >>
> >
> > _______________________________________________
> > freebsd-net at freebsd.org mailing list
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freebsd.org_mailman_listinfo_freebsd-2Dnet&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=SPMIiiJNfXk7ujuip5qobK77LnnVM8kVNC-LzM_0RWk&m=gVqPCwvWs-eO0Y8jGefr8abxlnmG_GklVISDsn3solU&s=_748SiGYexZf7oZMSG2ZVDkzcelyZECM0lFMpbojDWA&e=
> > To unsubscribe, send any mail to
> "freebsd-net-unsubscribe at freebsd.org"
More information about the freebsd-net
mailing list