radsniff behaviour change?
As of 2.1.10, radsniff doesn't decode packets automatically without -x: $ sudo bin/radsniff -i lo -c 1 Access-Request Id 17 127.0.0.1:43171 -> 127.0.0.1:1812 +0.000 Attr-1 = 0x7374657665 Attr-2 = 0x98f7337df71223dc220a3a682c5f0a7f Attr-4 = 0x7f000001 Attr-5 = 0x00000001 Looking at the code, it doesn't even read the dictionary unless you add -x (debug) or -F (filter). This change was made in commit 7a85628d I wonder if this logic is unintentionally broken, and in fact you meant to load the dictionary *unless* -F is present? Regards, Brian.
On Thu, Dec 02, 2010 at 02:32:16PM +0000, Brian Candler wrote:
I wonder if this logic is unintentionally broken, and in fact you meant to load the dictionary *unless* -F is present?
This appears to fix it. diff --git a/src/main/radsniff.c b/src/main/radsniff.c index 935d2ce..6c3ca14 100644 --- a/src/main/radsniff.c +++ b/src/main/radsniff.c @@ -422,7 +422,7 @@ int main(int argc, char *argv[]) /* * There are many times where we don't need the dictionaries. */ - if (fr_debug_flag || radius_filter) { + if (fr_debug_flag || !radius_filter) { if (dict_init(radius_dir, RADIUS_DICTIONARY) < 0) { fr_perror("radsniff"); return 1;
Brian Candler wrote:
As of 2.1.10, radsniff doesn't decode packets automatically without -x: ... Looking at the code, it doesn't even read the dictionary unless you add -x (debug) or -F (filter). This change was made in commit 7a85628d
I wonder if this logic is unintentionally broken, and in fact you meant to load the dictionary *unless* -F is present?
The attribute names are needed only when they're being printed. So the code should be fixed to not load the dictionaries when it's writing PCAP files. In all other situations, it should load them. Alan DeKok.
participants (2)
-
Alan DeKok -
Brian Candler