RL317 Posted March 3, 2019 Share Posted March 3, 2019 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: On the other hand the TalkTalk router WiFi gave me this: 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: The TalkTalk WiFi, again, on the other hand: 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 Link to comment Share on other sites More sharing options...
bbursley Posted March 3, 2019 Share Posted March 3, 2019 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. Link to comment Share on other sites More sharing options...
RL317 Posted March 3, 2019 Author Share Posted March 3, 2019 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: That's with QoS disabled 🤔 Link to comment Share on other sites More sharing options...
Azlios Posted March 3, 2019 Share Posted March 3, 2019 Welcome to the club, mines exactly the same, with near enough exactly the same log. They aren't sure what causes it. Link to comment Share on other sites More sharing options...
bbursley Posted March 3, 2019 Share Posted March 3, 2019 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. Link to comment Share on other sites More sharing options...
bbursley Posted March 3, 2019 Share Posted March 3, 2019 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: That's with QoS disabled 🤔 I think your SOL lol, might as well just use dialup, or is that dialup? ;D Link to comment Share on other sites More sharing options...
RL317 Posted March 3, 2019 Author Share Posted March 3, 2019 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... Link to comment Share on other sites More sharing options...
RL317 Posted March 3, 2019 Author Share Posted March 3, 2019 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* 😂 Link to comment Share on other sites More sharing options...
Administrators Netduma Admin Posted March 4, 2019 Administrators Share Posted March 4, 2019 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? Link to comment Share on other sites More sharing options...
RL317 Posted March 5, 2019 Author Share Posted March 5, 2019 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 🤨 Link to comment Share on other sites More sharing options...
Netduma Staff Netduma Jack Posted March 5, 2019 Netduma Staff Share Posted March 5, 2019 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). Link to comment Share on other sites More sharing options...
Azlios Posted March 5, 2019 Share Posted March 5, 2019 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. Link to comment Share on other sites More sharing options...
Administrators Netduma Fraser Posted March 5, 2019 Administrators Share Posted March 5, 2019 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. Link to comment Share on other sites More sharing options...
Azlios Posted March 5, 2019 Share Posted March 5, 2019 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. Link to comment Share on other sites More sharing options...
Administrators Netduma Fraser Posted March 5, 2019 Administrators Share Posted March 5, 2019 Okay great keep us updated! Link to comment Share on other sites More sharing options...
RL317 Posted March 6, 2019 Author Share Posted March 6, 2019 I haven't downloaded anything from a PC BTW 🙄 lol Link to comment Share on other sites More sharing options...
Administrators Netduma Fraser Posted March 6, 2019 Administrators Share Posted March 6, 2019 5 hours ago, lllRL said: I haven't downloaded anything from a PC BTW 🙄 lol Has yours dropped since it started working again? Link to comment Share on other sites More sharing options...
RL317 Posted March 7, 2019 Author Share Posted March 7, 2019 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 Link to comment Share on other sites More sharing options...
Administrators Netduma Fraser Posted March 7, 2019 Administrators Share Posted March 7, 2019 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 Link to comment Share on other sites More sharing options...
RL317 Posted March 7, 2019 Author Share Posted March 7, 2019 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 Link to comment Share on other sites More sharing options...
Administrators Netduma Fraser Posted March 7, 2019 Administrators Share Posted March 7, 2019 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. Link to comment Share on other sites More sharing options...
RL317 Posted March 8, 2019 Author Share Posted March 8, 2019 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. Link to comment Share on other sites More sharing options...
Azlios Posted March 14, 2019 Share Posted March 14, 2019 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. Link to comment Share on other sites More sharing options...
bbursley Posted March 14, 2019 Share Posted March 14, 2019 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. Link to comment Share on other sites More sharing options...
Administrators Netduma Fraser Posted March 14, 2019 Administrators Share Posted March 14, 2019 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 Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.