Wesley Spadola <wspadola@porchlight.ca> wrote:
Because we do not want accounting data terribly out of sync, we are shifting the accounting data over from our live machine to a test machine in increments of a few minutes, and I'm logging such data with "tcpdump -s 1500 -w raw.txt port 1813 and udp".
Why not just log to the "detail" file?
I hope to catch some log data that I can easily replay to the test machine while the accounting is shifted back to our live server.
The "detail" file is meant to do exactly this.
To replay that data. I am using "cat raw.txt | nc -u <ip of test server> radius-acct". When the data starts to flow, I receive this output from radiusd -X:
WARNING: Bad RADIUS packet from host x.x.x.x: unknown packet code 212
Run tcpdump on the network again to see if "nc" is sending real RADIUS packets. I don't think it is. If you're sending *text* output from tcpdump to "nc", that won't work. If you're sending "pcap" data to "nc", then it probably won't work, either.
I realize that the accounting port may not understand and handle authorization requests, but I do know that there are /some/ accounting requst packets in this raw file that FR should be handling.
Nope. The data you're sending it is not RADIUS accounting packets. It's something else.
Am I using tcpdump/netcat in the correct manner?
No.
Should I capture /much more data/ for FreeRADIUS to work this way?
No. Use the "detail" file.
Is there something else I could do to capture raw UDP streams and replay them?
Don't. You need to use the shared secret, for one. Use existing tools to replay traffic. "detail", "radrelay". Alan DeKok.