I made another attempt and briefly removed “Rapid Commit”. Server got (but FB didn’t use it) and further solicitations are not successful (probably because the DHCP server thinks - “it already has everything, leave me alone”).. I think an AVM Support case is worth it.. you may be able to say why the advertisement is not being processed. It’s also interesting that the FB keeps using the same XID.
I can’t imagine that IPv6 native should only work with a Swisscom router or requires activation from a Swisscom router.
I can’t imagine how you come up with that statement without any facts.
Small update: I would stop all attempts. Doesn’t do anything. It’s the holidays and I can imagine that the topic will be looked at internally at SC at the beginning of 2023.
Would you like to tell us how you came to this turnaround?
Since IPv4 works, the 10 FRITZ!Box customers will continue to be able to surf the Internet.
This evening I spent some time thinking about what to do with this statement. Correct. V4 was already working in May when I started this thread. That’s not the point. I want to get V6 working. Since May 2022 and not just at the beginning of 2023. But apparently I’m a little impatient?
I don’t know how their super users work. I’m just a simple engineer who wants to improve the world. Part of my job is to program errors, find them and fix them. And I’m still interested in a win-win situation. Together with my customers.
So and the counter-argument would be:
“It would be nice to hear something relevant from the operator, I’m hardly the only one with a third-party router on the network!? I’ll also do a nice know-how article - like that in return / win-win situation. ”
You can forget about the deal, Swisscom understandably does not provide support for third-party routers.
It is foreign to me to change your worldview here. Mine has changed a lot over the course of this discussion/thread. Maybe I didn’t always write the right words. Was tendentious or impatient. However, tonight I am one step further away from a cemented attitude towards knowledge, insight, progress. (Goes to bed shaking his head.)
I hope we can focus on the technical topics again tomorrow.
Goodnight community.
@wwe wrote:
but the Wireshark trace showed an exciting difference: the first solicitation without RC got an advertisement from the DHCP server (but FB didn’t use it) and further solicitations are not successful (probably because the DHCP server thinks - “it already has everything, leave me alone”).
@wwe: Thanks for the info! 🤩If you like, you can copy/send the SOLICIT request(s) to me in a PM. I would like to look at them and examine them for differences. Or just post it here anonymously, as I did. Then we find out:
I think we’re getting further in this puzzle game step by step.
Goodnight.
🙋♂️
@andiroid How do I arrive at my statements? He’s good.
Of course you can keep experimenting. It won’t do anything. The topic has been deposited with the right person and they will look at it after the Christmas holidays. And just enjoy the contemplative time and watch cat videos, or something like that.
@ChristianEb wrote:
Seems as if v6 has to be activated via the router GUI, without this this service doesn’t seem to work for third-party routers either, at least that’s my guess.
I think we still have overlapping problems. The F-bus from @wwe gets answers, but something “confused”. 🙂 Mine is desperately shouting packages into the ether and getting no answers. I think we can confirm this by analyzing the SOLICIT packages.
Think of two variants: attach the SCS “router” to the access, pair it, and activate the option, and then connect the FB again and pair it…
I’ll try this work-around. I’ll be getting glass (or plastic?) soon. And a new router.
I have another emergency idea, but it would be a bit breakneck and would require another access line that can be tinkered with…
Craft!? You’ve gotten over the warm-up and are pretty much in nerd mode. Exactly to my liking!
😁
Ernst: What do you mean by customizable access line? I mean, if it’s a temporary attempt without major collateral damage, I’ll make myself available. The rainy days literally invite you to do crafts. If I have to go back to the tunnels, I can no longer do that due to time constraints.
🫡
@wwe wrote:
I made another attempt and briefly removed “Rapid Commit”. Got DHCP server (but FB didn’t use it) and further solicitations are not successful (probably because the DHCP server thinks - “it already has everything, leave me alone”)
@wwe: Thanks for the log files sent via PM.
1) I don’t see any difference in your packages and mine. I think we agreed on that. Schälterli. Thank you to everyone who contributed to this. Both here and there. 😉
2) The question of why the frit drops the ADVERTISE packet could be answered with Rule 1 in the [DHCPv6 standard](https: //datatracker.ietf.org/doc/html/rfc8415). The received packet contains a ServerIdentifier, but the type is “Unknown”. I have no idea whether that is reason enough to discard the package.
I also came across the operational models in the standard in [Chapter 6](http://Operational%20Models). Essentially these are Stateless, [Non-temporary](https://datatracker.ietf.org/doc/html/rfc8415 #section-6.2) and DHCP for prefix Delegation.
3) We also don’t yet have a hypothesis as to which method will be used to assign IPv6 later. We are missing a clear trace. But that could possibly lead to a reliable answer from the log files from “over there” more quickly than with huge data dumps from the frit. 😉
I think that we are one step further and that an error in the Fritzbox still cannot be ruled out. But I can’t find any indication in the SOLICIT package (or in the standard you skimmed) that could influence RA behavior. I’m curious to see what else @wwe can report on the feedback from Berlin.
Hi @andiroid, thank you for sharing the AC of your connection with me, as mentioned in the direct messages, at least in the last 15 days I have not seen any radius information that would show an ipv6 delegated prefix. which led me to my assumption that I wrote yesterday.
If possible, I would like to take another look at the Pcap you drew,
Greeting
Chris
Swisscom Network Engineer IP+ AS3303,
@ChristianEb wrote:
As mentioned in the direct messages, at least in the last 15 days, I have not seen any radius information that would show an ipv6 delegated prefix. which led me to my assumption that I wrote yesterday.
Hey @ChristianEb, thank you very much for your efforts! 🎖️ Ultimately, you confirm to me that we are talking about two overlapping problems. I really appreciate your proactive communication!
I further assume that a (proprietary?) protocol is used with the IBs to enable v6 to be switched on. If someone from the RES CPE/Provisioning team knows more, I would also submit a feature request to AVM. (But that would be a one-off solution and other routers would have the same problem…)
🤔
If possible, I would like to take another look at the Pcap you drew
Are there any initial findings yet, or are you (or the team of specialists) still figuring it out?
😉
I have now also made a packet dump! Another wonderful feature of the F-Büxe! Can the I-buses do that too?
No, the IB can’t do that and doesn’t have to be able to do it.
I don’t want to add fuel to the fire or troll you. But the capture feature of the WAN interface has shown us that it is sometimes essential to understand why the end devices behave differently. (Comparing IB and FB might have saved us some time?) It’s precisely because of these nice features that I’d rather not give away my fry.
😇
Hi @andiroid, I don’t think that a proprietary protocol is being used here. I assume that a request is sent to a tool from the Gui, which then enables a toolchain to activate a service on a single access line or, in your case, to have it deactivated.
for your thanks, gladly. I can see the need for people to like using their own hardware on an Access, this sometimes has advantages and occasionally also big disadvantages (like in this one here…)
Greeting
Chris
Swisscom Network Engineer IP+ AS3303,
@ChristianEb wrote:
Hi @andiroid, I don’t think that a proprietary protocol is being used here. I assume that a request is sent to a tool from the Gui, which then enables a toolchain to activate a service on a single access line or, in your case, to have it deactivated.
Hey @ChristianEb! Understand. 😉 Okay, if this is a REST API that handles standardized HTTP(S) requests, the protocol is of course not yet proprietary. But since nothing is known about the specific implementation, I would stick with proprietary. 😇
I was thinking more about a method for operating the peeler, which has been standardized using RFC-wxyz and which AVM could replicate. I don’t really believe that such a suggestion will be implemented… 🙁
Conclusion: I understand the problem. In the case of a connection with deactivated IPv6 and without temporary access to an IB, there is currently no solution. In my case it’s not that bad because I’ll be getting glass and then probably a new IB soon. I’ll leave it like that.
Thank you again @ChristianEb for the great support!
🍾
Hello to everyone constructively involved!
With the help of @ChristianEb we found out that the FB set with the settings from post #57 generates a DHCPv6 “Solicit” that has DHCP options 3 (IA_NA) and 25 (IA_PD) **at the same time* * contains:
Currently the SCS infrastructure doesn’t seem to tolerate this well.. (to the trolls: sending both options at the same time is RFC compliant).. But SCS only wants one of the two options at the same time..
I carried out tests with different Fritzbox settings and found out that FB can generate a DHCP request with option 25 and without option 3 with the following settings:
This contradicts the online help from AVM and at first showed no difference - no IPv6 prefix. However, due to the intervention of AVM support, I updated my FB 7583 from 7.29 to 7.31.. and was surprised to find that the FB * *got an IPv6 prefix immediately after the reboot**!
The update to 7.31 has been available for a while but it has not yet been found automatically for me.
I am sure that an update to 7.31 is not necessary and I suspect that the settings also work with 7.29. I would be happy if someone with FB 7.29 can confirm these settings
- “use native IPv6”
- derive global address using assigned prefix
-rapid commit
work and the IPv6 prefix is obtained immediately after reboot/reconnect.
Counter-testing with 7.31 and the settings from post #57 resulted in the well-known error “No response from DHCPv6 server (SOL)”.. the correct behavior could only be achieved after applying the above-mentioned settings and DSL separation.
Important note: if the FB has created “incorrect” DHCP requests (and it does this every minute), in my opinion new solicitation requests are blocked/ignored by the SCS backend for a certain time.. and you have to **after correct settings* * are configured, disconnect the box from the DSL for about 90 seconds - then IPv6 works very quickly as soon as the DSL connection is established or “Reconnect” is pressed… and instead of after x hours as before…
A fix should be rolled out in February that should then be able to handle both options at the same time on the network side, so the issue in question should improve soon.
Was happy to be able to watch captures with @wwe and @andiroid. (A slightly different leisure activity again)
Greeting
Chris
Swisscom Network Engineer IP+ AS3303,
In the meantime I received some information from AVM. With v7.50 - currently available for 7590 and will be available in the future for many important fries such as 7583 and even 7490 - IPv6 profiles are changing. Unfortunately I don’t know the details, but there is hope that in the future you will get the right settings “automatically” after selecting the Swisscom provider. I will report as soon as v7.50 comes out for my 7583.
I’ve had absolutely no problems with IPv6 in the meantime.. feels the internet is a little more “responsive” now - but that could also be my imagination, especially after a few weeks of inexplicable phenomena after IPv6 failure and days of “messing around” on Anschluss with unstable config..
@cybi wrote:
OK, I’ve done it now. With the same result.
Internet connection IPv6 could not be established: No response from DHCPv6 server (SOL)
Absolute gut feeling: I think you have the same problem as me. See conclusion in post above. That’s still the status quo here for me. The short error message (No response from DHCPv6 server) from the event monitor is the clue that the packages are validly sent by the frit but do not receive a valid response from the Swisscom backend. The analysis of my Wireshark traces at the beginning of the year clearly showed this. Therefore the strong suspicion that you have the same cause. I still have the FW version 07.29, actually 07.50 should be released soon for my classic car, maybe some dark magic will happen from AVM then. A straw. 😇
Hypothesis about the cause: I assume that I was playing around with IPv6 with my last IB and I didn’t get static IPv6. (I think that was before the time of 6th, a few years ago…) Because it was “unsuccessful”, I deactivated it again and in the meantime got the SIP credentials and removed the IB from the configuration - and disposed of it. In this respect, v6 was validly deactivated in the SC backend and can no longer be activated with the FritzBox alone. 😉
If you still have the IB, you could: Connect the IB temporarily, activate it, switch on v6, reactivate Fritzbox. Then you would also have to get IPv6 with the Fritzbox. As I said, this is a theory that has not yet been substantiated. And because my glass may not be finished so quickly, confirmation is still a long way off. 🙁
Äs Greetings
Android
👽
