linux-kernel - RE: nic enumeration

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 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]

Message-ID: <D3F292ADF945FB49B35E96C94C2061B90C3CFABA@nsmail.netscout.com>
Date:	Mon, 12 Jul 2010 12:56:31 -0400
From:	"Loke, Chetan" <Chetan.Loke@...scout.com>
To:	"Steve Fink" <sphink@...il.com>
Cc:	"Florian Weimer" <fweimer@....de>, <linux-net@...r.kernel.org>,
	"Matt Domsch" <Matt_Domsch@...l.com>,
	"Michael Di Domenico" <mdidomenico4@...il.com>,
	<linux-kernel@...r.kernel.org>, <kay.sievers@...y.org>
Subject: RE: nic enumeration

> -----Original Message-----
> From: Steve Fink [mailto:sphink@...il.com]
> Sent: July 09, 2010 5:27 PM
> To: Loke, Chetan
> Cc: Florian Weimer; linux-net@...r.kernel.org; Matt Domsch; Michael Di
> Domenico; linux-kernel@...r.kernel.org; kay.sievers@...y.org
> Subject: Re: nic enumeration
> 
> 
> Your problem is different from the one that began this thread. Can you
> describe your situation more fully?
> 

Sorry guys, I thought I mentioned my requirement. And I apologize for
pulling in my discussion in this thread.

Requirement:
I've a box with 'M' NICs. During install time, all the h/w config is
static, customers will configure the box. They would say use 'ethX' for
task-foo and 'ethY' for task-bar.
All this while our-apps where happy because we would never modify the
h/w config(single NIC vendor). So the configuration was pretty static.
However, we now let customers add/replace NICs from different vendors(so
different drivers will get loaded).The older 'ethX' might now map to a
newly-inserted-NICs-mac. So I would now like an 'ethX' agnostic way of
addressing the NICs and BTW we can't reboot the box[look below why].

Possible solution:
S1)I thought symlink[or a reference etc] would solve this problem. 
S2)I have another idea in mind(using mac-ids,enhance dev_ioctl[introduce
SIOCGHWADDR_TO_IFNAMEINDEXMAP] and traverse
for_each_netdev::for_each_dev_addrs) but I will wait for everyone's
suggestions because there might be an easy way.

Why can't I reboot?
Imagine the above configuration within a VM. Some customers have as many
as 75+ VMs deployed and we cannot afford to reboot the VMs after adding
a new (virtual)vNIC. The newly added vNIC is seen by the guest as if it
were a hot-insertion.

> I only partially understand your problem, but I am still wondering if
> my bridge idea would work for you. (Preferably combined with udev
> rules or whatever so the bridges are unnecessary after the next
> reboot.)

Why a bridge? Just to get around naming issues?

Regards
Chetan Loke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/