Serve ips to another gateway

[alpe12]

My router doesn't set the MTU right for the IPv6 clients, so I have to manually configure them to use MTU 1480. But that is not pratical. So I though about using radvd in my Odroid board to reannounce the prefix with the correct AdvLinkMTU option and with AdvDefaultPreference high so that it is preferred over the router announce. The clients receive the IP from this server just fine, but they use the Odroid as a gateway, not the router. Any way to make this work?

[reubenhwk]

Your router doesn’t set linkmtu right? Can you elaborate? What does it do, and what is it supposed to do? How are you working around it and why does the workaround work?

Sent from my iPhone

On Feb 12, 2018, at 9:22 AM, alpe12 notifications@github.com wrote:

My router doesn't set the MTU right for the IPv6 clients, so I have to manually configure them to use MTU 1480. But that is not pratical. So I though about using an server in my Odroid board to reannounce the prefix with the correct AdvLinkMTU option and with AdvDefaultPreference high so that it is preferred over the router announce. The clients receive the IP from this server just fine, but they use the Odroid as a gateway, not the router. Any way to make this work?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[alpe12]

The MTU on the wan is 1480 (PPPoE), the router doesn't advertise any mtu to the clients, so they use 1500 (I think). If I don't manually configure the clients (android, linux, windows, doesn't matter) to use MTU 1480 (a little less over wifi), most sites that use IPv6 don't open. Like Netflix, Pinterest, etc. They just keep trying to connect but never do. And they don't fallback to IPv4 either. Maybe the router doesn't send the "Packet Too Big" messages and the clients don't lower the MTU because of this, I don't know. But without mannualy setting the MTU on the client it doesn't work. My router is an TP-Link Archer C7 v4. I already posted on their forums about this weeks ago, but got no response.

The problem is in my router. I want to use radvd on my odroid (similar to raspberry pi) to advertise the same prefix as the router but with AdvLinkMTU set, as setting the mtu manually fix the issue.

[reubenhwk]

So your C7 is running radvd but not setting the link mtu and path mtu discovery is also not working through the C7? Is the WAN on the C7?

Sent from my iPhone

On Feb 12, 2018, at 9:42 AM, alpe12 notifications@github.com wrote:

The MTU on the wan is 1480, the router doesn't advertise any mtu to the clients, so they use 1500. If I don't manually configure the clients (android, linux, windows, doesn't matter) to use MTU 1480, most sites that use IPv6 don't open. Like Netflix, Pinterest, etc. They just keep trying to connect but never do. And they don't fallback to IPv4 either. Maybe the router doesn't send the "Packet Too Big" messages, I don't know. But without mannualy setting the MTU on the client it doesn't work. My router is an TP-Link Archer C7 v4. I already posted on their forums about this weeks ago, but got no response.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[alpe12]

Yes and yes. The router is with the stock firmware, so I can't freely tweak it. I'm going to install LEDE when a stable version is released to it. That's why I though about using a second radvd that is configured with AdvLinkMTU as a workaround.

Dump from the RA of the router:

# # radvd configuration generated by radvdump 2.11 # based on Router Advertisement from fe80::52c7:bfff:fef9:3c20 # received by interface eth0 #

interface eth0 { AdvSendAdvert on; # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump AdvManagedFlag off; AdvOtherConfigFlag on; AdvReachableTime 0; AdvRetransTimer 0; AdvCurHopLimit 64; AdvDefaultLifetime 1800; AdvHomeAgentFlag off; AdvDefaultPreference medium; AdvSourceLLAddress on;

    prefix 2804:214:3:1::/64
    {
            AdvValidLifetime 86400;
            AdvPreferredLifetime 14400;
            AdvOnLink on;
            AdvAutonomous on;
            AdvRouterAddr on;
    }; \# End of prefix definition

}; # End of interface definition

[reubenhwk]

Have you attempted to explicitly set the mtu on the c7? Looks like there’s a setting for it.

Sent from my iPhone

On Feb 12, 2018, at 2:57 PM, alpe12 notifications@github.com wrote:

Yes and yes. The router is with the stock firmware, so I can't freely tweak it. I'm going to install LEDE when a stable version is released to it. That's why I though about using a second radvd that is configured with AdvLinkMTU as a workaround.

Dump from the RA of the router:

#

radvd configuration generated by radvdump 2.11

based on Router Advertisement from fe80::52c7:bfff:fef9:3c20

received by interface eth0

#

interface eth0 { AdvSendAdvert on;

Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump

AdvManagedFlag off; AdvOtherConfigFlag on; AdvReachableTime 0; AdvRetransTimer 0; AdvCurHopLimit 64; AdvDefaultLifetime 1800; AdvHomeAgentFlag off; AdvDefaultPreference medium; AdvSourceLLAddress on;

prefix 2804:214:3:1::/64
{
        AdvValidLifetime 86400;
        AdvPreferredLifetime 14400;
        AdvOnLink on;
        AdvAutonomous on;
        AdvRouterAddr on;
}; \# End of prefix definition

}; # End of interface definition

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[alpe12]

The only place that we can set it is in the PPPoE connection. It's set to 1480 (maximum 1492). :/ I already tried 1492, but same thing. Already tried 1280 too.

[reubenhwk]

Do you know where/why PMTUD is failing?

Sent from my iPhone

On Feb 12, 2018, at 5:52 PM, alpe12 notifications@github.com wrote:

The only place that we can set it is in the PPPoE connection. It's set to 1480 (maximum 1492). :/ I already tried 1492, but same thing.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[alpe12]

No. :/

But good news. After almost 3 weeks, finally TP-Link answered the message and provided me with a beta firmware. This firmware fixed the issue. The router still doesn't advertise the MTU, but now the PMTUD works.

Thanks for answering my messages and for the patience. :+1:

Many thanks for your feedback. We have noticed your issue on our forum recently. The MSS will not be adjusted as it pass the our router, which will casue the wrong bytes of the packet. This week we have talked about this issue with our RD engineers.

[reubenhwk]

Wow! That's great. I've always like TP-Link products. Now I like their support too.

Nice work TP-Link!

On Tue, Feb 13, 2018 at 5:50 AM, alpe12 notifications@github.com wrote:

No. :/

But good news. After almost 3 weeks, finally TP-Link answered the message and provided me with a beta firmware. This firmware fixed the issue. The router still doesn't advertise the MTU, but now the PMTUD works.

Thanks for answering my messages and for the patience. 👍

Many thanks for your feedback. We have noticed your issue on our forum recently. The MSS will not be adjusted as it pass the our router, which will casue the wrong bytes of the packet. This week we have talked about this issue with our RD engineers.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/reubenhwk/radvd/issues/86#issuecomment-365271927, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMTe1pxG2GGxdcr_--UiuYNqyZpKsMFks5tUZMegaJpZM4SCiC3 .

[alpe12]

I think it's ok to close it now, since it's not needed anymore. Thanks again.