ive got att uverse internet dsl. i suspect the pace modem does a nat'd dmz mode. it's set for 86400 seconds. i suspect with the two being different is clogging up (dont know the offical term) the pace modem. something like devices connected to the orbi is generating more sessions than the pace modem can handle; which appears to be 8112 sessions. its easier for me to change value in the pace modem to match orbi. incidentally, ive had the pace modem set for 1800 seconds for the last five days or so and no internet service disruptions since. meaning no complaints from wife and kid for five days....ive made the internet great again.
can you dig up the value for udp? might as well set them to matching values.
at 7440 seconds on the isp gateway, tcp sessions doubled to just under 2000 sessions. orbi/debug reports around 600 sessions. i think they should be reporting similar number of sessions. as it times out the orbi, the isp gateway should be timing out shortly after. att uverse pace gateway appears to support 8112 sessions. while the orbi appears to support 65536...ive since changed it 3600 seconds. the number of sessions on the isp gateway continues to drop as time passes, although it is still higher than that reported on the orbi.
i did more googling and it appears one tried and true solution to the double nat is to match tcp session timeout on isp device and router. att uverse dsl gateway by pace allows editing of tcp session timeout, but many do not. netgear please add tcp session timeout field to advanced tab.
other problem is when isp device has ridiculous long tcp session timeout, and the router has short timeout; it can fill up the isp device's nat table (found the proper terminology) or clog up the device. hence the internet service disruption. as stated before, ive reduced tcp session timeout on the isp device and yet to experience internet service disruption.
i should also complain to att for leasing low end equipment supporting only 8112 tcp sessions compared to the 65536 on the orbi. before changing the timeout, it was always around 6000 sessions on the isp device. i guess it didnt take much more to put the hurt on the isp device with everything internet connected in the home.
att/pace does not offer that selection. just dmzplus which is still nat. att uverse devices pull multiple duty. i have internet only but the device also processes phone (internet phone?) should i ever get a land line again.
to anyone following: reboot your gateway (isp device) after making changes to the tcp session timeout or wait for enough sessions to timeout. then wait a day or three before declaring victory.
furry, did anyone respond to you saying they have an att uverse gateway by pace? i would love for someone to confirm changing this setting makes a difference. ill even walk them through it.
There was a couple of posters a while back that mentioned having PACE combo units. They came to the forum complainting about speeds with the Orbi. After giving them my standard feedback about combo units, one of them mentioned having problems at the modem and with it's FW. It was solved at the modem and not in the Orbi. I'll post the link I have on monday as I don't have it with me at the moment.
to anyone following: reboot your gateway (isp device) after making changes to the tcp session timeout or wait for enough sessions to timeout. then wait a day or three before declaring victory.
furry, did anyone respond to you saying they have an att uverse gateway by pace? i would love for someone to confirm changing this setting makes a difference. ill even walk them through it.
to anyone following: reboot your gateway (isp device) after making changes to the tcp session timeout or wait for enough sessions to timeout. then wait a day or three before declaring victory.
.......
I found out that the session timeout values can also been changed in Orbi, as follows:
root@RBR50:/# sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=7440 --This (7440) is the default value
ive changed the pace modem back to default of 86400 seconds and the orbi to match. lets see how it does...im a sucker for pain...how do i get it to read out that value to confirm it is there? nevermind...sysctl -a
net.netfilter.nf_conntrack_tcp_timeout_established may not be the right variable to adjust. pace modem continued to climb until internet service interruption. orbi sessions stayed under or around 1000. ive returned orbi to default values. pace modem now set to tcp session timeout = 3600. one of the variables on the orbi must be equivalent to the name used on the pace modem. i spent the last three hours searching openwrt, not sure i found document covering those variables.
net.netfilter.nf_conntrack_tcp_timeout_established may not be the right variable to adjust. pace modem continued to climb until internet service interruption. orbi sessions stayed under or around 1000. ive returned orbi to default values. pace modem now set to tcp session timeout = 3600. one of the variables on the orbi must be equivalent to the name used on the pace modem. i spent the last three hours searching openwrt, not sure i found document covering those variables.
It is really the parameter to change the tcp session timer, but it seems that to take effect it has to be changed in the file /etc/sysctl.conf.
I tried a reboot after changing the value using sysctl -w but the value returned to it's default after the reboot. 😞
I also tried the following command (find and replace in the file):
root@RBR50:/# sed 's/7440/7430/' /etc/sysctl.conf (since 7440 is the only such value in the file 🙂 )
The value was taken momentarily but changed back immediately to it's original value. Looks like the file sysctl.conf is -somehow- protected from being changed,
chmod? i havent touched linux in 20 years. i only went deep enough to satisfy curiosity on an old 486. maybe it was a 386. i would rather see this parameter on the UI for the greater good of users. anyways, the affect of increasing it on the orbi to match the pace gateway may not be a great idea.
i suspect internet connected devices are opening a session and leaving it open. then the orbi kills them at timeout (7440 seconds) but the gateway still has it open until timeout (86400 seconds). then the device wakes up after 7441 seconds and opens another session. multiply that by the number of devices. or could it be the orbi not closing sessions at the gateway? at some point the gateway becomes saturated until x number of sessions timeout.
to anyone following: reboot your gateway (isp device) after making changes to the tcp session timeout or wait for enough sessions to timeout. then wait a day or three before declaring victory.
furry, did anyone respond to you saying they have an att uverse gateway by pace? i would love for someone to confirm changing this setting makes a difference. ill even walk them through it.
i wish i could edit older posts so information could be better presented. the guy in the other thread has a 'better' gateway than mine in terms of performance and features.
ive got a pace 5031NV-030 from 2016. it has a firmware log that show initial and current firmware. both are the same. about two weeks ago, i called att and one of the actions they took was to reflash the firmware. needless to say, internet connectivity/stability did not improve. this particular device only does phone and internet. internal wifi is 2.4N (currently disabled). i am not subscribed to the phone service. max rate in my area is 45mbps. i was at the 24mbps rate until yesterday. when i found the tcp session timeout improved stability, i reduced service to 18mbps to save a few dollars.
tcp session timeout at the pace gateway. one should reset both the gateway and orbi or wait more than a few hours for the changes to settle.
1800 seconds: tried this for five/six days with no issues. at least no family members complained.
7500 seconds: 24 hours, so far so good. i know i the orbi is at 7440.
86400 seconds: default value. loss of internet at sporadic intervals.
i believe the internet service disruption is caused by the isp gateway being overloaded. the cause is the tcp session timeout value being grossly miss-matched between the two devices when the isp gateway has to do NAT or PAT. i guess it is not yet possible for the downstream router to self adjust to the isp gateway timeout.
i wonder if those who changed to other mesh solutions got lucky and that unit happened to have matching tcp session timeout values.
i wish i could edit older posts so information could be better presented. the guy in the other thread has a 'better' gateway than mine in terms of performance and features.
ive got a pace 5031NV-030 from 2016. it has a firmware log that show initial and current firmware. both are the same. about two weeks ago, i called att and one of the actions they took was to reflash the firmware. needless to say, internet connectivity/stability did not improve. this particular device only does phone and internet. internal wifi is 2.4N (currently disabled). i am not subscribed to the phone service. max rate in my area is 45mbps. i was at the 24mbps rate until yesterday. when i found the tcp session timeout improved stability, i reduced service to 18mbps to save a few dollars.
tcp session timeout at the pace gateway. one should reset both the gateway and orbi or wait more than a few hours for the changes to settle.
1800 seconds: tried this for five/six days with no issues. at least no family members complained.
7500 seconds: 24 hours, so far so good. i know i the orbi is at 7440.
86400 seconds: default value. loss of internet at sporadic intervals.
i believe the internet service disruption is caused by the isp gateway being overloaded. the cause is the tcp session timeout value being grossly miss-matched between the two devices when the isp gateway has to do NAT or PAT. i guess it is not yet possible for the downstream router to self adjust to the isp gateway timeout.
i wonder if those who changed to other mesh solutions got lucky and that unit happened to have matching tcp session timeout values.
Ugh. Is there a character limit on posts? I struggled so much to reach word count on essays back in school. It would be nice if it notified you when going over the limit.
Phone typing version....long version after I’m home from work. 1. Upload speed matters. 5Mbps better than 1.5Mbps. They don’t offer faster upload speed where I live. Frequency of lost internet vastly improved. 2. Openwrt router with fresh release and orbi ap is pretty good. Any other device as router is probably going to be good.
I experimented with Linux back in college about 20 years ago. Openwrt experience is limited to some light reading of wiki and a stay at holiday inn express.
Nothing useful in logs explaining lost internet. Buffer bloat?
@Shotround wrote: Ugh. Is there a character limit on posts? I struggled so much to reach word count on essays back in school. It would be nice if it notified you when going over the limit.
Phone typing version....long version after I’m home from work. 1. Upload speed matters. 5Mbps better than 1.5Mbps. They don’t offer faster upload speed where I live. Frequency of lost internet vastly improved. 2. Openwrt router with fresh release and orbi ap is pretty good. Any other device as router is probably going to be good.
I experimented with Linux back in college about 20 years ago. Openwrt experience is limited to some light reading of wiki and a stay at holiday inn express.
Nothing useful in logs explaining lost internet. Buffer bloat?
Pace 5031 nv - dmzplus setting - Linksys wrt1900ac - orbi ap mode - no complaints from family
Pace appears to be arris now. Linksys has latest openwrt by my preferred source. I’ll post other observations when I’m on computer. Perhaps netgear implementation to deal with buffer bloat. The base code openwrt used by orbi is quite dated. I wonder how much that contributed to issues observed.
And when you put the Orbi in place of the Linksys and in router mode is when you do see problems. i wouldnt be posting if there were no problems.
Does the modem from the ISP use DHCP or PPPoE to connect to the ISP services? some variant of dsl, likely vdsl. while it supports that, it is not something the user can select.
