Hello,
On Tue, 21 May 2001, Andrey Savochkin wrote:
> Hi,
>
> Here are the patches.
>
> The first one implements selection of IP addresses of ARP requests based on
> the routing table. It allows to eliminate pollution of ARP caches of
> neighbors by our local IP addresses for which we don't want to provide our
> link-level address.
> Additionally, it skips arp filtering mechanism for PACKET_HOST packets, which
> was proposed by Alexey, if I remember.
>
> Two comments:
> 1. I don't completely understand how the current code works for the case
> of forwarding of packets and looking up for link-level address of the next
> gateway. Do I get it right that IP source of ARP request will be wrong?
I have the same feeling
> Or I misunderstand what we queue in neigh->arp_queue?
> 2. The big `if'
> if (arp->ar_op == __constant_htons(ARPOP_REQUEST) &&
> ip_route_input(skb, tip, sip, 0, dev) == 0)
> looks suspicious.
> If ip_route_input fails (e.g., because rejecting route is installed), we fall
> back into just updating of the neighbor state to NUD_REACHABLE.
> The packets from this neighbor are rejected.
> Is it a good reason to immediately consider it as "reachable"?
3. rt is not released after ip_route_output
4. Do we need to distinguish the input/output routes based on
rt_iif != 0, for example:
/* Determine source IP for the probing packet. */
rt = NULL;
saddr = 0;
if (skb != NULL) {
rt = (struct rtable*)skb->dst;
if (!rt->rt_iif) {
/* Is it always local? */
saddr = rt->rt_src;
}
}
if (saddr == 0) {
if (ip_route_output(&rt, target, 0, RTO_ONLINK, dev->ifindex) <
0)
/* Never send probes with 0 source as we used to. */
return;
saddr = rt->rt_src;
ip_rt_put(rt);
if (!saddr)
return;
}
i.e.:
- is it right to avoid the input routes?
- is rt_src always local in 2.4
- ONLINK
> The second patch is for Julian.
> I understand that the current scheme is not extremely convenient for you.
> As you explained, for the configuration
> Source/Gateway - Redirector - Host,
> where Redirector and Host has the same IP address and the address isn't
> exposed on Host, arp_filter patch requires you to block all IP communications
> between Source/Gateway and Host.
> If you want to have more filtering abilities, the second patch provides the
> first step: a per-rtentry flag no blocking IP communications and disallowing
> answering ARP requests. You just need to add an interface to set this flag
> from the userspace, by iproute.
Filtering by routes is not my dream but give me some days to
think on it (of course this patch #2 is not for 2.4.5, I hope :)).
- In my case control over the announced source in the probe is needed
- RTF_NOARPREPLY: is it for unicast routes only? The filtering isn't
for routes to local (ip_route_input)?
> Andrey
Regards
--
Julian Anastasov <ja@xxxxxx>
|