MoCA causes 50% ICMP loss icm HAPax2

RouterOS Beginner Basics
1

I have a HEX acting as router and a second HAPax2 as a access point. In between the line is a COAX cable that has Ethernet over Coax through MoCA. I am experiencing weird behavior where there is an unstable connection causing a +/- 50% ICMP packet loss. Client do get a DHCP lease and can connect to routeros but difficult. However, if i switch the HAPax2 with a regular dump switch, there is no packet loss and fast throughput (measured with iperf)!

The goal is to run the HAPax2 as access point.

Various setup and configurations i tried.
Preferred setup
Iperf server -> HEX -> MoCA adapter 1 ->COAX -> MoCA adapter 2 -> HAPax2 -> Client PC: Result: Iperf 20mbit/s and 50% ICMP packet loss
The HEX is acting as the main router with DHCP server. The HAPax2 is configured as a switch with DHCP disabled and a static IP on ether1. The client PC is running on ether2. Otherwise it is a basic configuration. The client PC receives the correct dhcp lease from the dhcp server and can connect to the webgui of routeros. There are no splitters on the COAX cable. Just a strait line from adapter 1 to adapter 2.

Hardware control setup:
Iperf server -> HEX -> MoCA adapter 1 ->COAX -> MoCA adapter 2 -> Client PC: Result: Iperf 350mbit/s and 0% ICMP packet loss
Removing the HAPax2 result in a direct dhcp lease from the dhcp server. The client pc is connected to cable with wifi disabled. Speed is fast and steady. This setup shows it is no faulty MoCA hardware.

Access point configuration control setup.
Iperf server -> HEX -> Powerline adapter 1 -> Powercable -> Powerline adapter 2 -> HAPax2 -> Client PC: result Iperf 70mbit/s and 0% icmp packet loss
Having a same configuration but with the setup with a Powerline will result in both the Client PC and the HAPax2 steady and happy. The performance of the Powerline is lacking behind that of the MoCA solution. This was my initial setup and worked, albeit slow connection. Again HEX is main router and HAPax2 configured as access point. This setup shows that the access point configuration works.

Hardware control setup 2
Resetting the HAPax2 to is default settings will give me a fast and steady connection albeit with NAT behind NAT.
Iperf server -> HEX -> MoCA adapter 1 ->COAX -> MoCA adapter 2 -> HAPax2 -> Client PC: Result: Ipef 350mbit/s and 0% ICMP packet loss
This setup is the default out of the box setup for RouterOS. So for the HAPax2 NAT is enabled, DHCP server is enabled on LAN with 192.168.88.0/24. On ether1 the HAPax2 get's a DHCP lease from the HEX. Everything works fine, but you get NAT behind NAT which is a situation i want to avoid. This setup shows that there is no hardware issues with the HAPax2.

The preliminary conclusion that i can draw is that i must be missing something in the configuration as a access point in combination with the MoCA adapters. I have read that COAX is half duplex. But how this translate into a configuration setting i do not know. I would assume that the interface / ethernet / Auto Negotiation enabled (default configuration) would handle this kind half duplex.

What might be causing the unstable connection to the HAPax2?
What might i be overlooking?
Thank you very much for you advice in advance.



Configuration of the HAPax2 with some information removed.

2024-01-04 17:17:20 by RouterOS 7.13

software id = D2TY-4DYI

model = C52iG-5HaxD2HaxD

/interface bridge
add admin-mac=48:A9:8A:D7:EB:C7 auto-mac=no comment=defconf name=bridge port-cost-mode=short
/interface wifi datapath
add bridge=bridge disabled=no name=capdp
/interface wifi

managed by CAPsMAN

/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=default-dhcp disabled=yes interface=bridge lease-time=10m name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=ether3 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=ether4 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=ether5 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=wifi1 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=wifi2 internal-path-cost=10 path-cost=10
add bridge=bridge interface=ether1 internal-path-cost=10 path-cost=10
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf disabled=yes interface=ether1 list=WAN
/interface wifi cap
set certificate=request discovery-interfaces=bridge enabled=yes slaves-datapath=capdp
/ip address
add address=192.168.1.4/24 comment=defconf interface=ether1 network=192.168.1.0
/ip dhcp-client
add comment=defconf disabled=yes interface=ether1

Ping results of the HEX -> MoCA -> HAP setup.
Pinging 192.168.1.15 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.1.15: bytes=32 time=4ms TTL=64
Request timed out.
Reply from 192.168.1.15: bytes=32 time=4ms TTL=64
Request timed out.
Reply from 192.168.1.15: bytes=32 time=4ms TTL=64
Request timed out.
Reply from 192.168.1.15: bytes=32 time=4ms TTL=64
Request timed out.
Reply from 192.168.1.15: bytes=32 time=4ms TTL=64
Request timed out.
Reply from 192.168.1.15: bytes=32 time=5ms TTL=64
Request timed out.
Reply from 192.168.1.15: bytes=32 time=4ms TTL=64
Request timed out.
Reply from 192.168.1.15: bytes=32 time=4ms TTL=64
Request timed out.
Reply from 192.168.1.15: bytes=32 time=4ms TTL=64

Ping statistics for 192.168.1.15:
Packets: Sent = 20, Received = 9, Lost = 11 (55% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 5ms, Average = 4ms

Iperf results of the HEX -> MoCA -> HAP setup.
Connecting to host 192.168.1.15, port 4444
[ 4] local 192.168.1.10 port 8213 connected to 192.168.1.15 port 4444
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 512 KBytes 4.16 Mbits/sec
[ 4] 1.01-2.00 sec 7.25 MBytes 61.2 Mbits/sec
[ 4] 2.00-3.01 sec 0.00 Bytes 0.00 bits/sec
[ 4] 3.01-4.00 sec 384 KBytes 3.18 Mbits/sec
[ 4] 4.00-5.01 sec 14.9 MBytes 124 Mbits/sec
[ 4] 5.01-6.01 sec 0.00 Bytes 0.00 bits/sec
[ 4] 6.01-7.00 sec 256 KBytes 2.12 Mbits/sec
[ 4] 7.00-8.01 sec 10.8 MBytes 89.8 Mbits/sec
[ 4] 8.01-9.01 sec 0.00 Bytes 0.00 bits/sec
iperf3: error - control socket has closed unexpectedly

2

I have the same issue over powerline

RB5009 eth2 → hapax2 → device = ok
RB5009 eth3 → powerline-in → powerline-out → hapax2 → = 20mbit. → lol

BUT
what iis interesting :
I made a Tools-> speedtest with udp →
RESULT : and on BOTH connection can ~1GB be send / received. ==> no problem

I never sehn tis in that way .

can u please do this test either ?
witch powerline u got ?


cheers

3

what was the solution ?
can u explain, pls ?

thx

4

If you perform iperf3 tests and see large discrepancy between results for TCP and UDP, look at UDP performance … specially dropped packets.

For that you should run UDP tests with bandwidth set slightly lower than what physical connection should sustain (if you expect whole link to allow e.g. 350Mbps, then run UDP tests at, say, 330Mbps). And it’s critical to observe results on receiving side. The gotcha with UDP tests is that UDP packets can be dropped at will by intermediate nodes (including switches) and IP/UDP stack will not react. So sending side will never know that there were dropped packets. TCP on the other hand will issue retransmits in such case and sending side will notice it (it can count retransmitted packets). The other consequence is that with IP/TCP transfer rates will drop a lot if packets are dropped. For one, Tx queue will stall if packets need to be retransmited, and secondly TCP window size (which affects throughput over links with non-zero round trip time) shrinks when retransmission occur (to make Tx queue stalls shorter).

In short: if one runs UDP tests and only looks at Tx side, one can get impression that every thing works wirespeed (UDP Tx buffer only gets throttled because local IP stack can not push into L2 queues/hardware at faster rate than hardware permits) … if there’s a bottleneck further down the link, packets get dropped (at wire speed :wink: ).

5

If using iperf3, it will indicate the amount of dropped packets.
E.g. having a 950Mb connection being reported yet 50% dropped packages, then you know that result is useless.

What does manual of MOCA adapter say as far as ethernet connection settings are concerned ?

Things to consider:

  • are there any indications in log file about changes on speed/settings/… for the concerned ether port when using that MOCA adapter ?
  • set speed on ether port connected to MOCA to manual speed, not auto (it may negotiate a wrong speed for that ether part of the connection from router to MOCA adapter, check on both ends)
  • Same with duplex/half duplex setting. Definitely check what manual says it should be. In case auto setting has got it wrong, set it manually.
  • MTU settings ? Also there, check if something is mentioned in manual of MOCA adapter.
6

It will if the total buffer between sender and receiver is less than a second or so … otherwise client will timeout waiting for server report. In addition, if one follows receiver stats, it’s possible to get feeling about link performance on reporting interval time resolution.

7

Sorry for the late reply

The solution was weird and I can’t explain why it worked.
On the HEX I switched the port from ethernet2 to ethernet3 with the same cable … and it worked.

If you have some ideas why it would work, I would love to hear.

@holvoetn: Thanks for your great response. I was looking in the same direction of what you proposed. In response to your tips.

The MOCA manual is quite slim. So i couldn’t get a lot of information out of that.

  • are there any indications in log file about changes on speed/settings → No unfortunately not.
  • set speed on ether port connected to MOCA to manual speed, not auto → Tried, but to no effect.
  • Same with duplex/half duplex setting. → Tried, but to no effect. I figured it might have been a solution but that wasn’t the solution.
  • MTU settings ? → Haven’t tried that. I will investigate
8

Hi koalabambu
I got an ZyXEL PLA5206. It works great, but it is facing to many obstacles to be stable. .

9

@mkx:
Thanks mkx. :smiley: I have learned something from your post. It made sense.