Bug 87691 - NIC catches packets after "ifconfig eth1 down"
NIC catches packets after "ifconfig eth1 down"
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: net-tools (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-01 07:20 EST by Michael Muenz
Modified: 2015-03-04 20:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-27 08:09:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Muenz 2003-04-01 07:20:09 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 
1.0.3705)

Description of problem:
I've got a test machine in my network and the following situation:

Firewall Internal IP: 192.168.1.1
Gateway IP to 192.168.0.0/24 is 192.168.1.2

Test machine has IP 192.168.0.50 (eth0).
I give Test machine 192.168.1.1 (eth1) with ifconfig and then
type "ifconfig eth1 down".
Normal ifconfig output then shows only eth0. With
"ifconfig -a" I can see the IP from eth1 further.

Now, when I want to ping from 192.168.1.1 to 192.168.0.50, 
the test machine got the packet (find out with tcpdump)
but doesn't send a reply. It sends the answer to eth1.

When I give eth1 a completly different IP again, the reply
will arrive the Firewall. 

Perhaps it's a problem of the kernel, I'm not a developer.

Is it a known bug ? 



Version-Release number of selected component (if applicable):
1.60

How reproducible:
Always

Steps to Reproduce:
described above

Additional info:
Comment 1 Phil Knirsch 2003-06-27 08:09:09 EDT
From what i understand of your description this is expected behaviour:

You have only shut down the interface but not 'completely' disabled it (via
module unloading, route deletetion etc), so without any iptables or ipchains
rules the interface will still receive packages, but the kernel obviously won't
route them anymore.

And as soon as you give your interface another IP address it automatically
becomes up again and therefore starts to operate again.

I hope i have understood your problem correctly.

Read ya, Phil

Note You need to log in before you can comment on or make changes to this bug.