发表文章

[C] 使用远程身份验证和 EnablePreauth 的问题 Trouble using remote authentication and EnablePreauth[nodogsplash]

phenobarbital 2017-10-9 28

我使用 EnablePreauth 进行远程 mac 地址身份验证, 它按预期方式使用此配置工作:
BinVoucher/本地/宾/preauth
EnablePreAuth 1
ForceVoucher 0

但脚本被反复调用, 直到身份验证:
周六 9月17日 08:00:49 2016 用户. 通知 preauth: sendind pre-auth
周六 9月17日 08:00:50 2016 用户. 通知 preauth: sendind pre-auth
周六 9月17日 08:00:51 2016 用户. 通知 preauth: sendind pre-auth
周六 9月17日 08:01:02 2016 用户. 通知 preauth: sendind pre-auth
周六 9月17日 08:01:02 2016 用户. 通知 preauth: sendind pre-auth
星期六 9月17日 08:01:03 2016 守护程序. 通知 nodogsplash [16434]: 验证 10.0.0.79 04:4b: ed: 88:3a: 2 c

这个问题目前在 Iphone 中更引人注目, 我们的远程认证服务器反复调用。
这是正常的吗?

原文:

I'm using EnablePreauth for remote mac address authentication, it works as expected with this configuration:
BinVoucher /usr/local/bin/preauth
EnablePreAuth 1
ForceVoucher 0

but script is called over and over again until authentication:
Sat Sep 17 08:00:49 2016 user.notice preauth: sendind pre-auth
Sat Sep 17 08:00:50 2016 user.notice preauth: sendind pre-auth
Sat Sep 17 08:00:51 2016 user.notice preauth: sendind pre-auth
Sat Sep 17 08:01:02 2016 user.notice preauth: sendind pre-auth
Sat Sep 17 08:01:02 2016 user.notice preauth: sendind pre-auth
Sat Sep 17 08:01:03 2016 daemon.notice nodogsplash[16434]: Authenticating 10.0.0.79 04:4b:ed:88:3a:2c

this issue is currently more noticeable in Iphone, calling over and over again our remote auth server.
this is normal?

相关推荐
最新评论 (4)
mwarning 2017-10-9
1

也许电话会打多个电话?也许你可以测试一下

原文:

Maybe the phone makes multiple calls? Maybe you can test that.

bluewavenet 2017-10-9
2

这可能是在专属的门户检测领域。通常情况下, 一个设备将循环 ssid 它知道, 如果一个俘虏的门户被检测到, 它会移动到下一个它可以看到。它可以多次尝试得到最强的信号1。闭合的网络, 2。打开, 3。captive-in 那命令这一切都不同于供应商的供应商, 当然, 我已经注意到苹果设备做这比其他人, 但并不可怕。通常需要几圈/秒来连接和显示初始页面。我发现, 在设备上, 你可以看到它骑自行车-连接, 下降, 连接等。您可以直接选择所需的 ssid, 或者在设备上 "忘记" 它, 然后重新连接。这将强制门户检测留在所选的 ssid 上, 而不是循环轮寻找 "最佳"。
有许多实施的专属门户检测和一些比其他更好。它正在迅速发展。我不确定我们能否在 NodogSplash 结束时做很多事情。

原文:

This may be in the realms of Captive Portal Detection. Typically a device will cycle round ssids it knows about and if a captive portal is detected it will move on to the next it can see. It can go round a few times trying to get the strongest signal of 1. closed networks, 2. open, 3. captive - in that order. This all varies from vendor to vendor of course and I have noticed Apple devices doing this more than others, but not terribly so. It usually takes a few cycles/seconds to connect and show the splash page. I have found that on the device you can see it cycling - connect, drop, connect etc. You can make this immediate by either selecting manually the ssid you want or "forget" it on the device then reconnect. This forces the portal detection to stay on the ssid selected rather than cycle round looking for the "best".
There are many implementations of Captive Portal detection and some are better than others. It is evolving rapidly. I am not sure we can do much at the NodogSplash end though.

gazambuja 2017-10-9
3

我认为最好的选择在这里 (我这样做)/本地/bin/preauth 做一些缓存, 以避免性能问题。

原文:

I think the best option here (I do this) in /usr/local/bin/preauth make some cache to avoid performance issues.

lynxis 2017-10-9
4

我猜你说的是版本0.9 还是版本1.0?权利.所以我把这个标记给 v1

原文:

I guess you're talking about version 0.9 or version 1.0? right. So I'm flagging this to v1.

返回
发表文章
phenobarbital
文章数
2
评论数
0
注册排名
60912