tunnelbroker Tunnelbroker Timeout on XR500

[GoalTV]

Hello,

 

I have recently bought NetGear XR500 and I ran into issue with tunnelbroker

I'm routing IPv6 threw Raspberry PI based on this guide https://www.raspberrypi.org/forums/viewtopic.php?t=88054

However I no longer can get IPv6 connection no matter of the settings even with DZM enabled to my PI I just get timeout like some firewall is blocking it on router side.

If I connect my old ISP router it works no problem so not sure what I'm doing wrong as even radvd cannot connect with XR500

I tried every signgle option in Advanced Settings to enable IPv6 but even without it I still should get PI working itself with IPv6.

 

Did anyone was successful with setting tunnelbroker on this router as I'm out of ideas even created new tunnel to make sure old one didn't brake anything.

[Netduma Fraser]

Hey, welcome to the forum!

Try disabling QoS completely and see if that helps. It may be blocking the connections.

[GoalTV]

Hello,

 

Thank you I have tried to disable QoS but not luck, I also tried upgrade to 3.0 firmware but I got same results.

even tried set dmz which seems not working or don't have any effect at all.

So I guess based on this IPv6 Tunnels are not supported on XR500.

Noticed some few bugs with 3.0 to disable QoS you need reboot the router else after few minutes the button to disable won't save.

 

Well I guess I will try due it via Hybrid VPN maybe as solution to this.

[Netduma Fraser]

Just to double check did you disable QoS from the Anti-Bufferbloat/Congestion Control 3 line option menu? As you're on the beta in Traffic Controller make a rule for the Pi to allow ALL traffic and see if that helps. 

[GoalTV]

Hello,

I have tried do the Traffic Controller rule for all however no luck.

If I'm correct QoS can be disabled in

QoS

>

Congestion Control

>

Disable QoS

Not Recommended

 

if so I have done it but  based on these error below I will do factory reset tonight as maybe upgrade to 3.0 did mess up something around fomr 2.x.

(I have hidden some IPs with * on the start and Mac Addresses hidden)

[DumaOS] Error parsing line in ARP table: 'fe80::86e:c59b:d926:278c dev br0 lladdr [Mac-Hidden] REACHABLE', Friday, October
[DumaOS] Error parsing line in ARP table: 'fe80::a9bf:2adb:469f:71ab dev br0 lladdr [Mac-Hidden] REACHABLE', Friday, Octobe
[DumaOS] Error parsing line in ARP table: 'fe80::192:168:1:100 dev br0 lladdr [Mac-Hidden] router STALE', Friday, October 3
[DumaOS] Error parsing line in ARP table: 'fe80::ca94:da42:aeb6:e64d dev br0 lladdr [Mac-Hidden] REACHABLE', Friday, Octobe
[DumaOS] Error parsing line in ARP table: '*:*:*:0:c9bd:fe2f:efcb:3ea dev br0 lladdr [Mac-Hidden] STALE', Friday, 
[DumaOS] Error parsing line in ARP table: 'fe80::e9a2:9a8:e90:6e1 dev br0 lladdr [Mac-Hidden] STALE', Friday, October 30, 2
[DumaOS] Error parsing line in ARP table: '*:*:*:0:e9a2:9a8:e90:6e1 dev br0 lladdr [Mac-Hidden] STALE', Friday, Oc
[DumaOS] Error parsing line in ARP table: 'fe80::ba27:ebff:febc:b4f dev br0 lladdr [Mac-Hidden] router STALE', Friday, Octo
[DumaOS] Error parsing line in ARP table: 'fe80::9c9f:51d4:791b:3cc9 dev br0 lladdr [Mac-Hidden] DELAY', Friday, October 30
[LAN access from remote] from *.*.30.13:65109 to 192.168.1.100:5632, Friday, October 30, 2020 14:45:26
[DumaOS] RPC call 'disabled' exception 'ERROR: Rule not found in chain stack traceback: ^I?: in function '__new__' ^I?: in func,
[DumaOS] Long call 'del_rule' exception 'ERROR: Rule not found in chain stack traceback: ^I?: in function '__new__' ^I?: in fun,
[DumaOS] RPC call 'set_dpi_settings' exception 'ERROR: Rule not found in chain stack traceback: ^I?: in function '__new__' ^I?, 
[DumaOS] Long call 'del_rule' exception 'ERROR: Rule not found in chain stack traceback: ^I?: in function '__new__' ^I?: in fun,
[DumaOS] RPC call 'set_dpi_settings' exception 'ERROR: Rule not found in chain stack traceback: ^I?: in function '__new__' ^I?, 
[DumaOS] Long call 'del_rule' exception 'ERROR: Rule not found in chain stack traceback: ^I?: in function '__new__' ^I?: in fun,
[DumaOS] config write 'com.netdumasoftware.qos.settings', Friday, October 30, 2020 14:45:22
[DumaOS] pausing 'auto_hyperlane', Friday, October 30, 2020 14:45:22
[DumaOS] RPC call 'auto_hyperlane' exception 'ERROR: Rule not found in chain stack traceback: ^I?: in function '__new__' ^I?: i,
[DumaOS] Long call 'del_rule' exception 'ERROR: Rule not found in chain stack traceback: ^I?: in function '__new__' ^I?: in fun,
[DumaOS] RPC call 'disabled' exception 'ERROR: Rule not found in chain stack traceback: ^I?: in function '__new__' ^I?: in func,
[DumaOS] Long call 'del_rule' exception 'ERROR: Rule not found in chain stack traceback: ^I?: in function '__new__' ^I?: in fun,
[DumaOS] RPC call 'set_dpi_settings' exception 'ERROR: Rule not found in chain stack traceback: ^I?: in function '__new__' ^I?, 
[DumaOS] Long call 'del_rule' exception 'ERROR: Rule not found in chain stack traceback: ^I?: in function '__new__' ^I?: in fun,
[DumaOS] RPC call 'set_dpi_settings' exception 'ERROR: Rule not found in chain stack traceback: ^I?: in function '__new__' ^I?, 
[DumaOS] Long call 'del_rule' exception 'ERROR: Rule not found in chain stack traceback: ^I?: in function '__new__' ^I?: in fun,

 

[Netduma Fraser]

Factory reset is a definite good first step as quite a lot will have changed in the firmware. Let us know how that goes and in the meantime I'll try to think about what else could be causing it.

[GoalTV]

Hello,

 

I did reset router to Factory Reset sadly no progress on this.

 

 

I talked with Tunnelbroker and Respond I got is:

 

The tcpdump logs show only outbound, not inbound which would indicate that something is blocking Protocol-41 traffic from reaching the raspi.

You may want to check your router to see if there's an option in the firewall.

[Zippy]

@Netduma Fraser  Not sure if this is the cause for the Op but I figured id share one of my findings..

  One cant always disable QoS from the three line option.. The only way I could get it to fully disable and stay disabled was doing a factory reset and clear all browser cache and cookies. Then very quickly go into the QoS three line and disable it. One has to do this rather quickly or it wont disable. Ive tested this several times.. And thats the only way to accomplish this. Its possible this is happening with the Op and QoS might be what is blocking his tunnel broker.. One will know real quick if they have successfully disabled QoS completely and to test this all one has to do is navigate away from the QoS page then come back to it.. If it is successfully disabled one will be greeted by a pop up saying all QoS is disabled.. This should pop up every time one comes back to the QoS page there forward until one reenables it.. Once QoS is completely disabled check and see if your tunnel broker works then..

That might be why his tunnel broker isnt working.. Not sure but its worth a shot!

Thanks!

Zippy.

 

[Netduma Fraser]

As well as the above, in WAN Settings switch NAT to Open. That makes it a less restrictive firewall and so may help.