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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
