Updated monitor.c to take care of host byte order

[mqasimsarfraz]

There was a network to host byte order issue, due to which tunnel monitor wasn't working for big endian machine. This patch fix this issue.

@4ast Other than that I am just curious,why ethernet->type works without the need to correct the byte ordering. Does NIC driver take care of it?

[drzaeus77]

Something still seems wrong about this to me, as in the patch should not be needed. Can you tell me what ip -d link show gives for the vxlan device inside the namespace?

The reason it should not be needed is that internally the kernel does a bswap if needed (false on big-endian) before giving the return value of load_half(). So in your case, if you need to force a bswap, that implies that the vxlan device is actually listening and transmitting on port 46354, which is why I ask for ip -d link show.

[mqasimsarfraz]

Below is the output:

root@qasim-dev:~# ip netns exec host0 ip -d link show vxlan1
6: vxlan1: <BROADCAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master br1 state UNKNOWN mode DEFAULT group default
link/ether fa:3b:3d:24:c8:a1 brd ff:ff:ff:ff:ff:ff promiscuity 1
vxlan id 10001 group 239.1.1.2 dev eth0 srcport 0 0 dstport 46354 ageing 300
bridge_slave state forwarding priority 32 cost 100 hairpin off guard off root_block off fastleave off learning on flood on addrgenmode eui64

root@qasim-dev:~# ip netns exec host0 ip -d link show vxlan2
10: vxlan2: <BROADCAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master br2 state UNKNOWN mode DEFAULT group default
link/ether ba:15:5c:23:bc:53 brd ff:ff:ff:ff:ff:ff promiscuity 1
vxlan id 10002 group 239.1.1.3 dev eth0 srcport 0 0 dstport 46354 ageing 300
bridge_slave state forwarding priority 32 cost 100 hairpin off guard off root_block off fastleave off learning on flood on addrgenmode eui64

[mqasimsarfraz]

Also, I see this vxlan port is configured to be 46354 at line 47 of main.py

vxlan_port=htons(4789),

[drzaeus77]

Can you then please track down what the right fix is on the python side?

[mqasimsarfraz]

@drzaeus77 I have updated the patch set. Please, see if the change looks good to you.

[zaafar]

@drzaeus77 Does it mean networking/distributed_bridge/tunnel.py:38 vxlan_port=htons(4789) is also incorrect? We shouldn't use hton* when creating a local vxlan interface.

[4ast]

the fix looks good to me. @drzaeus77 ping?

[drzaeus77]

The mystery of why this change is needed bothers me. Did pyroute2 change? Did the display of ip command change? It didn't used to be this way (according to my memory), but at some point something did change. The fix is probably fine, but maybe old versions will break. I guess it doesn't matter at this point.

[drzaeus77]

Also, to be consistent, probable these should change:

grep -r vxlan_port examples/networking/
examples/networking/tunnel_monitor/main.py:                                    vxlan_port=htons(4789),
examples/networking/distributed_bridge/tunnel.py:                     vxlan_link=ifc, vxlan_port=htons(4789),
examples/networking/distributed_bridge/tunnel_mesh.py:                         vxlan_link=ifc, vxlan_port=4789,
examples/networking/distributed_bridge/tunnel_mesh.py~:                         vxlan_link=ifc, vxlan_port=4789,