Sure, can provide more info...
============ /etc/network/interfaces :
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
#iface eth0 inet dhcp
iface eth0 inet static
address xxx.yyy.zzz.32
network xxx.yyy.zzz.0
netmask 255.255.255.0
broadcast xxx.yyy.zzz.255
gateway xxx.yyy.zzz.100
pre-up /etc/iptables/iptables.sh start
post-down /etc/iptables/iptables.sh stop
# The secondary network interface
auto eth1
#iface eth0 inet dhcp
iface eth1 inet static
address 192.168.42.100
network 192.168.42.0
netmask 255.255.255.0
#broadcast 192.168.42.255
gateway 192.168.42.100
=============== route result:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
xxx.yyy.zzz.0 * 255.255.255.0 U 0 0 0 eth0
192.168.42.0 * 255.255.255.0 U 0 0 0 eth1
===============
To reiterate:
* The fundamental breakdown involves communication over the eth0
interface. Things just seem to "hang" when trying stuff
like apt-get update.
* ssh'ing into this machine from another host (directly to the IP of
this machine) always works.
* firewall is "unchanged"; well, ok, added:
$IPT -A OUTPUT -o eth1 ! -s 192.168.42.0/25 -j DROP
$IPT -A OUTPUT -o eth1 -s 192.168.42.0/24 -j ACCEPT
$IPT -A INPUT -i eth1 ! -s 192.168.42.0/24 -j DROP
$IPT -A INPUT -i eth1 -s 192.168.42.0/24 -j ACCEPT
All communication with 192.168.42.x devices is functional.
Listing iptables -L -n -v shows eth0 where it should.
* simply turning firewall off (allowing everything)
does not (at least by itself) fix eth0 communication.
* as you can see, this is IPs are entirely static - no dhcp
* "network-manager" not installed
Since turning eth1 entirely OFF seems key to restoring eth0 full
functionality, I agree that somehow the system seems confused
about which interface to use.
Any other thoughts/ideas welcome!
-f
*
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
