-----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-----
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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
In article <[email protected]>,
Nuno Silva <[email protected]> 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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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" <[email protected]>
> To: <[email protected]>
> 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 [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/