Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have an odd problem that seems simple enough but has evaded me thus far. I am attempting to support a legacy application that has a hard-coded ethernet device name ("eth0"). This hard-coding, I am told, will not change.

Now, we are attempting to bring this software in a much more modern OS (Fedora 17) that uses persistent device naming and, as such, has no "eth0" interface. Furthermore, this effort requires that I use the loopback interface for communication to another module as part of a virtualization effort (there is actually a LOT more going on here, but that would take way too long to describe).

I am aware that it is possible to create an alias of the form "lo:0", however the software is explicitly looking for "eth0" and my research and testing thus far has indicated that the "iface:N" naming scheme is the only one supported.

So, in short:

Is there any way to create a virtual interface named "eth0" that communicates over lo?

share|improve this question

2 Answers 2

up vote 1 down vote accepted

There may be a simpler way. But if compiling your own kernel is an option, you could create a driver based on the existing loopback driver, change the name (line 193 in that version), and load the module. You'd have a second loopback interface with the name you want.

Edit: To be more specific, I mean adding another loopback driver, not replacing the existing one. After copying drivers/net/loopback.c to drivers/net/loopback2.c, apply the following patch (done on top of 3.8):

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 335db78..cba692f 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_MACVLAN) += macvlan.o
 obj-$(CONFIG_MACVTAP) += macvtap.o
 obj-$(CONFIG_MII) += mii.o
 obj-$(CONFIG_MDIO) += mdio.o
-obj-$(CONFIG_NET) += Space.o loopback.o
+obj-$(CONFIG_NET) += Space.o loopback.o loopback2.o
 obj-$(CONFIG_NETCONSOLE) += netconsole.o
 obj-$(CONFIG_PHYLIB) += phy/
 obj-$(CONFIG_RIONET) += rionet.o
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 9ef07d0..ed9d82d 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2718,6 +2718,7 @@ static inline bool netif_supports_nofcs(struct net_device *dev)
 }

 extern struct pernet_operations __net_initdata loopback_net_ops;
+extern struct pernet_operations __net_initdata loopback2_net_ops;

 /* Logging, debugging and troubleshooting/diagnostic helpers. */

diff --git a/net/core/dev.c b/net/core/dev.c
index f64e439..7c1cffb 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6834,6 +6834,9 @@ static int __init net_dev_init(void)
        if (register_pernet_device(&loopback_net_ops))
                goto out;

+       if (register_pernet_device(&loopback2_net_ops))
+               goto out;
+
        if (register_pernet_device(&default_device_ops))
                goto out;

I'm realizing that simply loading the module won't be sufficient, as this modifies code in net/core/dev.c. You'll also have the install the patched kernel.

share|improve this answer
    
An interesting approach. Certainly one I am open to exploring. Reading through the source, though, raises one question. It specifically states that there is only ever allowed to be one loopback device per network namespace. Won't the existing lo and my new proposed eth0 clash in the root namespace? Or are you advocating outright replacing lo with a newly compiled driver? And, if so, will that have negative repercussions on existing apps on the system? –  phobos51594 Apr 25 '13 at 17:10
    
Wow, thanks for the complete patch! –  phobos51594 Apr 26 '13 at 0:17
    
Thanks for accepting, but I'm not sure the approach would work, could you comment here if it does? –  Frederik Deweerdt Apr 26 '13 at 1:14
    
Sure. I think the approach has merit, my only concern is registering two loopback devices in the same namespace. I may be able to create another namespace that is exposed to the app stack and work around the limitation that way. Will certainly take some time, so unfortunately the results may not come quickly. –  phobos51594 Apr 26 '13 at 17:59

Does ifrename do what you want?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.