Tomato ignores IPv6 Router Advertisements

Discussion in 'Tomato Firmware' started by Marcin R., Jan 8, 2017.

  1. Marcin R.

    Marcin R. Connected Client Member

    Hi All,

    I'm using the latest Tomato build for my ASUS RT-AC3200 (1.28.0000 -138 K26ARM USB AIO-64K)

    My ISP is Comcast Business with dynamic IP - the same as residental.

    I've configured my router to use DHCPv6 with 64 bit prefix delegation. This mostly works - the router gets a /128 IP address on the wan, then it is delegated a /64 prefix for the internal network, all this works well. However, the router is missing the IPv6 default route. I've enabled "Accept RA from WAN". This version of Tomato doesn't have the spurious ipv6 default route bug, I simply don't have an ipv6 default route at all!

    So, what I did was tcpdump all the IPv6 packets on the WAN interface, and the RA's are definitely there. So, I manually added a default route like this:
    route add -A inet6 default gw fe80::201:5cff:fe62:5446 vlan2, based on what I saw in the captured RA's and IPV6 works great for a while, until the router address changes.

    Any tips on how to make Tomato automatically accept those RA's and configure the default gw?
     
  2. Sean B.

    Sean B. LI Guru Member

    Interesting. I'm wondering if there's something different regarding the Business class. I use Comcast residential and it's working as it should, although it will fail to obtain the routes if "Request PD only" is used. Have you confirmed the 64 prefix is correct for business class? Also, are you using the provided Comcast gateway/modem combination or are you using your own modem?
     
  3. Marcin R.

    Marcin R. Connected Client Member

    No, it turns out that it's a kernel bug that was fixed in 2.6.37, but this tomato build is off 2.6.36.

    Here's a link to another forum post about this.

    I'm using my own Arris modem, not their business gateway (which does some strange stuff over RIP and static IPv6). The IP addresses are correct. This is misbehavior purely on Tomato's side.

    I previously had the static IPv6 from Comcast with their modem, and there's no automatic way to get that working. They assign you a /56, so you just pick a /64 from out of there and manually configure Tomato with some hard coded addresses. I had to do it via WAN up scripts since there's no way to set the default gw via UI, and with the business gateway modem, that never changed.
     
  4. Sean B.

    Sean B. LI Guru Member

    Hmm, IMHO I don't think this is a kernel issue. If it was, this would be a much more wide spread and prevalent issue.. not a " sometimes works sometimes doesn't " issue as that post states. The direct cause, once again IMHO, is likely a configuration miss-match in either the Tomato IPv6 settings/Cable modem/or ISP dhcpv6 server. I see that Comcast business issues a /56 and expects their supplied gateway/modem to delegate /64's for internal subnetting. If this is the case, you'd be missing a route if your configured for a 64 prefix. Or if using a gateway/modem combo and not in bridge mode, sense ( if properly configured ) your supplied comcast gateway needs to pass through to your tomato router and not try to handle routing itself.. otherwise it will conflict. If you're set that it's a kernel issue, all good. If you'd be interested in a bit of a debugging process to be sure this isn't something we can get working I'd be happy to run through it with you. Up to you :)
     
  5. Marcin R.

    Marcin R. Connected Client Member

    Comcast only uses a /56 is you have static IP addresses, which I do not. The dynamic IP based business class is identical to consumer (I will be switching soon). The router delegates a specific /64 and send an RA advertising itself. Tomato was ignoring it. I don't think it's a modem incompatibility - the modem dutifully forwards evertything as tcpdump showed. The link above suggested disabling forwarding on the interface where you want RA's so that the kernel doesn't drop them, and that indeed fixed it for me. This is a kernel behavior which the UI needs to consider when generating its config scripts. The Tomato config behavior is correct for 2.6.37+. I only have one router, so maybe other routers run a later kernel version and don't have this issue.
     
  6. Sean B.

    Sean B. LI Guru Member

    I'd suggest configuring the Basic->IPv6 section with a prefix length of 56, and then delegating a 64 to your LAN interface in dnsmasq custom section. I have a feeling this may solve the routing issue. Worth a shot.
     
  7. Sean B.

    Sean B. LI Guru Member

    Ah I see, not familiar with Business class. All tomato firmware runs either 2.4.34 (MIPS) or 2.6.36 (ARM). The broadcom drivers are tied to these versions and it cannot be changed.
     
  8. koitsu

    koitsu Network Guru Member

    @Marcin R. So, um, did you try the workaround (disabling IPv6 packet forwarding for the WAN interface) in the thread you posted? I'll provide actual links to remove confusion:

    http://www.linksysinfo.org/index.ph...eway-not-accepted-assigned.71239/#post-260879

    This supposedly worked for some people:

    http://www.linksysinfo.org/index.ph...eway-not-accepted-assigned.71239/#post-260945
    http://www.linksysinfo.org/index.ph...eway-not-accepted-assigned.71239/#post-264012

    But not others:

    http://www.linksysinfo.org/index.ph...eway-not-accepted-assigned.71239/#post-260880
    http://www.linksysinfo.org/index.ph...eway-not-accepted-assigned.71239/#post-263823

    And one is undetermined:

    http://www.linksysinfo.org/index.ph...eway-not-accepted-assigned.71239/#post-264025

    Also, when someone online tells me something like "it's a kernel bug which was fixed in 2.6.37 or newer", I always ignore it/reject it unless actual commits that confirm/reference the problem itself are provided. It's not that I don't "believe" (the poster of that thread or you) someone, it's that "blame the kernel" is something I've heard throughout the decades more times than I can count and is often used as a defunct go-to when someone can't explain something (think magic smoke). Can you find the correlating Linux kernel commits that fix it? I haven't been able to (here's another reference). Because such things can be backported to 2.6.36. We cannot upgrade/change the kernel version due to reliance on binary blob wireless drivers from Broadcom.
     
  9. Marcin R.

    Marcin R. Connected Client Member

    Yes, this works for me, that's why I responded when I found that thread, since I wasn't aware of it before posting originally.

    I was just repeating what that first thread says, don't have time to dig into this myself, I accepted this is a behavior with changed w.r.t. forwarding interfaces in 2.6.37, don't have time to vet everything myself. Check out OpenWRT issue 12882, it has more context, but it does appear that accept_ra = 2 doesn't work before kernel 2.6.37, but that setting is used in the 2.6.36 on my router - though I have no idea if it's been backported. It clearly works for some people.

    What I know is that in my case:
    - WAN RA's were ignored with accept_ra = 2 for vlan2
    - The Arris modem forwarded these to my WAN port, because tcpdump on the router showed them
    - Setting forwarding= 0 fixed the problem, and it explains why I was able to manually make a default route which fixed everything.

    It really does sound like that behavior change. Is there a list somewhere of which kernel patches have been ported back into Tomato's source, or do I have to dig through git?
     
  10. koitsu

    koitsu Network Guru Member

    WARNING WARNING WARNING: LONG POST BECAUSE I HAVE BEEN ESSENTIALLY ASKED TO DIG THROUGH TOAMTO SOURCE CODE ONCE AGAIN. ;-)

    OpenWRT ticket 12882 talks about how as of Linux 2.6.37, a new value to the accept_ra tunable was added: 2. Prior to that, only values 0 and 1 were accepted. I have talked about this tunable recently (within the past 3-4 months). With IPv6, it has to do with SLAAC.

    There is a good reference for this matter: http://strugglers.net/~andy/blog/2011/09/04/linux-ipv6-router-advertisements-and-forwarding/ (I hate the way this information is presented, but it's there -- note, we do not have sysctl on Tomato)

    As for Tomato code: you'll have to dig through git, I'm sorry to say -- and it's very painful because of all the forks and integration/sharing of commits (many things have to be manually backported/migrated) between forks.

    There are a couple places which tweak/touch accept_ra. I'm more familiar with MIPS (2.6.22) than I am ARM, but I'll provide the following as a quick point of reference. God, the more I look at this the more text I have to write out. There is no documentation for Tomato, so reverse-engineering must be done every time.

    I am referring below to the Toastman-ARM branch -- I do not look at Shibby branches.

    NVRAM variable ipv6_accept_ra is the tunable (an integer) that controls accept_ra behaviour for the WAN interface and the LAN interface (yes, in one variable). Bit 0 controls the capability for the WAN interface, and bit 1 controls the capability for the LAN interface. You can see how the code in router/www/basic-ipv6.asp ends up OR'ing the relevant bit/value (per interface), that's how the checkbox works in this case.

    I'm using the word "capability" because this variable does not contain the actual value stuffed into the /proc/sys/net/ipv6/conf/XXX/accept_ra tunable.

    The default value for this NVRAM variable is 1 (per router/shared/defaults.c).

    There is a function called accept_ra() (router/rc/network.c) which accepts an interface name (ex. vlan2, br0, etc.) and then tweaks the appropriate /proc variables for that interface name like so:

    Code:
     753 void accept_ra(const char *ifname)
     754 {
     755         char s[256];
     756
     757         sprintf(s, "/proc/sys/net/ipv6/conf/%s/accept_ra", ifname);
     758         f_write_string(s, "2", 0, 0);
     759
     760         sprintf(s, "/proc/sys/net/ipv6/conf/%s/forwarding", ifname);
     761         f_write_string(s, "2", 0, 0);
     762 }
    
    From this we can see that /proc/sys/net/ipv6/conf/XXX/accept_ra gets set to 2, and /proc/sys/net/ipv6/conf/XXX/forwarding also gets set to 2 whenever this function is called.

    But wait, didn't we just determine that Linux 2.6.37 is when the value of 2 got introduced/supported, yet ARM is running 2.6.36 (technically 2.6.36.4 I think)? Yeah, now you're getting the picture. Tomato is not a normal Linux distro, it's a very kludgy hodgepodge hacked-up mix of things because we can't change the kernel version due to binary blob drivers.

    So, this may be one of those things that didn't get backported into Tomato -- or maybe it did. I simply don't know. The only way to know for certain is to actually dig through all the code and see if the accept_ra value of 2 is truly supported or not in the Linux kernel (digging through the Tomato Makefile infrastructure may also be required, as for all I know it might be a patch that gets applied at make-time, but I doubt it).

    Anyway, onward:

    accept_ra() is called in a couple different places.

    router/rc/wan.c has a start_wan6_done() function which is passed the WAN interface name. I haven't looked what calls this function. It has the following code in it:

    Code:
     860         if (service != IPV6_DISABLED) {
     861                 if ((nvram_get_int("ipv6_accept_ra") & 1) != 0)
     862                         accept_ra(wan_ifname);
     863         }
    
    In other words: if bit 0 is set to 1 (i.e. accept RAs on WAN in the GUI is enabled), then (let's just assume vlan2 is the WAN interface) you'll end up with /proc/sys/net/ipv6/conf/vlan2/accept_ra=2 and /proc/sys/net/ipv6/conf/vlan2/forwarding=2.

    router/rc/services.c is another place, function start_ipv6(), which does the following:

    Code:
     886         if (service != IPV6_DISABLED) {
     887                 if ((nvram_get_int("ipv6_accept_ra") & 2) != 0 && !nvram_get_int("ipv6_radvd"))
     888                         accept_ra(nvram_safe_get("lan_ifname"));
     889         }
    
    In other words: if bit 1 is set to 1 (i.e. accept RAs on LAN in the GUI is enabled), and ipv6_radvd == 0, then (let's just assume br0 is the LAN interface) /proc/sys/net/ipv6/conf/br0/accept_ra=2 and /proc/sys/net/ipv6/conf/br0/forwarding=2.

    This situation becomes more complicated when we get into discussing the forwarding tunable, and here's why:

    router/rc/firewall.c has the following code in it, where if IPv6 is enabled (per ipv6_service in NVRAM -- meaning if it's set to something, vs. being empty) then forwarding=1 else forwarding=0 (but keep reading):

    Code:
     147 void enable_ip6_forward(void)
     148 {
     149         if (ipv6_enabled()) {
     150                 f_write_string("/proc/sys/net/ipv6/conf/default/forwarding", "1", 0, 0);
     151                 f_write_string("/proc/sys/net/ipv6/conf/all/forwarding", "1", 0, 0);
     152         }
     153         else {
     154                 f_write_string("/proc/sys/net/ipv6/conf/default/forwarding", "0", 0, 0);
     155                 f_write_string("/proc/sys/net/ipv6/conf/all/forwarding", "0", 0, 0);
     156         }
     157 }
    
    The "default" and "all" fake interfaces in Linux appear obvious at first, but in actuality they aren't. In fact, they're way more convoluted than their names allude to -- read the question and the top-voted answer (which talks about IPv4, but I want to assume it's the same for IPv6): http://unix.stackexchange.com/quest...6-conf-whats-the-difference-between-all-defau

    So the reason I mention all this is because for a "proper fix" to be applied, one is going to have to REALLY sift through all the code and figure out what is calling what and when/where. You have to get familiar with the services bits too, because when clicking Save in some parts of the GUI, Tomato could end up running a function like the above that might stomp or override a forwarding=0 workaround.

    My opinion is that if the forwarding=0 workaround is actually working, then someone needs to figure out when and where Linux actually fixed the real problem, so that preferably none of the Tomato code (not the kernel, but Tomato) has to be changed.
     
    Monk E. Boy likes this.
  11. Marcin R.

    Marcin R. Connected Client Member

    Damn, thanks for digging into that stuff. It's a mess indeed, and I didn't realize that the devs had to jump through so many hoops to stay compatible with closed binary drivers.
     
  12. koitsu

    koitsu Network Guru Member

    And now you understand one of the many reasons why OpenWRT doesn't support binary blob drivers. :)
     
  13. Sean B.

    Sean B. LI Guru Member

    Perhaps I've looked right over it, but I'm not clear on what is the cause of the issue for the OP when the IPv6 tuneables in their stock form are working for myself and many others on Comcast residential? Is this an actual Tomato issue, or a mis-match configuration between something different about Comcast Business?
     
  14. Sean B.

    Sean B. LI Guru Member

    It seems rather similar to what happens if you "Request PD only" on a Comcast connection. Your LAN interface will receive a /64 delegated prefix.. and dnsmasq will hand out IP's to clients properly.. but there will be no internet connectivity do to the missing route. Of which is a route that would have been through the NA-PD /128 given to the WAN interface had PD Only not been used. Not saying PD Only is the cause of this issue, but really seems like a basic configuration issue.
     
  15. koitsu

    koitsu Network Guru Member

    Wow, Sean... this may be a first (LOL), but I think your last post flew right over my head. Welcome to my inexperience with IPv6 (I "get it" but it's horribly overcomplicated, and why I have books :p). :D

    As for why the OP's situation might be different: I wouldn't be surprised if there was slight differences between the services. We know for a FACT there are differences in IPv6 behaviour between ISPs, so it wouldn't surprise me if there were slight anomalies between service classifications within a single ISP.
     
    M_ars likes this.
  16. Sean B.

    Sean B. LI Guru Member

    Lol you just made me need to verify gravity hasn't reversed and the sky isn't falling ;)
     
    M_ars likes this.
  17. Sinopsys

    Sinopsys Reformed Router Member

    Hello,

    I was very exited to find that thread as I am struggling to make IPv6 working on my Tomato box with the exact same situation but the forwarding trick isn't working.

    My config:
    - box: Netgear R8000 (ARM)
    - firmware: fresh tomato 2018.4 (based on kernel 2.6.36.4)
    - ISP: NETVIGATOR (HK) with IPv6 native and DHCPv6-PD support
    - Connection type: FTTH through a huawei modem/router with no open doors

    My setup:
    - IPv6 activated with DHCPv6-PD
    - prefix lenght: 56 (seems to be the requirement as per some local forums)
    - Request PD Only set: no DHCPv6 prefix provided otherwise
    - Static DNS: blank
    - Accept RA from WAN:set LAN:unset
    - Announce IPv6 on LAN (SLAAC): set
    - Announce IPv6 on LAN (DHCP): set

    I have no special tweaks applied as seen in forums (forwarding, accept_ra) as it looks like this firmware has already integrated these changes with some patches in linux core sources.

    So here is what is happening:
    - DHCPv6 negociation is successfull thanks to dhcp6c:
    /56 prefix is provided
    DNS are provided and updated
    br0 (LAN) is assigned a /64 address that is advertised and validated
    Here is the "cleaned" log of dhcp6c:
    thanks to that I have addresses set on interfaces
    So far so good.

    Now the routing table isn't updated with default route through provided gateway fe80::200:5eff:fe00:102
    So this is almost normal out of DHCPv6 part.

    Nevertheless, I do have a ICMPv6 RA sent by the gateway on vlan2:
    But this RA is not triggering the ND processing as it should.

    To try to figure out what is happening on this RA, I've set a logging ACCEPT rule in ip6tables specifically for this type of icmp (134) message: no trace of it in syslog !?

    looks like it is trashed/droped/?? before.

    edit: ip6tables do log it !

    I would really appreciate your wise advises and I am keeping investigating...

    again the accept_ra/forwarding stuff seems to be managed natively with the famous accept_ra = 2 to workaround dependency on forwarding state.
     
    Last edited: Nov 7, 2018
  18. Sean B.

    Sean B. LI Guru Member

    Has the huawei modem/router been set to transparent bridge mode? I just skimmed through your post as I'm headed to bed, but initial impression is that the modem/router hasn't been set to transparently bridge your connection and is therfor receiving the IPv6 address meant for your WAN interface ( VLAN2 ) when PD-only is not selected. If modem/router is not configured as stated, I suggest doing so and then attempt connection using DHCPv6 w/ prefix delegation and do not select PD-only.
     
  19. Sinopsys

    Sinopsys Reformed Router Member

    Hi,

    Thank you for answering on wake up :)

    I have no hands on the Huawei device despite having it in my flat as the fiber end-point.

    I’ve tried to contact my ISP to get further info on the setup but they told me that they cannot provide me support as my personal router is not among their ipv6 compliant certified devices.

    I will try to investigate myself on it but from my previous attempt it looks pretty much black box.

    I’ll also review more in details that final RA that looks to be what is supposed to finalise the linkage from what I
    understand ! Any confusion ?
     
  20. Sinopsys

    Sinopsys Reformed Router Member

    Early research is that the bridge is Huawei hg8040h which is said on paper to support “Transparent transmission of IPv6 packets at Layer 2”

    Going to have a look on any config capabilities...
     
  21. Sean B.

    Sean B. LI Guru Member

    Here is a section from an IETF document entitled "Route Problem at Relay during DHCPv6 Prefix Delegation " :

    I believe that without transparent bridge mode enabled on the modem/router.. the issue is the same.
     
  22. Sinopsys

    Sinopsys Reformed Router Member

    Hello again,

    Thank you for the great reference.

    well difficult to tell as again I have no way to get into that huawei GPON/ONT/...

    But from what I can read is that it is a fully capable router with DHCP server, DHCPv6, SLAAC...

    Then I'm a bit confused on what mode it is configured actually.

    But apparently the Huawei device apply as the Delegating router.

    I'll try again with PD-Only unset and see what I get tonight and keep you posted...

    But it is very frustrating to see that if I manually set the default gateway in the routing table, I'm all set and have full ipv6 live and running :(
     
  23. Sean B.

    Sean B. LI Guru Member

    When you have time, give this a try and see if there's any change for IPv6 connectivity.

    In the routers web interface under Advanced->DHCP/DNS:
    • Disable ( uncheck ) the option "Announce IPv6 on LAN" for both SLAAC and DHCPv6.
    • Place the following lines in the Custom Config box -
    Code:
    enable-ra
    dhcp-range=tag:br0,::100,::150,constructor:br0,off-link,64,1440m
    • Click save.
    • Under Status->Logs click the "View last 100 lines" link. Make sure there aren't repeating error lines from dnsmasq at the tail end of the log ( I'm not sure on exactly what version of dnsmasq the off-link directive was added, and therefor am not sure if it's supported by the version running under your build of Tomato ). If repeating error logs from dnsmasq are present, revert the changes made above. If no repeating error logs from dnsmasq are found, reboot the router.
    • While the router is rebooting, reboot all LAN clients as well.
    • Once the router and clients are back up, check for any change in IPv6 connectivity for LAN clients.
     
    Last edited: Nov 8, 2018
  24. Sinopsys

    Sinopsys Reformed Router Member

    Feedback on the test with PD-only not set: it is not improving the situation. Delegating router is answering the DHCPv6 process the same way as with PD-only so I do get /56 prefix, DNS, a local address for WAN and a local+global address is assigned to LAN.
    But for the IA part, Delegating router is rejecting with an error:
    Then dhcp6c run in endless loop re-sending SOLICIT for IA that is not answered by the delegating router.

    :( So PD-Only seems the better option to accommodate my ISP setup !?

    If I sum'up my understanding: my router is performing the DHCPv6 protocol pretty much correctly for the WAN part to get the prefix and then taking the delegation to create an address for the LAN and advertising it to make it global while The WAN do not get its own global address. but nothing else is expected from there actually is it ?

    From the various reading I got, the default route isn't supposed to be set in this process !? It's not exactly the problem described in the ietf as communication between WAN and delegating router is working !?

    The missing bit is the "default" route between WAN and Gateway that is more a matter of Neighbor Discovery !?

    I do the second test right away to check...
     
  25. Sinopsys

    Sinopsys Reformed Router Member

    ... done

    well I'm not sure what this is supposed to bring this second change ?

    Looks like the current dnsmasq (version 2.80test6) is supporting the off-link directive.

    With PD-Only set (which seems to be no different from unset) and customized dnsmasq I have IPv6 LAN working properly in local network: I can ping my router or any other device in the network. While connectivity with WAN remains broken:
    This is not different from the previous situation, route table is unchanged:
    I would be curious to have ND driver with debug logs to investigate this area and to understand why LAN do not discover properly route to WAN !? known ways to do it or that needs dedicated build ?
     
  26. Sean B.

    Sean B. LI Guru Member

    This failure is almost certainly due to the modem/router. While some service providers do use just "pd-only", it's mainly for commercial/enterprise customers that are expected to be configuring large internal infrastructure and handling their own routing anyway. With IPv6, a client/host/router interface that receives a prefix delegation must be on-link with the delegating router in order to auto set the default route. The reason for this is technical and long to explain, google if interested. Here'e the catch, your routers WAN interface counts as a hop between your LAN and the delegating router. Therefor your LAN is not on-link with that router.. hense no route. That is where the IA comes in. PD only is only the prefix, when an IA is requested as well it gives your WAN interface a /128 IPv6 IP and then the prefix passes through it to the LAN. Now your WAN interface becomes the "delegating router" and is on-link with your LAN.. and route is made. The modem/router is almost certainly causing the IA to fail.
     
  27. Sinopsys

    Sinopsys Reformed Router Member

    Well if that so, I'm screwed as I cannot change the router/modem and ISP isn't willing to help.
    Then I don't understand how standard routers (netgear, asus, linksys with stock firmware) can connect in IPv6 on their network ????

    I will try to get further info on the modem with ISP...
     
  28. Sean B.

    Sean B. LI Guru Member

    The same type of thing happens with an IPv4 modem/router. If it's not put into bridge mode your routers WAN interface gets an internal IP such as 192.168.100.X or 10.1.10.X . Speaking of which, what IPv4 IP address is your router getting from that modem/router? Is it your actual global IP, or an internal?
     
  29. Sinopsys

    Sinopsys Reformed Router Member

    On IPv4 i do have a public ip: 112.120.151.113

    I had a « technical expert » from ISP, feedback is;
    - modem is set as pure transparent bridge
    - their IPv6 is setup fully standard with no specifics (if that means anything)
    - it is working with most personal routers in « autoconfig » mode
    - they cannot provide further support as none of their customers ask for such technical elements (prefix length, Pf-only or not...) and I am using an exotic setup (device out of their short list + custom firmware)

    I’ll have to dig further in theoretical to then dig and explore more in details what is happening.

    Thank you anyway for your explanations and I am very open to any other advices for investigating.
     
  30. Sean B.

    Sean B. LI Guru Member

    Under Basic->IPv6, did you set the prefix length to 64 or 56? If 56, then try setting it to 64 and do not enable PD-only. Most provider systems will assign a requested prefix size as long as it's bigger ( smaller network size ) than what it would provide by default. If their system does allow for it and assigns a 64, I'm curious to see if it affects the issue at all.
     
    Last edited: Nov 9, 2018
  31. Sinopsys

    Sinopsys Reformed Router Member

    I tried both already w and w/o PD-Only.

    I will retry with full reboot of modem & router...
     
  32. Sinopsys

    Sinopsys Reformed Router Member

    No change :(

    Actually this is what is confusing me: in IPv4, I have:
    - WAN (vlan2): assigned with public IP address allocated by ISP dhcp (42.2.33.XX)
    - LAN (br0): set with internal IP address I choose (192.168.1.1)
    - a default route to tell that all other addresses out of LAN should go to WAN
    So I wonder why in IPv6 it is different;
    - WAN remains with local link only as I would have expected that it get global link (public) through ND/SLAAC at first
    - LAN would have been set first with local link getting global link once PD is done

    LAN is currently reachable from outside.

    I wanted to try an old tweak forcing forwarding to 0 on WAN: surprisingly it is automatically reset to 1 :(

    I’ll try to build my R8000 package with NDP trace enabled to understand what is happening inside...
     
    Last edited: Nov 11, 2018
  33. Sean B.

    Sean B. LI Guru Member

    I don't recall if the option affects IPv6 or not, but I'd suggest enabling "DHCP routes" under Advanced->Routing and see if anything changes. If you haven't already.
     
  34. Sinopsys

    Sinopsys Reformed Router Member

    Thank you for this new proposal. It seems that it is only for ipv4 indeed. Anyway it was enabled already so no improvement on that front.

    I might have found the issue: the back porting of the accept_ra tweak has been done on all the routers but the arm7 version with SDK7 so not working in R8000
    I'm rebuilding to confirm my finding...
     
  35. M_ars

    M_ars Network Guru Member

    mmh... I think you are right
    https://bitbucket.org/kille72/freshtomato-arm/commits/fb5ead90de939d16220d132c9f8450450eeb3059

    ==> missing for arm7 SDK

    @pedro311 @kille72 can you add that patch to arm7 branches?
     
    kille72 likes this.
  36. Sinopsys

    Sinopsys Reformed Router Member

    At least I can confirm that with this patch I do have IPv6 working properly: WAN gets its own global link address as expected (not rejecting anymore RA).

    Now there is an additional tweak to have the default route being set properly during ND with following WAN UP script:
    Code:
    echo 0> /proc/sys/net/ipv6/conf/`nvram get wan_iface`/accept_ra
    ip -6 route del default dev `nvram get wan_iface`
    echo 2> /proc/sys/net/ipv6/conf/`nvram get wan_iface`/accept_ra
    As discribed in older post:
     
  37. M_ars

    M_ars Network Guru Member

    Could you show/explain whats not working? --> "default route being set properly during ND"
     
  38. Sinopsys

    Sinopsys Reformed Router Member

    With default settings (no additional script) I have:

    - a global address being assigned thanks to NPD (RA)
    Code:
    vlan2      Link encap:Ethernet  HWaddr XX:XX:XX:XX 
               inet addr:XXX.XXX.XXX.XXX  Bcast:112.120.148.255  Mask:255.255.255.0
               inet6 addr: 2404:c800:901b:1d2:XXXX:XXXX:XXXX:XXXX/64 Scope:Global
               inet6 addr: 2404:c800:901b:1d1:XXXX:XXXX:XXXX:XXXX/64 Scope:Global
               inet6 addr: fe80::XXXX:XXX:XXX:XXXX/64 Scope:Link
               UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    - default gateway added
    Code:
    2404:c800:901b:1d1::/64 dev vlan2  proto kernel  metric 256  expires 1209sec mtu 1500 advmss 1440 hoplimit 0
    2404:c800:901b:1d2::/64 dev vlan2  proto kernel  metric 256  expires 1238sec mtu 1500 advmss 1440 hoplimit 0
    2404:c804:1b00:f200::/56 dev br0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev vlan1  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev br0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev vlan2  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    default dev vlan2  metric 1024  mtu 1500 advmss 1440 hoplimit 0
    default via fe80:5eff:fe00::200::102 dev vlan2  proto kernel  metric 1024  expires 1238sec mtu 1500 advmss 1440 hoplimit 0
    But with a default gateway already set from wan interface init:
    Code:
    default dev vlan2  metric 1024  mtu 1500 advmss 1440 hoplimit 0
    Messing up routing.
     
  39. M_ars

    M_ars Network Guru Member

    I am using DHCPv6 with PPPoE and latest freshtomato (RT-N18U)
    --> working without problems, nothing to add
    Code:
    2003:d4:abcd:1e7c::/64 dev ppp0  proto kernel  metric 256  expires 14092sec mtu 1492 advmss 1432 hoplimit 0
    2003:d4:abcd:7a00::/64 dev br0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev br0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev vlan10  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev br1  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev vlan7  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev ppp0  proto kernel  metric 256  mtu 1492 advmss 1432 hoplimit 0
    fe80::/10 dev ppp0  metric 1  mtu 1492 advmss 1432 hoplimit 0
    fe80::/10 dev ppp0  proto kernel  metric 256  mtu 1492 advmss 1432 hoplimit 0
    default dev ppp0  metric 1024  mtu 1492 advmss 1432 hoplimit 0
    default via fe80::111:123:3e9b:f3a1 dev ppp0  proto kernel  metric 1024  expires 1492sec mtu 1492 advmss 1432 hoplimit 64
    something missing for arm7 SDK mabye? Do you have a mips router or non SDK7 router to test?

    Another thing you could try is to use latest Toastman firmware for your router and see if everthing is working. Maybe there is a problem with multiwan.
    (But I think latest Toastman firmware for SDK7 is also missing the accept RA patch)
    Edit: patch also not applied for Toastman... so thats a problem again --> custom build
     
    Last edited: Nov 17, 2018
  40. Sinopsys

    Sinopsys Reformed Router Member

    well it is very strange that it works for you as your first default entry should behave as a blackhole !?
    I have a very similar routing table except 1/ it is vlan2 instead of ppp0 2/ I do not have the fe80::10/ entries.

    in such case traceroute behaviour from router is:
    Then if I remove the initial spurious default route (ip -6 route del default dev vlan2):
    And those 2 behaviours are for me perfectly normal and are not highlighting any bug !?

    I would be tented to consider that the issue is this "default dev vlan2" entry in routing table from boot as raised in several other posts earlier.

    I really don't get how your setup is getting around this ???
     
  41. M_ars

    M_ars Network Guru Member

    thats your routing table without changing or adding anything right?

    Code:
    2404:c804:1b00:c200::/64 dev br0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev br0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev vlan2 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev eth2 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev eth3 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
    default dev vlan2 metric 1024 mtu 1500 advmss 1440 hoplimit 0
    that is missing/not added by default or?
    Code:
    default via fe80:5eff:fe00::200::102 dev vlan2  proto kernel  metric 1024  expires 1238sec mtu 1500 advmss 1440 hoplimit 0
    thats would be at least one difference compared to my setup.

    I will test a few things, i have an idea
     
  42. Sinopsys

    Sinopsys Reformed Router Member

    The first block is indeed what is set by default (except first line that is added once PD is provided).
    The second block is automatically added along RA hand shake.

    I suspect the last line of first block not to be relevant.
     
  43. Sean B.

    Sean B. LI Guru Member

    Are you still selecting "PD-Only"? If so, that is why:

    Code:
    case IPV6_NATIVE:
           snprintf(addr6, sizeof(addr6), "%s/%d", nvram_safe_get("ipv6_wan_addr"), nvram_get_int("ipv6_prefix_len_wan"));
           eval("ip", "-6", "addr", "add", addr6, "dev", (char *)wan_ifname);
           eval("ip", "-6", "route", "del", "::/0");
           eval("ip", "-6", "route", "add", nvram_safe_get("ipv6_isp_gw"), "dev", (char *)wan_ifname);
           eval("ip", "-6", "route", "add", "::/0", "via", nvram_safe_get("ipv6_isp_gw"), "dev", (char *)wan_ifname);
           //eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname, "metric", "2048");
           break;
       case IPV6_NATIVE_DHCP:
           if (nvram_get_int("ipv6_pdonly") == 1) {    <----**HERE**--------
               eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname);  <----**HERE**--
           }
           stop_dhcp6c();
           start_dhcp6c();
           break;
    
    I would bet @M_ars is not using "PD-only", and therefor the routing table will not have that entry. As you can see, when "PD-Only" is selected the route that is breaking your connectivity is set.
     
  44. M_ars

    M_ars Network Guru Member

    I use PD-only :)
     
  45. Sean B.

    Sean B. LI Guru Member

    @M_ars , is the fe80 address in the default route the link address of your WAN interface? I have no experience with PD-Only, every setup I have dealt with has a /128 address on the WAN.

    @Sinopsys , would you post the output of "route -A inet6" please.
     
    Last edited: Nov 18, 2018
  46. Sinopsys

    Sinopsys Reformed Router Member

    Code:
    Destination                                 Next Hop                                Flags Metric Ref    Use Iface
    2404:c800:8000:16::1201/128                 2404:c800:8000:16::1201                 UC    0      0        6 vlan2   
    2404:c800:8000:1a::1201/128                 2404:c800:8000:1a::1201                 UC    0      0        4 vlan2   
    2404:c800:901b:1d9::/64                     ::                                      UA    256    0        0 vlan2   
    2404:c800:901b:1da::/64                     ::                                      UA    256    0        0 vlan2   
    2404:c804:1b00:f900:25ad:2f4e:4140:4877/128 2404:c804:1b00:f900:25ad:2f4e:4140:4877 UC    0      0       11 vlan2   
    2404:c804:1b00:f900:5d6c:d840:3c68:2178/128 2404:c804:1b00:f900:5d6c:d840:3c68:2178 UC    0      1        8 vlan2   
    2404:c804:1b00:f900:eafc:afff:feff:99de/128 2404:c804:1b00:f900:eafc:afff:feff:99de UC    0      0       26 vlan2   
    2404:c804:1b00:fa00::4855:cca1/128          2404:c804:1b00:fa00::4855:cca1          UC    0      0       17 br0     
    2404:c804:1b00:fa00:2139:5c3c:280b:d975/128 2404:c804:1b00:fa00:2139:5c3c:280b:d975 UC    0      0        9 br0     
    2404:c804:1b00:fa00:2aff:3cff:fe55:7119/128 2404:c804:1b00:fa00:2aff:3cff:fe55:7119 UC    0      0        5 br0     
    2404:c804:1b00:fa00:5d6c:d840:3c68:2178/128 2404:c804:1b00:fa00:5d6c:d840:3c68:2178 UC    0      0       14 br0     
    2404:c804:1b00:fa00:64e1:5f5:6b33:10aa/128  2404:c804:1b00:fa00:64e1:5f5:6b33:10aa  UC    0      0        9 br0     
    2404:c804:1b00:fa00:8a12:4eff:fe15:2388/128 2404:c804:1b00:fa00:8a12:4eff:fe15:2388 UC    0      0        5 br0     
    2404:c804:1b00:fa00:8a66:a5ff:fed6:a32b/128 2404:c804:1b00:fa00:8a66:a5ff:fed6:a32b UC    0      0        5 br0     
    2404:c804:1b00:fa00:a6c0:e1ff:fe0e:1c44/128 2404:c804:1b00:fa00:a6c0:e1ff:fe0e:1c44 UC    0      0        5 br0     
    2404:c804:1b00:fa00:bc84:b2eb:239b:7d86/128 2404:c804:1b00:fa00:bc84:b2eb:239b:7d86 UC    0      0       76 br0     
    2404:c804:1b00:fa00:ce44:63ff:fe9f:df1b/128 2404:c804:1b00:fa00:ce44:63ff:fe9f:df1b UC    0      0        5 br0     
    2404:c804:1b00:fa00::/56                    ::                                      U     256    0        0 br0     
    2600:1417:28::db4c:ac1/128                  2600:1417:28::db4c:ac1                  UC    0      0       18 vlan2   
    2600:1417:28::db4c:ac2/128                  2600:1417:28::db4c:ac2                  UC    0      0       12 vlan2   
    2a01:111:2003::52/128                       2a01:111:2003::52                       UC    0      0        3 vlan2   
    fe80::211:32ff:fe0c:8db0/128                fe80::211:32ff:fe0c:8db0                UC    0      0        3 br0     
    fe80::46b:874:5806:4ffc/128                 fe80::46b:874:5806:4ffc                 UC    0      0        5 br0     
    fe80::14d2:dbb9:a2b5:11ce/128               fe80::14d2:dbb9:a2b5:11ce               UC    0      0       56 br0     
    fe80::1891:541b:dfe3:d69e/128               fe80::1891:541b:dfe3:d69e               UC    0      0        5 br0     
    fe80::5d6c:d840:3c68:2178/128               fe80::5d6c:d840:3c68:2178               UC    0      0       28 br0     
    fe80::/64                                   ::                                      U     256    0        0 vlan1   
    fe80::/64                                   ::                                      U     256    0        0 br0     
    fe80::/64                                   ::                                      U     256    0        0 vlan2   
    ::/0                                        ::                                      U     1024   0        2 vlan2   
    ::/0                                        ::                                      !n    -1     1      509 lo     
    ::1/128                                     ::                                      Un    0      1        0 lo     
    2404:c800:901b:1d9::/128                    ::                                      Un    0      1        1 lo     
    2404:c800:901b:1d9:eafc:afff:feff:99df/128  ::                                      Un    0      1       30 lo     
    2404:c800:901b:1da::/128                    ::                                      Un    0      1        0 lo     
    2404:c800:901b:1da:eafc:afff:feff:99df/128  ::                                      Un    0      1       27 lo     
    2404:c804:1b00:fa00::/128                   ::                                      Un    0      1        0 lo     
    2404:c804:1b00:fa00:eafc:afff:feff:99de/128 ::                                      Un    0      1      117 lo     
    fe80::/128                                  ::                                      Un    0      1        0 lo     
    fe80::/128                                  ::                                      Un    0      1        0 lo     
    fe80::/128                                  ::                                      Un    0      1        0 lo     
    fe80::eafc:afff:feff:99de/128               ::                                      Un    0      1        0 lo     
    fe80::eafc:afff:feff:99de/128               ::                                      Un    0      1       84 lo     
    fe80::eafc:afff:feff:99df/128               ::                                      Un    0      1        5 lo     
    ff02::1/128                                 ff02::1                                 UC    0      0        3 vlan2   
    ff02::1/128                                 ff02::1                                 UC    0      0       20 br0     
    ff02::2/128                                 ff02::2                                 UC    0      0        6 br0     
    ff02::c/128                                 ff02::c                                 UC    0      0       48 br0     
    ff02::16/128                                ff02::16                                UC    0      0       30 br0     
    ff02::fb/128                                ff02::fb                                UC    0      0      229 br0     
    ff02::1:2/128                               ff02::1:2                               UC    0      0        5 vlan2   
    ff02::1:2/128                               ff02::1:2                               UC    0      0       15 br0     
    ff02::1:3/128                               ff02::1:3                               UC    0      0       28 br0     
    ff02::1:ff0b:d975/128                       ff02::1:ff0b:d975                       UC    0      0        1 br0     
    ff02::1:ff0c:8db0/128                       ff02::1:ff0c:8db0                       UC    0      0        2 br0     
    ff02::1:ff0d:da68/128                       ff02::1:ff0d:da68                       UC    0      0        1 br0     
    ff02::1:ff15:d794/128                       ff02::1:ff15:d794                       UC    0      0        1 br0     
    ff02::1:ff2f:446c/128                       ff02::1:ff2f:446c                       UC    0      0        1 br0     
    ff02::1:ff33:10aa/128                       ff02::1:ff33:10aa                       UC    0      0        1 br0     
    ff02::1:ff45:4c76/128                       ff02::1:ff45:4c76                       UC    0      0        7 br0     
    ff02::1:ff55:cca1/128                       ff02::1:ff55:cca1                       UC    0      0        2 br0     
    ff02::1:ff68:2178/128                       ff02::1:ff68:2178                       UC    0      0        2 br0     
    ff02::1:ff6f:c035/128                       ff02::1:ff6f:c035                       UC    0      0        1 br0     
    ff02::1:ff70:9f8a/128                       ff02::1:ff70:9f8a                       UC    0      0        1 br0     
    ff02::1:ff74:1ccd/128                       ff02::1:ff74:1ccd                       UC    0      0        1 br0     
    ff02::1:ff74:4b78/128                       ff02::1:ff74:4b78                       UC    0      0        1 br0     
    ff02::1:ff74:616c/128                       ff02::1:ff74:616c                       UC    0      0        1 br0     
    ff02::1:ff9b:7d86/128                       ff02::1:ff9b:7d86                       UC    0      0        2 br0     
    ff02::1:ffaf:c5e7/128                       ff02::1:ffaf:c5e7                       UC    0      0        1 br0     
    ff02::1:ffb1:8cdd/128                       ff02::1:ffb1:8cdd                       UC    0      0        1 br0     
    ff02::1:ffe5:56b/128                        ff02::1:ffe5:56b                        UC    0      0        1 br0     
    ff02::1:fff9:aae5/128                       ff02::1:fff9:aae5                       UC    0      0        1 br0     
    ff02::1:ffff:99de/128                       ff02::1:ffff:99de                       UC    0      0       51 br0     
    ff02::1:ffff:99df/128                       ff02::1:ffff:99df                       UC    0      0        1 vlan2   
    ff00::/8                                    ::                                      U     256    0        0 vlan1   
    ff00::/8                                    ::                                      U     256    0        0 br0     
    ff00::/8                                    ::                                      U     256    0        0 vlan2   
    ::/0                                        ::                                      !n    -1     1      509 lo 
     
  47. Sinopsys

    Sinopsys Reformed Router Member

    My understanding is that pd-only or not do not change much from router stand point, it is just a matter of which part of the protocol is providing the address:
    W/o PD-only isp is providing address in a state full (DHCPv6) way along side with the prefix
    W PD-only isp provides prefix, router allocate its own address (state less) and publish it via RA (NPD) and capture its default gateway from isp RA.

    Not only @M_ars has PD-Only set but he also have this entry:
    Code:
    2003:d4:abcd:1e7c::/64 dev ppp0  proto kernel  metric 256  expires 14092sec mtu 1492 advmss 1432 hoplimit 0
    2003:d4:abcd:7a00::/64 dev br0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev br0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev vlan10  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev br1  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev vlan7  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev ppp0  proto kernel  metric 256  mtu 1492 advmss 1432 hoplimit 0
    fe80::/10 dev ppp0  metric 1  mtu 1492 advmss 1432 hoplimit 0
    fe80::/10 dev ppp0  proto kernel  metric 256  mtu 1492 advmss 1432 hoplimit 0
    default dev ppp0  metric 1024  mtu 1492 advmss 1432 hoplimit 0 <--- HERE
    default via fe80::111:123:3e9b:f3a1 dev ppp0  proto kernel  metric 1024  expires 1492sec mtu 1492 advmss 1432 hoplimit 64
    Still it is working properly !!??
     
  48. M_ars

    M_ars Network Guru Member

    Yes, its working

    Code:
    root@RT-N18U:/tmp/home/root# ping6 -c 5 ipv6.google.com
    PING ipv6.google.com (2a00:1450:400e:80d::200e): 56 data bytes
    64 bytes from 2a00:1450:400e:80d::200e: seq=0 ttl=58 time=30.193 ms
    64 bytes from 2a00:1450:400e:80d::200e: seq=1 ttl=58 time=30.172 ms
    64 bytes from 2a00:1450:400e:80d::200e: seq=2 ttl=58 time=30.430 ms
    64 bytes from 2a00:1450:400e:80d::200e: seq=3 ttl=58 time=30.164 ms
    64 bytes from 2a00:1450:400e:80d::200e: seq=4 ttl=58 time=30.440 ms
    
    --- ipv6.google.com ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max = 30.164/30.279/30.440 ms
    root@RT-N18U:/tmp/home/root#
    this route is also set on my side, BUT there is one more and i think thats the problem on Synopsis side.
    --> Why is it missing in your case? (that is the main problem i think)

    Code:
    case IPV6_NATIVE:
           snprintf(addr6, sizeof(addr6), "%s/%d", nvram_safe_get("ipv6_wan_addr"), nvram_get_int("ipv6_prefix_len_wan"));
           eval("ip", "-6", "addr", "add", addr6, "dev", (char *)wan_ifname);
           eval("ip", "-6", "route", "del", "::/0");
           eval("ip", "-6", "route", "add", nvram_safe_get("ipv6_isp_gw"), "dev", (char *)wan_ifname);
           eval("ip", "-6", "route", "add", "::/0", "via", nvram_safe_get("ipv6_isp_gw"), "dev", (char *)wan_ifname);
           //eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname, "metric", "2048");
           break;
       case IPV6_NATIVE_DHCP:
           if (nvram_get_int("ipv6_pdonly") == 1) {    <----**HERE**--------
               eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname);  <----**HERE**--
           }
           stop_dhcp6c();
           start_dhcp6c();
           break;
     
  49. Sean B.

    Sean B. LI Guru Member

    It does. If you read those sections of document I posted awhile back, stateful VS stateless configuration of the WAN interface IP plays a key role in whether or not the route can be auto configured easily.

    How can the next hop be itself?

    You have 2 /128 addresses being configured for the WAN from 2 different prefixes. @M_ars , does yours show the same?
     
    M_ars likes this.
  50. M_ars

    M_ars Network Guru Member

    mmh i do look at the code right now.
    First it was removed some time ago
    https://repo.or.cz/tomato.git/commi...8?hp=362df2b5dcd738616168aa4aab8af9a00a32b738

    Code:
            case IPV6_NATIVE_DHCP:
    -               eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname);
    +//             eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname);  //removed by Toastman
    +//      see discussion at http://www.linksysinfo.org/index.php?threads/ipv6-and-comcast.38006/
    +//             post #24 refers. 

    see also https://www.linksysinfo.org/index.php?threads/ipv6-and-comcast.38006/

    then shibby added an option to choose
    with the following note:
    https://repo.or.cz/tomato.git/commi...8?hp=702656bbf29da99a633e0a35e79c971343047b63

    Code:
            case IPV6_NATIVE_DHCP:
    -//             eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname);  //removed by Toastman
    -//      see discussion at http://www.linksysinfo.org/index.php?threads/ipv6-and-comcast.38006/
    -//             post #24 refers.
    +               if (nvram_get_int("ipv6_isp_opt") == 1) {
    +                       eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname);
    after that

    https://repo.or.cz/tomato.git/histo...b4c5b28d750:/release/src/router/rc/wan.c?pg=0

    Code:
            case IPV6_NATIVE_DHCP:
                    if (nvram_get_int("ipv6_isp_opt") == 1) {
    -                       eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname);
    +                       eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname, "metric", "2048"); //not needed? - workaround for misconfigured ISPs?
                    }
    and then

    https://bitbucket.org/pedro311/freshtomato-arm/commits/37ce5b52f1981b329f54e83e4dac931c2ddcf442


    As far as i can see all Tomato-Branches (Toastman, Shibby, Freshtomato) have/do the following:

    Code:
       case IPV6_NATIVE_DHCP:
           if (nvram_get_int("ipv6_pdonly") == 1) {    <----**HERE**--------
               eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname);  <----**HERE**--
           }
           stop_dhcp6c();
           start_dhcp6c();
           break;
     
  51. Sean B.

    Sean B. LI Guru Member

    So, the question remains.. wtf is his router doing?
     
  52. Sinopsys

    Sinopsys Reformed Router Member

    Those 2 addresses are the dns provided from ISP through dhcp6c.

    I'm quite interested by @M_ars route table to compare because can't figure out why in his case the 2 default routes do not conflict hiding the relevant one !?

    When I drop it manually (the ::/0) my route table looks much better (and it works :))
    Code:
    Kernel IPv6 routing table
    Destination                                 Next Hop                                Flags Metric Ref    Use Iface
    2404:c800:901b:1da::/64                     ::                                      UA    256    0        0 vlan2  
    2404:c804:1b00:fa00::d445:4c76/128          2404:c804:1b00:fa00::d445:4c76          UC    0      0       31 br0    
    [...]
    2404:c804:1b00:fa00::/56                    ::                                      U     256    0        0 br0    
    fe80::/64                                   ::                                      U     256    0        0 vlan1  
    fe80::/64                                   ::                                      U     256    0        0 br0    
    fe80::/64                                   ::                                      U     256    0        0 vlan2  
    ::/0                                        fe80::200:5eff:fe00:102                 UGDA  1024   0      713 vlan2  <--- GOOD
    ::/0                                        ::                                      !n    -1     1    60881 lo    
    ::1/128                                     ::                                      Un    0      1        0 lo    
    2404:c800:901b:1da::/128                    ::                                      Un    0      1       16 lo    
    2404:c800:901b:1da:eafc:afff:feff:99df/128  ::                                      Un    0      1     4708 lo    
    2404:c804:1b00:fa00::/128                   ::                                      Un    0      1        0 lo    
    2404:c804:1b00:fa00:eafc:afff:feff:99de/128 ::                                      Un    0      1    25673 lo    
    fe80::/128                                  ::                                      Un    0      1        0 lo    
    fe80::/128                                  ::                                      Un    0      1        0 lo    
    fe80::/128                                  ::                                      Un    0      1        0 lo    
    fe80::eafc:afff:feff:99de/128               ::                                      Un    0      1        2 lo    
    fe80::eafc:afff:feff:99de/128               ::                                      Un    0      1     5538 lo    
    fe80::eafc:afff:feff:99df/128               ::                                      Un    0      1      353 lo    
    ff02::1/128                                 ff02::1                                 UC    0      0        1 br0    
    ff02::fb/128                                ff02::fb                                UC    0      0      361 br0    
    ff00::/8                                    ::                                      U     256    0        0 vlan1  
    ff00::/8                                    ::                                      U     256    0        0 br0    
    ff00::/8                                    ::                                      U     256    0        0 vlan2  
    ::/0                                        ::                                      !n    -1     1    60881 lo    
    
    
     
  53. Sean B.

    Sean B. LI Guru Member

    And every route of which had itself as next hop is gone. What would be great is to see wireshark captures on the WAN interface of the dhcpv6 exchange. Any chance you have entware installed and can run a capture?

    You can run a build of the firmware with these lines commented out:

    Code:
    case IPV6_NATIVE_DHCP:
            if (nvram_get_int("ipv6_pdonly") == 1) {
                eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname);
            }
    Which are lines 1108-1111 of freshtomato-arm/release/src-rt-6.x.4708/router/rc/wan.c
    if you wish. As that should fix your problem.
     
    Last edited: Nov 18, 2018
  54. M_ars

    M_ars Network Guru Member

  55. M_ars

    M_ars Network Guru Member

    i still do not understand why you do not have a default route :) --> announced via RA from your service provider
    Do you have QoS enabled?
     
    Last edited: Nov 18, 2018
  56. M_ars

    M_ars Network Guru Member

    Code:
    root@RT-N18U:/tmp/home/root# route -A inet6
    Kernel IPv6 routing table
    Destination                                 Next Hop                                Flags Metric Ref    Use Iface
    2003:d44:3bbf:1e7c::/64                      ::                                      UA    256    0        0 ppp0
    2003:d44:3bde:7a00:1189:7eee:7ab2:b395/128   2003:d44:3bde:7a00:1189:7eee:7ab2:b395   UC    0      0        1 br0
    2003:d44:3bde:7a00::/64                      ::                                      U     256    0        0 br0
    2003:180:2:7000:0:1:0:53/128                2003:180:2:7000:0:1:0:53                UC    0      0        8 ppp0
    2003:180:2:9000:0:1:0:53/128                2003:180:2:9000:0:1:0:53                UC    0      0        2 ppp0
    fe80::/64                                   ::                                      U     256    0        0 br0
    fe80::/64                                   ::                                      U     256    0        0 vlan10
    fe80::/64                                   ::                                      U     256    0        0 br1
    fe80::/64                                   ::                                      U     256    0        0 vlan7
    fe80::/64                                   ::                                      U     256    0        0 ppp0
    fe80::/10                                   ::                                      U     1      0        0 ppp0
    fe80::/10                                   ::                                      U     256    0        0 ppp0
    ::/0                                        ::                                      U     1024   0        1 ppp0
    ::/0                                        fe80::143:143:3e9b:f3a1                 UGDA  1024   0        0 ppp0
    ::/0                                        ::                                      !n    -1     1  4081410 lo
    ::1/128                                     ::                                      Un    0      1        0 lo
    2003:d44:3bbf:1e7c::/128                     ::                                      Un    0      1     1830 lo
    2003:d44:3bbf:1e7c:d02a:b5f5:c2ab:7734/128   ::                                      Un    0      1    74207 lo
    2003:d44:3bde:7a00::/128                     ::                                      Un    0      1        0 lo
    2003:d44:3bde:7a00:2e4d:54ff:fe1d:a0fc/128   ::                                      Un    0      1    56782 lo
    fe80::/128                                  ::                                      Un    0      1        0 lo
    fe80::/128                                  ::                                      Un    0      1        0 lo
    fe80::/128                                  ::                                      Un    0      1        0 lo
    fe80::/128                                  ::                                      Un    0      1        0 lo
    fe80::/128                                  ::                                      Un    0      1        0 lo
    fe80::2e4d:54ff:fe1d:a0fc/128               ::                                      Un    0      1    46864 lo
    fe80::2e4d:54ff:fe1d:a0fc/128               ::                                      Un    0      1        0 lo
    fe80::2e4d:54ff:fe1d:a0fc/128               ::                                      Un    0      1        0 lo
    fe80::2e4d:54ff:fe1d:a0fd/128               ::                                      Un    0      1        0 lo
    fe80::d02a:b5f5:c2ab:7734/128               ::                                      Un    0      1      784 lo
    ff02::1/128                                 ff02::1                                 UC    0      0        1 vlan7
    ff02::c/128                                 ff02::c                                 UC    0      66      66 br0
    ff02::1:ff00:0/128                          ff02::1:ff00:0                          UC    0      0        1 vlan7
    ff02::1:ff00:1/128                          ff02::1:ff00:1                          UC    0      0        1 vlan7
    ff05::c/128                                 ff05::c                                 UC    0      66      66 br0
    ff0e::c/128                                 ff0e::c                                 UC    0      66      66 br0
    ff00::/8                                    ::                                      U     256    0        0 br0
    ff00::/8                                    ::                                      U     256    0        0 vlan10
    ff00::/8                                    ::                                      U     256    0        0 br1
    ff00::/8                                    ::                                      U     256    0        0 vlan7
    ff00::/8                                    ::                                      U     256    0        0 ppp0
    ::/0                                        ::                                      !n    -1     1  4081410 lo
    root@RT-N18U:/tmp/home/root#
    
    Edit: removed the default route ::/ for ppp0 and still everything is working on my side!

    Code:
    root@RT-N18U:/tmp/home/root# ip -6 route show
    2003:d44:3bbf:1e7c::/64 dev ppp0  proto kernel  metric 256  expires 14304sec mtu 1492 advmss 1432 hoplimit 0
    2003:d44:3bde:7a00::/64 dev br0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev br0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev vlan10  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev br1  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev vlan7  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev ppp0  proto kernel  metric 256  mtu 1492 advmss 1432 hoplimit 0
    fe80::/10 dev ppp0  metric 1  mtu 1492 advmss 1432 hoplimit 0
    fe80::/10 dev ppp0  proto kernel  metric 256  mtu 1492 advmss 1432 hoplimit 0
    default via fe80::143:143:3e9b:f3a1 dev ppp0  proto kernel  metric 1024  expires 1704sec mtu 1492 advmss 1432 hoplimit 64

    will play a little bit more with it. But some people maybe need that route?
     
    Last edited: Nov 18, 2018
  57. Sean B.

    Sean B. LI Guru Member

    Anyone notice when the offending default route is removed, the next traceroute shows a first hop in a different delegated prefix?

    @M_ars , does your ISP delegate a /56 or /48 etc? Or a standard /64?
     
  58. Sinopsys

    Sinopsys Reformed Router Member

    No it is not activated.
     
  59. Sinopsys

    Sinopsys Reformed Router Member

    May be I'm getting confused !? I do have a default route (on top of static one) coming indeed from RA

    When I keep setup without additional tweak scripts (thus having the "default dev vlan2" route set during init)
    RA comes and gateway route is being properly added by NDP:
    Code:
    default dev vlan2  metric 1024  mtu 1500 advmss 1440 hoplimit 0
    HERE ---> default via fe80:5eff:fe00::200::102 dev vlan2  proto kernel  metric 1024  expires 1238sec mtu 1500 advmss 1440 hoplimit 0
    but routing does not work properly as this rule appended is being shadowed by the first one and thus it is not pushed in /proc/net/ipv6_route and so not showing on "route -A inet6".

    And it seems that as soon as I delete the first entry then it is pushed in /proc/net/ipv6_route (or a new RA comes to set default route without issue).

    this is so far the difference I see with your router behavior that seems to push it right away in the routing table.

    I must admit that the code is a bit too tricky for me to investigate why&where
    ip6_route_add fails :(
     
    Last edited: Nov 19, 2018
  60. Sinopsys

    Sinopsys Reformed Router Member

    I do have tcpdump. Here is the capture of dhcpv6 + icmpv6 (only RA/RS):
    Code:
    No.     Time           Source                Destination           Protocol Length Info
        145 105.127901     fe80::eafc:afff:feff:99df ff02::1:2             DHCPv6   137    Solicit XID: 0xd03f82 CID: 000300011a8b42f2a806
    
    Frame 145: 137 bytes on wire (1096 bits), 137 bytes captured (1096 bits)
        Encapsulation type: Ethernet (1)
        Arrival Time: Nov  7, 2018 11:54:12.800028000 China Standard Time
        Frame Number: 145
        Frame Length: 137 bytes (1096 bits)
        Capture Length: 137 bytes (1096 bits)
        [Frame is marked: False]
        [Frame is ignored: False]
        [Protocols in frame: eth:ethertype:ipv6:udp:dhcpv6]
    Ethernet II, Src: Netgear_ff:99:df (e8:fc:af:ff:99:df), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02)
        Destination: IPv6mcast_01:00:02 (33:33:00:01:00:02)
            Address: IPv6mcast_01:00:02 (33:33:00:01:00:02)
            .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
            .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
        Source: Netgear_ff:99:df (e8:fc:af:ff:99:df)
            Address: Netgear_ff:99:df (e8:fc:af:ff:99:df)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        Type: IPv6 (0x86dd)
    Internet Protocol Version 6, Src: fe80::eafc:afff:feff:99df, Dst: ff02::1:2
        0110 .... = Version: 6
        .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
            .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
            .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
        .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
        Payload Length: 83
        Next Header: UDP (17)
        Hop Limit: 1
        Source: fe80::eafc:afff:feff:99df
        Destination: ff02::1:2
        [Source SA MAC: Netgear_ff:99:df (e8:fc:af:ff:99:df)]
    User Datagram Protocol, Src Port: 546, Dst Port: 547
        Source Port: 546
        Destination Port: 547
        Length: 83
        [Stream index: 0]
    DHCPv6
        Message type: Solicit (1)
        Transaction ID: 0xd03f82
        Client Identifier
            Option: Client Identifier (1)
            Length: 10
            Value: 000300011a8b42f2a806
            DUID: 000300011a8b42f2a806
            DUID Type: link-layer address (3)
            Hardware type: Ethernet (1)
            Link-layer address: 1a:8b:42:f2:a8:06
        Option Request
            Option: Option Request (6)
            Length: 2
            Value: 0017
            Requested Option code: DNS recursive name server (23)
        Identity Association for Prefix Delegation
            Option: Identity Association for Prefix Delegation (25)
            Length: 41
            Value: 000000000000000000000000001a0019ffffffffffffffff...
            IAID: 00000000
            T1: 0
            T2: 0
            IA Prefix
                Option: IA Prefix (26)
                Length: 25
                Value: ffffffffffffffff38000000000000000000000000000000...
                Preferred lifetime: infinity
                Valid lifetime: infinity
                Prefix length: 56
                Prefix address: ::
    
    No.     Time           Source                Destination           Protocol Length Info
        146 -1541562747.130366 fe80::200:5eff:fe00:102 fe80::eafc:afff:feff:99df DHCPv6   199    Advertise XID: 0xd03f82 CID: 000300011a8b42f2a806
    
    Frame 146: 199 bytes on wire (1592 bits), 199 bytes captured (1592 bits)
        Encapsulation type: Ethernet (1)
        Arrival Time: Jan  1, 1970 08:00:00.541761000 China Standard Time
        Frame Number: 146
        Frame Length: 199 bytes (1592 bits)
        Capture Length: 199 bytes (1592 bits)
        [Frame is marked: False]
        [Frame is ignored: False]
        [Protocols in frame: eth:ethertype:ipv6:udp:dhcpv6]
    Ethernet II, Src: IETF-VRRP-VRID_02 (00:00:5e:00:01:02), Dst: Netgear_ff:99:df (e8:fc:af:ff:99:df)
        Destination: Netgear_ff:99:df (e8:fc:af:ff:99:df)
            Address: Netgear_ff:99:df (e8:fc:af:ff:99:df)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        Source: IETF-VRRP-VRID_02 (00:00:5e:00:01:02)
            Address: IETF-VRRP-VRID_02 (00:00:5e:00:01:02)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        Type: IPv6 (0x86dd)
    Internet Protocol Version 6, Src: fe80::200:5eff:fe00:102, Dst: fe80::eafc:afff:feff:99df
        0110 .... = Version: 6
        .... 1100 0000 .... .... .... .... .... = Traffic Class: 0xc0 (DSCP: CS6, ECN: Not-ECT)
            .... 1100 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 6 (48)
            .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
        .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
        Payload Length: 145
        Next Header: UDP (17)
        Hop Limit: 255
        Source: fe80::200:5eff:fe00:102
        Destination: fe80::eafc:afff:feff:99df
        [Source SA MAC: IETF-VRRP-VRID_02 (00:00:5e:00:01:02)]
        [Destination SA MAC: Netgear_ff:99:df (e8:fc:af:ff:99:df)]
    User Datagram Protocol, Src Port: 547, Dst Port: 546
        Source Port: 547
        Destination Port: 546
        Length: 145
        [Stream index: 1]
    DHCPv6
        Message type: Advertise (2)
        Transaction ID: 0xd03f82
        Client Identifier
            Option: Client Identifier (1)
            Length: 10
            Value: 000300011a8b42f2a806
            DUID: 000300011a8b42f2a806
            DUID Type: link-layer address (3)
            Hardware type: Ethernet (1)
            Link-layer address: 1a:8b:42:f2:a8:06
        Server Identifier
            Option: Server Identifier (2)
            Length: 16
            Value: fe8000000000000002005efffe000102
            DUID: fe8000000000000002005efffe000102
            DUID Type: Unknown (65152)
        Preference
            Option: Preference (7)
            Length: 1
            Value: ff
            Pref-value: 255
        Identity Association for Prefix Delegation
            Option: Identity Association for Prefix Delegation (25)
            Length: 54
            Value: 0000000000000384000005a0001a00190000070800000708...
            IAID: 00000000
            T1: 900
            T2: 1440
            IA Prefix
                Option: IA Prefix (26)
                Length: 25
                Value: 0000070800000708382404c8041b00bc0000000000000000...
                Preferred lifetime: 1800
                Valid lifetime: 1800
                Prefix length: 56
                Prefix address: 2404:c804:1b00:bc00::
            Status code
                Option: Status code (13)
                Length: 9
                Value: 000053756363657373
                Status Code: Success (0)
                Status Message: Success
        DNS recursive name server
            Option: DNS recursive name server (23)
            Length: 32
            Value: 2404c8008000001a00000000000012012404c80080000016...
             1 DNS server address: 2404:c800:8000:1a::1201
             2 DNS server address: 2404:c800:8000:16::1201
    
    No.     Time           Source                Destination           Protocol Length Info
        147 105.159226     fe80::eafc:afff:feff:99df ff02::1:2             DHCPv6   163    Request XID: 0xa625d6 CID: 000300011a8b42f2a806
    
    Frame 147: 163 bytes on wire (1304 bits), 163 bytes captured (1304 bits)
        Encapsulation type: Ethernet (1)
        Arrival Time: Nov  7, 2018 11:54:12.831353000 China Standard Time
        Frame Number: 147
        Frame Length: 163 bytes (1304 bits)
        Capture Length: 163 bytes (1304 bits)
        [Frame is marked: False]
        [Frame is ignored: False]
        [Protocols in frame: eth:ethertype:ipv6:udp:dhcpv6]
        [Coloring Rule Name: UDP]
        [Coloring Rule String: udp]
    Ethernet II, Src: Netgear_ff:99:df (e8:fc:af:ff:99:df), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02)
        Destination: IPv6mcast_01:00:02 (33:33:00:01:00:02)
            Address: IPv6mcast_01:00:02 (33:33:00:01:00:02)
            .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
            .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
        Source: Netgear_ff:99:df (e8:fc:af:ff:99:df)
            Address: Netgear_ff:99:df (e8:fc:af:ff:99:df)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        Type: IPv6 (0x86dd)
    Internet Protocol Version 6, Src: fe80::eafc:afff:feff:99df, Dst: ff02::1:2
        0110 .... = Version: 6
        .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
            .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
            .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
        .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
        Payload Length: 109
        Next Header: UDP (17)
        Hop Limit: 1
        Source: fe80::eafc:afff:feff:99df
        Destination: ff02::1:2
        [Source SA MAC: Netgear_ff:99:df (e8:fc:af:ff:99:df)]
    User Datagram Protocol, Src Port: 546, Dst Port: 547
        Source Port: 546
        Destination Port: 547
        Length: 109
        [Stream index: 0]
    DHCPv6
        Message type: Request (3)
        Transaction ID: 0xa625d6
        Client Identifier
            Option: Client Identifier (1)
            Length: 10
            Value: 000300011a8b42f2a806
            DUID: 000300011a8b42f2a806
            DUID Type: link-layer address (3)
            Hardware type: Ethernet (1)
            Link-layer address: 1a:8b:42:f2:a8:06
        Server Identifier
            Option: Server Identifier (2)
            Length: 16
            Value: fe8000000000000002005efffe000102
            DUID: fe8000000000000002005efffe000102
            DUID Type: Unknown (65152)
        Elapsed time
            Option: Elapsed time (8)
            Length: 2
            Value: 0000
            Elapsed time: 0ms
        Option Request
            Option: Option Request (6)
            Length: 2
            Value: 0017
            Requested Option code: DNS recursive name server (23)
        Identity Association for Prefix Delegation
            Option: Identity Association for Prefix Delegation (25)
            Length: 47
            Value: 000000000000000000000000001a00190000070800000708...
            IAID: 00000000
            T1: 0
            T2: 0
            IA Prefix
                Option: IA Prefix (26)
                Length: 25
                Value: 0000070800000708382404c8041b00bc0000000000000000...
                Preferred lifetime: 1800
                Valid lifetime: 1800
                Prefix length: 56
                Prefix address: 2404:c804:1b00:bc00::
            Status code
                Option: Status code (13)
                Length: 2
                Value: 0000
                Status Code: Success (0)
    
    No.     Time           Source                Destination           Protocol Length Info
        148 -1541562747.128479 fe80::200:5eff:fe00:102 fe80::eafc:afff:feff:99df DHCPv6   194    Reply XID: 0xa625d6 CID: 000300011a8b42f2a806
    
    Frame 148: 194 bytes on wire (1552 bits), 194 bytes captured (1552 bits)
        Encapsulation type: Ethernet (1)
        Arrival Time: Jan  1, 1970 08:00:00.543648000 China Standard Time
        Frame Number: 148
        Frame Length: 194 bytes (1552 bits)
        Capture Length: 194 bytes (1552 bits)
        [Frame is marked: False]
        [Frame is ignored: False]
        [Protocols in frame: eth:ethertype:ipv6:udp:dhcpv6]
    Ethernet II, Src: IETF-VRRP-VRID_02 (00:00:5e:00:01:02), Dst: Netgear_ff:99:df (e8:fc:af:ff:99:df)
        Destination: Netgear_ff:99:df (e8:fc:af:ff:99:df)
            Address: Netgear_ff:99:df (e8:fc:af:ff:99:df)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        Source: IETF-VRRP-VRID_02 (00:00:5e:00:01:02)
            Address: IETF-VRRP-VRID_02 (00:00:5e:00:01:02)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        Type: IPv6 (0x86dd)
    Internet Protocol Version 6, Src: fe80::200:5eff:fe00:102, Dst: fe80::eafc:afff:feff:99df
        0110 .... = Version: 6
        .... 1100 0000 .... .... .... .... .... = Traffic Class: 0xc0 (DSCP: CS6, ECN: Not-ECT)
            .... 1100 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 6 (48)
            .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
        .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
        Payload Length: 140
        Next Header: UDP (17)
        Hop Limit: 255
        Source: fe80::200:5eff:fe00:102
        Destination: fe80::eafc:afff:feff:99df
        [Source SA MAC: IETF-VRRP-VRID_02 (00:00:5e:00:01:02)]
        [Destination SA MAC: Netgear_ff:99:df (e8:fc:af:ff:99:df)]
    User Datagram Protocol, Src Port: 547, Dst Port: 546
        Source Port: 547
        Destination Port: 546
        Length: 140
        [Stream index: 1]
    DHCPv6
        Message type: Reply (7)
        Transaction ID: 0xa625d6
        Client Identifier
            Option: Client Identifier (1)
            Length: 10
            Value: 000300011a8b42f2a806
            DUID: 000300011a8b42f2a806
            DUID Type: link-layer address (3)
            Hardware type: Ethernet (1)
            Link-layer address: 1a:8b:42:f2:a8:06
        Server Identifier
            Option: Server Identifier (2)
            Length: 16
            Value: fe8000000000000002005efffe000102
            DUID: fe8000000000000002005efffe000102
            DUID Type: Unknown (65152)
        Identity Association for Prefix Delegation
            Option: Identity Association for Prefix Delegation (25)
            Length: 54
            Value: 0000000000000384000005a0001a00190000070800000708...
            IAID: 00000000
            T1: 900
            T2: 1440
            IA Prefix
                Option: IA Prefix (26)
                Length: 25
                Value: 0000070800000708382404c8041b00bc0000000000000000...
                Preferred lifetime: 1800
                Valid lifetime: 1800
                Prefix length: 56
                Prefix address: 2404:c804:1b00:bc00::
            Status code
                Option: Status code (13)
                Length: 9
                Value: 000053756363657373
                Status Code: Success (0)
                Status Message: Success
        DNS recursive name server
            Option: DNS recursive name server (23)
            Length: 32
            Value: 2404c8008000001a00000000000012012404c80080000016...
             1 DNS server address: 2404:c800:8000:1a::1201
             2 DNS server address: 2404:c800:8000:16::1201
    
    No.     Time           Source                Destination           Protocol Length Info
        152 -1541562747.616647 fe80::200:5eff:fe00:102 ff02::1               ICMPv6   118    Router Advertisement from 00:00:5e:00:01:02
    
    Frame 152: 118 bytes on wire (944 bits), 118 bytes captured (944 bits)
        Encapsulation type: Ethernet (1)
        Arrival Time: Jan  1, 1970 08:00:00.055480000 China Standard Time
        Frame Number: 152
        Frame Length: 118 bytes (944 bits)
        Capture Length: 118 bytes (944 bits)
        [Frame is marked: False]
        [Frame is ignored: False]
        [Protocols in frame: eth:ethertype:ipv6:icmpv6]
    Ethernet II, Src: IETF-VRRP-VRID_02 (00:00:5e:00:01:02), Dst: Netgear_ff:99:df (e8:fc:af:ff:99:df)
        Destination: Netgear_ff:99:df (e8:fc:af:ff:99:df)
            Address: Netgear_ff:99:df (e8:fc:af:ff:99:df)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        Source: IETF-VRRP-VRID_02 (00:00:5e:00:01:02)
            Address: IETF-VRRP-VRID_02 (00:00:5e:00:01:02)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        Type: IPv6 (0x86dd)
    Internet Protocol Version 6, Src: fe80::200:5eff:fe00:102, Dst: ff02::1
        0110 .... = Version: 6
        .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
            .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
            .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
        .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
        Payload Length: 64
        Next Header: ICMPv6 (58)
        Hop Limit: 255
        Source: fe80::200:5eff:fe00:102
        Destination: ff02::1
        [Source SA MAC: IETF-VRRP-VRID_02 (00:00:5e:00:01:02)]
    Internet Control Message Protocol v6
        Type: Router Advertisement (134)
        Code: 0
        Cur hop limit: 0
        Flags: 0x40, Other configuration, Prf (Default Router Preference): Medium
            0... .... = Managed address configuration: Not set
            .1.. .... = Other configuration: Set
            ..0. .... = Home Agent: Not set
            ...0 0... = Prf (Default Router Preference): Medium (0)
            .... .0.. = Proxy: Not set
            .... ..0. = Reserved: 0
        Router lifetime (s): 1800
        Reachable time (ms): 0
        Retrans timer (ms): 0
        ICMPv6 Option (Source link-layer address : 00:00:5e:00:01:02)
            Type: Source link-layer address (1)
            Length: 1 (8 bytes)
            Link-layer address: IETF-VRRP-VRID_02 (00:00:5e:00:01:02)
        ICMPv6 Option (MTU : 1500)
            Type: MTU (5)
            Length: 1 (8 bytes)
            Reserved
            MTU: 1500
        ICMPv6 Option (Prefix information : 2404:c800:901b:19a::/64)
            Type: Prefix information (3)
            Length: 4 (32 bytes)
            Prefix Length: 64
            Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A)
                1... .... = On-link flag(L): Set
                .1.. .... = Autonomous address-configuration flag(A): Set
                ..0. .... = Router address flag(R): Not set
                ...0 0000 = Reserved: 0
            Valid Lifetime: 1800
            Preferred Lifetime: 1800
            Reserved
            Prefix: 2404:c800:901b:19a::
    
     
  61. M_ars

    M_ars Network Guru Member

    soory, was an misunderstanding on my side. The first default entry is the problem on your side. After you delete it, IPv6 will work right? :)

    I did make a little patch, will test it first on my side
    --> it makes the default route an option for the Tomato user. I think I also do not need it, but maybe someone does...
    --> the missing accept RA from WAN patch for ARM7 is already added by freshtomato

    [​IMG]

    @Sean B. my ISP gives me a prefix with /56
     
    Last edited: Nov 19, 2018
  62. Sean B.

    Sean B. LI Guru Member

     
  63. Sinopsys

    Sinopsys Reformed Router Member

    correct it works once delete.

    Now you have it too and it does not break routing on your end so there might be way to accommodate with both !?
    Considering that this entry do not have the expected behavior (forwarding any unknown routes packet to default interface) I do not see its purpose.
     
  64. Sinopsys

    Sinopsys Reformed Router Member

    This is within the DHCPv6 Solicit message so this is not surprising: router tells he has no preferred prefix
     
  65. tvlz

    tvlz LI Guru Member

    I think I saw this before, look at the screen shots at the end.
    https://www.linksysinfo.org/index.php?threads/dnsmasq-restarting-every-2-seconds-with-ipv6.72708/

    @M_ars
    Instead of adding another checkbox to confuse people how about this?
    I made it years ago but never tested it.
    Code:
    From: Tvlz
    Date: Wed, 31 Aug 2016 12:49:56 -0400
    Subject: IPv6: Changes for ISPs(MEO) that use IPoE, they need the PD Only checkbox but no default route set
    
    --- a/release/src/router/rc/wan.c
    +++ b/release/src/router/rc/wan.c
         case IPV6_NATIVE_DHCP:
    -        if (nvram_get_int("ipv6_pdonly") == 1) {
    +        if ((nvram_get_int("ipv6_pdonly") == 1) && (!nvram_match("wan_proto", "dhcp"))) {
                 eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname);
             }
             stop_dhcp6c();
    
     
  66. Sinopsys

    Sinopsys Reformed Router Member

    Yes I saw that on several forums this exact same behaviour.

    But I couldn’t find any clear answer on why this is not working?
    Theoretically pushing any packet to wan interface whenever destination isn’t known within internal network should work !? It works for some people
     
  67. M_ars

    M_ars Network Guru Member

    @tvlz I use PPPoE (PD-only with /56) and i also do not need that default route. I think only a few people need that default route...
    But it can cause problems, see Sinopsys case or
    https://www.linksysinfo.org/index.php?threads/ipv6-and-comcast.38006/

    https://bitbucket.org/M_ars/freshtomato-arm/commits/59a738094281d5a724771ec586fff8563516d607

    I think its better the other way around. --> let IPv6 RA via WAN take care of adding the default route
    If thats not working (because of ...) , the user can enable the workaround --> Default: off, should not be required

    looks good on my side :)
    --> IPv6 is working perfect

    Code:
    root@RT-N18U:/tmp/home/root# ip -6 route show
    2003:d44:3bbf:1e7c::/64 dev ppp0  proto kernel  metric 256  expires 14304sec mtu 1492 advmss 1432 hoplimit 0
    2003:d44:3bde:7a00::/64 dev br0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev br0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev vlan10  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev br1  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev vlan7  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
    fe80::/64 dev ppp0  proto kernel  metric 256  mtu 1492 advmss 1432 hoplimit 0
    fe80::/10 dev ppp0  metric 1  mtu 1492 advmss 1432 hoplimit 0
    fe80::/10 dev ppp0  proto kernel  metric 256  mtu 1492 advmss 1432 hoplimit 0
    default via fe80::143:143:3e9b:f3a1 dev ppp0  proto kernel  metric 1024  expires 1704sec mtu 1492 advmss 1432 hoplimit 64
     
    Last edited: Nov 20, 2018
  68. Sean B.

    Sean B. LI Guru Member

    I'd have to say whatever is different with this situation is on the ISP's configuration.
     
  69. tvlz

    tvlz LI Guru Member

    What's different about this ISP is that it is using DHCP with a PPPoE type config (IA-PD Only) instead of the usual DHCPv6 (IA-NA + IA-PD) config and Tomato is not setup for that configuration, adding that patch should allow that config.

    @M_ars I think adding a checkbox for adding a Default Route is a step backwards, it should be automatic.

    You say "IPv6 is working perfect"
    Have you turned off IPv6 and let your current IPv6 lease expire, does it get a new lease afterwards?
     
  70. Sean B.

    Sean B. LI Guru Member

    That's what I thought as well. Except, to my surprise, @M_ars is using PD-only without issue.
     
  71. Sinopsys

    Sinopsys Reformed Router Member

    my understanding is that theoretically the “default dev WAN” route should enable traffic to be forwarded to external network whenever target address is unknown in internal network (no available route).

    In such case this rule shouldn’t interfere in the routing as soon as the actual default gateway address is provided and set as additional default route (as demonstrate by M_ars).

    But there are some case (mine for instance but many others from various forums) were the routing logic isn’t working as expected (at least as I understood).

    So the best would be to solve the root cause and figure out why packets are not forwarded to WAN !? And then see how to set explicitly this rule only when relevant (I’m not clear which case is it ? Only to workaround some ISP misbehaviour toward DHCPv6/SLAAC standard?).
     
  72. Sean B.

    Sean B. LI Guru Member

    I believe the answer is in your traceroute, but with X'd out IP's it makes an already hard to follow IPv6 address scheme even harder. But notice your first traceroute when routing is not working. It starts on 2404:c800:901b:1d6: going to the same 2404:c800:901b:1d6: prefix and fails. Yet after you remove the default route, it starts on 2404:c800:8101:41b::1 which is the first IP available in a different prefix ( correct behavior for a SLAAC configured customer-end link ) then going to the same prefix as in the previous traceroute and continues successfully.

    Almost as if the WAN comes up incorrectly configured, a route gets made and the device is linked in the wrong table. Then the WAN goes down, is reconfigured and another route added. M_ars's would work with both routes, providing the WAN was configured correctly the first time it came up.
     
  73. M_ars

    M_ars Network Guru Member

    I use PPPoE with pd-only and no ia-na --> no choise for me, requested by my provider

    I also have the case, that my IPv6 address/prefix is NOT static. My IPv6 address already changed :)
    After each re-connect i get an new IPv6 address, and again after some days (30 days maybe, i havent checked for a long time)
    (This is a problem for me for some other services, but thats a different topic; My ISP gives static address only to business)

    Why automatic? Where is the connection between pd-only and that default route? (Why?)
    RA will add the default route ;
    ==> send packets to :: via device vlan2/ppp0 ==> I do not know how this would work?
    I think we agree that RA will add the default route right?

    ping6, downloading, surfing, test ipv6 sites, all is working

    Whats your ipv6 setup tvlz? :)
     
    Last edited: Nov 21, 2018
  74. M_ars

    M_ars Network Guru Member

    Yes, it is/was working as soon as the new default route was set. Lucky me :)
     
  75. Sean B.

    Sean B. LI Guru Member

    Right here. Note the section I underlined, and how the OP's traceroute address went from a full /128 in one prefix to a shorthand ::1 in a different prefix when the route was removed.. and how the section I underline discusses using ::1 and ::2 of first prefix for the link. An initial misconfiguration of the WAN ( link ) address and/or prefix leaving a faulty route, then being reconfigured correctly seems fitting, as just like in iptables rules the routes are a first match basis and the bad one will be used until removed.

    Note that the OP posted ifconfig of vlan2.. which has two global IPv6 addresses. That doesn't seem right, sense it's not a privacy address ( shown by the first 64bits are not the same ).

    An IA_NA assigns a known address to the WAN interface, and route aggregation is not an issue.

    5.2. Routing Aggregation of the Point-to-Point Links
    Following this approach and assuming that a shorter prefix is typically delegated to a customer, for example a /48, it is possible to simplify the routing aggregation of the point-to-point links. Towards this, the point-to-point link may be numbered using the first /64 of the /48 delegated to the customer.

    Let's see a practical example:



    • A service provider uses the prefix 2001:db8::/32 and is using 2001:db8:aaaa::/48 for a given customer.
    • Instead of allocating the point-to-point link from a different addressing pool, it may use 2001:db8:aaaa::/64 (which is the first /64 subnet from the 2001:db8:aaaa::/48) to number the link.
    • This means that, in the case the non-EUI-64 approach is used, the point-to-point link may be numbered as 2001:db8:aaaa::1/64 for the provider side and 2001:db8:aaaa::2/64 for the customer side.
    • Note that using the first /64 and interface identifiers 1 and 2 is a very common practice. However other values may be chosen according to each case specific needs.
    In this way, as the same address pool is being used for both, the prefix and the point-to-point link, one of the advantages of this approach is to make very easy the recognition of the point-to-point link that belongs to a given customer prefix, or in the other way around, the recognition of the prefix that is linked by a given point-to-point link.

    For example, making a trace-route to debug any issue to a given address in the provider network, will show a straight view, and it becomes unnecessary one extra step to check a database that correlate an address pool for the point-to-point links and the customer prefixes, as all they are the same.

    Moreover, it is possible to use the shorter prefix as the provider side numbering for the point-to-point link and keep the /64 for the customer side. In our example, it will become:



    • Point-to-point link at provider side: 2001:db8:aaaa::1/48
    • Point-to-point link at customer side: 2001:db8:aaaa::2/64
    This provides one additional advantage as in some platforms the configuration may be easier saving one step for the route of the delegated prefix (no need for two routes to be configured, one for the delegated prefix, one for the point-to-point link). It is possible because the longest-prefix-match rule.

    The behavior of this type of configuration has been successfully deployed in different operator and enterprise networks, using commonly available implementations with different routing protocols, including RIP, BGP, IS-IS, OSPF, along static routing, and no failures or interoperability issues have been reported.

    5.3. DHCPv6 Considerations
    As stated in [RFC3633], "the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which is received the DHCP message from the delegating router", however the approach described in this document is still useful in other DHCPv6 scenarios or non-DHCPv6 scenarios.

    Furthermore, [RFC3633] was updated by Prefix Exclude Option for DHCPv6-based Prefix Delegation ([RFC6603]), precisely to define a new DHCPv6 option, which covers the case described by this document.

    Moreover, [RFC3769] has no explicit requirement that avoids the approach described in this document.

    5.4. Router Considerations
    This approach is being used by operators in both, residential/SOHO and enterprise networks, so the routers at the customer end for those networks MUST support [RFC6603] if DHCPv6-PD is used.

    In the case of Customer Edge Routers there is a specific requirement ([RFC7084]) WPD-8 (Prefix delegation Requirements), marked as SHOULD for [RFC6603]. However, in an scenario where the approach described in this document is followed, together with DHCPv6-PD, the CE Router MUST support [RFC6603].
     
    Last edited: Nov 21, 2018
  76. M_ars

    M_ars Network Guru Member

    @Sean B. i cant follow (only partly)
    send packets to :: via device vlan2/ppp0 ==> I do not know how this would work?
    --> link local address
    Code:
    fe80::/64 dev ppp0  proto kernel  metric 256  mtu 1492 advmss 1432 hoplimit 0
    fe80::/10 dev ppp0  metric 1  mtu 1492 advmss 1432 hoplimit 0
    fe80::/10 dev ppp0  proto kernel  metric 256  mtu 1492 advmss 1432 hoplimit 0
    default via fe80::143:143:3e9b:f3a1 dev ppp0  proto kernel  metric 1024  expires 1704sec mtu 1492 advmss 1432 hoplimit 64
     
    Last edited: Nov 21, 2018
  77. Sinopsys

    Sinopsys Reformed Router Member

    Isn’t it formally said in: https://tools.ietf.org/id/draft-ietf-v6ops-rfc7084-bis-04.html#rfc.section.5.2
    At W-3 as bellow:

    5.2. WAN-Side Configuration
    The IPv6 CE router will need to support connectivity to one or more access network architectures. This document describes an IPv6 CE router that is not specific to any particular architecture or service provider and that supports all commonly used architectures.

    IPv6 Neighbor Discovery and DHCPv6 protocols operate over any type of IPv6-supported link layer, and there is no need for a link-layer-specific configuration protocol for IPv6 network-layer configuration options as in, e.g., PPP IP Control Protocol (IPCP) for IPv4. This section makes the assumption that the same mechanism will work for any link layer, be it Ethernet, the Data Over Cable Service Interface Specification (DOCSIS), PPP, or others.

    WAN-side requirements:

    W-1:
    When the router is attached to the WAN interface link, it MUST act as an IPv6 host for the purposes of stateless [RFC4862] or stateful [RFC3315] interface address assignment.
    W-2:
    The IPv6 CE router MUST generate a link-local address and finish Duplicate Address Detection according to [RFC4862] prior to sending any Router Solicitations on the interface. The source address used in the subsequent Router Solicitation MUST be the link-local address on the WAN interface.
    W-3:
    Absent other routing information, the IPv6 CE router MUST use Router Discovery as specified in [RFC4861] to discover a default router(s) and install a default route(s) in its routing table with the discovered router's address as the next hop
     
    M_ars likes this.
  78. Sean B.

    Sean B. LI Guru Member

    Code:
    /* Delete default interface route */
        if (proto == WP_PPTP || proto == WP_L2TP || (proto == WP_PPPOE && using_dhcpc(prefix))) {    /* Delete MAN default route */
            route_del(NULL, 0, NULL, NULL, NULL);
    ?????
     
  79. Sean B.

    Sean B. LI Guru Member

    That expired December 14, 2017
     
  80. M_ars

    M_ars Network Guru Member

    Code:
    Absent other routing information, the IPv6 CE router MUST use Router Discovery as specified in [RFC4861] to discover a default router(s) and install a default route(s) in its routing table with the discovered router's address as the next hop 
    that is what we must do, so no need to add any other default route
    Everything else is a workaround (and can be selected/enabled if the Tomato user wants/needs it)

    https://obviate.io/2010/07/09/ipv6-getting-functional-dhcpv6-and-route-advertising-together/

    BR
    M_ars
     
  81. tvlz

    tvlz LI Guru Member

    I am not surprised, @M_ars ISP is using a regular PPPoE connection on WAN and based on what I see @Sinopsys ISP (which won't tell what to use) is using a DHCP connection from the ONT to the router WAN port, but is using it like a PPPoE connection for IPv6 (PD Only), that why he does not need the default route for it to work.

    It looks like @pedro311 picked up the changes from @M_ars (https://bitbucket.org/pedro311/freshtomato-arm/commits/3f566a8ebf85290de436ec996a18ca9325fa62e2), I still think it is a bad idea to change a working config, it just complicates the setup, I mean it has worked this way for years why have it break for the people who need it requiring them to figure out what went wrong when they upgrade vs people who IPv6 never worked for them to begin with.

    I side with the people who have been using Tomato for years.

    I was hoping @Sinopsys would a least try that patch to see if it would work, that could be the solution for both.

    Now if you were replacing the outdated Wide-Dhcpv6 client with a newer updated/maintained one (https://github.com/openwrt/odhcp6c) I would have no problem with the changes as they would be needed.

    It doesn't affect me using a Comcast DCHPv6-PD connection

    Edit: add current odhcpv6 url
     
    Last edited: Nov 23, 2018
  82. Sinopsys

    Sinopsys Reformed Router Member

    What patch are you referring to? I’d be glad to test it!
    Your suggestion on odhcp6c is a great idea!!! It would compete with stock firmwares which most of them provides autoconf (guess by probing the various options).

    Regarding the current setup, isn’t it possible that it has been built incrementally with successive patches seeking for working solutions in different use cases and then keeping some previous pieces not needed anymore ?
    From my reading the current existing default route set seems to be relevant mainly on static setup with direct PtP links but shouldn’t be set for dynamic configs (can be wrong as I’m not any ipv6 black belt master).
     
  83. Sean B.

    Sean B. LI Guru Member

    I agree with @tvlz , changing things to make this case work is likely not a good idea. The OP's ISP is using a configuration that, while not against RFC's, is unorthodox. As tvlz pointed out, and something I looked right over, is this setup is usually used over the pppoe connections. His ISP should be using the ia-na+pd, IMHO.
     
  84. Sinopsys

    Sinopsys Reformed Router Member

    By curiosity I had a look on dd-wrt config and it is interesting:
    Code:
    static void start_wan6_done(char *wan_ifname)
    {
        if (nvram_matchi("ipv6_enable", 0))
            return;
    
        eval("ip", "-6", "addr", "flush", "scope", "global");
    
        if (nvram_match("ipv6_typ", "ipv6native")) {
            if (nvram_match("wan_proto", "disabled")) {
                sysprintf("echo 1 > /proc/sys/net/ipv6/conf/%s/accept_ra", nvram_safe_get("lan_ifname"));
            } else {
                sysprintf("echo 2 > /proc/sys/net/ipv6/conf/%s/accept_ra", wan_ifname);
            }
    
            char ip[INET6_ADDRSTRLEN + 4];
            const char *p;
            char addr6[INET6_ADDRSTRLEN];
    
            p = ipv6_router_address(NULL, addr6);
            if (*p) {
                snprintf(ip, sizeof(ip), "%s/%d", p, nvram_geti("ipv6_pf_len") ? : 64);
                eval("ip", "-6", "addr", "add", ip, "dev", nvram_safe_get("lan_ifname"));
            }
            if (nvram_match("wan_proto", "disabled")) {
                eval("ip", "route", "add", "::/0", "dev", nvram_safe_get("lan_ifname"), "metric", "2048");
            } else {
                eval("ip", "route", "add", "::/0", "dev", wan_ifname, "metric", "2048");
            }
        }
    
        if (nvram_match("ipv6_typ", "ipv6pd")) {
            sysprintf("echo 2 > /proc/sys/net/ipv6/conf/%s/accept_ra", wan_ifname);
            eval("stopservice", "dhcp6c", "-f");
            eval("startservice", "dhcp6c", "-f");
        }
    
        if (nvram_match("ipv6_typ", "ipv6in4")) {
            stop_ipv6_tunnel(wan_ifname);
            start_ipv6_tunnel(wan_ifname);
        }
    
        eval("stopservice", "dhcp6s", "-f");
        eval("startservice", "dhcp6s", "-f");
    
    }
    https://github.com/mirror/dd-wrt/blob/master/src/router/services/networking/network.c

    2 findings:
    - default route is set only for full native IPv6
    edit: only on the ipv4 part but works for my case
    - default route metric is set to 2048 so that the dynamic default route added with 1024 metric will be prioritised over initial one.
     
    Last edited: Nov 22, 2018
    M_ars likes this.
  85. M_ars

    M_ars Network Guru Member

    @tvlz sorry i have to disagree, your patch adds just a condition for DHCP. Really? Why only for DHCP?

    Please tell me why does my PPPoE setup need that default route?
    --> Again: IPv6 RA will do that for you/me
    --> that has nothing to do with pd-only

    My connection is up an running and i have a working default route
    Code:
    fe80::/64 dev ppp0  proto kernel  metric 256  mtu 1492 advmss 1432 hoplimit 0
    fe80::/10 dev ppp0  metric 1  mtu 1492 advmss 1432 hoplimit 0
    fe80::/10 dev ppp0  proto kernel  metric 256  mtu 1492 advmss 1432 hoplimit 0
    default via fe80::143:143:3e9b:f3a1 dev ppp0  proto kernel  metric 1024  expires 1591sec mtu 1492 advmss 1432 hoplimit 64
    DHCP on sinopsys side does not need it
    PPPoE on my side does also not need it

    Do you need it?

    Back in 2015 shibby did the same thing and added an option to choose. I aligned to that.

    https://repo.or.cz/tomato.git/commi...8?hp=702656bbf29da99a633e0a35e79c971343047b63

    Toastman also removed it:
    Code:
                    break;
            case IPV6_NATIVE_DHCP:
    -//             eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname);  //removed by Toastman
    -//      see discussion at http://www.linksysinfo.org/index.php?threads/ipv6-and-comcast.38006/
    -//             post #24 refers.
    +               if (nvram_get_int("ipv6_isp_opt") == 1) {
    +                       eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname);
    +               }


    Then a few month later your patch was added.

    You wrote by your self: "Add default route to DHCPv6-PD for misconfigured ISPs, if needed"

    https://repo.or.cz/tomato.git/commit/27aceeeea27ca0adf5a48ee16c9eb8cfe0adafab

    So again. Why do you want to add that route by default? I do not need it.
    I am also a long time Tomato user.

    BR
    M_ars
     
    Last edited: Nov 22, 2018
  86. tvlz

    tvlz LI Guru Member

    In post #65
    As Sinopsy said his ISP will not work with that default route there, yours will
    Have you been having problems with IPv6 over the years, if not why change?
    But PPPoE in other countries(AUS,NZ) with different ISP do, why force them to figure out why their IPv6 is now broken when they update?
    I could also say that is what others did (Asuswrt/Merlin, Openwrt) before they changed to odhcp6c

    Yeah, I wrote that when I was trying to get IPv6 to work, Have you never made notes to yourself?

    Time to see what @kille72 and @pedro311 think?
     
  87. tvlz

    tvlz LI Guru Member

    @M_ars
    One more thing can you tell us what problems you are having with IPv6 that make this change required or is it just something you feel like changing?
     
  88. Sinopsys

    Sinopsys Reformed Router Member

    I try first @M_ars with little additional patch:
    Code:
    1109,1110c1109,1114
    <         if (nvram_get_int("ipv6_pdonly") == 1) {
    <             eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname);
    ---
    >         /* IPv6 RA (via WAN) will take care of adding the default route, so that ipv6_isp_opt should not be enabled/required!
    >            BUT: some ISP's, Snap (NZ), Internode (AU) may need the default route / workaround --> Tomato User can decide
    >            see also https://www.linksysinfo.org/index.php?threads/ipv6-and-comcast.38006/
    >         */
    >         if (nvram_get_int("ipv6_isp_opt") == 1) {
    >             eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname, "metric", "2048");
    It works properly with ipv6_isp_opt set to either 0 or 1.

    For sure post #65 will also work but why tying the ipv6 config with a ipv4 parameter that isn't involved in ipv6 config ?
     
    M_ars likes this.
  89. Sinopsys

    Sinopsys Reformed Router Member

    It might be already very clear for you guys, but for me it wasn't and I found at least an explanation why this default route was breaking the routing in my setup while not blocking M_ars's one : https://community.cisco.com/t5/switching/ipv6-default-route-with-outgoing-interface/td-p/2793613

    As stated: "Defining routes out interfaces is only suitable for point-to-point interfaces such as tunnels or serial interfaces using HDLC or PPP."

    Which is not my case with the ONT that behave as a router: as spotted by @tvlz

     
  90. M_ars

    M_ars Network Guru Member

    I think Tomato user can figure it out, if they need to activate something or not. Its just one click.

    By default, nobody should need that workaround. (route is provided with IPv6 RAs)

    I see it different, sorry. I like it to have a choise and do not force everyone.

    BR
    M_ars
     
    Last edited: Nov 24, 2018
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice