Make omping work with nat

[jfriesse]

Looks like libvirt with nat translates multicast. Replies are then visible as a bridge address and not as a source. Example network:

<name>default</name>
<forward mode='nat'>
<nat>
   <port start='1024' end='65535'/>
  </nat>
  </forward>
 <bridge name='virbr0' stp='on' delay='0'/>
 <ip address='192.168.122.1' netmask='255.255.255.0'>
   <dhcp>
     <range start='192.168.122.2' end='192.168.122.254'/>
   </dhcp>
 </ip>
</network>

and omping then

omping.c:421 Received multicast message from 192.168.122.1 type A (0x41), len 69

Solution seems to be to:

• Add source address as one of option
  • Such option is not in the RFC so has to use custom one
  • Add CLI option to force strict RFC behavior (= source address option is not included)
• When mcast packet with source address option is received display it in some kind of special format (example multicast(forwarded/nat/... by 192.168.122.1), seq=6, size=69 bytes, dist=0, time=0.514ms)

[liu4480]

Hi, Honza

I tried network filter(make the network to be isolated), it could work.

target prot opt in out source destination
ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0
REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable

Maybe adding network filter rules is simpler than modifying the rfc.

[jfriesse]

The main reason why omping exists is to DETECT potential multicast problems. It really shouldn't try to fix them, however it should contain detailed output documentation and can also suggest solution (= how to fix problem).

Also adding network filter rules is not as simple as it looks so. Keep in mind omping works on many systems and Linux is just one of them (as example I've tested OpenBSD@Sparc64, OpenIndiana@x86, Cygwin/NT@x86). Every OS has it's own way how to modify network filters so adding equivalent of three rules you suggested is actually trying to implement generic layer what is just super hard.