You may need to disable the other default WAN connections (xDSL, PPPoE etc.).

No luck I had deleted all the WAN connections and made a new one for it. 

@Madbushman considering there’s no limitations in this case with PPPoE just use that. The HG659 has PPPoE offloading and it is the better protocol to be using here. 

@michaelmurfy awesome thanks will do 

I had put off changing to DHCP because I thought it would require some work. I just switched my router's (RT-AC68U) WAN connection type from PPPoE to Automatic IP, changed nothing else, and it just works. Very nice. 

Plx: Hi. Is there any noticeable benefit to be gained with DHCP if you're on the Walker (50/10) plan? Thanks

From a change management and customer perspective opt in is better. End of the day the company changed something and it had an impact. Short of them having tried their router on a DHCP and PPOE ISP they would know? (idk if there are even any that offer dual methods)

Even an opt in, and then we'll make it auto opt in a month later would have avoided issues.

I got bit by it too and only knew it had happened due to the post here announcing it. An email out would have been helpful, to support the post it was being rolled out on the status page.

I think @quic as they rapidly mature should hear that feedback as it's valid, and shouldn't be brushed away because.. were a light touch or technical focussed ISP. 

@theviper Regardless, you'll still experience issues. What about those customers who want DHCP and don't figure out it's opt-in? What about existing customers? Having a "I have problems, opt out" button is the better option to opting in. So far, there has only been a very small number of routers with issues. The Eero just sounds like a terrible router.

michaelmurfy:

 

@theviper Regardless, you'll still experience issues. What about those customers who want DHCP and don't figure out it's opt-in? What about existing customers? Having a "I have problems, opt out" button is the better option to opting in. So far, there has only been a very small number of routers with issues. The Eero just sounds like a terrible router.

 

I'm looking at this from a service management perspective.

I disagree, I'd rather not have problems and have to opt out, but opt in and be aware of the risks and have the problems on my terms and time frames.

What's good though is people did have issues and shared which helped others :). Opt in or not that's why we're all here to share.

theviper: I disagree, I'd rather not have problems and have to opt out, but opt in and be aware of the risks and have the problems on my terms and time frames.

That's the point. More problems can occur with an opt-in. The idea here is the majority of routers will work with with their default configuration given there is basically no risk but a couple of routers (Asus and the Eero) in this case is not a reason to enforce an opt-in for any future customers who otherwise won't have any issues.

Quic have the Asus problem documented on their support page but being a self service ISP with BYOD routers there is always a chance you'll experience problems with some routers:

michaelmurfy:

 

theviper: I disagree, I'd rather not have problems and have to opt out, but opt in and be aware of the risks and have the problems on my terms and time frames.

 

That's the point. More problems can occur with an opt-in. The idea here is the majority of routers will work with with their default configuration given there is basically no risk but a couple of routers (Asus and the Eero) in this case is not a reason to enforce an opt-in for any future customers who otherwise won't have any issues.

 

Quic have the Asus problem documented on their support page but being a self service ISP with BYOD routers there is always a chance you'll experience problems with some routers:

 

 

I'm with theviper.

All existing connections should of been opt in, not opt out. For new connections I can understand having both (dual stack), but changing existing customers over to a system which is known to have issues with certain routers is a recipe for disaster. Personally I would much prefer it if you specified DHCP or PPPoE manually on your connection.

Why not start from a point of stability and let people move when they're ready? Most consumers wont miss being on PPPoE rather than DHCP, especially when they were on PPPoE. They will however be concerned if their internet not working. 

As I've posted in another thread.

I was forced to move to DHCP/IPoE yesterday when I got authentication errors on PPPoE.

Then I noticed there are a couple of sites cannot be reached.

For example:

Site below can be connected.

>tracert 51.81.2.58

  1     *        *        *     Request timed out.
  2    <1 ms    <1 ms    <1 ms  192.168.1.250
  3     2 ms     2 ms     2 ms  bng1-akl1.vetta.net [103.243.102.32]
  4     3 ms     2 ms     2 ms  xe1-2100-146.pe2-akl1.vetta.net [103.243.102.96]
  5     2 ms     2 ms     2 ms  xe1-2100-402.core1-akl1.vetta.net [103.243.102.133]
  6     *        *        *     Request timed out.
  7   133 ms   132 ms   133 ms  et-0-2-8.atc-p-3.as55850.net [116.251.184.43]
  8   144 ms   142 ms   142 ms  ovh.as16276.any2ix.coresite.com [206.72.210.214]
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12   194 ms   194 ms   194 ms  was-nva1-sbb1-nc5.va.us [178.32.135.161]
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18   195 ms   195 ms   195 ms  ip58.ip-51-81-2.us [51.81.2.58]

While:

> tracert 51.81.2.60

Tracing route to ip60.ip-51-81-2.us [51.81.2.60]
over a maximum of 30 hops:

  1     *        *        *     Request timed out.
  2    <1 ms    <1 ms    <1 ms  192.168.1.250
  3     3 ms     2 ms     2 ms  bng1-akl1.vetta.net [103.243.102.32]
  4     3 ms     3 ms     2 ms  xe1-2100-146.pe2-akl1.vetta.net [103.243.102.96]
  5     1 ms     2 ms     2 ms  xe1-2100-401.core1-akl1.vetta.net [103.243.102.131]
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.

Failed.

Checked MTU settings, I think it was all set to 1500, and I was getting MTU 1492 when running PPPoE. 

Also checked the same site using phone's hotspot.

.\mturoute.exe 51.81.2.60
* ICMP Fragmentation is not permitted. *
* Speed optimization is enabled. *
* Maximum payload is 10000 bytes. *
+ ICMP payload of 1472 bytes succeeded.
- ICMP payload of 1473 bytes is too big.
Path MTU: 1500 bytes.

All good.

Quite bit of sites have similar problems.

Anyone else experiencing the same problems?

i'm in wgtn, somethings up but i also got issues at work so will have another look later if no one jumps in and explains it.

[pc@snakedog:~]$ traceroute 51.81.2.60
traceroute to 51.81.2.60 (51.81.2.60), 30 hops max, 60 byte packets
 1  _gateway (192.168.1.1)  0.318 ms  0.285 ms  0.264 ms
 2  bng1-akl1.vetta.net (103.243.102.32)  12.256 ms  12.233 ms  12.240 ms
 3  xe1-2100-146.pe2-akl1.vetta.net (103.243.102.96)  12.562 ms  13.296 ms  12.681 ms
 4  xe1-2100-402.core1-akl1.vetta.net (103.243.102.133)  12.255 ms  12.008 ms  12.171 ms
 5  * * *
 6  et-0-2-8.atc-p-3.as55850.net (116.251.184.43)  141.728 ms  144.247 ms  144.204 ms
 7  ovh.as16276.any2ix.coresite.com (206.72.210.214)  155.018 ms  153.514 ms  153.484 ms
 8  * * *
 9  * * *
10  * * *
11  was-cva1-sbb1-nc5.va.us (178.32.135.156)  206.537 ms  203.705 ms  205.402 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

[pc@snakedog:~]$ mtr -wr 51.81.2.60
Start: 2024-03-13T17:41:10+1300
HOST: snakedog.kaseus.net               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- _gateway                           0.0%    10    0.5   0.4   0.3   0.6   0.1
  2.|-- bng1-akl1.vetta.net                0.0%    10   14.3  13.1  11.4  14.6   1.1
  3.|-- xe1-2100-146.pe2-akl1.vetta.net    0.0%    10   12.0  13.4  12.0  14.8   1.0
  4.|-- xe1-2100-402.core1-akl1.vetta.net  0.0%    10   12.4  12.9  11.1  14.7   1.1
  5.|-- ???                               100.0    10    0.0   0.0   0.0   0.0   0.0
  6.|-- et-0-2-8.atc-p-3.as55850.net       0.0%    10  144.3 142.5 140.9 144.3   1.2
  7.|-- ovh.as16276.any2ix.coresite.com    0.0%    10  152.7 152.6 150.7 154.7   1.2
  8.|-- ???                               100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- ???                               100.0    10    0.0   0.0   0.0   0.0   0.0
 10.|-- ???                               100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- was-nva1-sbb1-nc5.va.us            0.0%    10  203.8 205.1 203.8 206.8   1.1
 12.|-- vl1333.was1-vin1-g2-nc5.wa.us     60.0%    10  208.6 207.6 206.5 208.6   0.9
 13.|-- ???                               100.0    10    0.0   0.0   0.0   0.0   0.0
 14.|-- ???                               100.0    10    0.0   0.0   0.0   0.0   0.0
 15.|-- ???                               100.0    10    0.0   0.0   0.0   0.0   0.0
 16.|-- ???                               100.0    10    0.0   0.0   0.0   0.0   0.0
 17.|-- ip60.ip-51-81-2.us                 0.0%    10  206.5 205.7 203.9 207.4   1.2

p.s looks like traceroute with UDP fails, TCP succesfull.

p.p.s tcp and udp traceroute to 8.8.8.8 fails, icmp traceroute works, no idea...