Bug? ARP with wrong src IP address

Bug? ARP with wrong src IP address

[Carlos Velasco]

Hi,

Problem Description:

1 ethernet interface IP (eth0): 192.168.128.16 netmask 255.255.255.0
1 loopback address IP (lo:2): 1.1.1.1 netmask 255.255.255.255
1 route to 2.2.2.2 through 192.168.128.60

A packet is sent from machine with IP 2.2.2.2 to the linux machine to dst IP 
1.1.1.1 (lo:2) through ethernet interface (eth0).

When linux machine tries to find out the mac address of 192.168.128.60 with 
ARP, it uses the loopback IP address (lo:2) as source insted of the IP address 
of the ethernet interface (eth0).

tcpdump output:
> tcpdump -nei eth0 arp or host 2.2.2.2
tcpdump: listening on eth0

00:29:38.385849 0:c:85:1f:a3:d6 0:48:54:6a:3a:dd 0800 64: 2.2.2.2.55302 > 
1.1.1.1.23: S 4186612861:4186612861(0) win 4128 <mss 1460> (DF) [tos 0xc0] 
00:29:38.386200 0:48:54:6a:3a:dd ff:ff:ff:ff:ff:ff 0806 42: arp who-has 
192.168.128.60 tell 1.1.1.1
00:29:39.385310 0:48:54:6a:3a:dd ff:ff:ff:ff:ff:ff 0806 42: arp who-has 
192.168.128.60 tell 1.1.1.1


ifconfig output:
> ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:48:54:6A:3A:DD  
          inet addr:192.168.128.16  Bcast:192.168.128.255  Mask:255.255.255.0
          inet6 addr: fe80::248:54ff:fe6a:3add/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2695 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2829 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:308510 (301.2 Kb)  TX bytes:353754 (345.4 Kb)
          Interrupt:15 Base address:0xe000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:379 errors:0 dropped:0 overruns:0 frame:0
          TX packets:379 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:136862 (133.6 Kb)  TX bytes:136862 (133.6 Kb)

lo:2      Link encap:Local Loopback  
          inet addr:1.1.1.1  Mask:255.255.255.255
          UP LOOPBACK RUNNING  MTU:16436  Metric:1


route print:
> ip route list
2.2.2.2 via 192.168.128.60 dev eth0 
192.168.128.0/24 dev eth0  proto kernel  scope link  src 192.168.128.16 
default via 192.168.128.200 dev eth0  mtu 300

arp table:
> arp -a
? (192.168.128.202) at 00:30:B6:01:17:80 [ether] on eth0
router.newipnet.com (192.168.128.200) at 00:0C:85:1F:A3:D6 [ether] on eth0
? (192.168.128.60) at <incomplete> on eth0
madre.newipnet.com (192.168.128.4) at 00:E0:7D:7B:D3:8E [ether] on eth0


Steps to reproduce:

1. Setup Loopback interface
2. clear arp table
3. setup a route in another PC to reach the loopback address through IP in 
ethernet interface in linux box.
4. use ping from another PC to the loopback ip address.
5. You can see the ARP requests with wrong ip source address in linux box with 
tcpdump or ethereal.



Possible Patch (I have tried it and works, but not know if it's 100% accurate):

--- linux-2.6.0-test1/net/ipv4/arp.c      Mon Jul 14 05:37:28 2003
+++ linux-2.6.0-test1-patch/net/ipv4/arp.c    Wed Jul 23 15:31:29 2003
@@ -326,10 +326,14 @@
        u32 target = *(u32*)neigh->primary_key;
        int probes = atomic_read(&neigh->probes);
 
+        /* This don't work if the src addr is a loopback or similar.
+          See http://bugzilla.kernel.org/show_bug.cgi?id=978 
+
        if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL)
                saddr = skb->nh.iph->saddr;
-       else
-               saddr = inet_select_addr(dev, target, RT_SCOPE_LINK);
+       else */
+
+       saddr = inet_select_addr(dev, target, RT_SCOPE_LINK);
 
        if ((probes -= neigh->parms->ucast_probes) < 0) {
                if (!(neigh->nud_state&NUD_VALID))



Bug is reported in bugzilla:
http://bugzilla.kernel.org/show_bug.cgi?id=978


Regards,
Carlos Velasco

Bug? ARP with wrong src IP address

[Carlos Velasco]

Hi,

Problem Description:

1 ethernet interface IP (eth0): 192.168.128.16 netmask 255.255.255.0
1 loopback address IP (lo:2): 1.1.1.1 netmask 255.255.255.255
1 route to 2.2.2.2 through 192.168.128.60

A packet is sent from machine with IP 2.2.2.2 to the linux machine to dst IP 
1.1.1.1 (lo:2) through ethernet interface (eth0).

When linux machine tries to find out the mac address of 192.168.128.60 with 
ARP, it uses the loopback IP address (lo:2) as source insted of the IP address 
of the ethernet interface (eth0).

tcpdump output:
> tcpdump -nei eth0 arp or host 2.2.2.2
tcpdump: listening on eth0

00:29:38.385849 0:c:85:1f:a3:d6 0:48:54:6a:3a:dd 0800 64: 2.2.2.2.55302 > 
1.1.1.1.23: S 4186612861:4186612861(0) win 4128 <mss 1460> (DF) [tos 0xc0] 
00:29:38.386200 0:48:54:6a:3a:dd ff:ff:ff:ff:ff:ff 0806 42: arp who-has 
192.168.128.60 tell 1.1.1.1
00:29:39.385310 0:48:54:6a:3a:dd ff:ff:ff:ff:ff:ff 0806 42: arp who-has 
192.168.128.60 tell 1.1.1.1


ifconfig output:
> ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:48:54:6A:3A:DD  
          inet addr:192.168.128.16  Bcast:192.168.128.255  Mask:255.255.255.0
          inet6 addr: fe80::248:54ff:fe6a:3add/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2695 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2829 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:308510 (301.2 Kb)  TX bytes:353754 (345.4 Kb)
          Interrupt:15 Base address:0xe000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:379 errors:0 dropped:0 overruns:0 frame:0
          TX packets:379 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:136862 (133.6 Kb)  TX bytes:136862 (133.6 Kb)

lo:2      Link encap:Local Loopback  
          inet addr:1.1.1.1  Mask:255.255.255.255
          UP LOOPBACK RUNNING  MTU:16436  Metric:1


route print:
> ip route list
2.2.2.2 via 192.168.128.60 dev eth0 
192.168.128.0/24 dev eth0  proto kernel  scope link  src 192.168.128.16 
default via 192.168.128.200 dev eth0  mtu 300

arp table:
> arp -a
? (192.168.128.202) at 00:30:B6:01:17:80 [ether] on eth0
router.newipnet.com (192.168.128.200) at 00:0C:85:1F:A3:D6 [ether] on eth0
? (192.168.128.60) at <incomplete> on eth0
madre.newipnet.com (192.168.128.4) at 00:E0:7D:7B:D3:8E [ether] on eth0


Steps to reproduce:

1. Setup Loopback interface
2. clear arp table
3. setup a route in another PC to reach the loopback address through IP in 
ethernet interface in linux box.
4. use ping from another PC to the loopback ip address.
5. You can see the ARP requests with wrong ip source address in linux box with 
tcpdump or ethereal.



Possible Patch (I have tried it and works, but not know if it's 100% accurate):

--- linux-2.6.0-test1/net/ipv4/arp.c      Mon Jul 14 05:37:28 2003
+++ linux-2.6.0-test1-patch/net/ipv4/arp.c    Wed Jul 23 15:31:29 2003
@@ -326,10 +326,14 @@
        u32 target = *(u32*)neigh->primary_key;
        int probes = atomic_read(&neigh->probes);
 
+        /* This don't work if the src addr is a loopback or similar.
+          See http://bugzilla.kernel.org/show_bug.cgi?id=978 
+
        if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL)
                saddr = skb->nh.iph->saddr;
-       else
-               saddr = inet_select_addr(dev, target, RT_SCOPE_LINK);
+       else */
+
+       saddr = inet_select_addr(dev, target, RT_SCOPE_LINK);
 
        if ((probes -= neigh->parms->ucast_probes) < 0) {
                if (!(neigh->nud_state&NUD_VALID))



Bug is reported in bugzilla:
http://bugzilla.kernel.org/show_bug.cgi?id=978


Regards,
Carlos Velasco

Re: Bug? ARP with wrong src IP address

[Julian Anastasov]

	Hello,

On Wed, 23 Jul 2003, Carlos Velasco wrote:

> When linux machine tries to find out the mac address of 192.168.128.60 with
> ARP, it uses the loopback IP address (lo:2) as source insted of the IP address
> of the ethernet interface (eth0).

	You are right but the kernel tries to preserve the sender's
IP. This helps the receiver to select the best interface
to answer this ARP probe - the same where the IP packet will be
accepted later. As there are different setups, the tuning of the
ARP handling can be done better with user tools such as arptables
and iparp.

http://sourceforge.net/projects/ebtables/
http://www.ssi.bg/~ja/#iparp

> Regards,
> Carlos Velasco

Regards

--
Julian Anastasov <ja@ssi.bg>

Re: Bug? ARP with wrong src IP address

[Carlos Velasco]

On 24/07/2003 at 2:01 Julian Anastasov wrote:

>> When linux machine tries to find out the mac address of 192.168.128.60
>with
>> ARP, it uses the loopback IP address (lo:2) as source insted of the IP
>address
>> of the ethernet interface (eth0).
>
>	You are right but the kernel tries to preserve the sender's
>IP. This helps the receiver to select the best interface
>to answer this ARP probe - the same where the IP packet will be
>accepted later. As there are different setups, the tuning of the
>ARP handling can be done better with user tools such as arptables
>and iparp.

Julian,

The linux box is trying to do an ARP request with a source IP address that has not sense in that ethernet network. It's imposible to obtain a reply in that way. Although the receiver would have a route to the loopback address through ethernet interface it would never reply such a ARP request.
IMHO it's a bug. Loopback IP address has not any sense on the eth0 network.

Linux receives the packet destination loopback address and then performs a lookup in the route table to reach the src address.
It takes the route (ex. default) and is on eth0 interface, then does the arp request.
As the route is in eth0, it must use the src IP address of eth0, not the loopback address.

If we have more than 1 IP address in eth0 (eth:0, eth:1) I suppose that the route table must distinguish the right interface for ARP.

I have tried to reproduce the same problem with a Cisco router with IOS 12.2(15)T5, but it works fine in Cisco.
I will try to test on Solaris 8, but I think the only problem is in linux.


>http://sourceforge.net/projects/ebtables/
>http://www.ssi.bg/~ja/#iparp

I didn't know about these tools.
I have taken a look on them, but they seem to be used for arp filtering?
I can't see how these tools can help me into this.

My workaround with linux is to use static arps for solving this problem (arp -s).

Regards,
Carlos Velasco

Re: Bug? ARP with wrong src IP address

[Bart De Schuymer]

On Thursday 24 July 2003 01:34, Carlos Velasco wrote:
> >http://sourceforge.net/projects/ebtables/
> >http://www.ssi.bg/~ja/#iparp
>
> I didn't know about these tools.
> I have taken a look on them, but they seem to be used for arp filtering?
> I can't see how these tools can help me into this.

arptables can mangle the arp payload with the "mangle" module. You'll need a 
very recent kernel for this, net/ipv4/netfilter/arpt_mangle.c must exist. The 
userspace code for this is in the CVS at the mentioned site, I haven't made a 
new release yet due to lack of time.

cheers,
Bart

Re: Bug? ARP with wrong src IP address

[Carlos Velasco]

On 24/07/2003 at 11:30 Bart De Schuymer wrote:

>arptables can mangle the arp payload with the "mangle" module. You'll need
>a 
>very recent kernel for this, net/ipv4/netfilter/arpt_mangle.c must exist.
>The 
>userspace code for this is in the CVS at the mentioned site, I haven't
>made a 
>new release yet due to lack of time.


Thanks Bart,

However I don't see how these tools can help in this ARP problem.
There is no need of filtering or mangling arp, the problem is an incorrect arp being sent.

Regards,
Carlos Velasco

Re: Bug? ARP with wrong src IP address

[Julian Anastasov]

	Hello,

On Thu, 24 Jul 2003, Carlos Velasco wrote:

> On 24/07/2003 at 11:30 Bart De Schuymer wrote:
>
> However I don't see how these tools can help in this ARP problem.
> There is no need of filtering or mangling arp, the problem is an incorrect arp being sent.

	The src IP in the ARP probe is a hint. In most of the
cases it is ignored. But the receiver has the right to answer
based on it. You know, the reply is sent to the sender's hwaddr,
not to the src IP. Also, Linux always replies if the remote host asks
for IP configured on loopback interface. So, there is no problem.
If the remote system has your patch, there is also no problem.
What kind of problems do you see except the loopback IP as sender
IP? Dropped probes? Unanswered probes?

> Regards,
> Carlos Velasco

Regards

--
Julian Anastasov <ja@ssi.bg>

Re: Bug? ARP with wrong src IP address

[Carlos Velasco]

On 24/07/2003 at 14:04 Julian Anastasov wrote:

>	The src IP in the ARP probe is a hint. In most of the
>cases it is ignored. But the receiver has the right to answer
>based on it. You know, the reply is sent to the sender's hwaddr,
>not to the src IP. Also, Linux always replies if the remote host asks
>for IP configured on loopback interface. So, there is no problem.
>If the remote system has your patch, there is also no problem.
>What kind of problems do you see except the loopback IP as sender
>IP? Dropped probes? Unanswered probes?

Julian,

The problem is more complicated than the simplified setting I have builded for describing the bug:
Real setting and meaning of the lo interface is because I'm using IOS Load Balancing in dispatched mode on Cisco Catalyst 6500.
This cause packets being sent to a server farm of Linux boxes with destination IP the one configured on the loopback interface in all machines.
In the ethernet interface all Linux boxes have diferent IP address and the balancing device send the packets through any of these interfaces, choosing the "leastconnections" server.
Thus, the load balancing device only change the mac address of the real packet on the fly sending it to one of the real servers where it's accepted cause of destination IP is the loopback IP address on every Linux machine.

Problem is when the packet go back to the balancing device, as they send ARP request with loopback source IP address, that cause Cisco device not to reply the ARP request.
I have tried different IOS and Cisco devices, no one reply this ARP request.


As you have stated in your last e-mail I checked the RFC (if I'm not wrong it's rfc826) to see if when replying an ARP request the source IP address need to be correct and stepped into this:

"
      ?Is the opcode ares_op$REQUEST?  (NOW look at the opcode!!)
      Yes:
	Swap hardware and protocol fields, putting the local
	    hardware and protocol addresses in the sender fields.
	Set the ar$op field to ares_op$REPLY
	Send the packet to the (new) target hardware address on
	    the same hardware on which the request was received.
"

According to this, I think YOU ARE RIGHT and the source IP address should not be checked when replying to this ARP Request.

I have setup another setting forcing a windows machine to be the default route of the linux box and see if windows OS replied to this ARP request... and IT DID.

For now, I'm going to contact Cisco TAC and open a case to see if the bug is in Cisco IOS.
Will keep you posted about this issue if you want to.

Regards,
Carlos Velasco

Re: Bug? ARP with wrong src IP address

[Julian Anastasov]

	Hello,

On Thu, 24 Jul 2003, Carlos Velasco wrote:

> The problem is more complicated than the simplified setting I have builded for describing the bug:
> Real setting and meaning of the lo interface is because I'm using IOS Load Balancing in dispatched mode on Cisco Catalyst 6500.
> This cause packets being sent to a server farm of Linux boxes with destination IP the one configured on the loopback interface in all machines.
> In the ethernet interface all Linux boxes have diferent IP address and the balancing device send the packets through any of these interfaces, choosing the "leastconnections" server.
> Thus, the load balancing device only change the mac address of the real packet on the fly sending it to one of the real servers where it's accepted cause of destination IP is the loopback IP address on every Linux machine.
>
> Problem is when the packet go back to the balancing device, as they send ARP request with loopback source IP address, that cause Cisco device not to reply the ARP request.
> I have tried different IOS and Cisco devices, no one reply this ARP request.

	I now see, it is the so called "ARP Problem" in the IPVS
context, many real servers and one director sharing same virtual
IP:

http://www.linuxvirtualserver.org/

The most used feature for such setups:
http://www.ssi.bg/~ja/#hidden

> Regards,
> Carlos Velasco

Regards

--
Julian Anastasov <ja@ssi.bg>

Re: Bug? ARP with wrong src IP address

[Carlos Velasco]

On 24/07/2003 at 18:54 Julian Anastasov wrote:

>	I now see, it is the so called "ARP Problem" in the IPVS
>context, many real servers and one director sharing same virtual
>IP:
>
>http://www.linuxvirtualserver.org/
>
>The most used feature for such setups:
>http://www.ssi.bg/~ja/#hidden

Julian,

This would be another approach, configuring the IP address on the ethernet interface (ex. eth0:2) and not advertising or replying arp with the hidden patch.
However the usual approach is configuring the destination IP address on a loopback interface that does real "hiding" as it's no more in ethernet interface.

Dispatched mode:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1833/products_feature_guide09186a0080086f2b.html#2728293

As long as I know, Solaris 8 and Windows 2000 have no problems with the ARP Request, as they use the src IP address of the ethernet interface. But as I have seen in the RFC it seems that Cisco devices should reply to this ARP request without looking into the source ip address.

I will open a TAC case and see if they raise a bug.

Regards,
Carlos Velasco

Re: Bug? ARP with wrong src IP address

[Julian Anastasov]

	Hello,

On Thu, 24 Jul 2003, Carlos Velasco wrote:

> This would be another approach, configuring the IP address on the 
> ethernet interface (ex. eth0:2) and not advertising or replying arp with 
> the hidden patch.
> However the usual approach is configuring the destination IP address on 
> a loopback interface that does real "hiding" as it's no more in ethernet 
> interface.

	The Linux concept differs. As for hidden, it works for 
different interface, not for the one where the probe is received. The 
alias names do not play here.

> As long as I know, Solaris 8 and Windows 2000 have no problems with the 
> ARP Request, as they use the src IP address of the ethernet interface. 
> But as I have seen in the RFC it seems that Cisco devices should reply 
> to this ARP request without looking into the source ip address.

	There are some exceptions for the src IP. Even Linux will
not reply if the src IP in incoming probe matches local IP. But
may be only Linux preserves the src IP in outgoing probes.

Regards

--
Julian Anastasov <ja@ssi.bg>

Re: Bug? ARP with wrong src IP address

[Carlos Velasco]

On 24/07/2003 at 19:32 Julian Anastasov wrote:

>	There are some exceptions for the src IP. Even Linux will
>not reply if the src IP in incoming probe matches local IP. But
>may be only Linux preserves the src IP in outgoing probes.

I think so, I don't like that src IP in outgoing probes... but as Windows OS replies to this ARP can't see why Cisco IOS is not replying.
Will open a TAC case tomorrow. I'm interested on testing this in Solaris.

Regards,
Carlos Velasco

Re: Bug? ARP with wrong src IP address

[Carlos Velasco]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 973 bytes --]

On 24/07/2003 at 18:36 Carlos Velasco wrote:

>>	There are some exceptions for the src IP. Even Linux will
>>not reply if the src IP in incoming probe matches local IP. But
>>may be only Linux preserves the src IP in outgoing probes.

Tested these platforms:

Solaris 8 -> sends src IP address of INTERFACE
Cisco -> sends src IP address of INTERFACE
Windows 2000, XP -> sends src IP address of INTERFACE
Linux 2.6.0-pre1, 2.4.20, 2.4.21 -> sends src IP address of LOOPBACK

Question: ¿What would be the implications of applying my patch or similar to do linux behave like other OS?

>Will open a TAC case tomorrow. I'm interested on testing this in Solaris.

Same tests:

Solaris 8 -> replies the ARP request
Windows 2000, XP -> replies the ARP request
Linux 2.4.21 -> replies the ARP request
Cisco -> NOT replies the ARP request

I will contact Cisco to see why they don't do and if it can be fixed in future releases.

Regards,
Carlos Velasco

Re: Bug? ARP with wrong src IP address

[David S. Miller]

On Thu, 24 Jul 2003 20:11:42 +0200
"Carlos Velasco" <carlosev@newipnet.com> wrote:

> Tested these platforms:
> 
> Solaris 8 -> sends src IP address of INTERFACE
> Cisco -> sends src IP address of INTERFACE
> Windows 2000, XP -> sends src IP address of INTERFACE
> Linux 2.6.0-pre1, 2.4.20, 2.4.21 -> sends src IP address of LOOPBACK
> 
> Question: _What would be the implications of applying my patch or similar to do linux behave like other OS?

You'll break things for people who depend upon the
way Linux currently behaves.

Re: Bug? ARP with wrong src IP address

[Carlos Velasco]

On 24/07/2003 at 11:37 David S. Miller wrote:

>> Question: _What would be the implications of applying my patch or
>similar to do linux behave like other OS?
>
>You'll break things for people who depend upon the
>way Linux currently behaves.

Well, really the question is: What are these situations exactly? IMHO... the patch is only changing the src ip address for arp requests on a few situations.

Regards,
Carlos Velasco

Re: Bug? ARP with wrong src IP address

[David S. Miller]

On Thu, 24 Jul 2003 18:54:04 +0300 (EEST)
Julian Anastasov <ja@ssi.bg> wrote:

> The most used feature for such setups:
> http://www.ssi.bg/~ja/#hidden

The hidden patch is not necessary with current kernels and arpfilter.

Re: Bug? ARP with wrong src IP address

[Carlos Velasco]

On 24/07/2003 at 9:10 David S. Miller wrote:

>The hidden patch is not necessary with current kernels and arpfilter.

arp_filter doesn't work.
If I'm not wrong it's applied when you have two or more interfaces in the same subnet. This is not the case.

I have applied hidden patch and it works.
If I'm not wrong, the hidden patch makes linux behave like other OS, separating selected interfaces of another interfaces.
It does not break anything because it's all configurable in /proc.

Maybe it would be good including it in the kernel package?

Regards,
Carlos Velasco

Re: Bug? ARP with wrong src IP address

[David S. Miller]

On Fri, 25 Jul 2003 20:24:19 +0200
"Carlos Velasco" <carlosev@newipnet.com> wrote:

> On 24/07/2003 at 9:10 David S. Miller wrote:
> 
> >The hidden patch is not necessary with current kernels and arpfilter.
> 
> arp_filter doesn't work.

This is impossible, hidden is a subset of what arpfilter can do.

arpfilter is a netfilter module that can block ARP packets
at any point in the networking stack, at your choosing.

Re: Bug? ARP with wrong src IP address

[Carlos Velasco]

On 25/07/2003 at 11:46 David S. Miller wrote:

>This is impossible, hidden is a subset of what arpfilter can do.
>
>arpfilter is a netfilter module that can block ARP packets
>at any point in the networking stack, at your choosing.

Maybe I'm looking in the wrong place.

I have tried with this setting in /proc:

===
arp_filter - BOOLEAN
        1 - Allows you to have multiple network interfaces on the same
        subnet, and have the ARPs for each interface be answered
        based on whether or not the kernel would route a packet from
        the ARP'd IP out that interface (therefore you must use source
        based routing for this to work). In other words it allows control
        of which cards (usually 1) will respond to an arp request.
===

Should I need any user space program to configure it or so?

Regards,
Carlos Velasco

Re: Bug? ARP with wrong src IP address

[David S. Miller]

On Fri, 25 Jul 2003 20:36:05 +0200
"Carlos Velasco" <carlosev@newipnet.com> wrote:

> On 25/07/2003 at 11:46 David S. Miller wrote:
> 
> >This is impossible, hidden is a subset of what arpfilter can do.
> >
> >arpfilter is a netfilter module that can block ARP packets
> >at any point in the networking stack, at your choosing.
> 
> Maybe I'm looking in the wrong place.

You are, I'm not talking about the sysconfig setting.

I'm talking about a netfilter module, and yes it does require
a tool for configuration which Bart DeSchuym has written, he
posted a link to his work earlier in these threads.

Re: Bug? ARP with wrong src IP address

[Carlos Velasco]

On 25/07/2003 at 11:59 David S. Miller wrote:

>I'm talking about a netfilter module, and yes it does require
>a tool for configuration which Bart DeSchuym has written, he
>posted a link to his work earlier in these threads.

Well, I consider the hiding patch to be a simplier and better approach to this strange behaviour in Linux (compared to other OS and systems) than needing to include and compile netfilter in the kernel. However I will take a look at it.

I have searched and found that this is not the first time that this discussion has raised:

http://www.ussg.iu.edu/hypermail/linux/kernel/0212.0/1128.html

Really I am 100% in accordance with this:

===
I still don't see why an address that is 
-=ASSIGNED TO AN INTERFACE=- should be responded to on a completely 
different interface... if we wanted the ip address to be assigned to the 
system, there should be a pseudo interface that will work on any of the 
interfaces attached. Why assign an address to an interface if it would work 
just the same if you assigned it to the loopback adapter? Why would you 
assign an address to the loopback adapter if you wanted it to be accessed 
from the world? 
===

Is "hiding" incompatible with any other feature?

Regards,
Carlos Velasco