Chris Howley wrote:
I encountered the following problem when the server received an Access-Challenge packet from a proxy server. Any help in fixing this problem would be appreciated.
See doc/bugs for giving additional information, such as the rest of the back trace. Also, a lot more of the debug log might help.
Waking up in 0.9 seconds. rad_recv: Access-Challenge packet from host 194.82.174.185 port 1812, id=76, length=81 Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 EAP-Message = 0x010300061920 Message-Authenticator = 0x193c8361dc660dd940460f693d6ebf9c State = 0xad8b0646ad881f6aaefeee6ec7165a25 Proxy-State = 0x313730 +- entering group post-proxy {...} [post_proxy_log] expand: /usr/local/var/log/radius/radacct/%Y-%m-%d/post-proxy-detail-%H:00 -> /usr/local/var/log/radius/radacct/2009-02-24/post-proxy-detail-16:00 [post_proxy_log] /usr/local/var/log/radius/radacct/%Y-%m-%d/post-proxy-detail-%H:00 expands to /usr/local/var/log/radius/radacct/2009-02-24/post-proxy-detail-16:00 [post_proxy_log] expand: %{Packet-Src-IP-Address} - %t -> 10.12.80.101 - Tue Feb 24 16:02:50 2009 ++[post_proxy_log] returns ok [attr_filter.post-proxy] expand: %{Realm} -> jrs attr_filter: Matched entry DEFAULT at line 103 ++[attr_filter.post-proxy] returns updated [eap] No pre-existing handler found ++[eap] returns noop ASSERT FAILED event.c[3593]: fun != NULL Abort (core dumped)
This is a catastrophic error indicating that the server has a request it doesn't know how to handle. The only way that this could happen is: a) buffer over-run somewhere b) source code modifications The code that receives a proxied response sets "fun", and doesn't do a whole lot else before it hits that assertion. If you're seeing this in debugging mode (i.e. no threads), then there *very* few things that can go wrong here. Alan DeKok.