Peplink Balance 20 and U-verse "WAN Failed DNS test" problems

Product Discussion Peplink Balance
1

I’m using a Peplink Balance 20 (firmware 5.4.9 build 1732) for my home and home office network (so, 5-10 devices on the network). I’m using it to connect to MediaCom (Motorola surfboard cable modem - working fine) and ATT U-verse (2Wire 3801HGV - not working as well). I’ve done a fair amount of reading online about problems with ATT U-verse and the Peplink, but I haven’t been able to resolve my problems.

The reasons I think the ATT connection is giving me the problem are:

  1. It seems others have been having similar problems with ATT
  2. The Peplink logs (see below)

With Health Check turned on, the MediaCom connection will create “WAN failed DNS test” errors in the log file (and disconnect/reconnect) a few times per week:
Jun 22 16:26:18 WAN: MediaCom connected (173.21.xxx.xxx)
Jun 22 16:25:27 WAN: MediaCom disconnected (WAN failed DNS test)
Jun 19 19:15:58 WAN: MediaCom connected (173.21.xxx.xxx)
Jun 19 19:14:07 WAN: MediaCom disconnected (WAN failed DNS test)
Jun 16 01:16:08 WAN: MediaCom connected (173.21.xxx.xxx)
Jun 16 01:04:25 WAN: MediaCom disconnected (WAN failed DNS test)
Jun 11 10:41:21 System: Changes applied

For the log entries above, I had manually turned off the ATT connection from June 11 through June 23. A few times a week doesn’t bother me, so I’m not worried about the MediaCom connection.

However, the ATT U-verse connection will disconnect/reconnect every few minutes with the Health Check turned on:
Jun 25 13:22:19 WAN: U-verse connected (172.1.yyy.yyy)
Jun 25 13:22:13 [1223999.836000] MAC address conflict: Received an ARP packet claiming to be from our MAC address 10:56:CA:06:F1:31, but with an unknown IP (172.1.yyy.yyy)
Jun 25 13:22:13 [1223999.756000] MAC address conflict: Received an ARP packet claiming to be from our MAC address 10:56:CA:06:F1:31, but with an unknown IP (172.1.yyy.yyy)
Jun 25 13:22:03 [1223989.676000] MAC address conflict: Received an ARP packet claiming to be from our MAC address 10:56:CA:06:F1:31, but with an unknown IP (172.1.yyy.yyy)
Jun 25 13:21:43 [1223969.516000] MAC address conflict: Received an ARP packet claiming to be from our MAC address 10:56:CA:06:F1:31, but with an unknown IP (172.1.yyy.yyy)
Jun 25 13:21:22 WAN: U-verse disconnected (WAN failed DNS test)
Jun 25 13:21:22 [1223949.288000] MAC address conflict: Received an ARP packet claiming to be from our MAC address 10:56:CA:06:F1:31, but with an unknown IP (172.1.yyy.yyy)
Jun 25 13:18:56 [1223803.308000] MAC address conflict: Received an ARP packet claiming to be from our MAC address 10:56:CA:06:F1:31, but with an unknown IP (172.1.yyy.yyy)
Jun 25 13:18:16 [1223763.280000] MAC address conflict: Received an ARP packet claiming to be from our MAC address 10:56:CA:06:F1:31, but with an unknown IP (172.1.yyy.yyy)
Jun 25 13:18:13 WAN: U-verse connected (172.1.yyy.yyy)
Jun 25 13:18:12 [1223758.720000] MAC address conflict: Received an ARP packet claiming to be from our MAC address 10:56:CA:06:F1:31, but with an unknown IP (172.1.yyy.yyy)
Jun 25 13:18:02 WAN: U-verse disconnected (WAN failed DNS test)
Jun 25 13:14:55 [1223562.212000] MAC address conflict: Received an ARP packet claiming to be from our MAC address 10:56:CA:06:F1:31, but with an unknown IP (172.1.yyy.yyy)
Jun 25 13:14:15 [1223522.176000] MAC address conflict: Received an ARP packet claiming to be from our MAC address 10:56:CA:06:F1:31, but with an unknown IP (172.1.yyy.yyy)
Jun 25 13:14:12 WAN: U-verse connected (172.1.yyy.yyy)
Jun 25 13:14:11 [1223517.704000] MAC address conflict: Received an ARP packet claiming to be from our MAC address 10:56:CA:06:F1:31, but with an unknown IP (172.1.yyy.yyy)
Jun 25 13:13:41 WAN: U-verse disconnected (WAN failed DNS test)
Jun 25 13:13:40 [1223487.380000] MAC address conflict: Received an ARP packet claiming to be from our MAC address 10:56:CA:06:F1:31, but with an unknown IP (172.1.yyy.yyy)
Jun 25 13:09:45 [1223252.100000] MAC address conflict: Received an ARP packet claiming to be from our MAC address 10:56:CA:06:F1:31, but with an unknown IP (172.1.yyy.yyy)
Jun 25 13:09:09 System: Changes applied

For the u-verse WAN connection, I have filled in the DNS server 1 and DNS server 2 addresses manually under “DHCP Settings” with the DNS servers that my computer got when I connected it directly to the 2wire. The “Include Public DNS servers” option is selected under Health Check Settings. I’ve also tried filling in the Health Check DNS Servers with Google’s public DNS servers. Neither of these seemed to have much of an impact. I changed the “Timeout” setting to 10 seconds, and that seemed to reduce the frequency of the “WAN Failed DNS test” errors, but didn’t impact the “MAC address conflict” errors.

I would appreciate any help to try to resolve these errors, and any insight into what might be causing them. I’m reasonably savvy with IT issues, but I’m no network expert. I can’t seem to find anything on the “MAC address conflict” error.

Thanks in advance,
tom

2

Hi Tom,

Appreciate if you can open ticket here for us to check further.

3

If anyone else has any ideas, please feel free to respond. So far, I’ve been working with Peplink support for about 2 weeks, and no one has any ideas of how to solve this yet. They have returned the WAN1 (u-verse) settings back to the defaults, which will sometimes make our internet connection flaky (internet radio will just die when it happens to start a song on the u-verse connection which might croak in the middle of it).

Just in case someone else reads this, and needs some resources, here’s what I’ve found:

SomeJoe7777 in the ATT forums is a wealth of information about 2wire gateway that ATT uses for their u-verse service. In particular, he responded to this post “(https://forums.att.com/t5/Residential-Gateway/U-verse-for-BUSINESS-2Wire-3600HGV-bridge-mode-or-another-AT-amp/td-p/2707013)” and many, many follow up questions, about how to setup the 2wire routers in various ways with other routers downstream. One of the follow up posts even mentions Peplink routers.

In case you go down the road of using the “Cascaded Router” idea on a 2wire gateway, it’s probably worth it to read this post first: “3800HGV-B, Supplementary Network, Additonal Network, Cascaded Router”.

Here’s another post I found on dslreports.com: “uverse bridge mode” which had some relevant information.

I haven’t really found anything about the “MAC Address Conflict” error. I found a few (old) mentions online (2Wire 1000W…Updated firmware now having problems) that seem to indicate that other 2wire products use ARP packets to check what computers are behind the gateway and active. The 3801HGV is probably doing the same thing. My guess is that since the 2wire and the Peplink are sharing an IP address (due to the DMZ plus mode), the ARP packets are confusing the Peplink. I’m not really sure how concerned I should be about the “MAC Address Conflict” errors.

4
5

Sept 18, 2014 update:
For anyone looking into this, the final resolution is that the Peplink Balance won’t work correctly with 2Wire 3801HGV gateways. A call to ATT confirmed (after a fair about of hassle) that these are the only gateways that ATT uses for u-verse. So, while the Peplink Balance works, it doesn’t work particularly well. Lots of error messages and connecting/disconnecting. This would be true for any WAN connection that uses a 2Wire 3801HGV.

6

So far, I’ve been working with Peplink support for about 2 weeks, and no one has any ideas of how to solve this yet. They have returned the WAN1 (u-verse) settings back to the defaults, which will sometimes make our internet connection flaky (internet radio will just die when it happens to start a song on the u-verse connection which might croak in the middle of it).

7

I had the same problem with the ATT Arris NVG589. I had to specially request this modem because the original they gave me was blocking my IPSec VPN traffic to the Peplink. Their routers are a nightmare.
The modem was in IP Passthrough mode, but to clear the MAC address errors from the Peplink, I had to change ‘Passthrough Mode’ from ‘DHCPS-Dynamic’ to ‘DHCPS-Fixed’ and make sure the MAC address of the Peplink was in the MAC field.
Hopefully this helps anyone having the same problem.