On 15-07-14 19:34:42, Jeff Haran wrote: > > The last time I looked into this (and this was quite a while ago so take this > with much salt) the lo device was not a "regular network device". The stack > sets up an instance of lo in every network name space created, more or less > automatically via the registration of its init routine in a struct > pernet_operations. So lo doesn't initialize like most other network devices. > You might have issues there. I know I did last time I tried to "borrow" > loopback.c to do something similar for some prototyping I was doing.
Realized that while looking at this code. But thankd for pointing this. > > If you are willing to monkey with kernel code, it might be easier to just > twiddle the link sense routine in driver for the "other NIC" you were > planning to use to always report the link as up regardless of what the PHY > says. > This too is good option. Found anther option that looks like should solve the problem I am after. veth device - as you suggested earlier. So, as I understand veth device creates a sender and receiver. So, if I send on veth0, I will receive on veth1. So, the steps that I would need is (using iproute2 utility): ip link add type veth name veth0 peer name veth1 ip link set dev veth0 up ip link set dev veth1 up and then add the address to what ever I require. I quickly tested and seems that I am able to play on veth0 and receive on veth1. One last query on this, does this interface receive any packet by default of any protocol. If so, how do I make sure that no packets other than one injected by me are seen on this interface. Sorry, if this sounds too stupid, but I am noob in this area. > > > -- Thanks, -aka _______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
