1、超时时间=报文请求超时时长(单次发送超时) (认证重发次数 + 1)如下设置超时为8秒。3、 Portal Web与Portal服务器之间通信存在问题,比如socket绑定、端口占用等导致报文发送接收问题。3 上线一段时间掉线1、 可能是用户关掉心跳页面导致,比如单任务的手机终端就会存在该问题。2、 页面有缓存,发送心跳功能失效。3、 设备或iMC上设置限制时长或者设备配置相关命令,这样在超过闲置时间就会收到设备的下线报文(NTF_LOGOUT)。2012-09-25 15:55:41.468Portal服务器调试(0)ProxyRequestHandler:run192.168.26.5 ;
2、 NTF_LOGOUT(8) ; 1143 ; 192.168.26.1:2000 ; 报文处理成功 Packet Type:NTF_LOGOUT(8) SerialNo:1143 Address:192.168.50.2 Port:50908 RemoteIp:192.168.26.1 RemotePort:2000 Version:portal 2.0 Auth Type:CHAP ErrorID: UserIP:192.168.26.5 UserPort: ReqID: Rsvd: attriNum:4/HeadAttributes Device Ip: Session Id:d4 3d
3、 7e 11 f9 19 Text Info:Send NTF_LOGOUT when online! Device Time Stamp:1320777567/Attributes/Content4、 同一在多处登录,在线数量限制为1,且设置了如下参数:5、 配置了Portal服务器和Portal设备之间的用户级心跳,之前版本iMC在某些情况下处理存在问题会导致心跳报文不携带在线用户IP,后面版本已经改正。6、 收到设备NTF_LOGOUT报文,出现这个报文情况比较多,需要咨询设备具体原因,常见下述2种原因的下线报文。2012-06-12 09:54:08.859Portal服务器调试(0)
4、ProxyRequestHandler:run10.11.1.155 ; 7238 ; 10.11.255.5:723810.10.203.510.11.255.5PAP10.11.1.15590 fb a6 1d f7 10 Text Info:Send NTF_LOGOUT when waiting LOGIN_ACK!1277448815754010.11.1.10500 21 97 c8 c8 fe7、 UAM后台回应计费更新报文Session-Timeout(27) 属性为 0,常见一个原因是余额不足,还有其他一些特殊原因,举一个之前发生的特殊例子:上线报文正常,但计费开始和更新报文
5、携带mac地址不全,如下所示,mac少了1段,导致收到计费开始报文时不会插入在线表,这样在收到计费更新报文时就会出现如下错误而回应Session-Timeout(27)= 0属性。% 2012-11-28 09:32:12 ; WARNING (2) ; LAN ; $SYS$ ; (NULL) ; Fail to process user accounting update request: E63010: 使用指定业务的用户不在线CODE = 4.ID = 80.ATTRIBUTES: User-Name(1) = xueping. NAS-Identifier(32) = TZ-S75E
6、-AC4 NAS-Port(5) = 16789554. NAS-Port-Id(87) = 0100003000000050 NAS-Port-Type(61) = 19. Calling-Station-Id(31) = 00-1F-3B-CD-3C-63 Called-Station-Id(30) = 00-0F-E2-EA-DD-D0:OA Acct-Status-Type(40) = 1. Acct-Authentic(45) = 1. Acct-Session-Id(44) = 1121028085739b0 Framed-IP-Address(8) = 2230363123. N
7、AS-IP-Address(4) = 2230362882. Event-Timestamp(55) = 1354093042. hw_Connect_ID(26) = 1099. hw_Input_Peak_Rate(1) = 0. hw_Input_Average_Rate(2) = 0. hw_Output_Peak_Rate(4) = 0. hw_Output_Average_Rate(5) = 0. hw_Priority(22) = 0. hw_IP_Host_Addr(60) = 132.240.163.243 00:1f:3b:cd:3c:4 Portal服务器获取不到设备信息
8、或者设备没有回应req-info报文实际上目前实现和发送req_info已关系不大,所以出现此错误基本可以确认是根据用户地址找不到对应portal设备信息,有如下可能原因:1、 用户上线IP地址没有包含在iMC的Portal IP地址组网段中。2、 ACK_INFO回应的端口信息不在端口组设置围:上述端口设置不支持中文或特殊字,因此出现这种情况最典型的原因是设备的sysname含有中文或特殊字符,将sysname改为英文字符即可。3、 没有配置端口组,或者端口组中引用的地址组不正确。4、 使用移动终端等上线,IP地址经常变化,而由于Portal具有缓存机制,因此,造成缓存中原地址和现有报文头地
9、址不一致(分别对应私网地址属性和公网地址属性),被识别为NAT,从而无法匹配到对应的地址组,参见如下红色部分,正常情况下如果不是NAT这2个地址是一样的。CODE_PP_DOMAIN_REQUEST(110)1554510.80.162.310.80.164.10527192 Private Ip: Public Ip:5、 ACK_INFO报文返回错误码1,原因可能是设备没有学习到该用户的arp表项,或者较老设备不支持REQ_INFO报文,目前iMC版本已对这种情况进行了放行处理。6、 ACK_INFO报文返回成功,但没有携带端口信息,目前iMC版本已对这种情况进行了放行处理。ACK_INF
10、O(10)90172.16.88.64192.168.80.2192.168.80.7713241451207、 配置台配置没有生效,即,通知portal服务器加载失败,造成这种情况原因可能是portal服务器未正常启动或50900端口没有正常绑定,可以查看如下界面Portal主页信息显示正常与否来确认50900端口是否正常工作。5 页面显示向设备发送报文超时1、 大用户量并发上线,Portal服务器代理出现队列满情况,导致报文丢弃。这种情况如下日志文件中会有队列慢(英文full)的错误。2、 设备没有及时回应ACK_INFO/ACK_ CHALLENGE/ACK_AUTH等报文。3、 对于没
11、有接收到设备回应ACK_INFO报文情况较多,在下节单独列出。6 设备没有回应ACK_INFO报文这种情况portalserver_2013-02-20.txt日志会记录req_info报文,但却没有ack_info报文,同时有如下错误提示:2013-02-05 15:25:44.964Portal服务器调试(0)TimerSendTask:stopProcess用户“10.80.164.10”状态从“LOGIN_PORT_REQUEST_STATUS”变为“DEL_STATUS”44.965Portal服务器调试(0)RequestProcessor:sendLoginRespToUsere
12、rrorCode = 12444.965Portal服务器调试(0)ProxyResponseClientHandler:run10.80.164.10 ; CODE_PP_LOGIN_RESPONSE(101) ; 16 ; 10.80.162.3:65285 ; 向设备发送请求超时(124)发生这种错误有如下可能原因:1、 设备对应端口没有启用portal。2、 iMC上Portal设备地址配置错误3、 iMC配置的Portal设备地址是Portal设备某个端口地址,但是和Portal设备回应报文使用的地址不一致,会出现如下红色框框所示的错误。4、 有防火墙阻挡,可以通过抓包确认。5、 设
13、备上配置的portal server地址不正确。可以通过如下命令查看:6、 设备上没有配置对应的用户地址段。7、 Portal设备上配置的密钥和iMC配置台上配置的Portal设备密钥不一致。7 设备拒绝请求1、 设备回应ACK_CHALLENGE报文时携带错误码1,可能是设备没有对应arp表项,或者设备处理队列满导致,需要设备配合定位。ACK_CHALLENGE(2)132001:250:f004:400:0:100509150250:F004:0400:0000:0001portal 3.010.0.0.05 UserIPv6:69B5:2FA2:0A4C:4B50 Device Ipv6
14、:9567504122、 设备回应ack_auth报文时携带错误码1,日志会有如下记录,出现这样的错误原因很多,可以先查看radius日志是否认证通过,如果通过就需要咨询设备具体原因了,比如,配置了下发ACL,但设备没有配置对应ACL的情况。8 返回radius错误码信息凡是返回信息中带有如下红色框框所示错误号的说明radius认证出错,需要分析radius日志来确认具体失败原因。9 Portal页面一直处于请求状态无法打开或响应速度很慢1、 系统资源不足导致,查看启动脚本设置的存是否足够大如下设置中至少应为1024m。2、 系统资源不足导致,查看是否存在其他耗存的程序,比如sqlserver
15、数据库是否限制了最大占用存数。之前发生过sqlserver数据库不断占用存情况导致系统变慢。3、 原有Portal web实现依赖session,在用户量大时性能下降明显,新版本已经进行改善。10 iNode客户端上线提示有一个用户正在认证这个提示通常是存在其他错误导致上次认证未完成,客户端超时重发,所以有此提示,如果出现这个提示,必然存在上述19中的某个问题。21:15.227Portal服务器调试(0)ProxyResponseClientHandler: 4963 ; 10.80.164.10:63173 ; Portal认证失败,该用户正在认证过程中,请稍后重试。(3)11 Porta
16、l认证提示“raidus服务器没有响应”设备和radius服务器之间认证出现问题,可以通过分别在radius服务器、设备上抓包分析原因。12 使用iNode可以上线,使用网页不能上线网页获取客户端IP和iNode客户端获取IP方式不同,因此,这种情况多半为网页方式传递IP地址不正确,比如,前面提到的网页缓存导致使用旧IP上线失败情况。13 客户端反复上下线从服务器上看已经发送了上线成功报文,但仍不断收到客户端发来的上线请求报文,出现该问题的可能原因有:1、 客户端没有收到服务器发来的报文,可以通过在客户端抓包确认。2、 服务器发送上线成功报文迟延,导致客户端超时重发。14 Portal日志增长过快问题在极少情况下(具体什么情况不确定),网卡绑不上多播端口,而原代码未对该种情况进行保护处理,该问题在iMC UAM 3.60-E6301P06及之后的版本已经解决。15 弹出心跳页面但实际上并未上线成功某些终端由于自身机制问题,一旦上线成功过,后续上线不会发送任何报文,但仍会弹出心跳报文,造成上线成功假象。这个问题仅在实验环境下出现过一次。解决方法:将浏览器缓存和本地cookie信息全部清除,重新上线可解决问题。
copyright@ 2008-2022 冰豆网网站版权所有
经营许可证编号:鄂ICP备2022015515号-1