A return to PCI ordering problems...

A return to PCI ordering problems...

[Dale Amon]

I looked back on the thread from last year and thought
that this would be well in hand by now. Either that or
I've missed something obvious or I've got an overly
unfriendly BIOS.

In any case, here is the problem:

	NIC on motherboard, Realtek
	NIC on PCI card, Realtek
	Monolithic (no-module) kernel
	Motherboard must be set to eth0

The PCI search order always makes the PCI card 
eth0.

Tried various command line options:
	ethers=eth1,eth0
	ethers=eth0,eth1
	ether=x1,y1,eth1 ether=x2,y2,eth0
	ether=x1,y1,eth0 ether=x2,y2,eth1
	ether=0,0,eth0 ether=0,0,eth1
	ether=0,0,eth1 ether=0,0,eth0
	pci=reverse

In no case does the ordering get changed by the
command lines; in addtion, the pci=reverse does
not seem to be supported in 2.4.13. I see an 
error message for it in dmesg.

I also played with some of the other pci= options, but 
none of them seem to affect what is going on in a positive 
fashion.

I'm now at the point where I'm wondering if something
in the kernel PCI ordering is just not working quite
right.

-- 
------------------------------------------------------
    Nuke bin Laden:           Dale Amon, CEO/MD
  improve the global          Islandone Society
     gene pool.               www.islandone.org
------------------------------------------------------

Re: A return to PCI ordering problems...

[Tim Hockin]

> > 	NIC on motherboard, Realtek
> > 	NIC on PCI card, Realtek
> > 	Motherboard must be set to eth0
> > The PCI search order always makes the PCI card 
> > eth0.

I'd say your motherboard was broken for setting up the device select lines
that way.  Slots should always be higher than on-boards, IMHO.

In this case, linux is correct. A different example :

onboard natsemi
slotted eepro100

Both eepro100 and natsemi compiled monolithic.  I'd want the probe routine
to find the first device first.  That is, recognize that natsemi has the
lower PCI id, and run the natsemi probe first.  Last I looked, linux just
inits them in the order the _probe() routines are called.

Re: A return to PCI ordering problems...

[Richard B. Johnson]

On Tue, 20 Nov 2001, Dale Amon wrote:

> I looked back on the thread from last year and thought
> that this would be well in hand by now. Either that or
> I've missed something obvious or I've got an overly
> unfriendly BIOS.
> 
> In any case, here is the problem:
> 
> 	NIC on motherboard, Realtek
> 	NIC on PCI card, Realtek
> 	Monolithic (no-module) kernel
> 	Motherboard must be set to eth0
> 
> The PCI search order always makes the PCI card 
> eth0.

The PCI devices are read in the order that they are found. The
first bridge is device 0, etc. These are not usually configurable
since they are hard-wired, a particular slot has a certain device
number.

Device      Vendor                    Type
   0   Intel Corporation              440BX/ZX - 82443BX/ZX Host bridge  
       I/O memory : 0xe4000000->0xe7fffff7
   1   Intel Corporation              440BX/ZX - 82443BX/ZX AGP bridge   
       I/O memory : 0x40010100->0x470101ff
       I/O memory : 0x22a0d0e0->0x1fffdfef
       I/O memory : 0xe3c0e3d0->0xe3cfe3df
       I/O memory : 0xe3f0e400->0xe3ffe40f
   4   Intel Corporation              82371AB PIIX4 ISA                  
   9   S3 Inc.                        86c968 [Vision 968 VRAM] rev 0     
       IRQ 5 Pin 1
       I/O memory : 0x14000000->0x15ffffff
  10   Advanced Micro Devices [AMD]   79c970 [PCnet LANCE]               
       IRQ 12 Pin 1
       I/O  ports : 0xd000->0xd01e
       I/O memory : 0xdf800000->0xdf80001f
  11   3Com Corporation               3c905B 100BaseTX [Cyclone]         
       IRQ 10 Pin 1
       I/O  ports : 0xb800->0xb87e
       I/O memory : 0xdf000000->0xdf00007f
  12   BusLogic                       BT-946C (BA80C30), [MultiMaster 10]
       IRQ 11 Pin 1
       I/O  ports : 0xb400->0xb402
       I/O memory : 0xde800000->0xde800fff

The first ethermet board installed will be eth0, the second eth1, etc.
Therefore, if you want to make a particular board eth0, use modules
and `insmod` the one that you want to be first, first.

FYI, if you care about the name of your ethernet device, your
configuration is probably broken. The IEEE station address can
be used to identify a device and it's accessible from `ifconfig`
without setting any network parameters. So, given this, you
can set any number of boards found, to anything you need to
configure, including complicated servers and routers, with a
simple shell-script.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: A return to PCI ordering problems...

[Faux Pas III]

In article <Pine.LNX.3.95.1011120144925.14138A-100000@chaos.analogic.com> you wrote:

> FYI, if you care about the name of your ethernet device, your
> configuration is probably broken. The IEEE station address can

Fwiw, you can also rename your interfaces if you have 
the iproute2 tools and netlink in your kernel.

ip link set eth0 down
ip link set eth1 down
ip link set eth0 name temp
ip link set eth1 name eth0
ip link set temp name eth1
ip link set eth0 up
ip link set eth1 up

-- 
Josh Litherland (fauxpas@trellisinc.com)
 It is by caffeine alone that I set my mind in motion.
  It is by the juice of Mtn Dew that thoughts acquire speed.

Re: A return to PCI ordering problems...

[Dale Amon]

On Tue, Nov 20, 2001 at 03:03:23PM -0500, Richard B. Johnson wrote:
> FYI, if you care about the name of your ethernet device, your
> configuration is probably broken. The IEEE station address can
> be used to identify a device and it's accessible from `ifconfig`
> without setting any network parameters. So, given this, you
> can set any number of boards found, to anything you need to
> configure, including complicated servers and routers, with a
> simple shell-script.

I presume IEEE station address == MAC...

I haven't really much choice. I can't use modules for
security reasons; I have to assign the motherboard MAC
to eth0 because a commercial package we are installing
licenses on the MAC address of eth0.  

Ifconfig cannot, to my knowledge, swap the identify of
eth0 and eth1. However I the iproute2 calls, if they are
available, might do the trick. I will have to see.

The only thing I really have control over is the kernel
itself, not the dist even.

Has the pci=reverse option been removed? That might
have done the trick.

Also, I don't really see anything inherently wrong with
being able to force some of these things at the boot
command line. 

-- 
------------------------------------------------------
    Nuke bin Laden:           Dale Amon, CEO/MD
  improve the global          Islandone Society
     gene pool.               www.islandone.org
------------------------------------------------------

Re: A return to PCI ordering problems...

[David Woodhouse]

amon@vnl.com said:
> In any case, here is the problem:
> 	NIC on motherboard, Realtek
> 	NIC on PCI card, Realtek
> 	Monolithic (no-module) kernel
> 	Motherboard must be set to eth0 

Why must the motherboard be set to eth0? Why not just configure it as it 
gets detected?

If you really care about the names, there's an ioctl you can use to change 
them. You can call them 'fred' and 'sheila' if you so desire.


--
dwmw2

Re: A return to PCI ordering problems...

[Dale Amon]

On Tue, Nov 20, 2001 at 09:27:37PM +0000, David Woodhouse wrote:
> Why must the motherboard be set to eth0? Why not just configure it as it
> gets detected?

There are a couple reasons. One that is specific to this
particular case is that the VeryExpensiveProprietaryPackage
someone bought checks the eth0 MAC address to be sure you
haven't moved it. It would not really be smart to license
it against a removable, swappable PCI card.

In general: I have more than once gotten bitten late
in the night modifying kernels where I switched something
from modular to non-modular and lost communication with
the machine when it came back up. At 4am these things *do*
happen.

I'd really not mind the ability to say MAC addresss X is
by definition ethY. That would work for me because the only
way you get screwed is if you change the NIC. And if you
are swapping out hardware, you are usually physically present
to sort things out if your network gets effed.

> If you really care about the names, there's an ioctl you can use to change
> them. You can call them 'fred' and 'sheila' if you so desire.

The iproute2 commands another fellow mentioned look
like they will do the job nicely for my particular
immediate problem.

In the more general case though, I can see a need to
explicitely force or override assignments in special 
circumstances.

--
------------------------------------------------------
    Nuke bin Laden:           Dale Amon, CEO/MD
  improve the global          Islandone Society
     gene pool.               www.islandone.org
------------------------------------------------------

Re: A return to PCI ordering problems...

[David Woodhouse]

amon@vnl.com said:
>  I haven't really much choice. I can't use modules for security
> reasons; I have to assign the motherboard MAC to eth0 because a
> commercial package we are installing licenses on the MAC address of
> eth0.  

insmod dummy
ip link set dummy0 name eth0
ip link set eth0 address 01:02:03:04:05:06

Of course, if you're not in the Free World you may end up in prison for 
doing that.

--
dwmw2

Re: A return to PCI ordering problems...

[Andreas Dilger]

On Nov 20, 2001  21:20 +0000, Dale Amon wrote:
> I presume IEEE station address == MAC...
> 
> I haven't really much choice. I can't use modules for
> security reasons; I have to assign the motherboard MAC
> to eth0 because a commercial package we are installing
> licenses on the MAC address of eth0.  

Hmm, the drawbacks of such a licensing system are numerous under
Linux, and are virtually unenforcable.  Simply set the eth0 MAC
address to be whatever you like.  It shouldn't be too hard, and
it will also ensure that your expensive software will continue
to be available if you should ever have to swap the motherboard
because of hardware problems, or an upgrade.

Looking at ifconfig(8), it looks like the following will work:

ifconfig eth0 hw ether 01:23:45:67:89:ab

I just tested this and it appears to work on my card (xirc2ps_cs)
after I unconfigured the interface (couldn't do it while up),
and I checked on a remote host that it also appears with this
MAC to arp.  This is ifconfig 1.39 (1999-03-18) and kernel 2.4.13.


Note that I'm not advocating stealing the software (or using more
than the number of licensed copies), just in making the situation
much more convinient for you.


This is, once again, is a situation where describing the real
goal, as opposed to the immediate problem, is much more likely to
get you a usable solution.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: A return to PCI ordering problems...

[Dale Amon]

On Tue, Nov 20, 2001 at 09:49:01PM +0000, David Woodhouse wrote:

> insmod dummy
> ip link set dummy0 name eth0
> ip link set eth0 address 01:02:03:04:05:06

Ewwwww... that's totally evyul. I love it.

> Of course, if you're not in the Free World you may end up in prison for 
> doing that.

And a top o' the mornin' (well evening anyway) to ye. 
We're a County Cork company wouldn't you know? 

-- 
------------------------------------------------------
    Nuke bin Laden:           Dale Amon, CEO/MD
  improve the global          Islandone Society
     gene pool.               www.islandone.org
------------------------------------------------------

Re: A return to PCI ordering problems...

[Richard B. Johnson]

On Tue, 20 Nov 2001, Dale Amon wrote:

> On Tue, Nov 20, 2001 at 09:49:01PM +0000, David Woodhouse wrote:
> 
> > insmod dummy
> > ip link set dummy0 name eth0
> > ip link set eth0 address 01:02:03:04:05:06
> 
> Ewwwww... that's totally evyul. I love it.

Yep! Just don't use ff:ff:ff:ff:ff:ff if you don't want your CPU
to melt down. I'm told you get all the data in the universe, almost
as bad as NETbeui  ;^)

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: A return to PCI ordering problems...

[James A Sutherland]

On Tuesday 20 November 2001 9:27 pm, David Woodhouse wrote:
> amon@vnl.com said:
> > In any case, here is the problem:
> > 	NIC on motherboard, Realtek
> > 	NIC on PCI card, Realtek
> > 	Monolithic (no-module) kernel
> > 	Motherboard must be set to eth0
>
> Why must the motherboard be set to eth0? Why not just configure it as it
> gets detected?

He has some software licensing thing which checks the MAC address of eth0.

Of course, what he could do is change the MAC address of eth0 to whatever the 
licensing software wants... :-)

> If you really care about the names, there's an ioctl you can use to change
> them. You can call them 'fred' and 'sheila' if you so desire.

So you can you swap them, so eth1 becomes eth0? If so, that should solve his 
problem...


James.

Re: A return to PCI ordering problems...

[Alan Cox]

> > If you really care about the names, there's an ioctl you can use to change
> > them. You can call them 'fred' and 'sheila' if you so desire.
> 
> So you can you swap them, so eth1 becomes eth0? If so, that should solve his 
> problem...

You can do yes

Re: A return to PCI ordering problems...

[Helge Hafting]

Dale Amon wrote:
> 
> On Tue, Nov 20, 2001 at 09:27:37PM +0000, David Woodhouse wrote:
> > Why must the motherboard be set to eth0? Why not just configure it as it
> > gets detected?
> 
> There are a couple reasons. One that is specific to this
> particular case is that the VeryExpensiveProprietaryPackage
> someone bought checks the eth0 MAC address to be sure you
> haven't moved it. It would not really be smart to license
> it against a removable, swappable PCI card.
> 
Such a licencing scheme isn't very smart on a os where
the kernel source is available anyway.

It is trivial for a programmer to change what MAC address
(or _anything else_ the os reports about hardware,
simply by altering the system call.  There happens
to be tools for changing the MAC address, but 
event that isn't necessary - anything can be worked
around in the source.  So, a criminal can run
such a package on any number of machines because they
may all appear to have the same MAC address to the
checking program.  I have heard of people writing
emulators for parallell port dongles too.

Of course most people obey the law, but some still need
such tricks so they can work around broken licencing
schemes that prevent _legal_ use, and avoid dongles
that mess up communication with newer devices.

Helge Hafting

Re: A return to PCI ordering problems...

[Henning P. Schmiedehausen]

James A Sutherland <jas88@cam.ac.uk> writes:

>On Tuesday 20 November 2001 9:27 pm, David Woodhouse wrote:
>> amon@vnl.com said:
>> > In any case, here is the problem:
>> > 	NIC on motherboard, Realtek
>> > 	NIC on PCI card, Realtek
>> > 	Monolithic (no-module) kernel
>> > 	Motherboard must be set to eth0
>>
>> Why must the motherboard be set to eth0? Why not just configure it as it
>> gets detected?

>He has some software licensing thing which checks the MAC address of eth0.

>Of course, what he could do is change the MAC address of eth0 to whatever the 
>licensing software wants... :-)

One could imagine a module to read the MAC address from the eeprom and
not from the Interface.. Makes this scenario not impossible but much
harder.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: A return to PCI ordering problems...

[Christoph Hellwig]

In article <9tg371$ja3$1@forge.intermeta.de> you wrote:
> One could imagine a module to read the MAC address from the eeprom and
> not from the Interface.. Makes this scenario not impossible but much
> harder.

"To use the WizBang Webpublishing software you have to use one of
 the follwoing Network Interface Cards: Intel EEpro (TM) 100,
 3com 3c590C, SMC Etherpower."

Sure, looks practicable..

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: A return to PCI ordering problems...

[Henning P. Schmiedehausen]

Christoph Hellwig <hch@ns.caldera.de> writes:

>In article <9tg371$ja3$1@forge.intermeta.de> you wrote:
>> One could imagine a module to read the MAC address from the eeprom and
>> not from the Interface.. Makes this scenario not impossible but much
>> harder.

>"To use the WizBang Webpublishing software you have to use one of
> the follwoing Network Interface Cards: Intel EEpro (TM) 100,
> 3com 3c590C, SMC Etherpower."

>Sure, looks practicable..

BS. You buy an Appliance (let's say an "Limegreen RcK Server") which comes
with a Whizbang Software package (let's say Miracle SQL database (light)).

Miracle has an exclusive licensing agreement with Limegreen that their
software is only used on the RcK Servers and cannot be put onto
"run-off-the-mill" i386 Servers.

As I said "not impossible but much harder".

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: A return to PCI ordering problems...

[Christer Weinigel]

Helge Hafting wrote:
>Dale Amon wrote:
>> There are a couple reasons. One that is specific to this
>> particular case is that the VeryExpensiveProprietaryPackage
>> someone bought checks the eth0 MAC address to be sure you
>> haven't moved it. It would not really be smart to license
>> it against a removable, swappable PCI card.
>> 
>Such a licencing scheme isn't very smart on a os where
>the kernel source is available anyway.

It's not very smart even on a proprietary operating system such
as Solaris.  There have been tools available to report a different
hostid on Solaris for ages.

  /Christer
-- 
"Just how much can I get away with and still go to heaven?"

Re: A return to PCI ordering problems...

[James A Sutherland]

On Wednesday 21 November 2001 11:29 am, Henning P. Schmiedehausen wrote:
> James A Sutherland <jas88@cam.ac.uk> writes:
> >On Tuesday 20 November 2001 9:27 pm, David Woodhouse wrote:
> >> amon@vnl.com said:
> >> > In any case, here is the problem:
> >> > 	NIC on motherboard, Realtek
> >> > 	NIC on PCI card, Realtek
> >> > 	Monolithic (no-module) kernel
> >> > 	Motherboard must be set to eth0
> >>
> >> Why must the motherboard be set to eth0? Why not just configure it as it
> >> gets detected?
> >
> >He has some software licensing thing which checks the MAC address of eth0.
> >
> >Of course, what he could do is change the MAC address of eth0 to whatever
> > the licensing software wants... :-)
>
> One could imagine a module to read the MAC address from the eeprom and
> not from the Interface.. Makes this scenario not impossible but much
> harder.

Apart from depending on the specific NIC in use, probably easy to circumvent. 
Especially with EEPROMs. But discussing this probably violates the UK's CDPA 
(our answer to DMCA, but snuck onto the books in '88) prohibition on 
communicating information about circumvention...


James.