vr600v2 - Suddenly only the IPV6-compatible internet is reachable for me
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Good evening,
I have issues with my router and his connection to the internet. The service provider is o2 telefonica germany and i have a classic VDSL 50 mbit connection.
I can't reach ip adresses via IPV4(http(e.g. amazon twitch), ssh etc.), IPV6 is no problem(e.g. youtube.com or this beautiful website).
I updated to the most recent firmware for my router model, but its still not working.
I contaced the service provider today, they said everything is fine - i'm visible from the outside with an IPV4 and a IPV6 address - and i should contact the router manufacturer.
whatismyipaddress dot com tells me
IPv6:
show my ipv6 address
IPv4:
Not detected
I've used the ISP profile 'O2_VDSL(über Telekom)' and can establish a PPPoE connection despite the internet status under the Basic-Tab telling me the the detection fails following a 'Disconnected' Status. On the other hand, the DSL status under the Advanced-Tab shows a established connection(Line staus: Connected).
I guess the reason for the output in the Basic-Tab is the followin, if i refresh the failed connection there it produces more ncsi lookups which fail the same way
2020-10-28 19:38:17 [6] Httpd: DNS 2a01:c30::530 resolve succeed for dns.msftncsi.com
2020-10-28 19:38:17 [6] Httpd: DNS 2a01:c30::530 resolve timeout for www.msftncsi.com
2020-10-28 19:38:17 [6] Httpd: DNS 2a01:c30::531 resolve succeed for dns.msftncsi.com
2020-10-28 19:38:17 [6] Httpd: DNS 2a01:c30::531 resolve timeout for www.msftncsi.com
2020-10-28 19:38:20 [6] Httpd: DNS 62.109.121.2 resolve succeed for dns.msftncsi.com
2020-10-28 19:38:20 [6] Httpd: DNS 62.109.121.2 resolve succeed for www.msftncsi.com
2020-10-28 19:38:22 [4] Httpd: receive TCP packet failed for NCSI response
dns.msftncsi.com is reachable via IPV6, www.msftncsi.com not - checked that via nslookup
What i've tried:
- newest firmware and the one before
- changing the default isp dns addresses to googles
- factory reset
- disabled the IPV6 support in the wan interface via Advanced - Network - Internet, obviously afterwards i even weren't able to reach the ipv6 supporting websites aswell
Diagnostics output:
Test xDSL Synchronization Pass
Test WAN Connection Pass
Network Connection Status Inspect (NCSI) Fail
Diagnostics completed
example tracert to heise.de
C:\Users\user>tracert -6 heise.de
Tracing route to heise.de [2a02:2e0:3fe:1001:302::]
over a maximum of 30 hops:
1 <1 ms 1 ms <1 ms dynamic-2a01-0c22-721e-2701-b2be-76ff-fe6e-9a64.c22.pool.telefonica.de [2a01:c22:721e:2701:b2be:76ff:fe6e:9a64]
2 12 ms 12 ms 13 ms 2a02:3001::133
C:\Users\user>tracert -4 heise.de Tracing route to heise.de [193.99.144.80]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms ARCHER_VR600V [192.168.1.1]
2 * * * Request timed out.
complete system log attached
anyone?
small update, i finally convinced the isp to open a technical issue in their ticket system on friday after i've bought a fritzbox 7530 which had actually the same issues.
it was closed on saturday with 'no technical issues found for the connection'.
I have still the same issue with 3 different devices (windows, linux and android) and i can't think of anything which could cause that on my side with two different modems/routers and 3 different devices having the same issue.
The fritzbox shows established connections for IPV4 & IPV6, and i have public addresses for both. I guess their mechanism to check if the connection is established is different to the one which the archer vr600v uses(NCSI).
tracert to ipv4-only hosts even works sometimes now, i e.g. can tracert superuser.com.
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 8 ms 7 ms 9 ms loopback1.0001.acln.04.muc.de.net.telefonica.de [62.52.193.159]
3 8 ms 8 ms 8 ms bundle-ether8.0001.dbrx.04.muc.de.net.telefonica.de [62.53.18.41]
4 15 ms 15 ms 14 ms ae2-0.0001.corx.04.muc.de.net.telefonica.de [62.53.5.58]
5 15 ms 15 ms 14 ms ae20-0.0002.corx.02.fra.de.net.telefonica.de [62.53.5.83]
6 16 ms 15 ms 15 ms bundle-ether1.0003.dbrx.02.fra.de.net.telefonica.de [62.53.14.163]
7 16 ms 16 ms 16 ms bundle-ether1.0005.prrx.02.fra.de.net.telefonica.de [62.53.10.51]
8 15 ms 15 ms 15 ms fra1.decixfra.fastly.net [80.81.195.54]
9 16 ms 16 ms 15 ms 151.101.65.69
i also have done some inspections with wireshark and witnessed retransmissions/duplicate ack packages during tsl connection establishing, seems like its a specific issues with ipv4 and the establishment of the tsl connection which leads to a fail during the handshake mechanism.
I'm a little bit lost, give me a hint :)
The attached screenshot is a wireshark capture while trying to browse superuser.com
