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

Re: NIC only works in PROMISC mode



Please excuse me for not fully participating in the mailing list.  I just
wanted to follow up my previous post in case somebody else has the same 
problem.

Well, thanks to Dana's keen observations, I found a new perspective on
the situation.

I confess, in my original post I did not give the whole truth.  I am trying to 
use sea.c to spoof my MAC address so the ISP will dole out an IP to me.  I
didn't think sea was the problem because ifconfig -A reports the dx'd MAC 
address.

Dana provided me with a good reason for suspecting sea. Maybe somehow 
the rl NIC is still waiting for traffic to it's real MAC and ignoring the sea
address...  I don't know enough to actually test this theory.  And, I had to try a
few other things first.

First I tried going back to 3.4 since this is older hardware, I thought something
may have broke in 3.5 or 3.6, that didn't work.
Then I tried making rl1 the ext_if and rl0 the int_if, didn't work.
I finally succombed to tossing in a 3COM 3c900B and a 3c905 in place of the
Realtek NICs. Well, I modified my config files, rebooted, and it worked.

whaddayaknow.

My conclusions is that sea doesn't work well with either the Realtek driver, or my 
Realtek hardware.  The model number is actually AT-2500TX V3, can't remember 
who made it, I think I got it from Allied Telesyn.

Now, it's back to work, I need to do my fourth install for the weekend, back to 3.5.
At least I have the CD for this one, and it's getting quicker each time.

Thanks,

Barry



On 19/09/2004, at 11:37 PM, barry.grumbine wrote:

    What could be causing this?
    I am setting up a gateway/firewall.
    I first tried 3.5, then tried a 3.6 snapshot (9-18-04) with same results.
    The external NIC is rl0, the internal NIC is rl1.

    Problem: the external NIC sends/receives packets _ONLY_ while tcpdump -n -i rl0
    I think this tells me that the NIC _ONLY_ works in PROMISC mode. 


rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	address: 00:00:94:cf:88:ab
	media: Ethernet 100baseTX
	status: active
	inet6 fe80::200:94ff:fecf:88ab%rl0 prefixlen 64 scopeid 0x1
	inet 216.x.x.x netmask 0xffffff00 broadcast 216.x.x.255


    rl0 at pci0 dev 17 function 0 "Realtek 8139" rev 0x10: irq 11 address 00:a0:d2:10:20:74 


dana wrote:
My Quadra840av has a similar problem, and it looks to be caused by a similar oddity that shows up in your system.

ifconfig shows your rl0 to have the hardware address 00:00:94:cf:88:ab
dmesg shows your rl0 to have the hardware address 00:a0:d2:10:20:74


I suspect dmesg has the correct address, and ifconfig has the bogus one. Packets will leave your machine via rl0: identified as coming from 00:00:94:cf:88:ab, and when any reply is sent back for it, they will be sent to be collected by the NIC with that same address, 00:00:94:cf:88:ab

As the NIC's real address would then be 00:a0:d2:10:20:74, it will never pick them up - unless it's in promiscuous mode.

My Quadra shows the correct MAC address in dmesg, but ifconfig shows it as 00:00:00:00:00:00, and I get identical problems to yours, also solved by the tcpdump fix.

dana