netdev - Re: Trying to implement secondary loopback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 18 Mar 2013 10:33:20 +0100
From:	Thomas Martitz <thomas.martitz@....fraunhofer.de>
To:	Benjamin LaHaise <bcrl@...ck.org>
CC:	richard -rw- weinberger <richard.weinberger@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>
Subject: Re: Trying to implement secondary loopback

Am 15.03.2013 20:48, schrieb Martitz, Thomas:
>>
>> ________________________________________
>> Von: Benjamin LaHaise [bcrl@...ck.org]
>> Gesendet: Freitag, 15. März 2013 16:37
>> An: Martitz, Thomas
>> Cc: richard -rw- weinberger; Eric W. Biederman; netdev@...r.kernel.org; davem@...emloft.net; edumazet@...gle.com; herbert@...dor.apana.org.au
>> Betreff: Re: Trying to implement secondary loopback
>>
>> On Fri, Mar 15, 2013 at 04:07:32PM +0100, Thomas Martitz wrote:
>>> Same result. I assumed the kernel treats lo in a special way for
>>> localhost-connections and that it would be impossible to achieve the
>>> same with a custom interface.
>>>
>>> I did the following:
>>>
>>> ifconfig lo down
>>> insmod ./mykmod.ko
>>> ifconfig eth2 up
>>> ifconfig eth2 127.0.0.1
>>>
>>> At this point ifconfig prints the same information for eth2 that it had
>>> printed for lo before (except for the LOOPBACK flag, but I can enable
>>> that one as well by adding IFF_LOOPBACK to the interface flags in the
>>> module). Yet my test application only works with lo, not eth2.
>>
>> Don't use loopback ip addresses; it makes no sense to do so.  I've worked
>> on a couple opf nic implementations on FPGAs for a while now (a gige
>> implementation that works, and now a 10G nic), and it's easy enough to
>> develop it as a regular ethernet driver.  You can write test programs that
>> use raw sockets to send/receive packets over the ethernet device, or use
>> pktgen to send packets.  You don't even need to configure an ip address for
>> testing with raw packets.  Testing with IP is a lot harder during early
>> bring-up of your hardware as it requires everything to work (that is, you
>> need ARP to work successfully before IP can work).  Just stick to simple
>> packet injection initially, and don't confuse yourself by thinking about
>> the loopback device.
>
> Thank you for your very helpful mail. I haven't considered raw sockets, but it makes total sense now you mention it. This should give a lot less hassle.
>
> However, please let us try to clear up my (mis-)understanding. Even when I use non-looback addresses (e.g. 192.168.1.x) it does not work. For the ARP requirement I tried to workaround by using specifying the IFF_NOARP flag, and using the arp command line tool to populate the arp cache with the the MAC. With this, and all other interfaces down'ed, I cannot get transfers to work. The the sendto() (sending UDP datadagrams) call hangs while the ndk_start_xmit() method isn't even called. As works fine with the loopback interface I started to believe that I need to implement a real loopback interface. It is this supposed to work this way isn't it?
>
> Best regards.



I have found the root problem, that Linux does not allow local (same 
machine) connections via any non-lo interface. See [1] and [2]. Whether 
two NICs connected via crossover cable, or one NIC implementing a 
loopback, the kernel routes transmission via "lo" (and if it's down'ed 
there is no traffic at all).

This made me led me to the conclusion that I need a real (secondary) 
loopback, because an ethX interface simply doesn't work.

According to [2], I have now baked a script which enables local 
connections via non-lo interfaces, and I think I'm happy with it.

Do you guys now why linux makes it so hard (before 2.6.33 even 
impossible) to set up local connections like this (for testing 
purposes)? I understand that routing to lo is a strong optimization for 
real traffic but it should be easy to opt out if routing through NICs is 
really necessary as in my case.

Thank you for your patience and help.
Best regards.

[1]: http://www.zyztematik.com/?p=10
[2]: 
http://umweltsuende.wordpress.com/2011/11/13/monolog-fur-linux-server-send-to-self-patch-alternative/

-----
visit us at

OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807

NABSHOW 2013 / April 8-11 / Las Vegas Convention Center, Nevada, USA / booth C7843

www.hhi.fraunhofer.de/events
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html