texasbubb's profile
texasbubb
#1 Star!
10th stratosphere!
Mission control approves!

Mentor

 • 

36 Messages

Sat, Jun 18, 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

6 y 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

 • 

26.7K Messages

6 y 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

6 y 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

 • 

26.7K Messages

6 y 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

6 y 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

 • 

26.7K Messages

6 y 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

5 y 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

5 y 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

5 y 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

5 y 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.

Contributor

 • 

2 Messages

5 y ago

Any further information on this? I'm running into the same issue.

texasbubb

Mentor

 • 

36 Messages

5 y ago

Nope. You have two options. Set your router to static IP after the initial DHCP issue in DMZ mode and redo this manually every time you lose power or connection or ATT resets. Or option 2, buy a block of static IP addresses and set up to bypass the firewall ( This is what I am doing now and it seems to work without issue ) This is all discussed in the thread so I won't go into more detail here. Good luck.

Contributor

 • 

2 Messages

4 y ago

I have been experiencing the same issue, and I think I tracked it down to a missing route.

If you have your router setup to issue 192.168.1.x ip addresses on any of your LAN interfaces, this is most likely the issue.

 

The Pace modem itself listens to 192.168.1.254. That is the DHCP server address that your router will use to get the public IP lease (if using DMZPlus). What happens next is a routing issue. When the ER needs to renew the lease, it's not reaching out to the Pace modem on your WAN interface, but it is reaching out to the port that it thinks 192.168.1.x is being used on per its own routing table.

 

So the DHCP renewal request never reaches the Pace modem, and (this is speculation) your router will stop using the ip address once the lease expires, prompting a re-initialization of the wan interface, which will work - once.

 

I hope this makes sense. You can replicate this by logging into your router (ssh) and trying to ping the Pace modem at 192.168.1.254. The pings will go unanswered. To fix this, I added a static host route on my Ubiquity Edgerouter like this. These commands are specific to EdgeOS:

 

set protocols static interface-route 192.168.1.254/32 next-hop-interface eth0

set protocols static interface-route 192.168.1.254/32 next-hop-interface eth0 description "Direct route to AT&T RG"

set protocols static interface-route 192.168.1.254/32 next-hop-interface eth0 distance 1

commit

save 

 

Once you do this you should be able to ping 192.168.1.254 and reach the RG via your LAN too. The DHCP renewals should go out to the right interface now, and renewals should work. Make sure you don't accidentally issue 192.168.1.254 on your local LAN or you will get a routing conflict. It's best to limit the upper dhcp pool range to 253 to be safe.

 

Stephan

texasbubb

Mentor

 • 

36 Messages

4 y ago

Not sure I understand what your up to.  In my setup I have completely different class c addressing between LAN and WAN.  The only interface between the PACE and my switch is the WAN port.  I was not using the default 192... gateway address.  It didn't seem to make any difference if I did.  DHCP for my LAN is done on the Cisco box behind the firewall.  My WAN gateway was set to the PACE and is also the same address as the PACE DHCP server.  Address issue was assigned by MAC binding.  I don't see how the WAN would hit anything other than the gateway address it was programmed with.  It worked for first issue just not renewal.  But who knows... Could be routing issue.  But I think if you add the static rout as you suggest, you would be routing to the PACE DHCP server. LAN would never need to see that.  it's on the other side of the firewall. 

JefferMC

ACE - Expert

 • 

26.7K Messages

4 y ago

The DHCP issue, as I understand it, is not that the DHCP renewal request doesn't get to the Gateway, it is that the Gateway's renewal reply has a strange source address which causes many routers to drop it, unprocessed, so the router never gets a renewal reply and once its lease completely expires, it quits using it.  Static assignment of that IP to the router's WAN interface  is the usual work around, unless you feel like wiresharking the protocol and fixing up your router's IP tables to pass the malformed DHCP renewal reply.  

You can also extend the release time to make this much less frequent.

 

Need help?
New to the AT&T Community? Start by visiting the Community How-To.
New to the AT&T Community?
Visit the Community How-To.