Linux ARP and IP stack internals question

I hope I'm not asking the obvious, but from looking through the Linux
kernel source code, I couldn't readily find the answer.

I know some IP stacks will queue an IP packet while it sends out an
ARP request and awaits the response.

I also know that some IP stacks will basically reuse the outgoing IP
packet buffer (skb?) to send out the ARP request, implying that the original
IP packet is tossed (on the premise that an upper level protocol will
resend/retry if the packet is important).

Can anyone confirm which mechanism the Linux IP stack employs? One way
or the other, I need to confirm what happens to an IP packet when the
target IP address is NOT in the ARP cache?

Thanks for looking!

Patrick
================= GPS based time synchronization solutions =================
Patrick Klos Email: patrick@timegeeks.com
Klos Technologies, Inc. Web: http://www.timegeeks.com/
==================== http://www.loving-long-island.com/ ====================

Patrick Klos wrote:
> I hope I'm not asking the obvious, but from looking through the Linux
> kernel source code, I couldn't readily find the answer.
>
> I know some IP stacks will queue an IP packet while it sends out an
> ARP request and awaits the response.
>
No it does not queue packet rather while building packet
after IP header is added it queries for HW/Etherent header to be added
to packet so i would like to say that it does not queue but stops
packet building to check whether destination ip->mac entry exist in arp
table.
> I also know that some IP stacks will basically reuse the outgoing IP
> packet buffer (skb?) to send out the ARP request, implying that the original
> IP packet is tossed (on the premise that an upper level protocol will
> resend/retry if the packet is important).
>
> Can anyone confirm which mechanism the Linux IP stack employs? One way
> or the other, I need to confirm what happens to an IP packet when the
> target IP address is NOT in the ARP cache?
already explain. For more info write back to me with what exactly
you want?
regards,
rahul
>
> Thanks for looking!
>
> Patrick
> ================= GPS based time synchronization solutions =================
> Patrick Klos Email: patrick@timegeeks.com
> Klos Technologies, Inc. Web: http://www.timegeeks.com/
> ==================== http://www.loving-long-island.com/ ====================

Patrick Klos wrote:
> I hope I'm not asking the obvious, but from looking through the Linux
> kernel source code, I couldn't readily find the answer.
>
> I know some IP stacks will queue an IP packet while it sends out an
> ARP request and awaits the response.

Contrary to what Rahul said, I think it does actually queue the packets.
However, I there is a limit to the number of packets which can be
queued and beyond that they get dropped in FIFO order.

See the code in net/core/neighbor.c, __neigh_event_send(). If the
lookup is incomplete, the packet is queued via

__skb_queue_tail(&neigh->arp_queue, skb);

Chris

In article <11jlfumgabbl599@corp.supernews.com>,
Chris Friesen <cfriesen@nortel.com> wrote:
>Patrick Klos wrote:
>> I know some IP stacks will queue an IP packet while it sends out an
>> ARP request and awaits the response.
>
>Contrary to what Rahul said, I think it does actually queue the packets.
> However, I there is a limit to the number of packets which can be
>queued and beyond that they get dropped in FIFO order.
>
>See the code in net/core/neighbor.c, __neigh_event_send(). If the
>lookup is incomplete, the packet is queued via
>
>__skb_queue_tail(&neigh->arp_queue, skb);

Followup for anyone interested in the final result:

Chris was absolutely correct - the ARP cache entry has a queue for packets
to send once the ARP response is received. There is a parameter that limits
the number of entries the queue will hold (the default is 3), and it does
maintain the queue in FIFO order (so only the last so many packets will be
kept).

I believe the code should be modified to make sure a public counter is
bumped whenever it throws away a message from the queue, but I haven't
followed the code long enough to know if there's a reason why someone
didn't do that.

To fix the problem we were seeing, we increased the queue length by setting
the unres_qlen value in /proc/sys/net/ipv4/neigh/default to a larger number
(we did so by adding a line to /etc/sysctl.conf).

Thanks for the help Chris and Rahul!

Patrick