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] [thread-next>] [day] [month] [year] [list]

Message-ID: <3D7E565A361FB844A410A5EFCDD7BA40031932@MXSRV3.fe.hhi.de>
Date:	Fri, 15 Mar 2013 19:48:57 +0000
From:	"Martitz, Thomas" <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

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