Wi-Fi calling

[drinkingbird]

After running 386.10 for five days, It looks like 386.10 still has the ICMP and intra client connectivity issues.

You mean it still has IPv6 bugs. I don't expect that to go away anytime soon.

 

[Frank Monroe]

You mean it still has IPv6 bugs. I don't expect that to go away anytime soon.

No. This issue isn't specific to IPv6. The issue causes problems for IPv4 as well. The issue will also cause you to lose your IPv6 configuration.

 

[Tech9]

The issue will also cause you to lose your IPv6 configuration.

If I remember correctly your configuration is double NAT with Passthrough. Are you sure your Asus router is causing the issue? Quite a few firmware releases since 386.3_2 and no one else using IPv6 have seen it? I start to believe it is caused by something else on your network.

 

[Frank Monroe]

If I remember correctly your configuration is double NAT with Passthrough. Are you sure your Asus router is causing the issue? Quite a few firmware releases since 386.3_2 and no one else using IPv6 have seen it? I start to believe it is caused by something else on your network.

Actually, there have been quite a few other people reporting this issue. All of them reverted back to 386.3_2 and the problem went away. The issue is not an IPv6 issue. The issue causes ARP and ICMP to fail. Since IPv6 relies on ICMP for RA's, it breaks IPv6. The other people reporting the issue are complaining after a few days the router stops communication between devices on the router. And when they troubleshoot, they cannot ping (IPv4) devices on the internal network. When you look at the ARP table (IPv4) it's empty. Rebooting the router fixes the issue for 3-4 days. Like I said, several people have reported the issue on IPv4 networks.

 

[Tech9]

What did RMerlin say? Fixable, closed source from the base?

Have you tried saving your Asuswrt-Merlin configuration and running Asuswrt temporary?

 

[Frank Monroe]

What did RMerlin say? Fixable, closed source from the base?

Have you tried saving your Asuswrt-Merlin configuration and running Asuswrt temporary?

I was going to do that. Since it takes 3-5 days for the problem to show up I would have to run a week without Merlin to be sure. I'm using features of Merlin that I can't be without for a week.

 

[Tech9]

I'm using features of Merlin that I can't be without for a week.

In this case you stuck with 386.3_2 because there is no way to tell if something in Asuswrt-Merlin is the issue (RMerlin can eventually look into and fix) or something in Asuswrt base (RMerlin can eventually relay upstream to Asus so they can look into and fix). Is it router model specific?

 

[Frank Monroe]

In this case you stuck with 386.3_2 because there is no way to tell if something in Asuswrt-Merlin is the issue (RMerlin can eventually look into and fix) or something in Asuswrt base (RMerlin can eventually relay upstream to Asus so they can look into and fix). Is it router model specific?

Understood about having to remain on 386.3_2. I've been on that version for a year and half due to this. I can stick with it until I replace the router at some point. I generally do test every version to see if it goes away. As far as model specific, mine is an AC5300. I can't remember the others. If I remember at least one other person with the issue was on a different model. I will have to look back at posts.

 

[Tech9]

Just curious - what Asuswrt-Merlin features you can't go without for a week? Running your own custom scripts?

 

[Frank Monroe]

Just curious - what Asuswrt-Merlin features you can't go without for a week? Running your own custom scripts?

Yes. I have startup scripts with custom routes and iptable rules that route specific traffic through a VPN (thats not on the Asus router). I also use VPN director and DNSFilter.

 

[drinkingbird]

Actually, there have been quite a few other people reporting this issue. All of them reverted back to 386.3_2 and the problem went away. The issue is not an IPv6 issue. The issue causes ARP and ICMP to fail. Since IPv6 relies on ICMP for RA's, it breaks IPv6. The other people reporting the issue are complaining after a few days the router stops communication between devices on the router. And when they troubleshoot, they cannot ping (IPv4) devices on the internal network. When you look at the ARP table (IPv4) it's empty. Rebooting the router fixes the issue for 3-4 days. Like I said, several people have reported the issue on IPv4 networks.

ICMP between IPv4 devices on your LAN does not pass through the router, nor do ARPs, at least not if they're in the same subnet. They communicate directly between each other via the switch at L2 only. The router may see the ARPs and know about them but it would not be blocking communications.

 

[Frank Monroe]

ICMP between IPv4 devices on your LAN does not pass through the router, nor do ARPs, at least not if they're in the same subnet. They communicate directly between each other via the switch at L2 only. The router may see the ARPs and know about them but it would not be blocking communications.

Great. The point is communication between devices on the same router stop after the router is up for a few days. In addition, certain announcements from the router also cease. This causes issues for both IPv4 and IPv6. For IPv6, clients completely lose their configuration. This is not new information. Its been discussed in detail several times for over a year in this forum.

 

[drinkingbird]

Great. The point is communication between devices on the same router stop after the router is up for a few days. In addition, certain announcements from the router also cease. This causes issues for both IPv4 and IPv6. For IPv6, clients completely lose their configuration. This is not new information. Its been discussed in this forum several times for over a year.

Yes IPv6 could certainly be impacted. If communication between two IPv4 clients on the same subnet is impacted (and it isn't due to them not being able to renew their DHCP and losing their IP) then the only possibility is the MAC table for the switch is either full or corrupted (which would mean no traffic will pass at all). I mean there are many possibilities but that's the only one the router would cause, otherwise it is client issues.

 

[Frank Monroe]

Yes IPv6 could certainly be impacted. If communication between two IPv4 clients on the same subnet is impacted (and it isn't due to them not being able to renew their DHCP and losing their IP) then the only possibility is the MAC table for the switch is either full or corrupted (which would mean no traffic will pass at all). I mean there are many possibilities but that's the only one the router would cause, otherwise it is client issues.

The problem isn't that all traffic doesn't flow. Traffic to the Internet is fine. However, traffic from device to device stops working. For example, one device cannot ping another. In addition, IPv5 RA's from the router stop reaching client. This is not a client issue.

 

[Frank Monroe]

The problem isn't that all traffic doesn't flow. Traffic to the Internet is fine. However, traffic from device to device stops working. For example, one device cannot ping another. In addition, IPv5 RA's from the router stop reaching client. This is not a client issue.

IPv4 internet traffic continues to work that is. Of course, IPv6 stops working as clients lose their IPv6 configuration.

 

[drinkingbird]

The problem isn't that all traffic doesn't flow. Traffic to the Internet is fine. However, traffic from device to device stops working. For example, one device cannot ping another. In addition, IPv5 RA's from the router stop reaching client. This is not a client issue.

If two IPv4 devices can't ping each other via a switch there is something unrelated to the router going on. The packets don't even hit the router, only the switch. Even when going from wireless to wired it won't create an ARP entry on the router if they're both in the main LAN. So unless the router is for some reason replying to ARPs with its own MAC and replacing the one from the client (ARP poisoning), can't see what it would be doing. But you'd need to capture some stuff when it happens to see what is going on.

When you are attempting this client to client traffic are you sure it is using v4 and not v6? It will default to v6 if enabled. If RAs are failing and there is no DHCPv6 I can see the clients losing their v6 config, but that should have no impact on v4.

I've been on 386.7_2 for many months and never any issue like that (and several other iterations of after 386.3 before that).

 

[Frank Monroe]

If two IPv4 devices can't ping each other via a switch there is something unrelated to the router going on. The packets don't even hit the router, only the switch. Even when going from wireless to wired it won't create an ARP entry on the router if they're both in the main LAN. So unless the router is for some reason replying to ARPs with its own MAC and replacing the one from the client (ARP poisoning), can't see what it would be doing. But you'd need to capture some stuff when it happens to see what is going on.

When you are attempting this client to client traffic are you sure it is using v4 and not v6? It will default to v6 if enabled. If RAs are failing and there is no DHCPv6 I can see the clients losing their v6 config, but that should have no impact on v4.

I've been on 386.7_2 for many months and never any issue like that (and several other iterations of after 386.3 before that).

It's 100% the router issue. I others can reproduce the issue at will. All you have to do is install any version of Merlin past release 386.3_2. I have tested each and every release since then and they all have the issue.

Also, yes, the packets don't hit the router. And I'm not talking about the ARP table on the router. I'm talking about the ARP table on any client. The ARP requests are not passing through the switch for whatever reason. Because of this, when you try to. communicate with another client, you cannot resolve the MAC address for the client due to the lack of ARP. And this eventually ends up with empty ARP tables on all the clients. However, IPv4 communication to the internet still works.

Yes. Client to client traffic is using IPv4.

 

[drinkingbird]

It's 100% the router issue. I others can reproduce the issue at will. All you have to do is install any version of Merlin past release 386.3_2. I have tested each and every release since then and they all have the issue.

Also, yes, the packets don't hit the router. And I'm not talking about the ARP table on the router. I'm talking about the ARP table on any client. The ARP requests are not passing through the switch for whatever reason. Because of this, when you try to. communicate with another client, you cannot resolve the MAC address for the client due to the lack of ARP. And this eventually ends up with empty ARP tables on all the clients. However, IPv4 communication to the internet still works.

Yes. Client to client traffic is using IPv4.

If ARP stopped working through the switch you wouldn't be able to get to the internet, as you have to ARP for the gateway and that passes through the switch. Why it is happening with certain firmwares and not others, don't know, would need to try and capture debug data when it happens. But it seems to be limited to a certain config or hardware/firmware combo as it isn't a problem for the majority here.

I can't think of any reason a switch wouldn't pass an ARP packet, other than the frame being malformed/too small or the switch's MAC table being full.

Not denying you're having an issue, just giving insight to help narrow it down. If a switch can't manage to forward frames on a small home network, there is something desperately wrong with it. Something along the lines of a spanning tree loop, broadcast storm, or MAC table corruption.

 

[Frank Monroe]

If ARP stopped working through the switch you wouldn't be able to get to the internet, as you have to ARP for the gateway and that passes through the switch. Why it is happening with certain firmwares and not others, don't know, would need to try and capture debug data when it happens. But it seems to be limited to a certain config or hardware/firmware combo as it isn't a problem for the majority here.

I can't think of any reason a switch wouldn't pass an ARP packet, other than the frame being malformed/too small or the switch's MAC table being full.

Not denying you're having an issue, just giving insight to help narrow it down. If a switch can't manage to forward frames on a small home network, there is something desperately wrong with it. Something along the lines of a spanning tree loop, broadcast storm, or MAC table corruption.

The ARP entry for the router is still there.

 

[Frank Monroe]

Other times this has been reported.

arp problem between wifi devices on RT-AC88u

Hello, Sorry if this subject has already been discussed but I did not find an answer to my question, I have an RT-AC88U, and I have big problems of communication between wifi devices. It seems that it is a problem of propagation of ARP request between wifi equipments via the AC88U. Indeed, the...

www.snbforums.com

RT-AC3100 - Intermittently can't ping devices on the Network

I have a RT-AC3100. It's a replacement system that Asus sent me after my 2900 failed while under warranty. I'm running 3.0.0.4.386_43129 code. I've been using the router about 4 weeks. The issue I'm having is, I intermittently cannot ping between certain devices on the network. No device ever...

www.snbforums.com

AC5300 WLAN to WLAN connectivity issues

Recently setup an RT-AC5300. It was new in box, but had been sitting on a shelf for about a year. I flashed firmware to the latest Merlin version, RT-AC5300_386.7_2 and setup router. Initially everything seemed fine, but after a while I noticed that wireless devices were intermittently having...

www.snbforums.com