In article [EMAIL PROTECTED]>
you write:
>calls back up the stack to have it done. This would also allow smart
>network interfaces to provide hardware fragmentation assistance, which
>might be helpful on some media.
The code to support hardware fragmentation offload is already present
in the co
< said:
> Hi,
> we're seeing a strange thing happening, related to ARP and IP fragments.
Not strange at all. The ARP cache only queues a single packet waiting
for a reply, so the first few fragments you send get tossed. We could
easily arrange it so that the first frag, rather than the last, g
Lars Eggert wrote:
> we're seeing a strange thing happening, related to ARP and IP fragments.
After a big of poking around, this is due to some code in arpresolve()
and how struct llinfo_arp caches packets during lookup, see Stevens Vol.
2, page 699, the comment about lines 292-299. RFC 1122
Lars Eggert wrote:
> we're seeing a strange thing happening, related to ARP and IP fragments.
It seems that Bill Paul saw the same thing back in 1998
(http://www.geocrawler.com/mail/msg.php3?msg_id=822366&list=165) but I
couldn't find wheter this was ever resolved or not.
Correction:
> The
Hi,
we're seeing a strange thing happening, related to ARP and IP fragments.
In the tcpdump below, ifc is trying to send a large UDP message (~3x
MTU) to dee. It does not have dee's MAC address in its ARP cache
(happens both after an ARP timeout or an explicit ARP cache flush.)
The ARP reques
