Quad ethernet card getting assigned different channels every install

Quad ethernet card getting assigned different channels every install

[Ian S. Nelson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


The kernel is 2.4.18, from Redhat. I've looked at some of the code and I 
think this might actually be a hardware bug.  I'm helping setup a 3 port 
firewall, I'm remote so I haven't been hands on,  the guy has a quad 
ethernet card in it.  Between kernel installs eth0, eth1, eth2, and eth3 
seem to change which socket on the card they are.

Anyone seen anything like this before?  The hardware didn't change and 
to my knowledge no BIOS changes have happened.  I'd assume that the PCI 
bus would be enumerated the same each time and that the kernel, barring 
changes to PCI device discovery, would give the same ethernet channel to 
the same socket each time.  It boots consistently when we figure out 
what port is what.

In this particular case it's potentially a big security concern, if we 
swapped the DMZ and protected zones and didn't notice then his network 
might be exposed.


thanks,
Ian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE97LykV28blwDT2YMRAribAJ9N/kevyPK2ALbZqplzRnW2pp/mEACfe/cN
ug4c/2WZtGH7g5MzPBkU0xs=
=wykB
-----END PGP SIGNATURE-----

Re: Quad ethernet card getting assigned different channels every install

[Nuno Silva]

Hi!

You can load the module and specify the I/O address of each mii. This 
way you'll allways get the same eth for a given I/O. Read the module's 
fine manual :)

Regards,
Nuno Silva

Ian S. Nelson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> The kernel is 2.4.18, from Redhat. I've looked at some of the code and I 
> think this might actually be a hardware bug.  I'm helping setup a 3 port 
> firewall, I'm remote so I haven't been hands on,  the guy has a quad 
> ethernet card in it.  Between kernel installs eth0, eth1, eth2, and eth3 
> seem to change which socket on the card they are.
> 
> Anyone seen anything like this before?  The hardware didn't change and 
> to my knowledge no BIOS changes have happened.  I'd assume that the PCI 
> bus would be enumerated the same each time and that the kernel, barring 
> changes to PCI device discovery, would give the same ethernet channel to 
> the same socket each time.  It boots consistently when we figure out 
> what port is what.
> 
> In this particular case it's potentially a big security concern, if we 
> swapped the DMZ and protected zones and didn't notice then his network 
> might be exposed.
> 
> 
> thanks,
> Ian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.0 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQE97LykV28blwDT2YMRAribAJ9N/kevyPK2ALbZqplzRnW2pp/mEACfe/cN
> ug4c/2WZtGH7g5MzPBkU0xs=
> =wykB
> -----END PGP SIGNATURE-----
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

device driver modules

[Salman]

Hi !

I'm working with a device driver which comes in 2 modules.

One directly talking to the hardware and kernel, and the other sitting on top 
of it, in user mode providing a nice interface for user applications and etc.

Basically the top layer should directly communicate with bottom layer for any 
action.
I'm going through code of top layer, and it never calls the lower layer 
functions ! a sample code traverses as follows (i used source navigator to go 
through code)

ConnectRemoteSegment -> kcConnectR -> SISCI_IOCTL -> unixIoctl -> ioctl

all above fucntions are within the top layer code.
none are even listed in /proc/ksyms
and the ioctl function simply doesn't exist, not even in kernel source code.

I know i'm missing a major concept here, can someone guide me how to 
understand what's going on.

Thanks,

Salman

Re: device driver modules

[Salman]

Hi Henrique,

thanks alot. your explanation answered some important questions of mine.

I need to get deep into this though, and yet understand how to interpret the 
(unsigned32 variable) "cmd" into a function name in my drivers and etc.

120	int stat = ioctl(dev, cmd, arg);
(gdb) p cmd
$1 = 1615069522
(gdb) p dev
$2 = 5
(gdb) p arg
$3 = (void *) 0x8050d30

can you advise me on what to read ? or where to go from here ?
do you know of any resources on the internet regarding kernel, system calls, 
etc ? or which group/mailing list would be the optimum choice for me ?

thanks,

Salman


On Tuesday 03 December 2002 18:45, you wrote:
> Hi !!!
>
> User space application talk to the lower level software (kernel space)
> using ioctl commands. You can take a look at you application code and
> you're probably going to see a lot of ioctl called. To understand the ioctl
> you've got to look at the driver and the application simultaneously.
> There's a routine in the driver that treats all ioctl's the application is
> issuing, for example:
> if your application call something like:
>     ioctl (fd, COMMAND, ...)
>
> you must look for the word COMMAND in your driver and then you can discover
> what your driver is doing when your application call this ioctl comman.
>
> I hope it helps
> regards
> henrique
>
> ----- Original Message -----
> From: "Salman" <assembly@gofree.indigo.ie>
> To: <linux-kernel@vger.kernel.org>
> Sent: Tuesday, December 03, 2002 7:34 AM
> Subject: device driver modules
>
> > Hi !
> >
> > I'm working with a device driver which comes in 2 modules.
> >
> > One directly talking to the hardware and kernel, and the other sitting on
>
> top
>
> > of it, in user mode providing a nice interface for user applications and
>
> etc.
>
> > Basically the top layer should directly communicate with bottom layer for
>
> any
>
> > action.
> > I'm going through code of top layer, and it never calls the lower layer
> > functions ! a sample code traverses as follows (i used source navigator
> > to
>
> go
>
> > through code)
> >
> > ConnectRemoteSegment -> kcConnectR -> SISCI_IOCTL -> unixIoctl -> ioctl
> >
> > all above fucntions are within the top layer code.
> > none are even listed in /proc/ksyms
> > and the ioctl function simply doesn't exist, not even in kernel source
>
> code.
>
> > I know i'm missing a major concept here, can someone guide me how to
> > understand what's going on.
> >
> > Thanks,
> >
> > Salman
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/

Re: Quad ethernet card getting assigned different channels every install

[bill davidsen]

In article <3DECC289.2050500@vgertech.com>,
Nuno Silva  <nuno.silva@vgertech.com> wrote:
| Hi!
| 
| You can load the module and specify the I/O address of each mii. This 
| way you'll allways get the same eth for a given I/O. Read the module's 
| fine manual :)

| Ian S. Nelson wrote:

| > The kernel is 2.4.18, from Redhat. I've looked at some of the code and I 
| > think this might actually be a hardware bug.  I'm helping setup a 3 port 
| > firewall, I'm remote so I haven't been hands on,  the guy has a quad 
| > ethernet card in it.  Between kernel installs eth0, eth1, eth2, and eth3 
| > seem to change which socket on the card they are.

It's not clear if the association of the name (ethN) to the io address
changes or the association of the io address to the connector. If Ian
will clarify, and perhaps check the ifconfig after a few boots...

If it's the name to io address mapping, and I assume it is, then Nuno
has the right idea, an options statement in modules.conf or on a command
line. If it's the latter the the BIOS is NOT doing deterministic
assignment. That would show in lspci with -vv, I believe. You could
still fix this, but it would be ugly, parsing lspci output and building
a command line for insmod.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.