使用OpenWRT进行本地网络强制门户聊天

嘿！因此，最近我一直在思考当前的媒体状态如何引导我们花费大量时间关注全球事件和人员。我们与整个世界紧密相连，以至于有时我们看不到窗外正在发生的事情。与其通过在社交媒体上分享事件和想法来尝试尽可能地吸引最大的听众，不如将我们的工作转向本地社区怎么办？这看起来像是在外面钉牢活动海报，为社区互助聚会聚餐，还是在开放的本地网络上托管网页……？

我曾在柏林看到过这个想法-Google试图在Neukölln开设新总部，而人们则不允许这样做。除了抗议活动之外，有人在Google计划建立办公室的地方建立了本地网络。当您连接到网络时，它会弹出一个反Google宣传页面，每个人都应该注意。这是共享信息的一种很酷的补充方式，它局限于特定区域和想法。

我想在纽约在这里实现这样的功能，或者通过加入本地网络聊天以激发社区感以及一些（废奴主义？）宣传来使它更进一步。我想出了最重要的功能列表...

我们需要此项目的便携式路由器。这可能以多种不同的形式出现，我什至考虑使用Raspberry Pi，但最终由于其简单性和特殊功能而选择使用GL.iNet Slate Router。

这款可爱的便携式路由器带有OpenWRT的安装以及Admin Panel Web界面。我知道有时候我们都想成为终端纯化者，但是这个管理面板实际上非常好，并且有助于获得路由器状态的可视化表示。

为进行此实验做准备，我使用了管理面板来建立一个名为Starbucks WiFi的开放访客网络…（向我询问：p），我还使用该界面为访客网络启用了强制门户。根据您使用的路由器，您可能必须通过命令来弄清楚其中的一些内容，但是我很高兴获得此界面，并将享受它的好处：）

现在已经启用了强制门户，当连接到路由器时，我会收到一个弹出的html页面！现在将其与我们自己交换。

OpenWRT附带了NoDogSplash强制门户管理器。浏览文档时，我发现它发送给新连接的用户的html页面位于/etc/nodogsplash/htdocs/splash.html中。

因此，我们需要做的就是使用计算机上的scp复制带有（反资本主义？）宣传的html页面。

精彩！现在，每次您连接到开放的访客网络时，它都应该带您到（反Google？）宣传页面。

默认情况下，如果没有互联网，NoDogSplash强制门户将无法运行。如果路由器无法解析针对操作系统“连接性检查” URL的DNS请求（mac使用captive.apple.com），则NoDogSplash将返回错误并认为网络/强制门户不可用。

我发现这是一个非常棘手的问题，因为我的目标之一是将本地网络聊天带到无法保证WiFi连接的地方（纽约市地铁，街头抗议等）。此外，由于聊天的所有数据都是路由器本地的，因此实际上没有理由需要WiFi。

在浏览了一些G ithub问题之后，我发现了一个黑客，该黑客基本上将NoDogSplash配置为使用相同的随机公共地址在本地解析所有DNS查询，从而使它们似乎通过了“连接性检查”，并允许NoDogSplash继续进行。

（在路由器上）uci add_list dhcp。@ dnsmasq [0] .address =’/＃/ 121.122.123.124'＃重新启动后保存配置编辑以保持持久性uci commit dhcp service dnsmasq restart

在这一点上，我们基本上有足够的能力来重新创建Berlin anti google设置：）但是我仍然想看看是否有可能设置一个简单的聊天服务器。最简单的聊天需要运行的服务器，该服务器具有一条用于发布消息的路由，一条用于获取所有消息的路由，一个非常复杂的.json文件数据库以及一个用于显示聊天的html页面。

我只有的路由器模型只有128 mb的RAM ..所以我考虑下载Python-Light，但是它太轻了，没有SimpleHttpServer。我决定只是祈祷，希望该设备能够承受香草的Python安装。

然后从我的计算机上复制我的服务器代码和新的聊天html页面（我不会在这里描述聊天代码的工作方式，但是它非常简单，如果需要，您可以在此处进行查看：）

一切都很好…。但是，如果现在打开聊天，我们会看到对Python服务器的请求失败，并且连接超时，这意味着无法从聊天页面访问服务器正在侦听的端口。如果我们还记得的话，默认情况下，NoDogSplash负责强制门户，该门户会阻止大多数端口，因此我们可以调整其设置，以允许流量定向到服务器端口。

现在，如果我们再次运行服务器并尝试连接到开放式网络，我们的聊天窗口将弹出，作为一个强制门户，愉快地向本地服务器获取/发布请求：）

如果到此为止，那么您应该拥有一个自动捕获的门户，该门户会自动弹出并带有一个由运行在路由器上的简单Python服务器提供服务的聊天窗口。

为了达到理想的鲁棒性，我们需要确保我们的进程可以在重启后幸存！

OpenWRT使用Init Scripts配置在启动时运行的守护程序，如果我们使python服务器作为守护程序运行，则它有望能够在重启后幸存下来。

OpenWRT文档提供了一个非常简单的示例初始化脚本，我们可以根据需要对其进行修改：

＃！/ bin / sh /etc/rc.common START = 98 STOP = 98 start（）{echo“正在启动聊天服务器”（sleep 20; python /root/server.py)&} stop（）{echo“正在停止聊天服务器” killall python}

初始化脚本使用模板/etc/rc.common，该模板提供了其主要功能和默认功能，例如启动，停止，重新启动，启用和禁用。我们需要覆盖默认的启动和停止功能。如果您想了解有关初始化脚本详细信息的更多信息，请查看有关该主题的OpenWRT文档，它们很棒。

如果您在脚本中注意到，则我们的启动功能在该行中进行了很多操作：

首先，该进程在后台运行-用＆表示。我注意到，如果尝试在前台运行该进程，则不会显示管理面板！我有一个预感，init.d启动函数会阻塞，因此您需要启动的任何东西都需要通过将其自身作为后台进程运行来解决。

另一个奥秘是，如果我只运行（python /root/server.py)&而没有睡眠位，则服务器将无法正常启动。终止进程并使用/etc/init.d/chat start手动重新启动它之后，一切都会正常！我的直觉是在启动时无法使用python服务器初始化所需的某些东西……如果有人对此有更多信息，那会很高兴。现在，睡眠定时器可以工作了:)

我们可以将此文件从计算机复制到初始化脚本的指定目录中：

Nowwww交叉手指，让我们重新启动！！！为了确保重启后python服务器在后台运行，您可以运行