[#4903] ping to eth1 on vlan of 518f ezbrd can still work for a while after the eth1 is turn off
Submitted By: Mingquan Pan
Open Date
2009-02-13 05:52:56 Close Date
2009-03-03 23:42:45
Priority:
Medium Assignee:
Graf Yang
Status:
Closed Fixed In Release:
N/A
Found In Release:
N/A Release:
Category:
N/A Board:
N/A
Processor:
BF518 Silicon Revision:
Is this bug repeatable?:
Yes Resolution:
Rejected
Uboot version or rev.:
Toolchain version or rev.:
4.1 toolchain of Jan 16
App binary format:
N/A
Summary: ping to eth1 on vlan of 518f ezbrd can still work for a while after the eth1 is turn off
Details:
ping to eth1 on vlan of 518f ezbrd can still work for a while after the eth1 is turn off.
On target:
root:/> ifconfig
eth0 Link encap:Ethernet HWaddr 0A:39:0E:5C:AC:8E
inet addr:11.11.11.11 Bcast:11.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:128 errors:0 dropped:0 overruns:0 frame:0
TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:12650 (12.3 KiB) TX bytes:2212 (2.1 KiB)
eth2 Link encap:Ethernet HWaddr 0A:39:0E:5C:AC:8E
inet addr:10.100.4.2 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:103 errors:0 dropped:0 overruns:0 frame:0
TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:8336 (8.1 KiB) TX bytes:1260 (1.2 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
root:/> version
kernel: Linux release 2.6.28.3-ADI-2009R1-pre-svn6083, build #29 Fri Feb 13 17:03:19 GMT-8 2009
toolchain: bfin-uclinux-gcc release gcc version 4.1.2 (ADI svn)
user-dist: release svn-7715, build #9 Fri Feb 13 17:02:19 GMT-8 2009
On host:
test@51x:~>
test@51x:~> ping 10.100.4.1
PING 10.100.4.1 (10.100.4.1) 56(84) bytes of data.
64 bytes from 10.100.4.1: icmp_seq=1 ttl=64 time=0.321 ms
64 bytes from 10.100.4.1: icmp_seq=2 ttl=64 time=0.267 ms
^C
--- 10.100.4.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.267/0.294/0.321/0.027 ms
test@51x:~> ping 10.100.4.2
PING 10.100.4.2 (10.100.4.2) 56(84) bytes of data.
64 bytes from 10.100.4.2: icmp_seq=1 ttl=64 time=0.277 ms
64 bytes from 10.100.4.2: icmp_seq=2 ttl=64 time=0.270 ms
^C
--- 10.100.4.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.270/0.273/0.277/0.016 ms
Follow-ups
--- Graf Yang 2009-02-17 03:19:10
I can't duplicate such issues.
--- Mike Frysinger 2009-02-27 02:13:34
it depends on how things are plugged in. by default, Linux will happilly
respond to any IP address it has regardless of the interface it is bound to.
--- Graf Yang 2009-02-27 03:04:49
It seems grace pasted a wrong page.
In this case,
On target:
1. ifconfig eth1 10.100.4.1 up
2. ifconfig eth2 20.100.4.1 up
3. ifconfig eth1 down
Turn to host (PC):
1. ifconfig eth1 10.100.4.2
2. ping 10.100.4.1
Grace said that the ping command is still successful.
--- Mike Frysinger 2009-02-27 11:07:30
doing `ifconfig down` does not remove the ip address. if eth2 on the board can
reach eth1 on the PC, then this is correct behavior.
--- Mingquan Pan 2009-03-02 06:20:37
The connection is as following :
host eth1: 10.100.4.174 connect to target eth1 : 10.100.4.50
host eth2: 10.99.29.80 connect to company switch.
target eth2: 10.99.29.79 also connect to this commpany switch.
So should target eth2 can be pinged through by host after ifconfig it down?
--- Mike Frysinger 2009-03-02 10:40:10
if the systems are on the same network segment, then they'll see each others
broadcast. so the behavior is correct.
--- Mingquan Pan 2009-03-03 23:42:45
ok, so I set to two network segments. Close this issue.
--- Graf Yang 2009-06-03 22:32:54
It is not a bug.
Files
Changes
Commits
Dependencies
Duplicates
Associations
Tags
File Name File Type File Size Posted By
No Files Were Found