hi, when I first used omping and tried with the cmd : # omping fe80::62eb:69ff:feba:c932 fe80::200:1aff:fe1a:c90b # omping -6 fe80::62eb:69ff:feba:c932 fe80::200:1aff:fe1a:c90b # omping 10.16.40.142 10.16.42.40 # omping hostA hostB
I got a "omping: Multiple local interfaces match parameters" error each time .
Can you tell me how to use it ?
Thanks
Hi Hangbin, can you please rerun omping with -vvv parameter? This will give you a lot of debug messages and this should help us to identify problem.
But if not bug, it really looks like you have multiple NICs with same IP (ether 10.16.40.142 or 10.16.42.40).
Regards, Honza
Hangbin Liu napsal(a):
hi, when I first used omping and tried with the cmd : # omping fe80::62eb:69ff:feba:c932 fe80::200:1aff:fe1a:c90b # omping -6 fe80::62eb:69ff:feba:c932 fe80::200:1aff:fe1a:c90b # omping 10.16.40.142 10.16.42.40 # omping hostA hostB
I got a "omping: Multiple local interfaces match parameters" error each time .
Can you tell me how to use it ?
Thanks
On Thu, 2011-07-07 at 09:48 +0200, Jan Friesse wrote:
Hi Hangbin, can you please rerun omping with -vvv parameter? This will give you a lot of debug messages and this should help us to identify problem.
But if not bug, it really looks like you have multiple NICs with same IP (ether 10.16.40.142 or 10.16.42.40).
Jan,
With "-vvv" find the reason . I add a br0 on eth0 , so there is a fe80::62eb:69ff:feba:c932 on both eth0 and br0 . delete the fe80 addr on eth0 and omping going on well .
But I can't got any response msg from other remote hosts except from myself. Doesn't understand multicast clearly , can you tell me why ? Thanks.
/* without bridge , just an eth0 */
# omping 10.16.40.142 10.16.42.40 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg ^C 10.16.42.40 : response message never received
# omping 10.16.40.142 224.0.0.1 224.0.0.1 : waiting for response msg 224.0.0.1 : waiting for response msg 224.0.0.1 : waiting for response msg 224.0.0.1 : waiting for response msg ^C 224.0.0.1 : response message never received
# omping 10.16.40.142 10.16.40.142 10.16.40.142 : waiting for response msg 10.16.40.142 : joined (S,G) = (*, 232.43.211.234), pinging 10.16.40.142 : unicast, seq=1, size=69 bytes, dist=0, time=0.014ms 10.16.40.142 : multicast, seq=1, size=69 bytes, dist=0, time=0.024ms
Hangbin Liu napsal(a):
On Thu, 2011-07-07 at 09:48 +0200, Jan Friesse wrote:
Hi Hangbin, can you please rerun omping with -vvv parameter? This will give you a lot of debug messages and this should help us to identify problem.
But if not bug, it really looks like you have multiple NICs with same IP (ether 10.16.40.142 or 10.16.42.40).
Jan,
With "-vvv" find the reason . I add a br0 on eth0 , so there is a fe80::62eb:69ff:feba:c932 on both eth0 and br0 . delete the fe80 addr on eth0 and omping going on well .
Great, but one extra question. Did you had 10.16.40.142 on eth0 and br0 too, or not? Because if not, and omping was complaining, it is bug.
Btw. which version are you using?
But I can't got any response msg from other remote hosts except from myself. Doesn't understand multicast clearly , can you tell me why ? Thanks.
Ok, so basic usage is following.
Let's say you want to test connection between two computers (what you probably want) with IP 10.16.40.142 and 10.16.42.40
Only thing you must to is to run
omping 10.16.40.142 10.16.42.40
on both of computers. This is because normal ping is handled by OS (in other words you have server running all the time) but ssmping (protocol used by onping) is not running by OS, so you must run server (omping is behaving both as client and server)
/* without bridge , just an eth0 */
# omping 10.16.40.142 10.16.42.40 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg ^C 10.16.42.40 : response message never received
So here on 10.16.42.40 omping is not running.
# omping 10.16.40.142 224.0.0.1 224.0.0.1 : waiting for response msg 224.0.0.1 : waiting for response msg 224.0.0.1 : waiting for response msg 224.0.0.1 : waiting for response msg ^C 224.0.0.1 : response message never received
This is really bug and omping should complain, because 224.0.0.1 is multicast address.
# omping 10.16.40.142 10.16.40.142 10.16.40.142 : waiting for response msg 10.16.40.142 : joined (S,G) = (*, 232.43.211.234), pinging 10.16.40.142 : unicast, seq=1, size=69 bytes, dist=0, time=0.014ms 10.16.40.142 : multicast, seq=1, size=69 bytes, dist=0, time=0.024ms
I'm wondering that this works, but ... ya it make sense. Since omping 0.0.2 same effect gives you omping 10.16.40.142. This is good for testing local firewall, because at least on Fedora/RHEL you will never get multicast reply with default firewall on.
Regards, Honza
On Thu, 2011-07-07 at 10:41 +0200, Jan Friesse wrote:
Hangbin Liu napsal(a):
On Thu, 2011-07-07 at 09:48 +0200, Jan Friesse wrote:
Hi Hangbin, can you please rerun omping with -vvv parameter? This will give you a lot of debug messages and this should help us to identify problem.
But if not bug, it really looks like you have multiple NICs with same IP (ether 10.16.40.142 or 10.16.42.40).
Jan,
With "-vvv" find the reason . I add a br0 on eth0 , so there is a fe80::62eb:69ff:feba:c932 on both eth0 and br0 . delete the fe80 addr on eth0 and omping going on well .
Great, but one extra question. Did you had 10.16.40.142 on eth0 and br0 too, or not? Because if not, and omping was complaining, it is bug.
if we add an interface to bridge with out remove it's ip address , we will still have the address which it can't be used actually . i.e.
# brctl addbr br0 # brctl addif br0 eth0 <== which we should #ifconfig eht0 0.0.0.0 first # ifconfig br0 up # dhclient br0 # ifconfig br0 Link encap:Ethernet HWaddr 60:EB:69:BA:C9:32 inet addr:10.16.40.142 Bcast:10.16.47.255 Mask:255.255.248.0 inet6 addr: fe80::62eb:69ff:feba:c932/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:772 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:62584 (61.1 KiB) TX bytes:810 (810.0 b)
eth0 Link encap:Ethernet HWaddr 60:EB:69:BA:C9:32 inet addr:10.16.40.142 Bcast:10.16.47.255 Mask:255.255.248.0 inet6 addr: 2620:52:0:102f:62eb:69ff:feba:c932/64 Scope:Global inet6 addr: fe80::62eb:69ff:feba:c932/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:225267 errors:0 dropped:0 overruns:2 frame:0 TX packets:3558 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:29019407 (27.6 MiB) TX bytes:543379 (530.6 KiB) Memory:feb60000-feb80000
then we got 2 same ipv4 & ipv6 addresses on br0 and eth0. I don't know if it's a bug , because I need remove the address before add an interface to bridge. Use network-script method won't have this fault.
Btw. which version are you using?
omping-0.0.4
But I can't got any response msg from other remote hosts except from myself. Doesn't understand multicast clearly , can you tell me why ? Thanks.
Ok, so basic usage is following.
Let's say you want to test connection between two computers (what you probably want) with IP 10.16.40.142 and 10.16.42.40
Only thing you must to is to run
omping 10.16.40.142 10.16.42.40
on both of computers. This is because normal ping is handled by OS (in other words you have server running all the time) but ssmping (protocol used by onping) is not running by OS, so you must run server (omping is behaving both as client and server)
This time I run omping on both server and client . Another fault came out... I can't get the response with ipv4 , but done well with ipv6 .
IPv4 ( iptables -F & ip address are correct )
# omping 10.16.40.142 10.16.40.146 10.16.40.146 : waiting for response msg 10.16.40.146 : waiting for response msg 10.16.40.146 : joined (S,G) = (*, 232.43.211.234), pinging 10.16.40.146 : unicast, seq=1, size=69 bytes, dist=0, time=0.117ms 10.16.40.146 : unicast, seq=2, size=69 bytes, dist=0, time=0.161ms 10.16.40.146 : unicast, seq=3, size=69 bytes, dist=0, time=0.161ms 10.16.40.146 : unicast, seq=4, size=69 bytes, dist=0, time=0.159ms ^C 10.16.40.146 : unicast, xmt/rcv/%loss = 4/4/0%, min/avg/max/std-dev = 0.117/0.149/0.161/0.022 10.16.40.146 : multicast, xmt/rcv/%loss = 4/0/100%, min/avg/max/std-dev = 0.000/0.000/0.000/0.000 [root@dell-pec6105-02 omping-0.0.4]#
IPv6
# omping fe80::62eb:69ff:feba:c932 fe80::226:6cff:fef9:e8a8 fe80::226:6cff:fef9:e8a8 : waiting for response msg fe80::226:6cff:fef9:e8a8 : joined (S,G) = (*, ff3e::4321:1234), pinging fe80::226:6cff:fef9:e8a8 : unicast, seq=1, size=81 bytes, dist=0, time=0.180ms fe80::226:6cff:fef9:e8a8 : multicast, seq=1, size=81 bytes, dist=0, time=0.221ms fe80::226:6cff:fef9:e8a8 : unicast, seq=2, size=81 bytes, dist=0, time=0.178ms fe80::226:6cff:fef9:e8a8 : multicast, seq=2, size=81 bytes, dist=0, time=0.196ms fe80::226:6cff:fef9:e8a8 : unicast, seq=3, size=81 bytes, dist=0, time=0.177ms fe80::226:6cff:fef9:e8a8 : multicast, seq=3, size=81 bytes, dist=0, time=0.204ms ^C fe80::226:6cff:fef9:e8a8 : unicast, xmt/rcv/%loss = 3/3/0%, min/avg/max/std-dev = 0.177/0.178/0.180/0.002 fe80::226:6cff:fef9:e8a8 : multicast, xmt/rcv/%loss = 3/3/0%, min/avg/max/std-dev = 0.196/0.207/0.221/0.013 #
/* without bridge , just an eth0 */
# omping 10.16.40.142 10.16.42.40 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg ^C 10.16.42.40 : response message never received
So here on 10.16.42.40 omping is not running.
# omping 10.16.40.142 224.0.0.1 224.0.0.1 : waiting for response msg 224.0.0.1 : waiting for response msg 224.0.0.1 : waiting for response msg 224.0.0.1 : waiting for response msg ^C 224.0.0.1 : response message never received
This is really bug and omping should complain, because 224.0.0.1 is multicast address.
# omping 10.16.40.142 10.16.40.142 10.16.40.142 : waiting for response msg 10.16.40.142 : joined (S,G) = (*, 232.43.211.234), pinging 10.16.40.142 : unicast, seq=1, size=69 bytes, dist=0, time=0.014ms 10.16.40.142 : multicast, seq=1, size=69 bytes, dist=0, time=0.024ms
I'm wondering that this works, but ... ya it make sense. Since omping 0.0.2 same effect gives you omping 10.16.40.142. This is good for testing local firewall, because at least on Fedora/RHEL you will never get multicast reply with default firewall on.
Regards, Honza
Hangbin Liu napsal(a):
On Thu, 2011-07-07 at 10:41 +0200, Jan Friesse wrote:
Hangbin Liu napsal(a):
On Thu, 2011-07-07 at 09:48 +0200, Jan Friesse wrote:
Hi Hangbin, can you please rerun omping with -vvv parameter? This will give you a lot of debug messages and this should help us to identify problem.
But if not bug, it really looks like you have multiple NICs with same IP (ether 10.16.40.142 or 10.16.42.40).
Jan,
With "-vvv" find the reason . I add a br0 on eth0 , so there is a fe80::62eb:69ff:feba:c932 on both eth0 and br0 . delete the fe80 addr on eth0 and omping going on well .
Great, but one extra question. Did you had 10.16.40.142 on eth0 and br0 too, or not? Because if not, and omping was complaining, it is bug.
if we add an interface to bridge with out remove it's ip address , we will still have the address which it can't be used actually . i.e.
# brctl addbr br0 # brctl addif br0 eth0 <== which we should #ifconfig eht0 0.0.0.0 first # ifconfig br0 up # dhclient br0 # ifconfig br0 Link encap:Ethernet HWaddr 60:EB:69:BA:C9:32 inet addr:10.16.40.142 Bcast:10.16.47.255 Mask:255.255.248.0 inet6 addr: fe80::62eb:69ff:feba:c932/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:772 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:62584 (61.1 KiB) TX bytes:810 (810.0 b)
eth0 Link encap:Ethernet HWaddr 60:EB:69:BA:C9:32 inet addr:10.16.40.142 Bcast:10.16.47.255 Mask:255.255.248.0 inet6 addr: 2620:52:0:102f:62eb:69ff:feba:c932/64 Scope:Global inet6 addr: fe80::62eb:69ff:feba:c932/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:225267 errors:0 dropped:0 overruns:2 frame:0 TX packets:3558 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:29019407 (27.6 MiB) TX bytes:543379 (530.6 KiB) Memory:feb60000-feb80000
then we got 2 same ipv4 & ipv6 addresses on br0 and eth0. I don't know if it's a bug , because I need remove the address before add an interface to bridge. Use network-script method won't have this fault.
I don't think this is a bug and actually omping error message is clear. Two interfaces with same IP (at least ip4) may cause problems.
Btw. which version are you using?
omping-0.0.4
But I can't got any response msg from other remote hosts except from myself. Doesn't understand multicast clearly , can you tell me why ? Thanks.
Ok, so basic usage is following.
Let's say you want to test connection between two computers (what you probably want) with IP 10.16.40.142 and 10.16.42.40
Only thing you must to is to run
omping 10.16.40.142 10.16.42.40
on both of computers. This is because normal ping is handled by OS (in other words you have server running all the time) but ssmping (protocol used by onping) is not running by OS, so you must run server (omping is behaving both as client and server)
This time I run omping on both server and client . Another fault came out... I can't get the response with ipv4 , but done well with ipv6 .
IPv4 ( iptables -F & ip address are correct )
# omping 10.16.40.142 10.16.40.146 10.16.40.146 : waiting for response msg 10.16.40.146 : waiting for response msg 10.16.40.146 : joined (S,G) = (*, 232.43.211.234), pinging 10.16.40.146 : unicast, seq=1, size=69 bytes, dist=0, time=0.117ms 10.16.40.146 : unicast, seq=2, size=69 bytes, dist=0, time=0.161ms 10.16.40.146 : unicast, seq=3, size=69 bytes, dist=0, time=0.161ms 10.16.40.146 : unicast, seq=4, size=69 bytes, dist=0, time=0.159ms ^C 10.16.40.146 : unicast, xmt/rcv/%loss = 4/4/0%, min/avg/max/std-dev = 0.117/0.149/0.161/0.022 10.16.40.146 : multicast, xmt/rcv/%loss = 4/0/100%, min/avg/max/std-dev = 0.000/0.000/0.000/0.000 [root@dell-pec6105-02 omping-0.0.4]#
This is reason why omping is there. It means that it's possible to send/receive unicast packets, but not multicast one. Failure may be caused by ether improperly configured switch, or local firewall (iptables -F only flushes rules, it doesn't change default policy, service iptables stop is good way to really stop firewall at least on Fedora/RHEL) on one of side.
You can try
omping 10.16.40.142
on one machine and
omping 10.16.40.146
on second one. This will give you idea if problem is switch or local firewall.
It's also possible to use -vv to get more verbose output.
IPv6
# omping fe80::62eb:69ff:feba:c932 fe80::226:6cff:fef9:e8a8 fe80::226:6cff:fef9:e8a8 : waiting for response msg fe80::226:6cff:fef9:e8a8 : joined (S,G) = (*, ff3e::4321:1234), pinging fe80::226:6cff:fef9:e8a8 : unicast, seq=1, size=81 bytes, dist=0, time=0.180ms fe80::226:6cff:fef9:e8a8 : multicast, seq=1, size=81 bytes, dist=0, time=0.221ms fe80::226:6cff:fef9:e8a8 : unicast, seq=2, size=81 bytes, dist=0, time=0.178ms fe80::226:6cff:fef9:e8a8 : multicast, seq=2, size=81 bytes, dist=0, time=0.196ms fe80::226:6cff:fef9:e8a8 : unicast, seq=3, size=81 bytes, dist=0, time=0.177ms fe80::226:6cff:fef9:e8a8 : multicast, seq=3, size=81 bytes, dist=0, time=0.204ms ^C fe80::226:6cff:fef9:e8a8 : unicast, xmt/rcv/%loss = 3/3/0%, min/avg/max/std-dev = 0.177/0.178/0.180/0.002 fe80::226:6cff:fef9:e8a8 : multicast, xmt/rcv/%loss = 3/3/0%, min/avg/max/std-dev = 0.196/0.207/0.221/0.013 #
/* without bridge , just an eth0 */
# omping 10.16.40.142 10.16.42.40 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg 10.16.42.40 : waiting for response msg ^C 10.16.42.40 : response message never received
So here on 10.16.42.40 omping is not running.
# omping 10.16.40.142 224.0.0.1 224.0.0.1 : waiting for response msg 224.0.0.1 : waiting for response msg 224.0.0.1 : waiting for response msg 224.0.0.1 : waiting for response msg ^C 224.0.0.1 : response message never received
This is really bug and omping should complain, because 224.0.0.1 is multicast address.
# omping 10.16.40.142 10.16.40.142 10.16.40.142 : waiting for response msg 10.16.40.142 : joined (S,G) = (*, 232.43.211.234), pinging 10.16.40.142 : unicast, seq=1, size=69 bytes, dist=0, time=0.014ms 10.16.40.142 : multicast, seq=1, size=69 bytes, dist=0, time=0.024ms
I'm wondering that this works, but ... ya it make sense. Since omping 0.0.2 same effect gives you omping 10.16.40.142. This is good for testing local firewall, because at least on Fedora/RHEL you will never get multicast reply with default firewall on.
Regards, Honza
omping@lists.stg.fedorahosted.org
-
Hangbin Liu -
Jan Friesse