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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 08 Jun 2007 10:00:20 -0700 From: Ben Greear <greearb@...delatech.com> To: Pavel Emelianov <xemul@...nvz.org> CC: David Miller <davem@...emloft.net>, Linux Netdev List <netdev@...r.kernel.org>, "Eric W. Biederman" <ebiederm@...ssion.com>, Patrick McHardy <kaber@...sh.net>, Daniel Lezcano <dlezcano@...ibm.com>, Stephen Hemminger <shemminger@...ux-foundation.org>, Kirill Korotaev <dev@...nvz.org>, Linux Containers <containers@...ts.osdl.org> 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: >> VLAN >> VETH >> ETH >> PPP >> BRIDGE >> 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.... Thanks, Ben -- Ben Greear <greearb@...delatech.com> Candela Technologies Inc http://www.candelatech.com - 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
Powered by blists - more mailing lists