Setting up Gateway

Hi out there,
I'm sorry, I know this may be a quite stupid question, but I havn't got that
much time to read 100s of pages of how2's and so on

Situation:

PC #1
eth0 192.168.0.1
eth1 129.206.170.26

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
129.206.170.0 * 255.255.255.0 U 0 0 0 eth1
default cr-urz.wh.uni-h 0.0.0.0 UG 0 0 0 eth1


PC #2
eth0 192.168.02

192.168.0.1 as default route

Pinging #2 from #1 (and vice versa) doesn't work.
What do I need to configure (file, setting)?

Thanks in advance

Dario

Dario Kampkaspar wrote:
> Hi out there,
> I'm sorry, I know this may be a quite stupid question, but I havn't got that
> much time to read 100s of pages of how2's and so on
>
> Situation:
>
> PC #1
> eth0 192.168.0.1
> eth1 129.206.170.26
>
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
> 129.206.170.0 * 255.255.255.0 U 0 0 0 eth1
> default cr-urz.wh.uni-h 0.0.0.0 UG 0 0 0 eth1

That default gateway resolves to 129.206.170.1. Good.


> PC #2
> eth0 192.168.02

There's a dot (".") missing between "0" and "2", i suppose.


> 192.168.0.1 as default route
>
> Pinging #2 from #1 (and vice versa) doesn't work.
> What do I need to configure (file, setting)?

Well, firstly, Your routing table on PC#1 is basically correct.

If You cannot ping from #2 to #1, check Your cables first.

If You're absolutely sure that that's not the problem, see whether
You're blocking ICMP traffic from/to Your LAN on either box.

The thing is that You must be able to ping back and forth before
going any deeper (i. e. checking whether #1 does ip forwarding etc.).
Essentially, that's what ping is good for.

It's either cabling or blocking that causes Your problem.


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...

jack <not@all.org> writes:

>> PC #1
>> eth0 192.168.0.1
>> eth1 129.206.170.26
>>
>> Kernel IP routing table
>> Destination Gateway Genmask Flags Metric Ref Use Iface
>> 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
>> 129.206.170.0 * 255.255.255.0 U 0 0 0 eth1
>> default cr-urz.wh.uni-h 0.0.0.0 UG 0 0 0 eth1
>
> That default gateway resolves to 129.206.170.1. Good.
>
>
>> PC #2
>> eth0 192.168.02
>
> There's a dot (".") missing between "0" and "2", i suppose.

Yep, my mistake, sorry.

>
>
>> 192.168.0.1 as default route
>>
>> Pinging #2 from #1 (and vice versa) doesn't work.
>> What do I need to configure (file, setting)?
>
> Well, firstly, Your routing table on PC#1 is basically correct.
>
> If You cannot ping from #2 to #1, check Your cables first.

I'm perfectly sure cabling is a-okay. Reason:
Trying to solve this, on #1 I first configured only eth0. Pinging #2 worked
fine. Then, I configured eth1 (in my case, using SuSE 9.0's YaST). Now, I
can use outgoing connections via eth1 but not the internal one via eth0.

>
> If You're absolutely sure that that's not the problem, see whether
> You're blocking ICMP traffic from/to Your LAN on either box.

Don't see, how I could've blocked ICMP traffic since it worked with only one
NIC acrive...

>
> The thing is that You must be able to ping back and forth before
> going any deeper (i. e. checking whether #1 does ip forwarding etc.).
> Essentially, that's what ping is good for.
>
> It's either cabling or blocking that causes Your problem.
>
>
> Cheers, Jack.
>

Thanks and greets, Dario

Dario Kampkaspar <phlox@dario.wh.uni-heidelberg.de> wrote:
> jack <not@all.org> writes:
>> If You cannot ping from #2 to #1, check Your cables first.

> I'm perfectly sure cabling is a-okay. Reason:
> Trying to solve this, on #1 I first configured only eth0. Pinging #2 worked
> fine. Then, I configured eth1 (in my case, using SuSE 9.0's YaST). Now, I
> can use outgoing connections via eth1 but not the internal one via eth0.

Could the eth1 Ethernet card have somehow latched onto the IRQ or IO-port
that the card for eth0 was using? Take a look at the outputs of these:

cat /proc/interrupts
cat /proc/ioports

-- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Editing with vi is a lot better than using a huge swiss army knife.
Use =} to wrap paragraphs in vi. Or put map ^] !}fmt -72^M in
~/.exrc and use ^] to wrap to 72 columns or whatever you choose. */

In article <4mqjvb.qop.ln@corncob.localhost.tld>,
Clifford Kite <kite@see.signature.id> writes:
> Dario Kampkaspar <phlox@dario.wh.uni-heidelberg.de> wrote:
>> jack <not@all.org> writes:
>>> If You cannot ping from #2 to #1, check Your cables first.
>
>> I'm perfectly sure cabling is a-okay. Reason:
>> Trying to solve this, on #1 I first configured only eth0. Pinging #2 worked
>> fine. Then, I configured eth1 (in my case, using SuSE 9.0's YaST). Now, I
>> can use outgoing connections via eth1 but not the internal one via eth0.
>
> Could the eth1 Ethernet card have somehow latched onto the IRQ or IO-port
> that the card for eth0 was using? Take a look at the outputs of these:

'kay, both are on int5, but do you really think that this is a problem?
If they aren't configured (e.g. by YaST) they are present and so do take
an interrupt - so if it was an interrupt problem it shouldn't have worked
with only one card configured, should it?
As well, I already changed it to another PCI-slot as on its first the
card thought of itself to be HWaddr ff:ff:ff:ff:ff:ff sometimes ;). By that
time it used IRQ7 and eth0 used IRQ5 like now - inspite of this it didn't work.
But I'll try to change it again - any other ideas?

Dario Kampkaspar <phlox@dario.wh.uni-heidelberg.de> wrote:
> In article <4mqjvb.qop.ln@corncob.localhost.tld>,
> Clifford Kite <kite@see.signature.id> writes:
>> Dario Kampkaspar <phlox@dario.wh.uni-heidelberg.de> wrote:
>>> jack <not@all.org> writes:
>>>> If You cannot ping from #2 to #1, check Your cables first.
>>
>>> I'm perfectly sure cabling is a-okay. Reason:
>>> Trying to solve this, on #1 I first configured only eth0. Pinging #2 worked
>>> fine. Then, I configured eth1 (in my case, using SuSE 9.0's YaST). Now, I
>>> can use outgoing connections via eth1 but not the internal one via eth0.
>>
>> Could the eth1 Ethernet card have somehow latched onto the IRQ or IO-port
>> that the card for eth0 was using? Take a look at the outputs of these:

> 'kay, both are on int5, but do you really think that this is a problem?
> If they aren't configured (e.g. by YaST) they are present and so do take
> an interrupt - so if it was an interrupt problem it shouldn't have worked
> with only one card configured, should it?

If the same interrupt is assigned to two cards, but one card is not UP,
RUNNING (ifconfig) but the other card is, then the other card should
work, just as it did for you. Otherwise I think there very well could
be trouble. There certainly would be trouble for ISA.

I known PCI is capable of interrupt sharing between devices but I'm
not PCI-aware enough to know whether that applies to all devices or
only to some. Or applies to all IRQs or only some.

> As well, I already changed it to another PCI-slot as on its first
> the card thought of itself to be HWaddr ff:ff:ff:ff:ff:ff sometimes
> ;). By that time it used IRQ7 and eth0 used IRQ5 like now - inspite
> of this it didn't work.

Then I could be wrong - unless some other configured device also used
IRQ 7, e.g., a sound card. :)

> But I'll try to change it again - any other ideas?

If one card works with the other card not configured but doesn't work
when the other card is configured, then it certainly seems to me that
some interaction between the configured cards is causing the problem.

--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Those who can't write, write manuals. */

Clifford Kite wrote:
> Dario Kampkaspar <phlox@dario.wh.uni-heidelberg.de> wrote:
>>As well, I already changed it to another PCI-slot as on its first
>>the card thought of itself to be HWaddr ff:ff:ff:ff:ff:ff sometimes
>>;). By that time it used IRQ7 and eth0 used IRQ5 like now - inspite
>>of this it didn't work.
>
> Then I could be wrong - unless some other configured device also used
> IRQ 7, e.g., a sound card. :)

Or, by default, Your parallel port... - But if the NIC reports a hw
address like above, I think there's something wrong with it, hardware-
wise.


> If one card works with the other card not configured but doesn't work
> when the other card is configured, then it certainly seems to me that
> some interaction between the configured cards is causing the problem.

What a sentence... - But for the OP:

Anyways, since both are PCI cards, as You say, sharing one interrupt
should not cause any trouble like this - unless You messed with Your
bios settings. It's quite uncommon for NICs to request IRQ5, since that
will conflict with many legacy sound controllers. Normally, You'd find
them among 10 or 11. - BTW, what's make and model of those cards of
Yours?


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...