Re: problem with ethernet loopback test using loopback plug/stub: receiving socket not seeing packet.

In comp.os.linux.networking mcharon <(E-Mail Removed)> wrote:
> we are writing socket application to send UDP packets out from eth1
> and loop it back to the same interface using loopback stub to verify
> the hardware without using external devices/ports. The sending and
> receiving port are the same.

> our target machine has eth0 configured as 15.6.xx.xx and eth1
> configured as 16.6.6.6.

> the listening socket is listing on all ip.

> .

> When we looked at the packet in the tx code of the driver, we have
> observed that the packet passed down from the ip stack has the same
> MAC address for both source and destination. Also when packet is
> returning, its ip source and destination are the same as the
> transmitting packet, which is to be expected.

> The outgoing packet on eth1 has ip address of 16.6.10.10.

Is that what your application is using for the destination IP address?
Have you also tried to setup permanent ARP entries for that?

> 1. Is this type of loopback possible under linux?
> 2 Is it better to send raw packet, or should UDP work as well?
> 3. is there a similar code that we can leverage?
> 4. the returning (incoming) packet is lost after the driver passes it
> to the ip stack. The receving socket is not able to retrieve packets
> the driver receives.
> What could be some of the issues?

I was under the impression that if one targetted one's own IP address,
"the stack" would intercept that before it even got to the driver. On
inbound, if the destination IP address does not match a locally
assigned IP, the datagram is dropped, or the stack will attempt to
forward it if ip_foward(ing?) is set.

You may have to do things at the link-level.

rick jones
--
No need to believe in either side, or any side. There is no cause.
There's only yourself. The belief is in your own precision. - Joubert
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Hello,

Rick Jones a écrit :
>
> I was under the impression that if one targetted one's own IP address,
> "the stack" would intercept that before it even got to the driver.

It is not an impression. The Linux IP stack routes locally generated
packets to local destination addresses through the internal loopback
interface, lo.

> On inbound, if the destination IP address does not match a locally
> assigned IP, the datagram is dropped, or the stack will attempt to
> forward it if ip_foward(ing?) is set.

The packet is dropped also if it is received on a non loopback interface
and has a local source IP address. An externally looped back interface
does not count as a loopback interface.

> You may have to do things at the link-level.

I agree.

On 2010-08-18, Pascal Hambourg <boite-a-(E-Mail Removed)> wrote:
> Hello,
>
> Rick Jones a ?crit :
>>
>> I was under the impression that if one targetted one's own IP address,
>> "the stack" would intercept that before it even got to the driver.
>
> It is not an impression. The Linux IP stack routes locally generated
> packets to local destination addresses through the internal loopback
> interface, lo.
>
>> On inbound, if the destination IP address does not match a locally
>> assigned IP, the datagram is dropped, or the stack will attempt to
>> forward it if ip_foward(ing?) is set.
>
> The packet is dropped also if it is received on a non loopback interface
> and has a local source IP address. An externally looped back interface
> does not count as a loopback interface.
>
>> You may have to do things at the link-level.
>
> I agree.

Or stick two cards into the machine and route from one to the other? Or
does the stack detect that as well and short circuit it?

unruh a écrit :
> On 2010-08-18, Pascal Hambourg <boite-a-(E-Mail Removed)> wrote:
>>
>> Rick Jones a ?crit :
>>> I was under the impression that if one targetted one's own IP address,
>>> "the stack" would intercept that before it even got to the driver.
>>
>> It is not an impression. The Linux IP stack routes locally generated
>> packets to local destination addresses through the internal loopback
>> interface, lo.
>>
>>> On inbound, if the destination IP address does not match a locally
>>> assigned IP, the datagram is dropped, or the stack will attempt to
>>> forward it if ip_foward(ing?) is set.
>>
>> The packet is dropped also if it is received on a non loopback interface
>> and has a local source IP address. An externally looped back interface
>> does not count as a loopback interface.
>>
>>> You may have to do things at the link-level.
>>
>> I agree.
>
> Or stick two cards into the machine and route from one to the other? Or
> does the stack detect that as well and short circuit it?

It does not change anything regarding the IP stack. Local addresses are
still routed through lo and extra network cards are still non loopback
interfaces.

mcharon <(E-Mail Removed)> writes:
> On Aug 18, 1:17*am, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org>
> wrote:
>> Rick Jones a écrit :
>> > I was under the impression that if one targetted one's own IP address,
>> > "the stack" would intercept that before it even got to the driver.
>>
>> It is not an impression. The Linux IP stack routes locally generated
>> packets to local destination addresses through the internal loopback
>> interface, lo.
>>
>> > On inbound, if the destination IP address does not match a locally
>> > assigned IP, the datagram is dropped, or the stack will attempt to
>> > forward it if ip_foward(ing?) is set.
>>
>> The packet is dropped also if it is received on a non loopback interface
>> and has a local source IP address. An externally looped back interface
>> does not count as a loopback interface.

[...]

> in our setup that i described above, we are able to send the packet to
> the driver, and the packet is not being intercepted by lo interface.
> the packet also loop backs via loopback stub but we just can't hand it
> back to the application.

Is the so-called rp_filter active on your system?
From linux/Documentation/networking/ip-sysctl.txt:

,----
| rp_filter - INTEGER
| 0 - No source validation.
| 1 - Strict mode as defined in RFC3704 Strict Reverse Path
| Each incoming packet is tested against the FIB and if the interface
| is not the best reverse path the packet check will fail.
| By default failed packets are discarded.
| 2 - Loose mode as defined in RFC3704 Loose Reverse Path
| Each incoming packet's source address is also tested against the FIB
| and if the source address is not reachable via any interface
| the packet check will fail.
|
| Current recommended practice in RFC3704 is to enable strict mode
| to prevent IP spoofing from DDos attacks. If using asymmetric routing
| or other complicated routing, then loose mode is recommended.
|
| The max value from conf/{all,interface}/rp_filter is used
| when doing source validation on the {interface}.
`----

The path prefix is /proc/sys/net/ipv4.

mcharon <(E-Mail Removed)> writes:
> On Aug 18, 10:46*am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> mcharon <mcha...@gmail.com> writes:

[...]

>> >> The packet is dropped also if it is received on a non loopback interface
>> >> and has a local source IP address. An externally looped back interface
>> >> does not count as a loopback interface.
>>
>> [...]
>>
>> > in our setup that i described above, we are able to send the packet to
>> > the driver, and the packet is not being intercepted by lo interface.
>> > the packet also loop backs via loopback stub but we just can't hand it
>> > back to the application.
>>
>> Is the so-called rp_filter active on your system?
>> From linux/Documentation/networking/ip-sysctl.txt:
>>
>> ,----
>> | rp_filter - INTEGER
>> | * * * * 0 - No source validation.

[...]

>> The path prefix is /proc/sys/net/ipv4.
>
> hi rainer, looks like our rp_filter is preconfigured to 0...i assume
> this is the correct setting.

This depends on what you want to do with it. 0 means 'no source
address verification', IOW, someone who can send a datagram to the
machine can use any source address he desires, including locally
configured ones, even 127.0.0.1. OTOH, the kernel shouldn't block
datagrams received on one interface which seems to be 'non-local'
(received from a NIC) but have a locally configured source address.

You could add logging rules to various of the existing netfilter
chains in order to get an idea what happens to your datagram. AFAIK,
it should travel from PREOUTING/raw -> PREOUTING/nat -> INPUT/filter.
(<chain>/<table>) and then be delivered.

mcharon <(E-Mail Removed)> writes:
> On Aug 18, 10:46*am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> mcharon <mcha...@gmail.com> writes:

[...]

>> >> The packet is dropped also if it is received on a non loopback interface
>> >> and has a local source IP address. An externally looped back interface
>> >> does not count as a loopback interface.
>>
>> [...]
>>
>> > in our setup that i described above, we are able to send the packet to
>> > the driver, and the packet is not being intercepted by lo interface.
>> > the packet also loop backs via loopback stub but we just can't hand it
>> > back to the application.
>>
>> Is the so-called rp_filter active on your system?
>> From linux/Documentation/networking/ip-sysctl.txt:
>>
>> ,----
>> | rp_filter - INTEGER
>> | * * * * 0 - No source validation.

[...]

>> The path prefix is /proc/sys/net/ipv4.
>
> hi rainer, looks like our rp_filter is preconfigured to 0...i assume
> this is the correct setting.

This depends on what you want to do with it. 0 means 'no source
address verification', IOW, someone who can send a datagram to the
machine can use any source address he desires, including locally
configured ones, even 127.0.0.1. OTOH, the kernel shouldn't block
datagrams received on one interface which seems to be 'non-local'
(received from a NIC) but have a locally configured source address.

You could add logging rules to various of the existing netfilter
chains in order to get an idea what happens to your datagram. AFAIK,
it should travel from PREROUTING/raw -> PREROUTING/nat -> INPUT/filter.
(<chain>/<table>) and then be delivered.

Rainer Weikusat a écrit :
> mcharon <(E-Mail Removed)> writes:
>> looks like our rp_filter is preconfigured to 0...i assume
>> this is the correct setting.
>
> This depends on what you want to do with it. 0 means 'no source
> address verification', IOW, someone who can send a datagram to the
> machine can use any source address he desires, including locally
> configured ones, even 127.0.0.1.

No. rp_filter=0 means no source address validation *by reversed path*.
Invalid source addresses, including 127.0.0.1 on non-loopback
interfaces, are still discarded.

I can appreciate the desire to be able to test network hardware
without an actual network present, but, short of doing everything at
layer2 and likely still having to have two NIC ports in the system, it
is going to be at best a "delicately robust" situation, prone to
breaking down at the slightest deviation from the required conditions.

You really should see about being able to do this testing with a
second system present.

rick jones
--
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

mcharon a écrit :
>
> hi Pascal/Rainer, can you explain how to create these rules, or is
> there a way to request the kernel to not drop any packets, even the
> bad ones, within the stack.

Sorry but AFAIK, the IP stack drops "bad" packets and this cannot be
disabled.