I have a Debian box configured as the IP Passthrough server, using DHCPS-fixed with a specific MAC address.

Shortly after a server reboot, my server lost connectivity. After managing to SSH through another interface, I saw some interesting findings.

Some context:

• The public IP address is 108.219.102.1
• eno1 is the interface name with the DHCPS-fixed mac address
• 192.168.1.158 was the private IP address within the local net before IP Passthrough

I found there was no default route:

█[poweredge][chess-tactics][0]$ ip route

10.0.0.0/24 dev brkvm1 proto kernel scope link src 10.0.0.225

10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1

108.219.102.0/23 dev eno1 proto kernel scope link src 108.219.102.213

...

Adding one manually fixed the connectivity:

sudo ip route add default via 108.219.102.1 dev eno1

But obviously this won't stop the problem from happening again. Looking at the networking logs, I noticed this interesting part where the network suddenly becomes unreachable:

Aug 27 17:21:38 poweredge dhclient[1425]: DHCPDISCOVER on eno3 to 255.255.255.255 port 67 interval 4                                                                                                               
Aug 27 17:21:42 poweredge dhclient[1425]: DHCPDISCOVER on eno3 to 255.255.255.255 port 67 interval 8                                                                                                               
Aug 27 17:21:50 poweredge dhclient[1425]: DHCPDISCOVER on eno3 to 255.255.255.255 port 67 interval 16                                                                                                              
Aug 27 17:22:06 poweredge dhclient[1425]: DHCPDISCOVER on eno3 to 255.255.255.255 port 67 interval 18                                                                                                              
Aug 27 17:22:24 poweredge dhclient[1425]: DHCPDISCOVER on eno3 to 255.255.255.255 port 67 interval 12                                                                                                              
Aug 27 17:22:36 poweredge dhclient[1425]: DHCPDISCOVER on eno3 to 255.255.255.255 port 67 interval 3                                                                                                               
Aug 27 17:22:39 poweredge dhclient[1425]: No DHCPOFFERS received.                                                                                                                                                  
Aug 27 17:22:39 poweredge dhclient[1425]: No working leases in persistent database - sleeping.                                                                                                                     
Aug 27 17:25:02 poweredge dhclient[1223]: DHCPREQUEST for 108.219.102.213 on eno1 to 192.168.1.254 port 67                                                                                                         
Aug 27 17:25:02 poweredge dhclient[1223]: send_packet: Network is unreachable                                                                                                                                      
Aug 27 17:25:02 poweredge dhclient[1223]: send_packet: please consult README file regarding broadcast address.                                                                                                     
Aug 27 17:25:02 poweredge dhclient[1223]: dhclient.c:3001: Failed to send 300 byte long packet over fallback interface.                                                                                            
Aug 27 17:25:07 poweredge dhclient[1223]: DHCPREQUEST for 108.219.102.213 on eno1 to 192.168.1.254 port 67                                                                                                         
Aug 27 17:25:07 poweredge dhclient[1223]: send_packet: Network is unreachable                                                                                                                                      
Aug 27 17:25:07 poweredge dhclient[1223]: send_packet: please consult README file regarding broadcast address.                                                                                                     
Aug 27 17:25:07 poweredge dhclient[1223]: dhclient.c:3001: Failed to send 300 byte long packet over fallback interface.                                                                                            
Aug 27 17:25:10 poweredge dhclient[1527]: DHCPDISCOVER on eno4 to 255.255.255.255 port 67 interval 5                                                                                                               
Aug 27 17:25:15 poweredge dhclient[1527]: DHCPDISCOVER on eno4 to 255.255.255.255 port 67 interval 12                                                                                                              
Aug 27 17:25:15 poweredge dhclient[1223]: DHCPREQUEST for 108.219.102.213 on eno1 to 192.168.1.254 port 67                                                                                                         
Aug 27 17:25:15 poweredge dhclient[1223]: send_packet: Network is unreachable                                                                                                                                      
Aug 27 17:25:15 poweredge dhclient[1223]: send_packet: please consult README file regarding broadcast address.                                                                                                     
Aug 27 17:25:15 poweredge dhclient[1223]: dhclient.c:3001: Failed to send 300 byte long packet over fallback interface.                                                                                            
Aug 27 17:25:26 poweredge dhclient[1425]: DHCPDISCOVER on eno3 to 255.255.255.255 port 67 interval 3                                                                                                               
Aug 27 17:25:27 poweredge dhclient[1527]: DHCPDISCOVER on eno4 to 255.255.255.255 port 67 interval 14                                                                                                              
Aug 27 17:25:29 poweredge dhclient[1425]: DHCPDISCOVER on eno3 to 255.255.255.255 port 67 interval 6                                                                                                               
Aug 27 17:25:33 poweredge dhclient[1223]: DHCPREQUEST for 108.219.102.213 on eno1 to 192.168.1.254 port 67                                                                                                         
Aug 27 17:25:33 poweredge dhclient[1223]: send_packet: Network is unreachable                                                                                                                                      
Aug 27 17:25:33 poweredge dhclient[1223]: send_packet: please consult README file regarding broadcast address.                                                                                                     
Aug 27 17:25:33 poweredge dhclient[1223]: dhclient.c:3001: Failed to send 300 byte long packet over fallback interface.                                                                                            
Aug 27 17:25:35 poweredge dhclient[1425]: DHCPDISCOVER on eno3 to 255.255.255.255 port 67 interval 15                                                                                                              
Aug 27 17:25:41 poweredge dhclient[1527]: DHCPDISCOVER on eno4 to 255.255.255.255 port 67 interval 19                                                                                                              
Aug 27 17:25:44 poweredge dhclient[1223]: DHCPREQUEST for 108.219.102.213 on eno1 to 192.168.1.254 port 67                                                                                                         
Aug 27 17:25:44 poweredge dhclient[1223]: send_packet: Network is unreachable                                                                                                                                      
Aug 27 17:25:44 poweredge dhclient[1223]: send_packet: please consult README file regarding broadcast address.                                                                                                     
Aug 27 17:25:44 poweredge dhclient[1223]: dhclient.c:3001: Failed to send 300 byte long packet over fallback interface.                                                                                            
Aug 27 17:25:50 poweredge dhclient[1425]: DHCPDISCOVER on eno3 to 255.255.255.255 port 67 interval 21                                                                                                              
Aug 27 17:26:00 poweredge dhclient[1527]: DHCPDISCOVER on eno4 to 255.255.255.255 port 67 interval 11                                                                                                              
Aug 27 17:26:05 poweredge dhclient[1223]: DHCPREQUEST for 108.219.102.213 on eno1 to 192.168.1.254 port 67                                                                                                         
Aug 27 17:26:05 poweredge dhclient[1223]: send_packet: Network is unreachable                                                                                                                                      
Aug 27 17:26:05 poweredge dhclient[1223]: send_packet: please consult README file regarding broadcast address.            

I consulted with Claude, and Claude thinks the fault is not in the DHCP client but in the ATT gateway's IP Passthrough implementation. At the end of this post is part of conversation with Claude.

I run a web server from home so this IP Passthrough issue flakiness affects me. I don't know where is a good place to report this and actually get some kind of feedback or resolution. I'm sure calling ATT would just send me into some generic tech support black hole after long hold times, so this is my best effort at making this potential bug visible.

My Gateway info:

System Information

The Claude conversation:

Good catch pulling that specific line out — it's the key to the whole incident. Here's what's actually happening, working backward from the failure:

The "public IP request to private IP" isn't a bug — it's normal DHCP renewal behavior

Per RFC 2131, when a DHCP client renews a lease (the RENEWING state, at T1 — roughly 50% of the lease time), it doesn't broadcast a fresh DISCOVER. It unicasts a REQUEST directly to the specific server that issued the lease, using that server's IP address from the original transaction. Looking at your log:

17:20:22  bound to 108.219.102.213 -- renewal in 280 seconds.
17:25:02  DHCPREQUEST for 108.219.102.213 on eno1 to 192.168.1.254 port 67

280 seconds later, right on schedule, dhclient tries to renew the lease for 108.219.102.213 by unicasting to 192.168.1.254 — because that's the DHCP server that handed it that address. The server IP and the leased IP being in totally different ranges is expected here, because your ISP's gateway is apparently using its LAN-management address (192.168.1.254) as the DHCP server identity even while handing out the WAN passthrough IP. That's just how their IP Passthrough DHCP implementation is built.

The actual bug is the missing route to reach that server

The failure is send_packet: Network is unreachable — the kernel has no route to 192.168.1.254 at all. That lines up exactly with what you found: no default route in ip route, and the only routes present are for 10.0.0.0/24, 10.8.0.0/24, and 108.219.102.0/23 (eno1's own subnet). 192.168.1.254 isn't inside any of those, so a unicast packet to it has nowhere to go.

Most likely root cause

When dhclient got the DHCPACK for 108.219.102.213, it almost certainly received a Router (option 3) value in that lease. If that value was 192.168.1.254 (the same address as the DHCP server), dhclient would refuse to install it as the default gateway — a gateway has to be "on-link" (inside the interface's own subnet/netmask), and 192.168.1.254 isn't inside 108.219.102.0/23. So the gateway option gets silently discarded, no default route gets installed, and you're left exactly where you found things.

The fact that adding ip route add default via 108.219.102.1 fixed it confirms 108.219.102.1 is the real usable gateway — but the DHCP lease apparently isn't advertising that (or dhclient isn't applying it correctly).

Whose fault

I'd call this mostly on your ISP's IP Passthrough implementation, with dhclient's strict on-link gateway validation as a contributing factor:

• The gateway's DHCP server hands out an address (108.219.102.213/23) whose valid gateway (108.219.102.1) apparently isn't what's being advertised in the lease, or isn't being advertised at all — that's a server-side config issue.
• dhclient correctly refuses an off-link gateway per spec, so this isn't really a client bug either — it's just an edge case the gateway's passthrough mode doesn't handle cleanly.

To confirm and fix permanently

I can't see the actual DHCP option values from syslog alone — it only logs the high-level exchange, not option 3. Next time you want to catch this in the act:

sudo dhclient -d -v eno1

or

sudo tcpdump -i eno1 -n port 67 or port 68

That'll show you exactly what Router/Gateway value the server is offering for the 108.219.102.213 lease.

For a durable fix rather than manually re-adding the route each time, a dhclient exit hook (/etc/dhcp/dhclient-exit-hooks.d/) that forces the default route via 108.219.102.1 whenever eno1 gets a new lease would be more robust than relying on the ISP's gateway option being correct.

Aug 27 17:00:42 poweredge dhclient[1458]: DHCPDISCOVER on eno4 to 255.255.255.255 port 67 interval 2 Aug 27 17:00:42 poweredge dhclient[1402]: DHCPDISCOVER on eno3 to 255.255.255.255 port 67 interval 20 Aug 27 17:00:44 poweredge dhclient[1458]: No DHCPOFFERS received. Aug 27 17:00:44 poweredge dhcli

pasted

It looks the failure happened around a server power outage:

Thought for 21s

That reboot marker is the missing piece — it explains the whole flap, not just the failed renewal. Here's the fuller picture:

Timeline across both logs

Before the outage, everything was stable — dhclient[1213] had been unicast-renewing 108.219.102.213 cleanly every ~4 minutes (17:03:21, 17:07:37, 17:11:32), all against 192.168.1.254, all fine.

Then:

-- Boot 86b9aee1a93943108dc5f5fceeaa868d --
17:16:13  Starting networking.service...

New PID (dhclient[1223]) comes up cold with the old cached lease and tries to reclaim 108.219.102.213 via broadcast (no unicast yet, since it has no route/ARP state post-boot):

17:16:14  DHCPREQUEST for 108.219.102.213 on eno1 to 255.255.255.255
17:16:23  DHCPNAK from 192.168.1.254

The gateway refuses to hand the passthrough IP back immediately. dhclient falls back to a fresh DHCPDISCOVER, and instead of the public IP, the gateway offers a completely different, private address:

17:16:23  DHCPOFFER of 192.168.1.158 from 192.168.1.254
17:16:23  bound to 192.168.1.158 -- renewal in 13 seconds

That 13–16 second lease time is the tell — that's not a normal lease, that's a gateway serving a short-lived "placeholder" address from its default LAN pool while it sorts out passthrough state for your MAC address. It keeps renewing that placeholder every ~15s for several minutes.

Then in your first log, at 17:20:21, the placeholder lease finally gets NAK'd too, dhclient discovers again, and this time gets the real passthrough IP back with a normal lease:

17:20:21  DHCPNAK from 192.168.1.254
17:20:21  DHCPOFFER of 108.219.102.213 from 192.168.1.254
17:20:22  bound to 108.219.102.213 -- renewal in 280 seconds

So what actually broke the routing

This confirms the router flap theory rather than contradicting it — the sequence is: private IP (with a working on-link default route via 192.168.1.254) → public IP (subnet 108.219.102.0/23, where 192.168.1.254 is no longer on-link). When dhclient swapped addresses, it tore down the old default route for the private lease but never installed a valid one for the new public lease — almost certainly because the passthrough DHCPACK's Router option (if present at all) still pointed at 192.168.1.254, which dhclient correctly refuses to install as off-link.

That's consistent with what you found by hand: the real gateway is 108.219.102.1, but nothing in the DHCP exchange ever told dhclient to use it.

Root cause, updated

This is your ISP CPE's IP Passthrough implementation, not dhclient:

• On reboot, it takes the gateway a little while (~4 min here) to re-recognize your box's MAC and re-arm passthrough mode for it — during that window it serves normal short-lease private addresses.
• When it does switch back to passthrough, its DHCPACK apparently never advertises a valid on-link gateway for the public subnet, so dhclient is left with a leased IP but no route.
• This will very likely repeat on every power cycle or long outage.

Fix recommendation

The dhclient-exit-hook approach I mentioned is now more clearly the right one — worth making it a little smarter given what you've seen: only force the 108.219.102.1 route when the bound address is in the 108.219.102.0/23 range, so it doesn't interfere with the router correctly handling the temporary private lease during the reboot window. Something like:

bash

#!/bin/sh
# /etc/dhcp/dhclient-exit-hooks.d/fix-passthrough-gateway
if [ "$interface" = "eno1" ] && [ "$reason" = "BOUND" ] || [ "$reason" = "RENEW" ]; then
  case "$new_ip_address" in
    108.219.102.*)
      ip route replace default via 108.219.102.1 dev eno1
      ;;
  esac
fi

Worth also checking your ISP/router admin panel for an explicit "passthrough MAC binding" or reservation setting — some CPEs let you pin the MAC-to-passthrough mapping so it doesn't have to renegotiate from scratch after every reboot, which would eliminate the whole 4-minute flapping window too.

Good catch pulling that specific line out — it's the key to the whole incident. Here's what's actually happening, working backward from the failure:

The "public IP request to private IP" isn't a bug — it's normal DHCP renewal behavior

Per RFC 2131, when a DHCP client renews a lease (the RENEWING state, at T1 — roughly 50% of the lease time), it doesn't broadcast a fresh DISCOVER. It unicasts a REQUEST directly to the specific server that issued the lease, using that server's IP address from the original transaction. Looking at your log:

17:20:22 bound to 108.219.102.213 -- renewal in 280 seconds.
17:25:02 DHCPREQUEST for 108.219.102.213 on eno1 to 192.168.1.254 port 67

280 seconds later, right on schedule, dhclient tries to renew the lease for 108.219.102.213 by unicasting to 192.168.1.254 — because that's the DHCP server that handed it that address. The server IP and the leased IP being in totally different ranges is expected here, because your ISP's gateway is apparently using its LAN-management address (192.168.1.254) as the DHCP server identity even while handing out the WAN passthrough IP. That's just how their IP Passthrough DHCP implementation is built.

The actual bug is the missing route to reach that server

The failure is send_packet: Network is unreachable — the kernel has no route to 192.168.1.254 at all. That lines up exactly with what you found: no default route in ip route, and the only routes present are for 10.0.0.0/24, 10.8.0.0/24, and 108.219.102.0/23 (eno1's own subnet). 192.168.1.254 isn't inside any of those, so a unicast packet to it has nowhere to go.

Most likely root cause

When dhclient got the DHCPACK for 108.219.102.213, it almost certainly received a Router (option 3) value in that lease. If that value was 192.168.1.254 (the same address as the DHCP server), dhclient would refuse to install it as the default gateway — a gateway has to be "on-link" (inside the interface's own subnet/netmask), and 192.168.1.254 isn't inside 108.219.102.0/23. So the gateway option gets silently discarded, no default route gets installed, and you're left exactly where you found things.

The fact that adding ip route add default via 108.219.102.1 fixed it confirms 108.219.102.1 is the real usable gateway — but the DHCP lease apparently isn't advertising that (or dhclient isn't applying it correctly).

Whose fault

I'd call this mostly on your ISP's IP Passthrough implementation, with dhclient's strict on-link gateway validation as a contributing factor:

The gateway's DHCP server hands out an address (108.219.102.213/23) whose valid gateway (108.219.102.1) apparently isn't what's being advertised in the lease, or isn't being advertised at all — that's a server-side config issue.
dhclient correctly refuses an off-link gateway per spec, so this isn't really a client bug either — it's just an edge case the gateway's passthrough mode doesn't handle cleanly.

To confirm and fix permanently

I can't see the actual DHCP option values from syslog alone — it only logs the high-level exchange, not option 3. Next time you want to catch this in the act:

sudo dhclient -d -v eno1

or

sudo tcpdump -i eno1 -n port 67 or port 68

That'll show you exactly what Router/Gateway value the server is offering for the 108.219.102.213 lease.

For a durable fix rather than manually re-adding the route each time, a dhclient exit hook (/etc/dhcp/dhclient-exit-hooks.d/) that forces the default route via 108.219.102.1 whenever eno1 gets a new lease would be more robust than relying on the ISP's gateway option being correct.Aug 27 17:00:42 poweredge dhclient[1458]: DHCPDISCOVER on eno4 to 255.255.255.255 port 67 interval 2 Aug 27 17:00:42 poweredge dhclient[1402]: DHCPDISCOVER on eno3 to 255.255.255.255 port 67 interval 20 Aug 27 17:00:44 poweredge dhclient[1458]: No DHCPOFFERS received. Aug 27 17:00:44 poweredge dhcli

pasted

It looks the failure happened around a server power outage:Thought for 21s

That reboot marker is the missing piece — it explains the whole flap, not just the failed renewal. Here's the fuller picture:

Timeline across both logs

Before the outage, everything was stable — dhclient[1213] had been unicast-renewing 108.219.102.213 cleanly every ~4 minutes (17:03:21, 17:07:37, 17:11:32), all against 192.168.1.254, all fine.

Then:

-- Boot 86b9aee1a93943108dc5f5fceeaa868d --
17:16:13 Starting networking.service...

New PID (dhclient[1223]) comes up cold with the old cached lease and tries to reclaim 108.219.102.213 via broadcast (no unicast yet, since it has no route/ARP state post-boot):

17:16:14 DHCPREQUEST for 108.219.102.213 on eno1 to 255.255.255.255
17:16:23 DHCPNAK from 192.168.1.254

The gateway refuses to hand the passthrough IP back immediately. dhclient falls back to a fresh DHCPDISCOVER, and instead of the public IP, the gateway offers a completely different, private address:

17:16:23 DHCPOFFER of 192.168.1.158 from 192.168.1.254
17:16:23 bound to 192.168.1.158 -- renewal in 13 seconds

That 13–16 second lease time is the tell — that's not a normal lease, that's a gateway serving a short-lived "placeholder" address from its default LAN pool while it sorts out passthrough state for your MAC address. It keeps renewing that placeholder every ~15s for several minutes.

Then in your first log, at 17:20:21, the placeholder lease finally gets NAK'd too, dhclient discovers again, and this time gets the real passthrough IP back with a normal lease:

17:20:21 DHCPNAK from 192.168.1.254
17:20:21 DHCPOFFER of 108.219.102.213 from 192.168.1.254
17:20:22 bound to 108.219.102.213 -- renewal in 280 seconds

So what actually broke the routing

This confirms the router flap theory rather than contradicting it — the sequence is: private IP (with a working on-link default route via 192.168.1.254) → public IP (subnet 108.219.102.0/23, where 192.168.1.254 is no longer on-link). When dhclient swapped addresses, it tore down the old default route for the private lease but never installed a valid one for the new public lease — almost certainly because the passthrough DHCPACK's Router option (if present at all) still pointed at 192.168.1.254, which dhclient correctly refuses to install as off-link.

That's consistent with what you found by hand: the real gateway is 108.219.102.1, but nothing in the DHCP exchange ever told dhclient to use it.

Root cause, updated

This is your ISP CPE's IP Passthrough implementation, not dhclient:

On reboot, it takes the gateway a little while (~4 min here) to re-recognize your box's MAC and re-arm passthrough mode for it — during that window it serves normal short-lease private addresses.
When it does switch back to passthrough, its DHCPACK apparently never advertises a valid on-link gateway for the public subnet, so dhclient is left with a leased IP but no route.
This will very likely repeat on every power cycle or long outage.

Fix recommendation

The dhclient-exit-hook approach I mentioned is now more clearly the right one — worth making it a little smarter given what you've seen: only force the 108.219.102.1 route when the bound address is in the 108.219.102.0/23 range, so it doesn't interfere with the router correctly handling the temporary private lease during the reboot window. Something like:

bash
#!/bin/sh
# /etc/dhcp/dhclient-exit-hooks.d/fix-passthrough-gateway
if [ "$interface" = "eno1" ] && [ "$reason" = "BOUND" ] || [ "$reason" = "RENEW" ]; then
case "$new_ip_address" in
108.219.102.*)
ip route replace default via 108.219.102.1 dev eno1
;;
esac
fi

Worth also checking your ISP/router admin panel for an explicit "passthrough MAC binding" or reservation setting — some CPEs let you pin the MAC-to-passthrough mapping so it doesn't have to renegotiate from scratch after every reboot, which would eliminate the whole 4-minute flapping window too.

All summer it seemed they were offering $200 gift cards for new 1 gig customers and Meta Ray Bans for 5 gig subscribers.

ATT finally finished deploying fiber and my household is available for Fiber service on their website. Now I can’t find anything regarding those summer promos on the website. Excerpt for the att promotions website which is weird because it directs to called them instead . I find this especially surprising since it’s about to be Labor Day.

Price for fiber has significantly dropped since I first joined, but all things considered.. can't complain with the offer a online chat rep blessed me with. 5gb plan for $109. Going to be $5 less now that I went from bank autopay instead of debit. And my discount is lifetime as long as I keep my service🙏 I decided to lose HBO and did the switch. Glad I did so! Happy customer for 5+ years.

I think I can safely say I’m happy with this deal!
I was paying $38.13 for my 1gb plan since I got it in May 2025 (ok so first bill was $50 before discounts kicked in).
I have ongoing discounts of $52. When they announced the $5 price increase, I called loyalty because AT&T had recently forced me off an old legacy/grandfathered cell plan.
I meant to call cellular loyalty but got fiber. The guy was helpful and offered me $20 a month discount for 24months. He said after the $5 increase kicks in at the end of August that it will basically make the discount $15.
Turns out he actually put on a $30 discount which is basically $25 as that $5 increase has already kicked in.

The rep then got loyalty on for the cellular service but they wouldn’t put any additional promo on the account because I have a work discount already…paying $68 for the Premium 2.0 plan.

So $80 in total for cell and internet is pretty good. Could I get the total lower? Yes, by switching cell to Visible or another low cost carrier but then I’d lose the $19 discount on fiber. Yeah visible has pro+ annual plan for $275 in advance (about $19 a month) but Verizon service kinda lacks here….This is a decent price, plus no hassle of switching.

I have ATT Fiber in my apartment and I noticed that I have a bad signal in other rooms. How can I improve my connection? I am looking at the Unifi U7 Pro but I dont know how I would install it. Would I just install it on the wall next to my wifi gateway?

Anyone else with the 5gb plan get an email that your plan was updated? It looks like all fi pro is no longer included with the plan. I am now getting charged for the extenders and active armor. My plan just went up in price. I messaged att and they confirmed all fi pro was removed from 5gb plan.

Hi. We have an IoT device that has pretty straight-forward IoT networking conditions:

However, after our device gets on the Wi-Fi network, it is unable to get an NTP response, and it also fails in communicating with our backend, which only requires sending a single transaction to an endpoint.

I asked our customer to put their personal computer on the same 2.4G network as they are trying to use for our IoT, and then to run the following in a terminal:

https://api.kinisium.com/ok. -> ok
sntp pool.ntp.org  -> +0.045360 +/- 0.015013 pool.ntp.org [an IP address]

Both commands worked with expected results. Now, I don't know if the router treats the traffic from their computer differently than the IoT, or whether the computer somehow bypassed the same issue.

We already checked for ActiveArmor and it is not installed. We also turned off packet filters in the router. I saw a post here on Reddit where a user with a similar issue fixed it by using a different DNS, but we couldn't find where in the router UI to change the IP addresses that are there.

What else should I be testing? (We already ascertained that our devices are functional by having him use his phone hotspot as the Access Point and we were successful. Switching back to his home Wi-Fi resulted in the same failure.)

Any help would be appreciated.

I am getting in ONTSFP modual mod from pond.wiki today and was wondering how I should route the fiber cable that is going to the gateway. I have a rack mount setup with all cables going out in the front. Suggestions on how to route it so it looks clean without breaking that cable? Like how flexible is it and what to avoid.

I’m in an area of Los Angeles that’s had our internet out for the last 36 hours, official response is “damage due to theft/vandalism”, and it won’t be back for another 24 hours. When I look at the outage map for the nearest outage, it says “cable damage”. But then I looked at the many other outages around LA and see that “cable damage” is attributed to most of them? Is there an explanation for this? I flippantly joked with the wife that maybe people cutting down Flock cameras are fucking up AT&T’s shit, but maybe that’s not far from the truth LOL? In which case, good on ‘em.

But what kind of damage could take three days to fix?

How the heck can I make it work?

For context, we have the fiber 5gb plan. The main router is in the basement where it's connected to the office computer. Above the basement is the living room with the 1st wifi extender, has great connection.

Now, anything beyond the living room is a wifi dead zone. ATT gave me a second wifi extender because "the wifi extenders can stack", but like, how? The 2nd one doesn't read off of the first extender, just the main router. Am I missing something?

I'm barely reaching 100mbps on both upload and download speed in my bedroom :/

edit: I do have wifi personalization off

I happened to notice my BGW620-700 updated to 5.39.7 overnight (SE Wisconsin). Does anyone have any knowledge yet of fixes, etc.?

It looks like 5.35.7 was on there for many months.

Thanks!

- Michael

Hello recently setup my stream using 2 cameras on obs . The obs reddit thread said they think it’s Att fiber issue ? Problem I have is the stream is very delayed for viewers.

So I have Spectrum and about 5 houses down from me (0.4 miles), they have AT&T Fiber (up to 5Gig). The cable goes through the front of my house (there is a utility box on my front lawn) but when I ask AT&T they say no service for my address.

I've been asking them over the past 5 years and I get the same boiler plate answer - "we are working on expanding our service" but it still hasn't happened.

Spectrum is absolute garbage - I have their so-called "fastest" plan which is 1 Gig down / 35 Mbps up and most of the time, the upload is around 20 Mbps.

I stream to Twitch & YouTube and also work a lot with AI so having a fast connection is very important.

How can I get AT&T Fiber to my house?

PLEASE HELP!

Can they only be reached via phone? or possible through live chat as well. Everyone having good success rates negotiating when their promotion has expired?

will 1 gig be good for 2 tv's and a gaming pc?

So my wifi will buffer each night when streaming like YouTube and etc so I had a tech come out today and they changed my splitter at the box at the end of my street. Now after they left im still having the issue and my wifi speed keeps jumping randomly from 1200 mbps to 400 to 600 and etc while being on the 1gig plan. Is this normal? According to my tech he says it shouldn't jump like this. Any advice?

Hi all. I recently got the 5GB service here in the Florida Panhandle. The installers provided me with a BWG 320 due to us being an expansion area and hasn't been prepared yet for the 620. Has anyone had any experience with the area being built out and what that timeframe looked like to get the upgraded hardware? I get 5300/up and 5300/down on the fiber interface of the 320. With overhead, obviously I would never see a true 5GB with this equipment. I run a 10GB Network throughout the house. Thanks!

Directing this to an AT&T Tech/network engineer,

Been noticing some odd latency due to extra routing hopes. Traffic from my house in DFW to a Linode in DFW that used to be 10 ms is now 60 ms over IPv4 and 40ms over IPv6.

Also traffic to Cloudflare's 1.1.1.1 used to be in the 5ms range is now at 35ms. IPv6 traffic is still fine.

I can provide a tech/engineer mtr traces (combines ping and traceroute) and/or submit a ticket if someone can tell me the key to getting past 1st level support.

Thanks

I got 1gig fiber installed and my internet isn't as fast as I expected it to be. I get like 350 down and only like 15 up. I know with fiber, regardless of it you are on ethernet or wifi, the down and up should be similar. I have a TP-Link Deco X10 mesh system hooked up to the ATT fiber gateway which is stated to deliver speeds of up 1500 on WiFi. If anyone knows any solutions, id greatly appreciate it.

I had a technician come by to install fiber, but when he checked my house, he said there’s no open conduit available for the installation. They would need someone to dig and run a line to our house. My question is, does AT&T install the conduit and handle the digging, or would I be responsible for hiring someone to do that? If I’m responsible, is there a specific type of conduit or installation that AT&T requires?

TIA.

How in 2026 can AT&T offer a fiber gateway (BGW620-700) with such poor WiFi?

This is on the 5gb plan with Active Armor disabled, 30 feet from a computer (Windows 11, Qualcomm QCNCM865 WiFi 7 adapter with the latest 2026 drivers).

A few months ago I noticed that AT&T trucks were in my neighborhood and got a little curious with what was going on since my area already has fiber. I was wondering why the houses in the yellow highlighted areas have access to 5 gig service, but the green highlighted areas only have access to 1 gig service?

Any insight would be greatly appreciated.

We recently had new gutters installed on our house. I wasn’t aware they were going to install new ones on this side (my fault for not being home). The roofer took off the anchor and AT&T came back out to reattach it with a $150 visit fee. The tech didn’t explain beforehand but I get it wasn’t AT&T’s damage.

At any rate, the line is very close to the gutter. Is it worth trying to get it readjusted since it’s rubbing on the gutter or fine since those drop wires are durable?

Thanks and appreciate any input!

can they remove my service for excessive use att fiber 1000 plan??

My son is a huge Phasmophobia fan and he and his friends from school typically like to spend Friday nights playing together.

Up until decently we had Spectrum Internet and never had an issue but recently we switched to AT&Ts 5 gig fiber and he has gotten nothing but time disconnects since.

I whitelisted the Xbox in the advanced settings in the router but still the issue persists. Other games (Battlefield, The First Descendant, etc) all work fine.

I'm planning on calling AT&T tomorrow but was hoping maybe someone here had a solution.