netdev - Question about arp_error_report() (IPV4): clarification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <147a89290801050043p24b3a116j75dc58954cdf8ed7@mail.gmail.com>
Date:	Sat, 5 Jan 2008 10:43:24 +0200
From:	"Andy Johnson" <johnsonzjo@...il.com>
To:	netdev@...r.kernel.org
Subject: Question about arp_error_report() (IPV4): clarification

Hi,
In neigh_timer_handler( ),  (core/neighbour.c), there is a comment which says:

# It is very thin place. report_unreachable is very complicated
# routine. Particularly, it can hit the same neighbour entry!

#  So that, we try to be accurate and avoid dead loop. --ANK

I tried to figure exactly what this comment mean (when dealing with IPV4).
 Can someone elaborate in 3-4 sentences on it ?

Why  "hit the same neighbour entry" can cause any complications ?
Why is report_unreachable() considered complicated ?
It seems to be simple, or am I missing something?

As far as I understand, eventually  ipv4_link_failure()
(net/ipv4/route.c) is called when  report_unreachable() is invoked.

(The path is: arp_error_report() calls dst_link_failure(skb), which in
case of ipv4, calls ipv4_link_failure().)
So it seems simply a matter of calling eventually ipv4_link_failure(),
which ends up with generating ICMP.

Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html