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]
Date:	Fri, 08 Jun 2007 10:00:20 -0700
From:	Ben Greear <>
To:	Pavel Emelianov <>
CC:	David Miller <>,
	Linux Netdev List <>,
	"Eric W. Biederman" <>,
	Patrick McHardy <>,
	Daniel Lezcano <>,
	Stephen Hemminger <>,
	Kirill Korotaev <>,
	Linux Containers <>
Subject: Re: [PATCH] Virtual ethernet tunnel (v.2)

Pavel Emelianov wrote:
> Ben Greear wrote:
> [snip]
>>>> I would also like some way to identify veth from other device types,
>>>> preferably
>>>> something like a value in sysfs.   However, that should not hold up
>>> We can do this with ethtool. It can get and print the driver name of
>>> the device.
>> I think I'd like something in sysfs that we could query for any
>> interface.  Possible return
>> strings could be:
>> ETH
>> PPP
>> AP /* wifi access point interface */
>> STA /* wifi station */
>> ....
>> I will cook up a patch for consideration after veth goes in.
> Ben, could you please tell what sysfs features do you
> plan to implement?
I think this is the only thing that has a chance of getting into the kernel.
Basically, I have a user-space app and I want to be able to definitively 
know the type for
all interfaces.  Currently, I have a hodge-podge of logic to query 
various ioctls and /proc
files and finally, guess by name if nothing else works.  There must be a 
better way :P

I have another sysfs patch that allows setting a default skb->mark for 
an interface so that you can set the skb->mark
before it hits the connection tracking logic, but I'm been told this one 
has very little chance
of getting into the kernel.  The skb->mark patch is only useful (as far 
as I can tell) if you
also include a patch Patrick McHardy did for me that allowed the 
conn-tracking logic to
use skb->mark as part of it's tuple.  This allows me to do NAT between 
virtual routers
(routing tables) on the same machine using veth-equivalent drivers to 
connect the
routers.  He thinks this will probably not ever get into the kernel either.

I have another sysctl related send-to-self patch that also has little 
chance of getting into the kernel, but
it might be quite useful with veth (it's useful to me..but my needs 
aren't exactly mainstream :))
I'll post this separately for consideration....


Ben Greear <> 
Candela Technologies Inc

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists