Thanks Giancarlo, I appreciate the recommendation to use ifstated. I'd used it in the past years for something at a job I was working at that I cannot remember what it was now, but it worked good.
I do however understand the importance of reporting any regression as soon as it is noticed, but I have to admit the first time I noticed it, I wasn't sure if it was a one off incident and back then where I lived my cable service was regrettably more reliable than it is now (the crap shoot that is moving). Now that my service goes out more often and/or I've needed to restart my firewall or certain services to debug other issues, I've seen the issue arise enough to confirm that there is indeed an issue with rtadvd. In once case, a simple reboot caused rtadvd to come up before the prefix was assigned via my DHCPv6 client. rtadvd did not pickup the prefix dynamically and was refusing to advertise it until I restarted it. In another case, the same DHCPv6 client was restarted, and I forgot to restart rtadvd and the internal interface had it's old prefix removed and and new one added. rtadvd continued advertising the old prefix which was now unroutable. It neither was able to detect that the old prefix was removed and retire it in it's RAs, nor detect that a new prefix was added and start advertising it. I pulled up the man page for it just to confirm that the previous behavior of being able to auto detect prefixes assigned to the monitored interface was normal behavior. I came to that conclusion because there is a flag ( -s ) you can use to call rtadvd with to prevent it from dynamically advertising prefixes and only use statically setup prefixes (presumably from the config file, of which I have no need of currently). I am willing to file a bug report even if it's a little late. What do I need to do to help out. I don't know much C/C++ but I can help wherever possible. And many thanks to both of you Giancarlo and Martin for replying. I understand that IPv6 is not yet very popular or used yet, so that functionality of OpenBSD isn't likely to get much attention. Therefore I don't mind helping to debug this issue any way I can. Btw, I confirmed that rtadvd had no knowledge of the changes to the prefixes assigned to the monitored interface by doing as the man page suggests and sending a SIGUSR1 to the pid and saw the output in /var/log/daemon where it was showing outdated prefix information. If I were to best guess it, it stopped working sometime in 2014 (I was still living at my old residence where I had much more stable service). I usually update within a month of release, so that would mean it stopped working in either 5.5 or 5.6 as it was not working in 5.7 and is still not working in 5.8. Sly On 11/09/2015 11:21 AM, Giancarlo Razzolini wrote: > Em 09-11-2015 13:52, Martin Pieuchot escreveu: >> As soon as you notice a regression please try to notify us. I'm sorry >> to say so, but we don't have the manpower to dig for a regression that >> might have happen since "a couple of releases". > I know Martin. For me it is not a regression, because I only recently, > ie, OpenBSD 5.8, started using it with IPv6 enabled CPE's. I'm working > on a very detailed bug report, I think I found a routing bug regarding > IPv6, I'll test on -current later this week. As soon as I have all the > info, I'll post to tech@. What I can talk right now is that, on OpenBSD > 5.8-stable, if you have a interface with inet6 autoconf enabled, you > aren't able to use manual configuration on any other interface (ULA > addressing). The routes simply vanish right after they are added. I > confirmed this behaviour with route monitor. > >> One of the reason we ask for a dmesg is that we can easily identify when >> things broke. We try the best we can not to break things, but sometimes >> it is hard. Sorry for that. > I was just confirming to the OP that I too had seen this behaviour. > Every time I've stumbled upon what I suspect might be a regression or a > bug I try to make sure before I report, but I always report them. So far > this happened only once on OpenBSD. > >> Now if you prefer to cook your own workaround, that's up to you > I don't like to cook workarounds, but sometimes they are necessary. In > my case I need to monitor changes so I can update DNS records, I was > just extending that so the OP could do another thing (restart rtadvd). I > don't know anything that could be done in my case, since my ISP and CPE > will change the prefix anytime the CPE restarts or the CPE connection to > the ISP is lost. > > Cheers, > Giancarlo Razzolini
