Maybe you should search your solution in the Windows common bugfix solution
tutorials where the common rule is defined this way:
If (strange_problem) {
Do "reboot the system"
}
(c) by BillySoft
But anyways, I think Tim Wright shows a problem , which is indeed serious for
admins. (I not tried his findings, but will do on weekend to try..)
You come over to a machine, do an ifconfig , you see "nothing" and therefore
you not belive anything different is active.
Would be really no bad idea, to change ifconfig this way that it shows "running
but down interfaces"
I personally guess that 99.99% of all linux admins (including me) will take the
listing of "ifconfig" as "fact" and will sure not investigate "if there might
be other things active"
But this is something "outside" linux kernel ...
It's simple a question of "trust"
Franz
-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Tim Wright
Gesendet: Dienstag, 28. November 2006 23:52
An: David Miller; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [email protected]
Betreff: RE: Arp undo issue in all 2.4 and 2.6 kernel releases
> -----Original Message-----
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 28, 2006 2:19 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [email protected]
> Subject: Re: Arp undo issue in all 2.4 and 2.6 kernel releases
>
> From: "Tim Wright" <[EMAIL PROTECTED]>
> Date: Tue, 28 Nov 2006 13:19:39 -0800
>
> > At the point where the system is responding, there should be no
> > interfaces with the given IP address and ifconfig confirms
> this. The
> > IP address is not associated with any interface and should not be
> > associated with the system either. The sequence of events
> is "bring up
> > the address on one interface, try to bring it up on another alias,
> > bring the address down". This isn't an issue of "replying
> to ARP out
> > the wrong interface", it is replying to arp requests when no
> > interfaces on the system have that IP address associated.
>
> Try "ifconfig -a" as suggested elsewhere, or "ip addr list".
> The addresses are still there.
>
> Bringing and interface down does not delete the IP addresses.
> Interfaces are associated with the system, not specific interfaces.
>
[EMAIL PROTECTED] root]# ip addr list
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
5: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:80:ad:72:3e:5a brd ff:ff:ff:ff:ff:ff
inet 10.12.0.20/16 brd 10.12.255.255 scope global eth0
inet6 fe80::280:adff:fe72:3e5a/64 scope link
valid_lft forever preferred_lft forever
6: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 00:80:ad:20:59:8b brd ff:ff:ff:ff:ff:ff
7: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 00:01:02:c6:fe:c1 brd ff:ff:ff:ff:ff:ff
8: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
[EMAIL PROTECTED] root]# ping 10.12.0.22
PING 10.12.0.22 (10.12.0.22) 56(84) bytes of data.
64 bytes from 10.12.0.22: icmp_seq=0 ttl=64 time=0.108 ms
64 bytes from 10.12.0.22: icmp_seq=1 ttl=64 time=0.076 ms
--- 10.12.0.22 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.076/0.092/0.108/0.016 ms, pipe 2
It's not associated with any interface on the system. Please try this
yourself. It is trivially reproducible.
Thanks,
Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
