Bugzilla – Bug 1109
ARP silently drops packets when waiting for an ARPreply
Last modified: 2012-01-28 19:16:39 EST
It might as well be the "normal" behaviour, but it can be still puzzling. When an ARP cache is invalid (or null) the packets are queued until the cache is filled. At the moment the cache size is 3, so if you send more than 3 consecutive packets, only the first 3 will be send and the others will be dropped. This can be quite rare if an application sends "normal" packets, as it's quite unlikely to queue a batch of more than 3 packets. On the other hand if you send a single UDP packet large enough (let's say 5000 bytes) on a csma interface it will be fragmented in 4 chunks, with the 4th dropped by ARP. Now, IP don't have any way to tell if the ARP cache is full, so there's no way to queue the fragments at IP level either. Possible solutions: 1) increase the ARP cache to ceil (MAX_IP_SIZE / MTU) 2) add a feedback to confirm that the packet hasn't been lost in ARP (interface->IsReady() ?) 3) make it easier to change the "PendingQueueSize" arp attribute. I know the packet could be still lost in the csma device (retransmit exceeded), but that's usually due to network congestion, so it's more logical. T. PS: I'm talking about IPv4, of course. PS2: yes, IPv4 fragmentation is implemented.
Created attachment 1310 [details] Doc update to point out common mistakes I don't like open bugs, so I checked out again this one. It seems that's more a documentation flaw rather than a real bug or misbehavior. Now, I'd like to add the attached paragraph to the "internet-stack.rst" to fill the gap. Of course this "fix" does assume that people DO read the documentation... which is basically always false. Still, we'll be able to answer politely "RTD" (Read The Documentation), or something less polite.
(In reply to comment #1) > Created attachment 1310 [details] > Doc update to point out common mistakes > > I don't like open bugs, so I checked out again this one. It seems that's more a > documentation flaw rather than a real bug or misbehavior. > > Now, I'd like to add the attached paragraph to the "internet-stack.rst" to fill > the gap. > > Of course this "fix" does assume that people DO read the documentation... which > is basically always false. Still, we'll be able to answer politely "RTD" (Read > The Documentation), or something less polite. ok
Updated the documentation about this behavior. changeset 7699 - 90904c14135f