Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serve ips to another gateway #86

Closed
alpe12 opened this issue Feb 12, 2018 · 10 comments
Closed

Serve ips to another gateway #86

alpe12 opened this issue Feb 12, 2018 · 10 comments

Comments

@alpe12
Copy link

alpe12 commented Feb 12, 2018

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
Copy link
Collaborator

reubenhwk commented Feb 12, 2018 via email

@alpe12
Copy link
Author

alpe12 commented Feb 12, 2018

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
Copy link
Collaborator

reubenhwk commented Feb 12, 2018 via email

@alpe12
Copy link
Author

alpe12 commented Feb 12, 2018

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
Copy link
Collaborator

reubenhwk commented Feb 13, 2018 via email

@alpe12
Copy link
Author

alpe12 commented Feb 13, 2018

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
Copy link
Collaborator

reubenhwk commented Feb 13, 2018 via email

@alpe12
Copy link
Author

alpe12 commented Feb 13, 2018

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.

@reubenhwk
Copy link
Collaborator

reubenhwk commented Feb 13, 2018 via email

@alpe12
Copy link
Author

alpe12 commented Feb 13, 2018

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

@alpe12 alpe12 closed this as completed Feb 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants