This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] New Document: "IPv6 Troubleshooting for Residential ISP Helpdesks"
- Previous message (by thread): [ipv6-wg] New Document: "IPv6 Troubleshooting for Residential ISP Helpdesks"
- Next message (by thread): [ipv6-wg] New Document: "IPv6 Troubleshooting for Residential ISP Helpdesks"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Niall O'Reilly
niall.oreilly at ucd.ie
Sun Oct 26 18:52:41 CET 2014
At Sun, 26 Oct 2014 08:35:17 -0700, Jason Fesler wrote: > > On Sunday, October 26, 2014, Niall O'Reilly <niall.oreilly at ucd.ie> > wrote: > > * Failed connect to ipv6.test-ipv6.ceengine.eu:80; Connection > refused > > As soon as I can get near a real computer I'll do a fresh audit and > disable/contact broken sites. I'll also put more thought into how to > export the data needed to a nagios plugin to catch issues quicker. Great! Thanks for the speedy response, Jason. Thinking a bit more, I have the idea that some more thought is needed about how the script running in the browser interprets failure to retrieve any of the target resources. In the case mentioned, it looks as if application error HTTP 404 is being interpreted as indicating IPv6 network target unreachable. Isn't this a layering misinterpretation? ATB Niall
- Previous message (by thread): [ipv6-wg] New Document: "IPv6 Troubleshooting for Residential ISP Helpdesks"
- Next message (by thread): [ipv6-wg] New Document: "IPv6 Troubleshooting for Residential ISP Helpdesks"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]