无网络请求的时候登录失败

[bsbds]

在没有其他使用网络的用户软件的情况下运行

# ipgw
using account 'xxxxxxxx'
login failed: 
	unknown reason

任意发一个公网连接请求后就能正常登录

# curl 1.1.1.1        
<script>top.self.location.href='http://202.118.1.87/index_15.html?wlanuserip=xx.xx.xx.xx&wlanacname=NS_Wifi_N18K&ssid=&nasip=202.118.0.11&snmpagentip=&mac=4a806e361ea3&t=wireless-v2-plain&url=http://1.1.1.1/&apmac=&nasid=NS_Wifi_N18K&vid=2008&port=27&nasportid=AggregatePort 1.20080000:2008-0'</script>

# ipgw
using account 'xxxxxxxx'
login successfully

[unbyte]

是稳定复现吗

[bsbds]

是, 两台笔记本(arch/freebsd)还有树莓派(debian)上都有这个问题
等待一段时间自动断开后再重新登录就会login failed

[amtoaer]

抱歉，最近在忙春招，没有及时回复。该问题在我 windows 11 上无法复现。😢
当前版本的登录逻辑是请求 ipgw 信息，如果出现网络错误则not in campus network，否则解析IP和用户名信息，IP为空也not in campus network，用户名不为空则"already logged in as '%s'。
其它情况，调用登录 api 并重新请求、解析 ipgw 信息，流程内出现错误则返回对应错误。无错误的情况下，查看用户名是否为空，如果用户名为空才返回unknown reason。
可见出现unknown reason是要在登录未出错的情况下，获取信息获取不到用户名才行，理论上不太可能出现。
我这边先排查一下是不是登录流程中有些 error 没有返回吧，@bsbds 如果方便的话，可以确认一下 ipgw 是否使用了最新版本与正确架构（因为之前有听说在 arm64 上使用 arm 的 ipgw 会报 unknown reason）。 🤣

[bsbds]

复现方法是在全新安装的系统上(无桌面环境), 使用wpa_supplicant和dhclient连接校园网, 然后用ipgw登录, 确认在 linux(amd64, arm64)和 freebsd(amd64)上都会出现问题, ipgw是编译自最新master分支

试着打印了一下错误, 问题好像是出在这个位置

--- a/pkg/handler/ipgw.go
+++ b/pkg/handler/ipgw.go
@@ -55,6 +55,7 @@ func (h *IpgwHandler) Login(account *model.Account) error {
                        return err
                }
                body, err = h.login(account.Username, password) // 通过用户名、密码登录
+               fmt.Println(body)
        }
 
        if err != nil {

# ipgw
using account 'xxxxxxxx'
{"code":1,"message":"no_response_data_error","Redirect":"","ID":"15"}
login failed: 
	unknown reason

用curl发一个http请求以后就正常了, 猜测是登录认证服务器需要客户端先发送一个http请求后才能登录?

可能有关
https://en.wikipedia.org/wiki/Captive_portal#Implementation

抱歉因为我对网络和go不了解调试能力有限..

[unbyte]

那连用两次ipgw，是不是第二次ipgw能成功呢

[bsbds]

那连用两次ipgw，是不是第二次ipgw能成功呢

不能, 重复多次也不行

[unbyte]

方便的话可以试一下先curl pass.neu.edu.cn再ipgw能不能成功吗

[bsbds]

不能..
好像这些用于认证的网址都不行, curl其他的url会返回上面发的那个script, 然后就可以登录了

[halozhy]

Google了下上面 PR#49 代码里面的 198.18.0.1 ，原来是出自 RFC2544 ，是被分配给基准测试专用的 IP 地址，涨姿势了

前段时间我在一个 ESP8266 单片机上面写了个登录校园网的工具，然后也稳定遇到了第一次登录 ipgw 失败，第二次登录才成功的 bug，当时没太多想，但是第一次登录失败返回的 json 信息确实是 "code":1,"message":"no_response_data_error"

这和本 issue 遇到的这个错误信息是一样的，并且我的单片机程序会在 ipgw 认证之后访问一次公网，相当于经过了

ipgw认证 -> 访问公网 -> 失败 -> 重新进行ipgw认证

这样一个流程之后，ipgw 才认证成功，因此我感觉这个 bug 应该可以被稳定复现，在 Windows 上不容易复现可能是因为 Windows 连接网络后就已经发过一些公网请求了，只不过没有被咱们直观感知到

[bsbds]

Google了下上面 PR#49 代码里面的 198.18.0.1 ，原来是出自 RFC2544 ，是被分配给基准测试专用的 IP 地址，涨姿势了

前段时间我在一个 ESP8266 单片机上面写了个登录校园网的工具，然后也稳定遇到了第一次登录 ipgw 失败，第二次登录才成功的 bug，当时没太多想，但是第一次登录失败返回的 json 信息确实是 "code":1,"message":"no_response_data_error"

这和本 issue 遇到的这个错误信息是一样的，并且我的单片机程序会在 ipgw 认证之后访问一次公网，相当于经过了

ipgw认证 -> 访问公网 -> 失败 -> 重新进行ipgw认证

这样一个流程之后，ipgw 才认证成功，因此我感觉这个 bug 应该可以被稳定复现，在 Windows 上不容易复现可能是因为 Windows 连接网络后就已经发过一些公网请求了，只不过没有被咱们直观感知到

嗯，而且必须是http请求，根据维基captive portal的实现里

A common method is to direct all World Wide Web traffic to a web server, which returns an HTTP redirect to a captive portal.

正常的登录流程应该是客户端有一个http请求后重定向到认证网页进行认证

我之前认真看了一下项目代码感觉大概看懂了，所以稍微改了一下，亲测可以正常使用