linux-kernel - Re: forcedeth ?

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: <1185835218.1911.64.camel@lov.localdomain>
Date:	Tue, 31 Jul 2007 00:40:18 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Gabriel C <nix.or.die@...glemail.com>
Cc:	Sasa Ostrouska <casaxa@...il.com>,
	Avuton Olrich <avuton@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: forcedeth ?


On Tue, 2007-07-31 at 00:19 +0200, Gabriel C wrote:
> Kay Sievers wrote:
> > On 7/31/07, Sasa Ostrouska <casaxa@...il.com> wrote:
> >> On 7/31/07, Gabriel C <nix.or.die@...glemail.com> wrote:
> >>> Sasa Ostrouska wrote:
> >>>> On 7/30/07, Avuton Olrich <avuton@...il.com> wrote:
> >>>>> On 7/30/07, Sasa Ostrouska <casaxa@...il.com> wrote:
> >>>>>> Hi people,
> >>>>>>
> >>>>>> I'm using this on a x86-64 amd machine. During boot of the last
> >>>>>> 2.6.22.1 kernel I get this error:
> >>>>> Somewhat unrelated, but I had a similar forcedeth problem, I took the
> >>>>> latest git forcedeth.c and put it into 2.6.22.1 and it worked for me.
> >>>>>
> >>>>> Good luck!
> >>>>> --
> >>>>> avuton
> >>>> Ok, maybe I can try that. In any case I noticed another strange thing.
> >>>> I have 2 nics in that machine.
> >>>> One is a nvidia MPC61 using the forcedeth.c the other one is a Realtec
> >>>> RTL8029 using the
> >>>> ne2k_pci.
> >>>> Now, whenever I compile them both as modules each reboot the cards get
> >>>> inversed eth assignement. Suppose first boot, the forcedeth is eth0 ,
> >>>> the next boot it is eth1 , this is very anoying as one cant make only
> >>>> one boot, probably this is someway related to the bios.
> >>>> Now I configured them one in the kernel and the other as a module so
> >>>> they get each time assigned the same name. But when powerloss happens
> >>>> (unplug the cable) the next boot they do not work. I see them assigned
> >>>> the correct name, ifconfig shows the IP's but ping results in a
> >>>> destination unreachable.
> >>>>
> >>>> Any ideas ?
> >>> Udev rules ?
> >>>
> >> Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
> >> to check that, thx for the tip.
> > 
> > Udev does that already, it automatically creates rules and assigns
> > persistent names to newly discovered network hardware. The names will
> > be stable across reboots, regardless of module loading order or
> > anything else. But sure, that's only on distros who take these issues
> > serious. :)
> 
> Yes but the rules are based on the MAC address no ?

The automatic rule creator, uses MAC addresses by default, yes. There
have been extensions for S/390 support recently, to create other sorts
of matching rules.

The rules that rename the interface, are not limited in any way, and can
match on any property of the device, they are just not created
automatically today, but can be specified manually.

Maybe the network susbsytem should let us know in the event environment,
that a random MAC was created, so we can automatically create rules that
uses the path to the hardware as a match instead.

Thanks,
Kay


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