Check out AT&T's Valentine's Day Gift Guide for ideas & deals on the new Samsung Galaxy S23!
texasbubb's profile
texasbubb
#1 Star!
10th stratosphere!
Mission control approves!

Mentor

 • 

36 Messages

Saturday, June 18th, 2016 8:39 AM

Pace 5268AC, DMZPlus Issue, drops lan every 10 minutes.

I have the Pace 5268AC in DMZPlus in front of a Cisco RV325.  In DMZ mode it apparently want to expire the lease on the address every 10 minutes and causes my network to go down.  Any thoughts on how to stop this?  Would moving to a static IP stop it?  Or do they just issue a fixed address via the same mechanism?

mibrnsurg

Expert

 • 

20.4K Messages

7 years ago

@texasbubb   Anyplace to adjust the time DMZ leases?  Check LAN>DHCP, here on my 3800 default is 24 hours. Smiley Surprised

 

Chris
__________________________________________________________

Please NO SD stretch-o-vision or 480 SD HD Channels
Need Help? PM ATT Uverse Care (all service problems)
ATT Customer Care(billing and all other problems)
Your Results May Vary, In My Humble Opinion
I Call It Like I See It, Simply a U-verse user, nothing more

JefferMC

ACE - Expert

 • 

30.9K Messages

7 years ago

The DHCP renewal responses from the AT&T firmware follow a rather "interesting" interpretation of the RFC, one that is not widely held.  Your Cisco router is probably not seeing the response to the DHCP renewal request.  I believe you can extend the DHCP lifetime to 48 hours, but that's not a lot of help.  

 

However, yes, you can plug the public IP and default gateway addresses it got via DHCP into the WAN setup for your router.  U-verse very rarely changes your dynamic public address, thus this will probably keep you from having this issue for years.

 

texasbubb

Mentor

 • 

36 Messages

7 years ago

Yes. That is what I have done and so far it seems to be working. However if the gateway ever restarts I am afraid the connection will not self restore since it expects DHCP on that port. But for now it is working. Thanks for the advice. I just wish ATT was more thoughtful about the needs of power users. It seems we are always forced to find work arounds and half measures.
JefferMC

ACE - Expert

 • 

30.9K Messages

7 years ago

If you're handy with wireshark and the Cisco's packet filters, I think the problem with the DHCP response is that the From address on the reply is strange.  Take a look.

 

Alternatley, there were scripts to get DD-WRT or Tomato to pass/recognize the response.  Maybe you can find one that'll help you solve it.

 

texasbubb

Mentor

 • 

36 Messages

7 years ago

Thanks to all who offer help. There is no way for the user to alter the lease time on this configuration. It appears to be either pushed down from ATTs network or hard coded into the firmware. I have not gone to the trouble of putting Wireshark on it. Not even sure how I would do that since I need to monitor transactions between the gateway and my router. I guess I could throw a hub in the line. Can you even get a gb Ethernet straight up hub...
JefferMC

ACE - Expert

 • 

30.9K Messages

7 years ago


@texasbubb wrote:
...Can you even get a gb Ethernet straight up hub...

Probably not.  But you can get switches with diagnostic modes for this purpose.  Don't know how many consumer switches would have that.

 

Ender519

Mentor

 • 

51 Messages

6 years ago

I also had this issue, hooked up to a Fortigate firewall.  What I found is that the lease from the modem was only 300 seconds!  And then when my firewall went to renew, the response is crazy and sets the lease for a matter of 20 seconds or less, sometimes as little as 4 seconds.. and then finally stops giving out the IP address altogether.  Its buggy as all get out.  This firewall worked great with old Uverse service on an older modem, as well as an Arris modem with Brighthouse and I am a firewall engineer by trade.  I am now on GigaPower using the same 5268AC modem listed above.  It is definitely not following RFC.  After this I tried a Cisco 1921 router I had sitting around, and same behavior results!  This has got to be a firmware bug.   I ended up setting my firewall to static IP but this is hardly ideal.  If AT&T ever changes IP I'm going down until I go through the hoops again.  Near as I can tell the internal DHCP server works just fine, it's only when you choose DMZPlus.

 

 

Take a look at the dhcp client debugs from my firewall (MAC Addresses are redacted)

 

T1 has expired, state renewing.
make request
make dhcp message, code=3
Insert option(255), len(0)
Insert option(53), len(1)
Insert max message len (1458)
Insert option(57), len(2)
Insert client ID
Insert option(61), len(7)
Insert requested options
Insert option(55), len(9)
Insert hostname
Insert option(12), len(9)
Insert class ID option
Insert option(60), len(14)
get_dhcp_msg_len, 291
too small, extend to 548
Sending request!
Send a packet out.
add hw header
###############3Receive packet:
len=60
del hw header
ether_type:0806
hw addr from: 00:1E:C0:20:xx:xx
arp packet received, len:46
A ARP packet is received.
timer 0x12b4f5c0(send_request -> send_request) will expire in 9 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 8 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 7 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 6 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 5 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 4 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 3 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 2 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 1 secs
timer 0x12b4f5c0 expired, take action
Sending request!
Send a packet out.
add hw header
dst hw addr: F8:2C:18:1F:xx:xx
src hw addr: 00:09:0F:09:xx:xx
add ip udp header
dhcpcd_send_packet,270:result:590, ifinde:7
unregister timer:0x12b4f5c0
register timer func=0x6591b0 arg=0x12b4c440 name=send_request -> send_request
Allocate a new timer
Registered timer 0x12b4f510 will expiry in 16 secs
timer 0x12b4f510(send_request -> send_request) will expire in 16 secs
fd 14 can be read now
###############3Receive packet:
len=60
del hw header
ether_type:0806
hw addr from: 00:1E:C0:20:xx:xx
arp packet received, len:46
A ARP packet is received.
timer 0x12b4f510(send_request -> send_request) will expire in 15 secs
timer 0x12b4f510(send_request -> send_request) will expire in 14 secs
timer 0x12b4f510(send_request -> send_request) will expire in 13 secs
timer 0x12b4f510(send_request -> send_request) will expire in 12 secs
timer 0x12b4f510(send_request -> send_request) will expire in 11 secs
timer 0x12b4f510(send_request -> send_request) will expire in 10 secs
timer 0x12b4f510(send_request -> send_request) will expire in 9 secs
timer 0x12b4f510(send_request -> send_request) will expire in 8 secs
timer 0x12b4f510(send_request -> send_request) will expire in 7 secs
timer 0x12b4f510(send_request -> send_request) will expire in 6 secs
fd 14 can be read now
###############3Receive packet:
len=60
del hw header
ether_type:0806
hw addr from: 00:1E:C0:20:xx:xx
arp packet received, len:46
A ARP packet is received.
timer 0x12b4f510(send_request -> send_request) will expire in 5 secs
timer 0x12b4f510(send_request -> send_request) will expire in 4 secs
fd 14 can be read now
###############3Receive packet:
len=60
del hw header
ether_type:0806
hw addr from: F8:2C:18:1F:xx:xx
arp packet received, len:46
A ARP packet is received.
timer 0x12b4f510(send_request -> send_request) will expire in 4 secs
timer 0x12b4f510(send_request -> send_request) will expire in 3 secs
timer 0x12b4f510(send_request -> send_request) will expire in 2 secs
timer 0x12b4f510(send_request -> send_request) will expire in 1 secs
timer 0x12b4f510 expired, take action
Sending request!
Send a packet out.
add hw header
dst hw addr: F8:2C:18:1F:xx:xx
src hw addr: 00:09:0F:09:xx:xx
add ip udp header
dhcpcd_send_packet,270:result:590, ifinde:7
unregister timer:0x12b4f510
register timer func=0x6591b0 arg=0x12b4c440 name=send_request -> send_request
Allocate a new timer
Registered timer 0x12b4f5c0 will expiry in 9 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 9 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 7 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 6 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 5 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 4 secs
fd 14 can be read now
###############3Receive packet:
len=60
del hw header
ether_type:0806
hw addr from: 00:1E:C0:20:xx:xx
arp packet received, len:46
A ARP packet is received.
timer 0x12b4f5c0(send_request -> send_request) will expire in 4 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 3 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 2 secs
timer 0x12b4f5c0(send_request -> send_request) will expire in 1 secs
timer 0x12b4f5c0 expired, take action
Sending request!
Send a packet out.
add hw header
dst hw addr: F8:2C:18:1F:xx:xx
src hw addr: 00:09:0F:09:xx:xx
add ip udp header
dhcpcd_send_packet,270:result:590, ifinde:7
unregister timer:0x12b4f5c0
register timer func=0x6591b0 arg=0x12b4c440 name=send_request -> send_request
Allocate a new timer
Registered timer 0x12b4f510 will expiry in 14 secs
timer 0x12b4f510(send_request -> send_request) will expire in 14 secs
timer 0x12b4f510(send_request -> send_request) will expire in 13 secs
timer 0x12b4f510(send_request -> send_request) will expire in 12 secs

firewall #
firewall #
firewall # timer 0x12b4f510(send_request -> send_request) will expire in 11 secs

firewall #
firewall # timer 0x12b4f510(send_request -> send_request) will expire in 10 secs
diatimer 0x12b4f510(send_request -> send_request) will expire in 9 secs
g deb dfd 14 can be read now

texasbubb

Mentor

 • 

36 Messages

6 years ago

Prety much what I found.  That box definatly has some bugs. 

 

I went ahead and purchased a block of static IP's.  If you do that, the setup can be such that you bypass the DHCP server and firewall all together, in effect bridging the router.  However, unless you are only using the device upstream of your primary router / firewall, you may have issues getting with the LAN addresses talking to the WAN addresses without an external bridge.  They subnet off the WAN block as a seperate network in effect creating two VLAN's one open to the world, and one behind their firewall.  For me, I'm good with it because all I need it for is the modem.  I have my own firewall / router that manages my network.

Ender519

Mentor

 • 

51 Messages

6 years ago

I would settle for trying to report it to AT&T to try to get it fixed, but to be honest I simply cannot find a venue.  Neither the call center nor local technician has any facility whatsoever for reporting problems with the functions on the modem, and in fact they tried to claim that DMZplus wasn't supported by AT&T, and that I should go talk to Pace, like they would give me the time of day.  I've seen forums saying that NVG599 and older did DMZPlus just fine, but that model tops out at 75Mbps so cannot be used for Gigapower.

 

Also, be aware setting the static IP manually is only a short term workaround.  I had a power outage due to storm (UPS was drained of battery) and when modem came back up my firewall was dead in the water until I switched interface back to DHCP, pulled the same IP from the modem, and set my firewall back to static.  Bear in mind my IP didn't change, but you can't start out with that IP and have it work on the 5268AC from boot, you have to let the modem hand you the IP first and THEN set it to static to get it to work.  Translation, if your modem loses power for any reason, you will lose internet until you manually intervene.

Tutor

 • 

4 Messages

6 years ago

Thanks all I too have Pace 5268ac RG. and have the same issue with my WAN

 

DHCP Lease Time:10 Minutes

 

 

 

AT&T really needs to adderess this issue ASAP.

Not finding what you're looking for?
New to AT&T Community?
New to the AT&T Community? Start by visiting the Community How-To.
New to the AT&T Community?
Visit the Community How-To.