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

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

Post by mcharo » Thu, 19 Aug 2010 09:54:22



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.

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?

Thank you in advance.

 
 
 

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

Post by Rick Jone » Thu, 19 Aug 2010 10:13:33



Quote:> 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?

Quote:> 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...

 
 
 

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

Post by mcharo » Thu, 19 Aug 2010 15:33:19




> > 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...

hi rick, what if i were to use raw socket to bypass the ip stack? i
will give this a try.
thank you for your response..
 
 
 

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

Post by Pascal Hambour » Thu, 19 Aug 2010 17:17:14


Hello,

Rick Jones a crit :

Quote:

> 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.

Quote:> 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.

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

I agree.
 
 
 

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

Post by unru » Thu, 19 Aug 2010 19:13:52



Quote:> 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?
 
 
 

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

Post by Pascal Hambour » Thu, 19 Aug 2010 20:16:50


unruh a crit :


>> 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.
 
 
 

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

Post by mcharo » Fri, 20 Aug 2010 02:32:50




Quote:> 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.

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.

if i send a UDP packet via raw socket, and manipulate the ip header
such that the ip destination field of the packet equals the ip address
of eth1, would i be able to fool the kernel to pass the returning
packet to the application? for example, eth1 has ip 16.6.10.10, and,
via raw socket which allows me to specify the ip addresses of the
packet, my dest ip is configured as 16.6.10.10 (note this is the ip of
eth1), and my source ip is configured as something arbitrary such as
17.6.10.10.
in this scenario, will this packet make it to the driver ?  if yes,
the loopback stub should bring the packet back to the driver and when
the packet is pushed up to the ip stack, the stack will see that the
dest ip is the same as eth1 and so will allow it to propogate to the
application. is this a correct assumption??

thank you.

 
 
 

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

Post by Rainer Weikusa » Fri, 20 Aug 2010 02:46:42





>> 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.

[...]

Quote:> 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.

 
 
 

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

Post by mcharo » Fri, 20 Aug 2010 08:46:58






> >> 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.

hi rainer, looks like our rp_filter is preconfigured to 0...i assume
this is the correct setting.
 
 
 

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

Post by Rainer Weikusa » Fri, 20 Aug 2010 22:04:17


[...]

Quote:>> >> 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.

[...]

Quote:>> 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.

 
 
 

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

Post by Rainer Weikusa » Fri, 20 Aug 2010 22:06:33


[...]

Quote:>> >> 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.

[...]

Quote:>> 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.

 
 
 

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

Post by Pascal Hambour » Fri, 20 Aug 2010 22:38:17


Rainer Weikusat a crit :


>> 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.
 
 
 

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

Post by mcharo » Sat, 21 Aug 2010 05:06:50




> Rainer Weikusat a crit :


> >> 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.

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.  can this be done without iptables? my
target macine is an embeded system and we won't have tools like
iptables.
thank you.
 
 
 

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

Post by Pascal Hambour » Sat, 21 Aug 2010 05:40:21


mcharon a crit :

Quote:

> 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.
 
 
 

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

Post by Rick Jone » Sat, 21 Aug 2010 05:22:09


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...

 
 
 

1. How to access local machine using ethernet interface, not loopback?

I am running a simulation (using TCP/IP) that requires the traffic to
go through a 'real' network connection. I have only one computer with
an ethernet card, so everything have to occur locally. Is it possible
to force the traffic to go through eth0 (to eth0:1)? I've tried to
bring down lo and set up the network as follows:

Network interfaces -
eth0 IP address: 192.168.0.1
eth0:1 IP address: 192.168.0.2

Routing -
For host 192.168.0.2, use eth0
For host 192.168.0.1, use eth0:1

(Because I want the traffic to go from 192.168.0.1 to 192.168.0.2 and
vice versa)

The result is that when I ping either IP address, 100% loss occur. If
lo is up, the traffic goes through lo (by checking the RX and TX
fields in ifconfig).

Am I missing something? Or is this mission impossible?

If this is impossible, will it be OK if I plug 1 more network card and
connect them using a crossover cable, so that I have 2 seperate
network interfaces?

2. Problem with compiling the kernel

3. Ethernet loopback Packet LOSS !!!

4. RH 4.1 and setting up as an IPP

5. loopback != loopback.uwc.edu (?)

6. recording with snd_t4dwave.ko: all zeros

7. loopback test with two ethernet cards

8. kernel 2.2.18 & sblive

9. Why do packets show up under loopback device and not eth0?

10. Why does select not see available buffer space on a loopback socket?

11. Socket problem on loopback??

12. WD8013epc and a AMD 386DX40: problems in loopback tests !?

13. How to receive UDP and ICMP packet using one UDP socket, (Path MTUD)