Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Duplicate allow rules created by wifidog when a user authenticates #55
@Kvncrck: Thank you,
I deliberately deleted your message because your post match mac adress trusted.
In fact, i want users who are truly authenticated or an account is created.
No need to send "Chain WiFiDog_eth1_Trusted".
We are using apAuthSplashOnlyPlugin for authentication. Here is the output
Chain PREROUTING (policy ACCEPT)
Chain INPUT (policy ACCEPT)
Chain FORWARD (policy ACCEPT)
Chain OUTPUT (policy ACCEPT)
Chain POSTROUTING (policy ACCEPT)
Chain WiFiDog_eth1_Incoming (1 references)
Chain WiFiDog_eth1_Outgoing (1 references)
Chain WiFiDog_eth1_Trusted (1 references)....
On Tue, Feb 24, 2015 at 8:34 AM, florida63 firstname.lastname@example.org wrote:
One possible fix is to first check if the rule already exists before creating it.
At one point the code always removed access before granting it in the re-auth code path. This was added explicitly in 2004 and removed a few years later probably because it made no sense without comments.
The problem with that approach is a race condition where the users' access is removed and recreated a few (hundreds in some case) milliseconds later.
on the auth page I log (1 time) and then sign out, I reconnected and sign out, etc, etc.
the command "iptables -L -t mangle returns me
wdctl restart and iptables -L -t mangle
wdctl restart makes the household.
Wdctl restart did not seem to fix the problems. I would stop wifidog, then start it. Users would have to revisit the Terms of Service page. I would do this often until I discovered that wdctl status seemed to be the cause. Perhaps executing the problematic "wdctl status" right after trying a wdctl restart led me to conclude that wdctl restart was not working.
I am not sure if this is related to the problem... The wifidog process dies after a period of time, typically 2 - 3 times a day. I did find OOM errors in the logs. The wifidog gateway is running Debian and has 8 GB memory. I monitored the processes on the wifidog gateway using ps and top periodically for a few days. Most of the time the wifidog process consumed very little memory. On one occasion I caught it consuming all available memory. Stopping the wifidog and starting it resolved the problem.
@acv: Always the same conclusion with the last release (by the same test as above).
however, if I wait a moment that I
root@Auz2:/etc# [Sat Jan 1 04:50:46 2000]8604 iptables_fw_counters_update(): Could not find 10.63.57.13 in client list, this should not happen unless if the gateway crashed
It must wait until iptables_fw_counters_update () is called for it to do the household.
I compiled from the git source and manually installed ecyassl with --enable-ecc.
wfgw kernel: [38113.926752] traps: wifidog general protection ip:7fe5ac715a3f sp:7fe5a8c85b80 error:0 in libc-2.18.so[7fe5ac69c000+1a0000]
I was able to restart wifidog, but it looks like I should go back to the previous version.
I kept running the latest build of wifidog after the general protection faults. I was suspicious of the "wdctl status" command, so I stopped running it. I haven't seen any more general protection faults since I stopped using wdctl status. I did find that the wifidog process on occasion would start consuming all available memory again. It crashed about 3 or 4 times yesterday. I think the OOMs are occurring with the same frequency as the old build.
I should point out that I have a number of other sites with 50+ simultaneous users where wifidog is rock solid. It is only at the site with a very high user volume (200 - 300 users) that we have problems.