Re: changing ethernet devices, new one stops cold at iptables

[Gene Heskett]

On Friday 23 July 2004 07:13, Neil Horman wrote:
>Gene Heskett wrote:
[...]
>> One thing I haven't tried is to reset the MAC address for the
>> nforce2 ethernet to match the D-Links hardware address.  Is it
>> worth a try just to prove the point?
>
>I'd think so.  Its a two minute test to verify that the problem is
>related to the MAC address of nic in the firewall.  You may also
> want to add a LOG target to all the chains in your firewall to
> match on the origional MAC address so you can see what your
> iptables code is doing with the packet.
>
>HTH
>Neil

ok, rebooted ignored the kudzu stuff about the old 8139too, fired up x 
and used redhat-config-network to deactive both (which now had the 
same MAC address) and rebuilt a new eth0 using the relabeled 
forcedeth driver, moved the cable and restarted the network.  It all 
works.

So, lemme go get the /etc/sysconfig/iptables file and include it, 
because I cannot see anything that makes use of the MAC address in 
any of it.  As you can see from the accounting, lots of data has 
moved.
------------------
# Generated by iptables-save v1.2.7a on Tue May 18 11:20:01 2004
*mangle
:PREROUTING ACCEPT [202871737:120105858881]
:INPUT ACCEPT [139048151:73020278748]
:FORWARD ACCEPT [46936292:35515502787]
:OUTPUT ACCEPT [154434852:126073464036]
:POSTROUTING ACCEPT [188592053:156100678907]
COMMIT
# Completed on Tue May 18 11:20:01 2004
# Generated by iptables-save v1.2.7a on Tue May 18 11:20:01 2004
*nat
:PREROUTING ACCEPT [1095914:117590573]
:POSTROUTING ACCEPT [506424:54549861]
:OUTPUT ACCEPT [506316:54543401]
[458696:27814663] -A POSTROUTING -s 192.168.71.3 -o eth0 -j MASQUERADE
# [] -A POSTROUTING -s 192.168.71.4 -o eth0 -j MASQUERADE
COMMIT
# Completed on Tue May 18 11:20:01 2004
# Generated by iptables-save v1.2.7a on Tue May 18 11:20:01 2004
*filter
:INPUT ACCEPT [764513:261233004]
:FORWARD ACCEPT [899862:777851140]
:OUTPUT ACCEPT [67156239:19633863841]
[152090648:81083207296] -A INPUT -i eth1 -j ACCEPT
[2813341:3132361045] -A INPUT -i eth0 -m state --state 
RELATED,ESTABLISHED -j ACCEPT
[174681:55726580] -A INPUT -i lo -j ACCEPT
[0:0] -I INPUT -p tcp --destination-port 6881:6889 -j ACCEPT
# [0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 6881:6999 
-j ACCEPT
[336:50753] -A INPUT -p tcp -m state --state NEW -m tcp ! --tcp-flags 
SYN,RST,ACK SYN -j LOG --log-prefix "New not
syn: "
[336:50753] -A INPUT -p tcp -m state --state NEW -m tcp ! --tcp-flags 
SYN,RST,ACK SYN -j DROP
[13478612:872497237] -A FORWARD -i eth1 -o eth0 -m state --state 
NEW,RELATED,ESTABLISHED -j ACCEPT
[26626623:33286598582] -A FORWARD -i eth0 -o eth1 -m state --state 
RELATED,ESTABLISHED -j ACCEPT
[87041832:106421017831] -A OUTPUT -o eth1 -j ACCEPT
[521:17036] -A OUTPUT -p icmp -m state --state INVALID -j DROP
[232781:18324718] -A OUTPUT -o eth0 -m state --state 
NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Tue May 18 11:20:01 2004
---------------------

The BitTorrent stuff didn't work :(, but I've not removed it...
Probhably something in the router, a linksys BEFSR41 w/latest flash.

If there is nothing above thats responsible, then it seems to me it 
has to be arp related.  I've just now started studying the manpages 
there, and I'm not too sure what I need to do there in order to 
restore full function to the new MAC address if and when I put it 
back to something nvidia related.  Pointers welcome in any case.

-- 
Cheers, Gene
There are 4 boxes to be used in defense of liberty. 
Soap, ballot, jury, and ammo.
Please use in that order, starting now.  -Ed Howdershelt, Author
Additions to this message made by Gene Heskett are Copyright 2004, 
Maurice E. Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/