problem with ethernet loopback test using loopback plug/stub: receiving socket not seeing packet.
mcharon
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.
Rick Jones
> 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...
mcharon
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..
Ersek, Laszlo
> 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.
I agree. (See also rp_filter.)
> You may have to do things at the link-level.
Or broadcast the packet, I think.
lacos
Pascal Hambourg
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.
unruh
> Hello,
>
> Rick Jones a ?crit :
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?
Pascal Hambourg
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
wrote:
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.
Rainer Weikusat
> 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
hi rainer, looks like our rp_filter is preconfigured to 0...i assume
this is the correct setting.
Rainer Weikusat
> 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.
Rainer Weikusat
> 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.
Pascal Hambourg
> mcharon <mch...@gmail.com> 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.
mcharon
wrote:
> Rainer Weikusat 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. can this be done without iptables? my
target macine is an embeded system and we won't have tools like
iptables.
thank you.
Pascal Hambourg
>
> 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.
Rick Jones
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?"
mcharon
hi everyone, there's a way to pass packets directly to layer 2 by
sending PF_PACKET protocol family packets, which is described in this
article
http://www.linuxjournal.com/article/4659.
we can now do our loopback.
thanks everyone for all your help....
Rainer Weikusat
Doing this with raw sockets is also possible, provided that IP can be
used.