Eric W. Biederman wrote:
> etun is a simple two headed tunnel driver that at the link layer looks
> like ethernet.  It's target audience is communicating between network
> namespaces but it is general enough it has other valid uses as well.
>
> Ben Greear implemented a similar device called redir-dev, for network
> emulation.
>
> OpenVZ has a similar device that goes by the name veth.
>
> I didn't want to mess with ioctls or weird non-general network
> interfaces for creating devices, so I used sysfs as my control
> mechanism.
>
> To create a pair of devices called veth0 and veth1:
>   echo -n 'veth0,veth1' > /sys/module/etun/parameters/newif
>
> To destroy a pair of devices:
>   echo -n 'veth0' > /sys/module/etun/parameters/delif
>   
Is there any way to tell for certain if an interface is a etun or not?  
Maybe
a file could be found (or not) in sysfs somewhere?

Also, how do you find the peer device from user-space?  This would be 
very useful
for anyone trying to manage these devices with a user-space program.

When you are creating new devices, I think you should check to make
sure there isn't already a device with that name.

In general though, I look forward to this being in the kernel so I can drop
my redirect device code from my out-of-tree patch.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Ben Greear <greearb@candelatech.com> writes:

> Is there any way to tell for certain if an interface is a etun or not?  Maybe
> a file could be found (or not) in sysfs somewhere?

Link for any decent network driver ethtool -i <interface>

> Also, how do you find the peer device from user-space?  This would be very
> useful
> for anyone trying to manage these devices with a user-space program.

Currently "ethtool -S <interface>"
And read the partner_ifindex.

Further whoever generates the pair specifies the initial set of names.

> When you are creating new devices, I think you should check to make
> sure there isn't already a device with that name.

alloc_netdev doesn't let you register two devices with the same name,
and I check the return status of alloc_netdev. 

> In general though, I look forward to this being in the kernel so I can drop
> my redirect device code from my out-of-tree patch.

Thanks.

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Eric W. Biederman wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>   
>> Is there any way to tell for certain if an interface is a etun or not?  Maybe
>> a file could be found (or not) in sysfs somewhere?
>>     
>
> Link for any decent network driver ethtool -i <interface>
>   
I guess that will do, but then if you ever change the strings, any 
user-space that is
depending on this will break or have to be modified with additional 
cruft.  It seems
cleaner to me to have an ioctl or a specific place in /proc or some 
other virtual
fs, but I can deal with it either way...

>> Also, how do you find the peer device from user-space?  This would be very
>> useful
>> for anyone trying to manage these devices with a user-space program.
>>     
>
> Currently "ethtool -S <interface>"
> And read the partner_ifindex.
>   
Ok, that will work.  Again, my personal preference is for a single 
specific ioctl or proc'ish file
to read the specific value instead of having to parse strings, but this 
will do.

> Further whoever generates the pair specifies the initial set of names.
>   
Yeah, but you can't depend on knowing that in an interesting environment.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Ben Greear <greearb@candelatech.com> writes:

> I guess that will do, but then if you ever change the strings, any user-space
> that is
> depending on this will break or have to be modified with additional cruft.  It
> seems
> cleaner to me to have an ioctl or a specific place in /proc or some other
> virtual
> fs, but I can deal with it either way...

True if the name of the driver changes from etun there is an issue.

>>> Also, how do you find the peer device from user-space?  This would be very
>>> useful
>>> for anyone trying to manage these devices with a user-space program.
>>>
>>
>> Currently "ethtool -S <interface>"
>> And read the partner_ifindex.
>>
> Ok, that will work.  Again, my personal preference is for a single specific
> ioctl or proc'ish file
> to read the specific value instead of having to parse strings, but this will do.

Hmm. I guess there is string parsing to identify the index.

I guess a sysfs device attribute would work as well.

>> Further whoever generates the pair specifies the initial set of names.
>>
> Yeah, but you can't depend on knowing that in an interesting environment.

Frankly.  In an interesting environment I haven't been able to think of a
way to successfully say anything about the partner device.

The problem is that all identifiers are namespace local so the remote side
is not in the current namespace the ifindex or the device name mean nothing.

In that case the only remotely usable value I can return is the mac address
of the other side.

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Eric W. Biederman wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>   
>> I guess that will do, but then if you ever change the strings, any user-space
>> that is
>> depending on this will break or have to be modified with additional cruft.  It
>> seems
>> cleaner to me to have an ioctl or a specific place in /proc or some other
>> virtual
>> fs, but I can deal with it either way...
>>     
>
> True if the name of the driver changes from etun there is an issue.
>   
So, how about a sysfs field for this too, something like 'is-etun' or 
whatever...
Or, IOCTL works fine too, of course.
>   
>>>> Also, how do you find the peer device from user-space?  This would be very
>>>> useful
>>>> for anyone trying to manage these devices with a user-space program.
>>>>
>>>>         
>>> Currently "ethtool -S <interface>"
>>> And read the partner_ifindex.
>>>
>>>       
>> Ok, that will work.  Again, my personal preference is for a single specific
>> ioctl or proc'ish file
>> to read the specific value instead of having to parse strings, but this will do.
>>     
>
> Hmm. I guess there is string parsing to identify the index.
>
> I guess a sysfs device attribute would work as well.
>   
Yes, that would be much appreciated.
>   
>>> Further whoever generates the pair specifies the initial set of names.
>>>
>>>       
>> Yeah, but you can't depend on knowing that in an interesting environment.
>>     
>
> Frankly.  In an interesting environment I haven't been able to think of a
> way to successfully say anything about the partner device.
>
> The problem is that all identifiers are namespace local so the remote side
> is not in the current namespace the ifindex or the device name mean nothing.
>
> In that case the only remotely usable value I can return is the mac address
> of the other side.
>   
Couldn't you also show the peer's name-space id in that case?

MAC could be duplicated, so that's not a very good key.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers