[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Switching between two network cards



On Thu, Oct 07, 2004 at 10:54:35PM +0200, Andrei Badea wrote:
> ...
> I've got two network cards: one integrated on my motherboard 
> (uses the sk98lin driver) and a PCI card (fealnx driver). Both drivers are 
> compiled as modules and upon startup I'm loading only fealnx via 
> /etc/modules (I'm not loading sk98lin at all). The network runs fine.
> 
> After my system starts, I want to switch to the other network card (the 
> sk98lin one), but I only want its module loaded, so I do:
> 
> ifdown eth0
> rmmod fealnx
> modprobe sk98lin
> ifup eth0

Why not load *both* modules all the time (i.e. put them both in
/etc/modules), and then simply use:
    ifdown eth0
    ifup eth1
and
    ifdown eth1
    ifup eth0
to switch?

The order in /etc/modules then dictates which one becomes eth0 and which
one becomes eth1.

It sounds like the two drivers are dissagreeing with being unloaded, but
there isn't much to go on.  Do you get anything in dmesg (~
/var/log/kern.log) when you load/unload the modules?  Is it different if
you boot with the "other" module loaded?

Some modules can be enticed into giving more verbose information... I
don't have those modules available, but 
    modinfo fealnx
    modinfo sk98lin
should give information about the module-specific options. In either
case, the kernel docs for those modules should be handy...

> Messages in dmesg say the network is up and running. But it isn't, it 
> seems I can't ping nor make net connections. However, when I (for example) 
> run a ping and look at the LEDs on the card, I see them bliking in the 
> "ping" way. I can also see the echo request and reply packets in tcpdump. 
> But ping doesn't get them and reports 100% loss.

!? If this is tcpdump on the same machine, then I'm thoroughly
confused..

If this is tcpdump on another box on the same network (more likely I
hope), then the firewalling rules should be eyeballed. 

and which maching is doing the pinging?

> If I unload sk98lin and reload fealnx, the net works fine. Now comes the 
> interesting part: if I put sk98lin in /etc/modules instead of fealnx and 
> restart, the net comes up. Only this time I can't switch to fealnx. This 
> shows both the cards are working.

Have you ever had both working at the same time? 

> I thought this was caused by iptables settings, so after loading the other 
> module I rerun the script which setups my firewall rules. Didn't help.

Assuming that you use the same firewalling rules all the time, that
indicates that the firewalling rules are not the problem here.

But you can make your firewalling rules generic by specifying "eth+"
rather than "eth0" (i.e. it will match all interfaces starting with
"eth").

To completely eliminate the possiblity of bad firewalling rules, you
could try clearing them
    /etc/init.d/iptables clear
and try again. I'm not 100% sure that the firewalling rules can be
eliminated as the cause.

A related question: How do you reload the firewalling rules? Are they
being cleared down first? i.e. is there an "accumulative" effect going
on here?

> Not that is it important, as my net is 
> running with any of the cards if I restart, I'm just curious. However, I'd 
> like to point out that I don't want both modules to be loaded. I want to 
> be able to unload the running one and load another without having to 
> restart.

But why insist on unloading the "other" module? Why isn't "ifdown"
sufficient?  

I assume that there is a reason (surely it cannot be because you don't
want an eth1, is it?), but it is not clear from your post.  

There may be different ways of solving your original problem

PS: Why put an extra network card in the box if you only want to use one
    network at any given time?

Hope this helps

-- 
Karl E. Jørgensen
karl@jorgensen.com   http://karl.jorgensen.com
==== Today's fortune:
When you say that you agree to a thing in principle, you mean that
you have not the slightest intention of carrying it out in practice.
		-- Otto Von Bismarck

Attachment: signature.asc
Description: Digital signature


Reply to: