[FS#1002] Dns ipv6 problem when interface restart

[LEDE Bugs]

The following task has a new comment added:

FS#1002 - Dns ipv6 problem when interface restart
User who did this - Mathias Kresin (mkresin)

----------
> But with tim we need to have 2 pppoe to actually have dual stack (or phone gets only ipv6 traffic but no ipv4, can't underestand why) 

I'm doubt that you need a 2nd ppp connection. You have already a working dual stack.

The only issue I see is that you only get a /64 prefix from your provider. Means, only **one** network can have IPv6. In your case the prefix is assigned to the guest network instead of the lan.

However, providers are advised to assign something like a /56 prefix to customers, which would allow to have 256 /64 networks. Seem to me TIM has a different opinion what is good for their customers.

If you talk about "phone", you mean a wireless client connected to the lan network?

>  Aaand now that i restarted the interface to tcpdump... I got the problem... 

What does interface restart means? which commands do you run? What I can see in your 2nd ifstatus wan6 output is that your prefix is gone. The usual command to down/up an (logical) interface is ifdown wan6/ifup wan6.

IN your package capture one can see that your router asks for DHCPv6 informations (Solicit), Tim response to the requests (Advertise) and offers all the time the same /64 prefix 2a01:2000:2001:e0a4:: with a lifetime of only 360 sec. What I'm somehow missing are the DHCPv6 Request package from your router. Might be these requests are not required if the prefix doesn't change. But could be a bug as well. Would you please check if your prefix disappears after 360sec or whether your valid counter jumps back to 360.

What furthermore is strange that ifstatus wan6 shows 2a01:2000:2001:e09c:: as your received prefix instead.

Could it be that you still have an interface which I do not know about. Would your please paste the output of "ubus list network.interface.*"
----------

More information can be found at the following URL:
https://bugs.lede-project.org/index.php?do=details&task_id=1002#comment3444