On Mon, 25 May 2009 08:37:33 +1200
Chris Bannister <mockingb...@earthlight.co.nz> wrote:

> On Fri, May 22, 2009 at 09:25:29AM -0700, Frank Miles wrote:
> > I recently added a second networking card to a hardware-test PC.  This 
> > elderly machine
> > had been working reasonably well.  The second networking card is for eth1, 
> > etc., and
> > /sbin/ifconfig shows things as properly connected, with eth0 being the 
> > outside interface
> > and eth1 being an internal 192.168.x.x interface for some special internal 
> > systems that
> > have absolutely no need to communicate with the outside world, just this 
> > one PC.
> 
> So now you have a gateway?
> 
> What firewall configuration software are you using?
> 
> What is the output of "cat /etc/network/interfaces"
> 
> > The weird thing is that with normal booting configuration, pinging INet 
> > addresses
> > fails.  This seems to be related to the order in which the interfaces come 
> > up: doing
> >     ifdown eth1 ; ifdown eth1 ; ifup eth0; ifup eth1
> > causes pings to fail; but if eth0/eth1 are reversed (bringing up eth0 
> > last), or eth1
> > is simply suppressed, pinging URLs works (i.e. ping www.debian.org).
> 

Sounds to me like both are setting a default gw. The last one takes precendence
so if you bring up eth0 last the default gw is set to the outside world, if you
bring eth1 last the default gw is in the local network and assuming the dns
address is not on the same subnet as eth0 requests are going through the
default gateway to eth1 which has no idea what to do with them

> Have you a local DNS server?
> 
> > Regrettably this last does not entirely solve things - for example, I 
> > cannot do system
> > updates: "apt-get update" fails to connect.
> 
> Error? times out? unable to contact … ?
> 
> > Eventually, if I play around long enough (killing eth1, killing my firewall 
> > - which
> > hasn't changed since before adding the second NIC,...) I can do a system 
> > update
> > but it's not entirely clear what the critical steps were to get that 
> > working.
> 
> killing the firewall mmm ...
> 
> > I freely admit that I'm a hardware guy - I don't know much about networking.
> 
> I don't know much about networking either but if I was asking this
> question I'd provide at least the config files (see above), exact error
> messages from logs (if any … if none say so.), exact messages on screen,
> (if none, say so) 
> 
> > Does anyone have a suggestion on where I might look to get this working 
> > properly?
> > Without sacrificing eth1?  Or at least some better diagnostic[s] to track 
> > down
> > where packets are getting lost?
> 
> Of course, I'd only post to this list after I'd used "apt-cache search
> network test | wc -l" and saw that it shows 83 packages which fit that
> search criteria and see that there is not really anthing useful, ok
> there is "ping", but you've already used that.
> 
> So I'd try "apt-cache search network diagnos | wc -l"  ok 14, and see …
>  that there is nothing very useful.
> 
> We're at the mercy of the package maintainers to at least put some
> decent search terms in the descriptions and not just copy a paragraph
> off the upstream website or manpage.
> 
> So I'd state I'd searched the packages and didn't really see anything
> useful.
> 
> Also describe the network a bit more -DSL? Is this the first time you
> are connecting to the net with this machine etc.
> 
> You may then get a response from someone who sees an anomaly with
> your setup, and might even help.
> 
> But, and this is a stab in the dark, I think you have to tell the
> firewall about your new interface.
> 


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to