2:30 a.m.
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
--
Hangbin Liu <haliu(a)redhat.com>
2:48 a.m.
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
3:20 a.m.
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
3:41 a.m.
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
4:55 a.m.
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
5:12 a.m.
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
>
4675
days inactive
4675
days old
5 comments
2 participants
participants (2)
-
Hangbin Liu -
Jan Friesse