Jump to content

Recommended Posts

Since upgrading to DumaOS I haven't had many problems with my R1's WiFi. On the old firmware it would randomly drop out, especially if I had both the geofilter and port forwarding in use simultaneously, but upon upgrading all those issues disappeared. 

 

Tonight I was trying to watch a pal stream on Twitch and noticed random buffering every minute or so. Nobody else in the stream had any issues and the streamer wasn't dropping frames or having any internet issues, so I assumed it was just a blip. A few hours later my WiFi started dropping out just like the grim old days on 1.03.6. I checked my QoS, tried to run a speed test and it gave me an error. The WiFi then disappeared for about 20 minutes, giving me "saved", "disconnected" and "disabled" statuses despite it clearly being there, before I could get on long enough to disable QoS and then reboot the router. It didn't make a difference. So I got my laptop out and wired up to my ISP router to turn its WiFi on for comparison. 

 

When I could finally do a speed test on the R1 WiFi it looked like this:

Screenshot_20190303-014323.thumb.png.118aa41f24d3a9ad1f214db6a88cefe7.png

On the other hand the TalkTalk router WiFi gave me this:

Screenshot_20190303-015610.thumb.png.a1a1c9c3a4fb2fef72f9242900886e47.png

I also did a wired test on the laptop while it was on, and it was working just fine. I turned the TalkTalk WiFi off again to try another test on the R1 (to prevent any interference between the two), and after changing WiFi channels and then many painful minutes waiting for it to connect it looked like this:

Screenshot_20190303-031704.thumb.png.781186ce1d3874aaaf43c3e1152c17a9.png

The TalkTalk WiFi, again, on the other hand:

Screenshot_20190303-031754.thumb.png.8a1559263c153e29ea6f5dce32f5a4fb.png

I've since tried changing channels four times, rebooting again, and finally resetting to factory defaults, and it's still effed up. Any ideas? Sitting around waiting for it to return to normal is driving me mental. 

 

Edit: it gets worse LOL

Screenshot_20190303-033918.thumb.png.946ca12d659cb6cc3afac4f46925bb9c.png

Share this post


Link to post
Share on other sites

Dude I’ve been legitimately having similar issues. It’s weird because when I first installed it I never had WiFi drop outs. Now they only occur when Qos is on (that I’ve noticed) anytime I’ve had it off, well the buffer bloat part it all seems to be fine and my lan still works when that issue happens. I even check the log and it doesn’t say anything about it when checking around the time it happens too. Yeah know it can’t just be me and I know 100% I set all the settings right. 

Share this post


Link to post
Share on other sites

My log mostly says this:

 

Sun Mar 3 18:20:02 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:20:02 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:20:01 2019 user.warn com.netdumasoftware.settings: Error opening wireless-mirror with error wireless-mirror: No such file or directory.

Sun Mar 3 18:19:48 2019 user.warn com.netdumasoftware.settings: Error opening wireless-mirror with error wireless-mirror: No such file or directory.

Sun Mar 3 18:19:40 2019 user.warn com.netdumasoftware.settings: Error opening wireless-mirror with error wireless-mirror: No such file or directory.

Sun Mar 3 18:19:02 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:17:45 2019 kern.info kernel: [198622.428000] send: nf_ct_get failed

Sun Mar 3 18:17:45 2019 kern.info kernel: [198622.428000] recv: nf_ct_get failed

Sun Mar 3 18:16:05 2019 user.warn com.netdumasoftware.settings: Error opening wireless-mirror with error wireless-mirror: No such file or directory.

Sun Mar 3 18:16:02 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:16:02 2019 kern.info dpiclass-daemon: Kill flow due to timeout

 

I managed to stay connected to WiFi long enough to do this lol:

_20190303_182207.JPG.542e102641fc50b825324152d410cf8c.JPG

That's with QoS disabled 🤔

Share this post


Link to post
Share on other sites

Welcome to the club, mines exactly the same, with near enough exactly the same log. They aren't sure what causes it.

Share this post


Link to post
Share on other sites

Idk what causes the drop outs, the old firmware didn't do it. 🤷‍♂️. Duma OS is great in alot of ways but of course far from being the finished product. Still waiting for the day they actually release anti-jitter....that was promised forever ago and that never happened. Even the original R1 firmware wasnt 100% fixed. Sure it was decent for what it offers versus most routers ill give it that, the company is definitely on the right track as far as what they have for goals in mind, no other router company has ever cared enough to design something like this.

Share this post


Link to post
Share on other sites
2 hours ago, lllRL said:

My log mostly says this:

 

Sun Mar 3 18:20:02 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:20:02 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:20:01 2019 user.warn com.netdumasoftware.settings: Error opening wireless-mirror with error wireless-mirror: No such file or directory.

Sun Mar 3 18:19:48 2019 user.warn com.netdumasoftware.settings: Error opening wireless-mirror with error wireless-mirror: No such file or directory.

Sun Mar 3 18:19:40 2019 user.warn com.netdumasoftware.settings: Error opening wireless-mirror with error wireless-mirror: No such file or directory.

Sun Mar 3 18:19:02 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:18:32 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:17:45 2019 kern.info kernel: [198622.428000] send: nf_ct_get failed

Sun Mar 3 18:17:45 2019 kern.info kernel: [198622.428000] recv: nf_ct_get failed

Sun Mar 3 18:16:05 2019 user.warn com.netdumasoftware.settings: Error opening wireless-mirror with error wireless-mirror: No such file or directory.

Sun Mar 3 18:16:02 2019 kern.info dpiclass-daemon: Kill flow due to timeout

Sun Mar 3 18:16:02 2019 kern.info dpiclass-daemon: Kill flow due to timeout

 

I managed to stay connected to WiFi long enough to do this lol:

_20190303_182207.JPG.542e102641fc50b825324152d410cf8c.JPG

That's with QoS disabled 🤔

I think your SOL lol, might as well just use dialup, or is that dialup? ;D

Share this post


Link to post
Share on other sites
40 minutes ago, bbursley said:

Idk what causes the drop outs, the old firmware didn't do it. 🤷‍♂️. Duma OS is great in alot of ways but of course far from being the finished product. Still waiting for the day they actually release anti-jitter....that was promised forever ago and that never happened. Even the original R1 firmware wasnt 100% fixed. Sure it was decent for what it offers versus most routers ill give it that, the company is definitely on the right track as far as what they have for goals in mind, no other router company has ever cared enough to design something like this.

Mine did pretty often. I went back to the old firmware a few weeks ago before ping assist wasn't working on DumaOS, but then I remembered the WiFi dropouts and they pissed me off more so I upgraded again lol. 

 

I just wish they'd justified the time it took to release DumaOS by giving us a fully working product 🙄

43 minutes ago, bbursley said:

I think your SOL lol, might as well just use dialup, or is that dialup? ;D

Haha nah it's TalkTalk fibre to the cab. Should be 80/20, modem stats claim I can get anywhere from 70-74 down, and over WiFi it's normally 67 tops. Bit strange considering the cab is a stone's throw away, but I'm paying less than I did for BT 50/10 so I can't really complain about that. 

 

I'm not really gaming anymore because the connections I get are shite despite constantly low stable pings (6ms to London for example). The average game gives me a good 300ms of UDP latency and I can't even run custom games with bots without lagging so I'm not exactly getting any use out of the R1. However it would be nice if the rest of my devices could use the bandwidth at least... 

Share this post


Link to post
Share on other sites
2 hours ago, Azlios said:

Welcome to the club, mines exactly the same, with near enough exactly the same log. They aren't sure what causes it.

In the words of Limmy... 

 

I don't get it *sad confused face* 😂

Share this post


Link to post
Share on other sites

Have any of you added anything to Traffic Prioritisation? For example, your console or PC?

If you have, could you try deleting this and then repeat your tests. Does the problem go away?

Share this post


Link to post
Share on other sites

Sorry for the late reply (trying to fix my broken sleep pattern lol)... 

 

No I didn't have anything like that set up at the time. The WiFi just randomly started working again yesterday afternoon 🤨

Share this post


Link to post
Share on other sites
5 hours ago, lllRL said:

Sorry for the late reply (trying to fix my broken sleep pattern lol)... 

No I didn't have anything like that set up at the time. The WiFi just randomly started working again yesterday afternoon 🤨

Hrm. Issues like this are so annoying, it's a difficult thing to troubleshoot. I have a feeling anything like this should disappear in the next few updates, since I think there's work ongoing with DHCP and the Device Manager. I reckon that's probably the root of the problem if it's not the hardware itself (which is equally likely, could be a Mikrotik bug).

Share this post


Link to post
Share on other sites
On 3/4/2019 at 2:40 PM, Netduma Admin said:

Have any of you added anything to Traffic Prioritisation? For example, your console or PC?

If you have, could you try deleting this and then repeat your tests. Does the problem go away?

Yes, I have to put my PC in traffic prio as a games console to get QoS to work, but it doesn't help much with that either, but that's a separate topic. When I have it in traffic prio it initially drops my wifi more but then goes back to the once a week drop after a couple days.

Share this post


Link to post
Share on other sites

Are you downloading a lot on that PC? As it will supercede QoS and could potentially cause a WiFi dropout if it's completely saturated, just a theory. 

Share this post


Link to post
Share on other sites
1 hour ago, Netduma Fraser said:

Are you downloading a lot on that PC? As it will supercede QoS and could potentially cause a WiFi dropout if it's completely saturated, just a theory. 

That could make sense actually. I'm constantly downloading game updates, driver updates and updates for design software. Next time I have a large download I'll see if it triggers a wifi drop.

Share this post


Link to post
Share on other sites
5 hours ago, Netduma Fraser said:

Has yours dropped since it started working again?

Yup, it just started again. Only difference is there's now zero internet access instead of it coming and going with 0.1Mb Screenshot_20190307-001317.thumb.png.be5bcc14e62cbda87a89002c3ef3f84f.png

Screenshot_20190307-001323.thumb.png.3cfb20345ab76a5ee89d818b95d4dfa5.png

Share this post


Link to post
Share on other sites

Really strange, I'm just going to list some potential causes/suggestions:

  • Make sure router is plugged directly into a wall outlet rather than extender
  • Make sure no wireless devices (anything that operates wirelessly, headphones, mobiles etc) are not within 3 feet of the route
  • Not close to a microwave!
  • Router in an open area and not enclosed

Share this post


Link to post
Share on other sites
2 hours ago, Netduma Fraser said:

Really strange, I'm just going to list some potential causes/suggestions:

  • Make sure router is plugged directly into a wall outlet rather than extender
  • Make sure no wireless devices (anything that operates wirelessly, headphones, mobiles etc) are not within 3 feet of the route
  • Not close to a microwave!
  • Router in an open area and not enclosed

None of those apply to me :( already plugged directly into the wall, no other devices near it, out in the open (signal is fine when it's actually working, better than my TalkTalk hub) and nowhere near a microwave lol

Share this post


Link to post
Share on other sites

Okay I think next step is to pass it on to the developers as I can't see any settings or outside factors that are causing it. I'll let the team know so they can take a look.

Share this post


Link to post
Share on other sites
22 hours ago, Netduma Fraser said:

Okay I think next step is to pass it on to the developers as I can't see any settings or outside factors that are causing it. I'll let the team know so they can take a look.

Alright cheers. Please post here when you have any updates so I get the notification. 

Share this post


Link to post
Share on other sites

Mine just went down now, wasn't downloading anything as far as I am aware. Thursday is generally the day it drops though.

This is my log:

 

Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:11 2019 kern.info kernel: [557319.408000] send: nf_ct_get failed
Thu Mar 14 17:18:11 2019 kern.info kernel: [557319.408000] send: nf_ct_get failed
Thu Mar 14 17:18:10 2019 kern.info kernel: [557318.544000] send: nf_ct_get failed
Thu Mar 14 17:18:10 2019 kern.info kernel: [557318.544000] recv: nf_ct_get failed
Thu Mar 14 17:18:10 2019 kern.info kernel: [557318.544000] send: nf_ct_get failed
Thu Mar 14 17:18:10 2019 kern.info kernel: [557318.544000] recv: nf_ct_get failed
Thu Mar 14 17:17:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:17:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:17:34 2019 daemon.warn dnsmasq[1187]: Maximum number of concurrent DNS queries reached (max: 150)
Thu Mar 14 17:17:27 2019 daemon.warn dnsmasq[1187]: Maximum number of concurrent DNS queries reached (max: 150)
Thu Mar 14 17:17:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:17:07 2019 daemon.warn odhcpd[737]: Failed to send to ff02::1%br-lan (Operation not permitted)
Thu Mar 14 17:17:01 2019 kern.info kernel: [557249.644000] send: nf_ct_get failed
Thu Mar 14 17:17:00 2019 kern.info kernel: [557248.496000] send: nf_ct_get failed
Thu Mar 14 17:17:00 2019 kern.info kernel: [557248.492000] recv: nf_ct_get failed
Thu Mar 14 17:16:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:10 2019 kern.info kernel: [557198.200000] send: nf_ct_get failed
Thu Mar 14 17:16:10 2019 kern.info kernel: [557198.200000] recv: nf_ct_get failed
Thu Mar 14 17:15:57 2019 user.info com.netdumasoftware.neighwatch: DHCP lease change.
Thu Mar 14 17:15:57 2019 user.info com.netdumasoftware.neighwatch: DHCP old event.

Share this post


Link to post
Share on other sites
On 3/7/2019 at 4:59 PM, Netduma Fraser said:

Okay I think next step is to pass it on to the developers as I can't see any settings or outside factors that are causing it. I'll let the team know so they can take a look.

Thing is, this happens to me as well. I think its a channel issue perhaps, because when i change mine the wireless works again. That is why I suggested it as a future update because otherwise its broken. I have dropped wifi SO MANY TIMES since upgrade. Honestly I am reconsidering downgrading as much as I love the QOS (I actually think it works decent on the R1 for what it is) the geo and wifi issues have been an absolute nightmare.

Share this post


Link to post
Share on other sites
1 hour ago, Azlios said:

Mine just went down now, wasn't downloading anything as far as I am aware. Thursday is generally the day it drops though.

This is my log:

 

Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:18:11 2019 kern.info kernel: [557319.408000] send: nf_ct_get failed
Thu Mar 14 17:18:11 2019 kern.info kernel: [557319.408000] send: nf_ct_get failed
Thu Mar 14 17:18:10 2019 kern.info kernel: [557318.544000] send: nf_ct_get failed
Thu Mar 14 17:18:10 2019 kern.info kernel: [557318.544000] recv: nf_ct_get failed
Thu Mar 14 17:18:10 2019 kern.info kernel: [557318.544000] send: nf_ct_get failed
Thu Mar 14 17:18:10 2019 kern.info kernel: [557318.544000] recv: nf_ct_get failed
Thu Mar 14 17:17:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:17:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:17:34 2019 daemon.warn dnsmasq[1187]: Maximum number of concurrent DNS queries reached (max: 150)
Thu Mar 14 17:17:27 2019 daemon.warn dnsmasq[1187]: Maximum number of concurrent DNS queries reached (max: 150)
Thu Mar 14 17:17:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:17:07 2019 daemon.warn odhcpd[737]: Failed to send to ff02::1%br-lan (Operation not permitted)
Thu Mar 14 17:17:01 2019 kern.info kernel: [557249.644000] send: nf_ct_get failed
Thu Mar 14 17:17:00 2019 kern.info kernel: [557248.496000] send: nf_ct_get failed
Thu Mar 14 17:17:00 2019 kern.info kernel: [557248.492000] recv: nf_ct_get failed
Thu Mar 14 17:16:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:43 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:13 2019 kern.info dpiclass-daemon: Kill flow due to timeout
Thu Mar 14 17:16:10 2019 kern.info kernel: [557198.200000] send: nf_ct_get failed
Thu Mar 14 17:16:10 2019 kern.info kernel: [557198.200000] recv: nf_ct_get failed
Thu Mar 14 17:15:57 2019 user.info com.netdumasoftware.neighwatch: DHCP lease change.
Thu Mar 14 17:15:57 2019 user.info com.netdumasoftware.neighwatch: DHCP old event.

You say it's happening every Thursday? Have you got DHCP lease set to 1 week by any chance? As I see that at the start of the log. Give WiFi devices static IPs, does it continue then? 

1 hour ago, bbursley said:

Thing is, this happens to me as well. I think its a channel issue perhaps, because when i change mine the wireless works again. That is why I suggested it as a future update because otherwise its broken. I have dropped wifi SO MANY TIMES since upgrade. Honestly I am reconsidering downgrading as much as I love the QOS (I actually think it works decent on the R1 for what it is) the geo and wifi issues have been an absolute nightmare.

Similar to above, could you extend your DHCP lease time to the maximum, I believe it's around 165 hours and see if you experience it less please? Also give static IPs to your WiFI devices

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...