Interestingly syslog does not use the configured timezone for all operations. Some operations show the configured timezone, others show GMT (see highlighted sections in the attached screenshot. CLI date returns the configured timezone.
Google shows that this is seen in other builds. The simple workaround is to set the timezone to GMT in the web UI. At least the times don't keep jumping forwards and backwards.
Interestingly syslog does not use the configured timezone for all operations. Some operations show the configured timezone, others show GMT (see highlighted sections in the attached screenshot. CLI date returns the configured timezone.
Google shows that this is seen in other builds. The simple workaround is to set the timezone to GMT in the web UI. At least the times don't keep jumping forwards and backwards.
Unfortunately this is a problem in the toolchain and not easily fixable. For userspace apps it is easy, but not kernel log outputs. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
Posted: Sun Oct 23, 2016 15:09 Post subject: Re: Guest vaps 2G & 5G in the same subnet with desipro t
Bib wrote:
............My setup works for a single vap, but not when I set the 2 vaps at 2.1 (same exact duplicated lines below, even the 2 last ip rules). Only setting the 5G vap @ 3.1 I get it work, but the 2 vaps aren't in te same net.
As mentioned bridgeing the two and using one DHCP makes most sense .........--
But for same subnet you could try:
dhcp-option=wl0.1,3,192.168.2.1
dhcp-option=wl1.1,3,192.168.2.151
dhcp-range=wl0.1,192.168.2.2,192.168.2.150,255.255.255.0,60m
dhcp-range=wl1.1,192.168.2.152,192.168.2.254,255.255.255.0,60m
Posted: Sun Oct 23, 2016 20:26 Post subject: Re: R7000 Guest bridge vaps 2G & 5G
mrjcd wrote:
As mentioned bridgeing the two and using one DHCP makes most sense .......
I ran tests this afternoon with a dedicated br1 bridge for guests wls
It works, but even with Net Isolation enabled and br1_bridged=0, guests still have access to the router.
I believe it comes from 3 bad rules in INPUT:
line 18 is not optimal (unuseful)
line 8 is a remaining back-door for http once the following would be removed
line 7 is the culprit allowing anything from -i br1
Posted: Sun Oct 23, 2016 20:45 Post subject: Re: Guest bridge vaps 2G & 5G
Bib wrote:
mrjcd wrote:
As mentioned bridgeing the two and using one DHCP makes most sense .......
I ran tests this afternoon with a dedicated br1 bridge for guests wls
It works, but even with Net Isolation enabled and br1_bridged=0, guests still have access to the router.
I believe it comes from 3 bad rules in INPUT:
line 18 is not optimal (unuseful)
line 8 is a remaining back-door for http once the following would be removed
line 7 is the culprit allowing anything from -i br1
That is a problem using br1 for guests network on newer builds..... don't work like in the old days.
That's why I mentioned same subnet...using different IP and DHCP that doesn't run over itself. Don't know that it would work.. likely net isolation might kill it all. Just something I thought was interesting and eill try when I get time.
You can sort thru firewall rules to make br1 work but most people will leave the br1 accessable to its own gateway IP or if using as a WAP its hard to keep br1 clients from accessing main router/WAN gateway by IP ... They really simplified these things with working net isolation.
e.g. net isolation works well on broadcom K3.x 27858 on a WAP but not on atheros boxs. It still leaves some minor things open. LocalDNS can still get guest to some things and/or direct IP. 29739 on most atheros routers used as WAP will work great.
Just a heads up that whaterver you use double check everything by IP.
Posted: Tue Oct 25, 2016 5:32 Post subject: Slows doen after few days
Router: R7000
Firmware: DD-WRT v3.0-r30700M kongac (09/27/16)
Kernel: Linux 4.4.22
Status: Worked well for 3 days
Reset: After Upgrade, Erase NVRAM & Manually Configure
Errors: None for 3 days
After 3 days the router throughput on the 2.4ghz wirelsess slowed down to 100kbs with a ping between 100-800ms. A reboot didn't help. No services were running except for secure shell and one assigned ip.
Posted: Tue Oct 25, 2016 5:50 Post subject: Re: Slows doen after few days
amml wrote:
Router: R7000
Firmware: DD-WRT v3.0-r30700M kongac (09/27/16)
Kernel: Linux 4.4.22
Status: Worked well for 3 days
Reset: After Upgrade, Erase NVRAM & Manually Configure
Errors: None for 3 days
After 3 days the router throughput on the 2.4ghz wirelsess slowed down to 100kbs with a ping between 100-800ms. A reboot didn't help. No services were running except for secure shell and one assigned ip.
I went back to r29300. All fine again.
If it worked for 3 days and a reboot didn't help, then it is obvious, that it was not the build:-)
29300 has the same wireless driver as the current build.
After more days of data gathering, I now have a theory on what was causing the occasional WiFi client drops. Kong, I'm sure you remember that my first theory was that iPhone 6 connections caused some sort of problem but that didn't bear out. I don't think any one type of device causes it: I think it might be related to the running state of the router once it thinks it has detected a DNS rebind attack.
I do recall seeing the message about "potential DNS rebind attack" (not sure of the exact wording but I think I'm close) in SysLog after noticing dropped clients. Recently I found a way to reproduce the problem (although it's not reliable as it doesn't happen every time). If I watch a show, home movie, etc. using Plex Media Server streaming to my Xbox One, that occasionally produces that "potential DNS rebind attack" message in SysLog. Most of the time when I get that message, I have a dropped IP camera that cannot reconnect until after a router reboot. The IP address of the camera is not the same as the Xbox One of course, so I don't know why that would happen unless the code that deals with that error is causing the broken connections. Meaning that once that error occurs, some variable (or code) gets broken until a reboot.
Knowing that the message came from dnsmasq, I disabled dnsmasq on the main setup tab and also unchecked the dnsmasq service on the services tab (you have to do both). Since then, I've used Plex at least a dozen times with no issue. No issues at all with the router since I completely disabled dnsmasq. BTW, my Xbox One had DNS set to 192.168.1.1 so once I disabled dnsmasq I had to change that to my usual OpenDNS IP's. I don't know if having the Xbox One set to 192.168.1.1 for DNS was what caused the Xbox One to initiate the "bug".
Sorry about being wordy: wanted to be as concise as possible. Long story short, my theory is that whatever code gets run when that rebind attack message appears in SysLog is causing the problem with dropped WiFi clients that won't reconnect until after rebooting the router. My suggestion is to trace the code related to rebind attack detections to see if anything in there could cause the radios to be in a "bad state" or could cause IP's unrelated to the detected "attack" to be affected in some way.
R7000 update: up for 12 days now on this build without issue. Yesterday I ftp'd about 25GB to a remote server, and crashed the router on the remote site. Twice. The local R7000 kept on ticking.
After more days of data gathering, I now have a theory on what was causing the occasional WiFi client drops. Kong, I'm sure you remember that my first theory was that iPhone 6 connections caused some sort of problem but that didn't bear out. I don't think any one type of device causes it: I think it might be related to the running state of the router once it thinks it has detected a DNS rebind attack.
I do recall seeing the message about "potential DNS rebind attack" (not sure of the exact wording but I think I'm close) in SysLog after noticing dropped clients. Recently I found a way to reproduce the problem (although it's not reliable as it doesn't happen every time). If I watch a show, home movie, etc. using Plex Media Server streaming to my Xbox One, that occasionally produces that "potential DNS rebind attack" message in SysLog. Most of the time when I get that message, I have a dropped IP camera that cannot reconnect until after a router reboot. The IP address of the camera is not the same as the Xbox One of course, so I don't know why that would happen unless the code that deals with that error is causing the broken connections. Meaning that once that error occurs, some variable (or code) gets broken until a reboot.
Knowing that the message came from dnsmasq, I disabled dnsmasq on the main setup tab and also unchecked the dnsmasq service on the services tab (you have to do both). Since then, I've used Plex at least a dozen times with no issue. No issues at all with the router since I completely disabled dnsmasq. BTW, my Xbox One had DNS set to 192.168.1.1 so once I disabled dnsmasq I had to change that to my usual OpenDNS IP's. I don't know if having the Xbox One set to 192.168.1.1 for DNS was what caused the Xbox One to initiate the "bug".
Sorry about being wordy: wanted to be as concise as possible. Long story short, my theory is that whatever code gets run when that rebind attack message appears in SysLog is causing the problem with dropped WiFi clients that won't reconnect until after rebooting the router. My suggestion is to trace the code related to rebind attack detections to see if anything in there could cause the radios to be in a "bad state" or could cause IP's unrelated to the detected "attack" to be affected in some way.
Good question! I never tried that. The last time it happened was when I had dnsmasq unchecked on the main setup tab but the service was still checked on the Services tab. When I lost an IP camera, I went to the Services tab and discovered dnsmasq was still checked so I unchecked it and did Apply. Don't take this as fact because I'd have to double check it, but as I remember, the camera did not reconnect even after unchecking and applying (I still had to reboot). I assume unchecking and applying would stop the service. Obviously it wouldn't restart it though: don't know if that part is necessary for the test.
Joined: 21 Jul 2006 Posts: 1898 Location: Fortaleza Ce Brazil
Posted: Wed Oct 26, 2016 15:41 Post subject:
<Kong> wrote:
mchaney wrote:
R8500...
After more days of data gathering, I now have a theory on what was causing the occasional WiFi client drops. Kong, I'm sure you remember that my first theory was that iPhone 6 connections caused some sort of problem but that didn't bear out. I don't think any one type of device causes it: I think it might be related to the running state of the router once it thinks it has detected a DNS rebind attack.
I do recall seeing the message about "potential DNS rebind attack" (not sure of the exact wording but I think I'm close) in SysLog after noticing dropped clients. Recently I found a way to reproduce the problem (although it's not reliable as it doesn't happen every time). If I watch a show, home movie, etc. using Plex Media Server streaming to my Xbox One, that occasionally produces that "potential DNS rebind attack" message in SysLog. Most of the time when I get that message, I have a dropped IP camera that cannot reconnect until after a router reboot. The IP address of the camera is not the same as the Xbox One of course, so I don't know why that would happen unless the code that deals with that error is causing the broken connections. Meaning that once that error occurs, some variable (or code) gets broken until a reboot.
Knowing that the message came from dnsmasq, I disabled dnsmasq on the main setup tab and also unchecked the dnsmasq service on the services tab (you have to do both). Since then, I've used Plex at least a dozen times with no issue. No issues at all with the router since I completely disabled dnsmasq. BTW, my Xbox One had DNS set to 192.168.1.1 so once I disabled dnsmasq I had to change that to my usual OpenDNS IP's. I don't know if having the Xbox One set to 192.168.1.1 for DNS was what caused the Xbox One to initiate the "bug".
Sorry about being wordy: wanted to be as concise as possible. Long story short, my theory is that whatever code gets run when that rebind attack message appears in SysLog is causing the problem with dropped WiFi clients that won't reconnect until after rebooting the router. My suggestion is to trace the code related to rebind attack detections to see if anything in there could cause the radios to be in a "bad state" or could cause IP's unrelated to the detected "attack" to be affected in some way.
Hope this helps.
Mike
Do they reconnect if you restart dnsmasq?
stopservice dnsmasq && startservice dnsmasq
Mike & Kong
same here .. this happens with BS builds too ( 30796 )
I will try without dnsmasq like mike said ..
_________________ DDwrt ...it rocks ....
1 R7800 54420 AP Wireguard webserver JFFS SAMBA FTP usb HD Mesh
1 R7800 54420 Cli Mesh
1 WZR1750 54389 AP Webserver Samba Wireguard
1 TP link Archer C7v5 54420 Cli Mesh
1 DD x86_64 48296 Gateway Samba Ftp Webserver
I did have that as a passing thought. I wanted to disable dnsmasq anyway due to it filling the SysLog with useless information and not being of much benefit anyway (from what I can tell) so I never tried just disabling No DNS rebind.
