发表文章

[C] 修改代码片断 Modifying pieces of code[nodogsplash]

mpbuijs 2017-10-9 63

首先, 很抱歉在这里发帖, 这是我第一次想问一些关于 GitHub 上可用代码的问题。如果我应该张贴在其他地方或联系个人, 请告诉我。

我的问题是, 我想使用发行版本 (0.9_beta9.9 8-1) 中提供的 Binvoucher 和预选项。但是, 此版本似乎较慢, 因为将人员重定向到初始页, 并且只有端口80被阻止用于 preauthenticated 用户 (甚至端口443似乎是打开的, 因此人们可以使用 https)。所有这一切, 我做的 OpenWrt (在一个 TP 链接 WDR3600)。我还尝试了 "标准" 版本的 OpenWrt nodogsplash (0.9_beta9.9 6-3)。在重定向速度和阻塞所有端口方面, 这似乎效果更好。

所以对我来说现在有两个选择。第一个是使用发布版本的 nodogsplash, 修复重定向速度问题, 并找到阻止所有端口而不是仅端口80的方法。我一直在寻找 iptables, 但我找不到问题, 我不很熟悉那些不幸..。

第二个选项, 这是最适合我, 是采取版本 0.9_beta9.9. 6-3, 这似乎是更稳定的 OpenWrt, 已经阻止所有端口自动和重定向速度似乎更好。那我还是需要一个方法来做验证这是因为我想使用多个节点/路由, 我不希望客户端在每次切换节点时显示初始页, 因为它们从一个位置移动到某个位置。所以我需要从发行版中取一些代码, 特别是在文件 nodogsplash/src/http。现在我真的不知道如何开发/修改 nodogsplash。因此, 在这种情况下, 我的问题是什么最简单的/最好的方法是做一个小修改的源代码的 nodogsplash, 编译和测试它。它只需要在 OpenWrt 上工作, 也许这会让事情变得更简单?目前我安装 nodogsplash 使用 opkg, 所以我要创建一个 ipk 文件包含修改过的 nodogsplash 代码, 但我是开放的更容易解决我的问题。

任何帮助将不胜感激!

原文:

First of all, sorry for posting this here, this is the first time I want to ask something about code available on GitHub. If I should post this somewhere else or contact someone personally please tell me.

The problem I have is that I wanted to use the Binvoucher and Preauthentication options available in the release version (0.9_beta9.9.8-1). However, this version seems to be slower with redirecting people to the splash page and only port 80 is blocked for preauthenticated users (even port 443 seems to be open so people can just use https). All this I am doing on OpenWrt (on a TP-Link WDR3600). I also tried the "standard" version for OpenWrt of nodogsplash (0.9_beta9.9.6-3). This seemed to work better with respect to redirection speed and blocking of all ports.

So for me there are two options now. The first is to use the released version of nodogsplash, fix the redirection speed issue and find a way to block all ports instead of only port 80. I have been looking into the iptables but I could not find the issue, I am not very familiar with those unfortunately...

The second options, which looks best to me, is to take version 0.9_beta9.9.6-3 which seems to be more stable on OpenWrt, already blocks all ports automatically and the redirection speed seems better. Then I still need a way to do pre-authentication. That is because I want to use multiple nodes/routes and I don't want clients to be shown the splash page every time they switch nodes because they move from place to place. So I would need to take some pieces of code from the release version, specifically in the file nodogsplash/src/http.c. Now I don't really know how to develop for/modify nodogsplash. So in this case my question would be what the easiest/best way would be to make a small modification to the source code of nodogsplash, compile and test it. It only has to work on OpenWrt, maybe that makes things easier? Currently I install nodogsplash using opkg so I would have to create an ipk file containing the modified nodogsplash code, but I am open to easier solutions to my problem.

Any help would be highly appreciated!

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

嗯, 所有的 preauthenticated 用户都应该阻止 (重定向端口80除外)。
关于速度问题, 我想知道这是否与删除的多线程有关。
但这似乎不太可能。
有关修改和测试 OpenWrt 的 NDS 代码的说明, 请在这里找到: https://github.com/nodogsplash/nodogsplash/tree/master/openwrt

原文:

Hm, everything should blocked for preauthenticated users (except for port 80 that is redirected).
Regarding the speed issues - I wonder if this is related to the multithreading that was removed.
But this does not seem to be very likely.
Instructions for modifying and testing the NDS code for OpenWrt can be found here: https://github.com/nodogsplash/nodogsplash/tree/master/openwrt

kinhunt 2017-10-9
2

问题确认 0.9_beta9.9 8。预用户可以访问除80以外的任何端口。我认为这是一个大问题。因为大多数移动应用程序在不使用80端口的情况下可以正常工作。0.9_beta9.9 6 工作正常, 但它没有 binvoucher 功能, 这对于自定义身份验证策略非常有用。

原文:

issue confirmed 0.9_beta9.9.8. pre-authenticated user can access any ports other than 80. I think this is a big problem. because most mobile app works fine without using 80 port. 0.9_beta9.9.6 works fine but it doesn't have the binvoucher feature, which is very useful for customizing authentication strategy.

mwarning 2017-10-9
3

好的, 我可以确认这个问题。这真的很糟糕我将标记最新版本。

原文:

Alright, I can confirm the issue. This is really bad. I will mark the latest release.

mwarning 2017-10-9
4

罪魁祸首是 73e5b8d

原文:

The culprit is 73e5b8d

contentfree 2017-10-9
5

73e5b8d的哪一部分是罪魁祸首?

原文:

Which part of 73e5b8d is the culprit?

mwarning 2017-10-9
6

我还在调查但我需要先睡一觉

原文:

I'm still investigating. But I need some sleep first.

mwarning 2017-10-9
7
kinhunt 2017-10-9
8

感谢您@mwarning。如何 "此版本似乎是较慢的重定向人到初始页" 问题?有什么猜测吗?

好好睡一觉。

原文:

Thank you @mwarning. How about the "this version seems to be slower with redirecting people to the splash page" problem? Any guess?

Have a good sleep.

contentfree 2017-10-9
9

@kinhunt"将用户重定向到" 初始页 "的表现是什么?

我们使用 NDS 在一个 OM2P, 并在同一智能手机, 我们得到的初始页时加入 wifi AP 只有一半的时间。其余的时间, 我们必须打开一个浏览器, 并要求任何 URL 得到它。

原文:

@kinhunt What's the behavior exhibited by this "seems to be slower with redirecting people to the splash page"?

We're using NDS on an OM2P and, on the same smartphone, we get the splash page when joining the wifi AP only half the time. The rest of the time we have to open a browser and request any URL to get it.

kinhunt 2017-10-9
10

您好@contentfree。mpbuijs 在最初的帖子中描述了这个问题。初始页面的加载时间可以是非常缓慢 (3-5 秒) 与 0.9_beta9.9 8, 而它的瞬间在 beta9.9.6。我在 openWRT 上证实了这一点

原文:

hi @contentfree. mpbuijs described this issue in the original post. The loading time of splash page can be very slow(3-5 seconds) with 0.9_beta9.9.8 while it's instant in beta9.9.6. I confirm this on openWRT.

contentfree 2017-10-9
11

对不起@kinhunt。你是对的。

您是否曾经体验过在加入网络时没有显示 (在 iOS 中, 具体) 的初始页面?(并且仅当您直接在 web 浏览器中请求 URL 时才显示它?

这似乎是一个缓慢的负载可能是相关..。

原文:

Sorry @kinhunt. You're right.

Have you ever experienced the splash page not showing (in iOS, specifically) when joining the network? (And it only being displayed when you request a URL in the web browser directly?)

It seems like a slow load could be related…

kinhunt 2017-10-9
12

@contentfree , 我没有经历过。它可能与加载时间问题有关。

原文:

@contentfree , I haven't experienced that. It is probably related to the loading time issue.

kinhunt 2017-10-9
13

让我们希望 mwarning 解决他梦中的问题。

原文:

Let's hope mwarning solved the problems in his dream.

sayuan 2017-10-9
14

我是删除多线程的人: #9
第一个念头, 我想这可能和多线程有关。
不过, 我已经做了一些压力测试, 似乎 non-threading 版本比多线程版本略快。

我运行的 nodogsplash, 基于最新的版本, 并删除提交 73e5b8d , 数百个 APs 几个月。
到目前为止, 所有工作都很棒, 我没有遇到任何速度问题。

我也试图重现这个问题使用最新版本 (只恢复2行, mwarning 提到) 和默认配置, 但一切看起来很好, 我。

一些问题:

  1. 速度问题是否始终存在?如果重新启动 nodogsplash 会发生什么?
  2. 您的网络中是否有其他用户?一些愚蠢的应用程序可能会创建大量的 HTTP 请求, 如果他们不能连接到他们自己的服务。
  3. top, netstat -tlan 命令是否输出异常高的 cpu, 大量的连接?
原文:

I am the guy who remove multi-threading: #9
On the first thought, I guess it might related to multi-threading, too.
However, I had already do some stress tests, and it seems the non-threading version is slightly faster than multi-threading version.

I ran the nodogsplash, based-on the latest release and remove the commit 73e5b8d, on hundreds of APs for months.
Up to now, there are all work great and I didn't experience any speed issue.

I am also trying to reproduce this issue using the latest release (only revert 2 lines that mwarning mentioned) and default config, but everything looks fine to me.

Some questions:

  1. Is the speed issue always exist? What happen if you restart nodogsplash?
  2. Is there other users in your network? Some stupid app might create a large number of HTTP requests if they cannot connect to their own services.
  3. Are top, netstat -tlan commands output any unusual? high cpu, large amount of connections?
kinhunt 2017-10-9
15

您好@sayuan 。我做了一些测试, 在一个干净的 openwrt + nodogsplash 环境, 低 cpu 和很少连接。每次加载初始页面花了5-10 秒 (chrome/safari osx, iphone 上似乎很好)。但是, 如果我使用 ip 地址 (任何) 而不是域名, 立即加载初始页。我想这可能与 dns 和防火墙规则有关。

您在生产环境中使用的是哪个版本?难道你没有预客户端可以访问任何端口, 但80的问题?

谢谢。

原文:

hi @sayuan . I did some test on a clean openwrt+nodogsplash environment, low cpu and few connections. It took 5-10 seconds to load the splash page every time (chrome/safari on osx, it seems to be fine on iphone). However, if I use ip address (any) instead of domain name, splash page loaded instantly. I am thinking maybe it's related to dns and firewall rules.

Which version are you using in your production environment? Don't you have the issue which pre-authenticated clients can access any ports but 80?

Thank you.

sayuan 2017-10-9
16

您好@kinhunt
谢谢你的信息, 但我仍然不能重现这个问题。
可以在预状态下执行以下命令, 并查看进程返回的速度:

  1. nslookup github.com
  2. wget --max-redirect 0 -O - http://github.com

我使用的版本是最新版本, 有一些小的更改, 并恢复提交 73e5b8d
原因是我不想用这种方式使用 QoS, 所以我没有面对这个问题。

谢谢.

原文:

HI @kinhunt
Thanks for your informations, but I still cannot reproduce this issue.
Can you execute the following commands in pre-authenticated state, and see how fast does the process return:

  1. nslookup github.com
  2. wget --max-redirect 0 -O - http://github.com

The version I use is the latest release with some minor changes, and revert the commit 73e5b8d.
The reason is that I don't want to use QoS that way, so I have not faced that problem.

Thanks.

mwarning 2017-10-9
17

我试图找出延迟的问题。但是, 在测试过程中, 初始页面几乎立即出现在所有版本中。昨天, 我能够重现它。:/

原文:

I tried to pinpoint the delay problem. But the splash page appeared almost instantly for all revisions during testing. Yesterday, I was able to reproduce it. :/

kinhunt 2017-10-9
18

@sayuan , 这两个命令将立即返回。我想也许这是一个浏览器特定的问题 (chrome osx)。我会在其他浏览器和操作系统上做更多的测试。

@mwarning , 谢谢。新的 ipk 准备好了吗?我试着用 openwrt 编译它。我的电脑很慢。它已经运行了2小时。

原文:

@sayuan , those two commands return instantly. I am thinking maybe it's a browser specific problem (chrome on osx). I will do some more tests on other browsers and os' .

@mwarning , thank you. is the new ipk ready? I tried to compile it with openwrt. My computer is slow. It had been running for 2 hours.

kinhunt 2017-10-9
19

最后, 得到了编译。防火墙问题解决了, 是的!但 "缓慢加载初始页" 问题仍然存在。

原文:

finally, got compiled. the firewall issue is solved, yeah!!!. but the "slow loading splash page" problem is still there.

mwarning 2017-10-9
20

@kinhunt , 我首先尝试了解问题。否则, 我们可能会引入另一个问题。

凭证代码 (引入了 bug) 源自此自定义源程序包: http://dev.cloudtrax.com/downloads/patches/nodogsplash-0.9_beta9.9.6.tar.gz
我们当前的代码库的差异主要是空白更改。
我将尝试检查上面的包是否有 bug (显然不是), 看看我们忘记了什么端口。

原文:

@kinhunt , I try to understand the problem first. Otherwise we might introduce another problem.

The voucher code (that introduced the bug) originated from this custom source package: http://dev.cloudtrax.com/downloads/patches/nodogsplash-0.9_beta9.9.6.tar.gz
The differences to our current code base are mostly white space changes.
I will try to check if the package above has the bug (apparently not) and see what we forgot to port.

mpbuijs 2017-10-9
21

@mwarning , 感谢您指出在何处查找有关如何为 OpenWrt (https://github.com/nodogsplash/nodogsplash/tree/master/openwrt) 生成代码的信息。感谢大家努力解决所报道的问题。我遵循的指示, 建立和修改 nodogsplash 为 OpenWrt, 第一部分是完美的工作, 现在我: 在. ipk 文件中构建当前版本的 nodogsplash。请注意, 我还必须选择 nodogsplash 在 "menuconfig" 在网络 > 专属门户部分, 否则它不会建立 nodogsplash. ipk 文件。现在我想对 nodogsplash 的代码进行修改, 但这似乎行不通。我下载了http://dev.cloudtrax.com/downloads/patches/nodogsplash-0.9_beta9.9.6.tar.gz, 做了一个小改动, 将其置于 git 控制之下, 添加了所有文件, 并使用两个绝对路径创建了符号链接。不过, 最新版本的 nodogsplash 是建立。请注意, 我还选择了 "高级配置选项" = > "启用包源树覆盖" 的开发选项。

我还想谈一谈关于 0.9_beta9.9 8-1 (再次使用 OpenWrt WDR3600) 的另一个问题。也许开始一个新的问题是好的。即 BinVoucher 支持输出脚本没有收到完整的 mac 地址的事实。在 http. c 行216-218 和393-395 中, 根据 nodogsplash 中 BinVoucher 的值, 调用脚本进行远程身份验证. conf。在这两种情况下, 传递给脚本的 MAC 地址的最后一部分丢失。与最后一部分, 我的意思是最后4十六进制从客户端的 MAC 地址, 包括中间的分号。因此, 我在脚本中收到的输出是 "04:0c: ce: dd" 和 "04:0c: ce: dd:" 的格式。我命名的脚本 "/bin/myauthentication", 这也是设置在 BinVoucher 变量。我最好的猜测是, 问题在于在两种情况下调用的 sprintf 函数, 以创建要用于执行的字符串。这里所提到的 sprintf 的问题是: http://linux.die.net/man/3/snprintf "因为 sprintf () 和 vsprintf () 假设一个任意长的字符串, 所以调用方必须注意不要溢出实际空间;这往往无法保证 "。底线: 我不认为这是打算验证 16 ^ 4 = 65536 MAC 地址, 而不是只有一个。我没有做任何计算, 但在我看来, 在大型网络的机会将大大增加, 人们将有相同的8十六进制在他们的 MAC 地址。

最后, 我将对不同版本的不同浏览器的初始页面的长加载时间问题进行更多的测试。

原文:

@mwarning , thank you for pointing out where to look for information on how to build code for OpenWrt (https://github.com/nodogsplash/nodogsplash/tree/master/openwrt). And thank you all for trying to solve the reported issues. I followed the instructions to build and modify nodogsplash for OpenWrt and the first part works perfectly for me now: building the current version of nodogsplash in an .ipk file. Notice that I also had to select nodogsplash during "make menuconfig" in the Network->Captive Portal section, else it wouldn't build the nodogsplash .ipk file at all. Now I wanted to make changes to the code of nodogsplash, but that didn't seem to work. I downloaded http://dev.cloudtrax.com/downloads/patches/nodogsplash-0.9_beta9.9.6.tar.gz, made a minor change, put it under git control, added all files and created the symbolic link using two absolute paths. Still, the newest version of nodogsplash is built. Notice that I also selected the development option "Advanced configuration options" => "Enable package source tree override".

I would also like to address another issue with respect to the 0.9_beta9.9.8-1 (again using OpenWrt on a WDR3600). Maybe it would be good to start a new Issue for that. Namely the fact that the BinVoucher support output script does not receive complete mac addresses. On lines 216-218 and 393-395 in http.c a script is called for remote authentication based on the value of BinVoucher in nodogsplash.conf. In both cases the last part of the MAC addresses passed to the script is missing. With the last part I mean the last 4 hexadecimals from the MAC address of the client including the middle semicolon. So the output I receive in the script that I call is of the form "04:0c:ce:dd" and "04:0c:ce:dd:". I named the script "/bin/myauthentication" and this is also set in the BinVoucher variable. My best guess is that the problem lies in the sprintf function called in both cases to create the string that is going to be used to execute. The problem with sprintf I am referring to here is documented here: http://linux.die.net/man/3/snprintf "Because sprintf() and vsprintf() assume an arbitrarily long string, callers must be careful not to overflow the actual space; this is often impossible to assure". Bottom line: I don't think it was the intention to authenticate 16^4=65536 MAC addresses instead of only one. I didn't do any calculations but it seems to me that on large networks chances will increase significantly that people will have the same 8 hexadecimals in their MAC addresses.

Last, I will do some more testing on the problem regarding long loading times of the splash page on different versions with different browsers.

mwarning 2017-10-9
22

关于http://dev.cloudtrax.com/downloads/patches/nodogsplash-0.9_beta9.9.6.tar.gz:

  • 虫子也在那里, 所以它可能不是我们的错 (TM);我等待作者确认。
  • 二进制期望预先创建两个链;使用 "iptables 过滤器-n NDS_FW_NG" 和 "iptables-t nat NDS_FW_NG" 创建它们

@mpbuijs: rm -r build_dir/target*/nodogsplash* 再次尝试并生成包。如果这个工作, 我们需要更新的方式。请为 MAC 问题创建一个新的问题/票证。我还没看
它还。216-218 和393-395 行在 http 中看起来很好。也许你的 BinVoucher 值太长 (> 230 字符)?

原文:

Regarding http://dev.cloudtrax.com/downloads/patches/nodogsplash-0.9_beta9.9.6.tar.gz:

  • the bug is there as well, so it may not be our fault (TM); I wait for the authors confirmation.
  • the binary expects two chains to be created beforehand; use "iptables -t filter -N NDS_FW_NG" and "iptables -t nat -N NDS_FW_NG" to create them

@mpbuijs: Try rm -r build_dir/target*/nodogsplash* and build the package again. If this works we need to update the howto. Please create a new issue/ticket for the MAC issue. I haven't looked into
it yet. Lines 216-218 and 393-395 in http.c look ok to me. Maybe your BinVoucher value is too long (>230 characters)?

mwarning 2017-10-9
23

好吧, 在一些帮助我们得到了它想通 out-sort。
上面提到的包有-I (前置) 更改为-A (追加), 因为否则 NDS 在处理通信量后将忽略所有以下防火墙规则。
使用-A, OpenWrts 默认防火墙规则首先应用。但这些都是 "全部接受"。结果-NDS 甚至没有得到任何流量拒绝/接受。上面的软件包是在不使用 OpenWrt 防火墙的环境中使用的, 因此该问题不存在。

我们该怎么办?使用-我和以前似乎是合乎逻辑的选择。这将是很好的, 让 OpenWrt 防火墙做它的东西时, 我们可以禁用 "接受所有" 的行为, 而不费力。
但先前的行为是预期的。因此, 我们应该使用-我 (和以前一样), 直到有一个更好的解决方案。

原文:

Alright, after some help we got it figured out - sort of.
The package mentioned above has -I (prepend) changed to -A (append) because otherwise NDS would ignore all following firewall rules once it has handled traffic.
With -A, OpenWrts default firewall rules apply first. But those have "ACCEPT all". As a consequence - NDS does not even get any traffic to reject/accept. The package above was used in an environment that does not use the OpenWrt firewall - so this problem was non-existent there.

So, what do we do? Using -I as before seem to be the logical choice. It would be good to let the OpenWrt firewall do its stuff when we can disable the "ACCEPT all" behavior without effort.
But the previous behavior is what was expected. Therefore we should use -I (as before) until there is a better solution.

mwarning 2017-10-9
24

d6bddae中还原了 iptable 的更改。请测试代码并为所有其他未决问题打开新的票证。感谢所有的反馈!:-)

原文:

The iptable -A/-I changes were reverted in d6bddae. Please test the code and open new tickets for all other outstanding issues. Thanks for all the feedback! :-)

返回
发表文章
mpbuijs
文章数
1
评论数
1
注册排名
60900