Malformed RADIUS packet from host
Hi, Here's my archi: NAS ---- FreeRADIUS Proxy(192.168.0.107) ---- WAP gateway(Home Server-192.168.1.6) I'm trying to proxy accounting requests to a WAP gateway (home server) using http://www.kannel.org/download/1.4.1/userguide-1.4.1/userguide.html#AEN1038 as the RADIUS client. I see malformed packets received by the Proxy. The same client when used with xtradius (+ an external perl script) to simply forward the accounting request to the wap gateway it works well. With Freeradius(2.0.4) proxy + MySQL(SQLIPPOOL) i see this error quite often. #../radius.log Wed May 28 14:00:28 2008 : Error: WARNING: Malformed RADIUS packet from host 192.168.1.6: too short (received 6 < minimum 20) Wed May 28 14:00:30 2008 : Error: Discarding duplicate request from client SLR1 port 1813 - ID: 242 due to unfinished request 194 Could you explain me the possible causes for this situation please? Any areas I have overlooked when configuring FreeRADIUS proxy(indicated below)? --------------------------------------------- FREERADIUS Proxy configuration --------------------------------------------- #../raddb/proxy.conf proxy server { default_fallback = no } home_server wap { type = acct ipaddr = 192.168.1.6 port = 1813 secret = secret response_window = 20 zombie_period = 40 revive_interval = 120 status_check = status-server check_interval = 30 num_answers_to_alive = 3 } home_server_pool my_acct_failover { type = fail-over home_server = wap } ------------------------------------------------ I'm puzzled that, if it's a problem with the Radius client being used, then what makes things working well with XtRADIUS+perl? Is there a better way to forward ONLY an accounting request (with selected set of AVPs) ? Here's are two Accounting-responses (Malformed and Normal) captured on the Proxy side(192.168.0.107) Malformed Packet ================= --------------------------------------------------------------------------------------------------------- Frame 4 (60 bytes on wire, 60 bytes captured) Arrival Time: May 28, 2008 14:03:07.090143000 Time delta from previous packet: 0.004755000 seconds Time since reference or first frame: 37.437385000 seconds Frame Number: 4 Packet Length: 60 bytes Capture Length: 60 bytes Frame is marked: False Protocols in frame: eth:ip:udp:radius Ethernet II, Src: 00:1b:78:d2:bc:f8 (00:1b:78:d2:bc:f8), Dst: Xensourc_0f:5c:ef (00:16:3e:0f:5c:ef) Destination: Xensourc_0f:5c:ef (00:16:3e:0f:5c:ef) Address: Xensourc_0f:5c:ef (00:16:3e:0f:5c:ef) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: 00:1b:78:d2:bc:f8 (00:1b:78:d2:bc:f8) Address: 00:1b:78:d2:bc:f8 (00:1b:78:d2:bc:f8) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Trailer: 0000000000000000 Internet Protocol, Src: 192.168.1.6 (192.168.1.6), Dst: 192.168.0.107 (192.168.0.107) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 38 Identification: 0x0a72 (2674) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 63 Protocol: UDP (0x11) Header checksum: 0x19e8 [correct] Good: True Bad : False Source: 192.168.1.6 (192.168.1.6) Destination: 192.168.0.107 (192.168.0.107) User Datagram Protocol, Src Port: radius-acct (1813), Dst Port: 1814 (1814) Source port: radius-acct (1813) Destination port: 1814 (1814) Length: 18 Checksum: 0x4f17 [correct] Radius Protocol Code: Accounting-Response (5) Packet identifier: 0xc7 (199) Length: 20 [Malformed Packet: RADIUS] Normal Response ================ ------------------------------------------------------------------------------------------------------ Frame 6 (62 bytes on wire, 62 bytes captured) Arrival Time: May 28, 2008 14:03:21.089332000 Time delta from previous packet: 0.009441000 seconds Time since reference or first frame: 51.436574000 seconds Frame Number: 6 Packet Length: 62 bytes Capture Length: 62 bytes Frame is marked: False Protocols in frame: eth:ip:udp:radius Ethernet II, Src: 00:1b:78:d2:bc:f8 (00:1b:78:d2:bc:f8), Dst: Xensourc_0f:5c:ef (00:16:3e:0f:5c:ef) Destination: Xensourc_0f:5c:ef (00:16:3e:0f:5c:ef) Address: Xensourc_0f:5c:ef (00:16:3e:0f:5c:ef) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: 00:1b:78:d2:bc:f8 (00:1b:78:d2:bc:f8) Address: 00:1b:78:d2:bc:f8 (00:1b:78:d2:bc:f8) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Internet Protocol, Src: 192.168.1.6 (192.168.1.6), Dst: 192.168.0.107 (192.168.0.107) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 48 Identification: 0x0a76 (2678) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 63 Protocol: UDP (0x11) Header checksum: 0x19da [correct] Good: True Bad : False Source: 192.168.1.6 (192.168.1.6) Destination: 192.168.0.107 (192.168.0.107) User Datagram Protocol, Src Port: radius-acct (1813), Dst Port: 1814 (1814) Source port: radius-acct (1813) Destination port: 1814 (1814) Length: 28 Checksum: 0x84e0 [correct] Radius Protocol Code: Accounting-Response (5) Packet identifier: 0x93 (147) Length: 20 Authenticator: 6DEA7F8F0B31CED4BE0F4D3BC95AB370 ---------------------------------------------------- FREERADIUS Proxy configuration ---------------------------------------------------- ../raddb/proxy.conf proxy server { default_fallback = no } home_server wap { type = acct ipaddr = 192.168.1.6 port = 1813 secret = secret response_window = 20 zombie_period = 40 revive_interval = 120 status_check = status-server check_interval = 30 num_answers_to_alive = 3 } home_server_pool my_acct_failover { type = fail-over home_server = wap } ------------------------------------------------ Thanks, srg
rsg wrote:
I see malformed packets received by the Proxy. The same client when used with xtradius (+ an external perl script) to simply forward the accounting request to the wap gateway it works well.
I have a hard time seeing how changing the proxy can change the packets sent by the client. My guess (I am biased) is that xtradius just ignores the malformed packets, and doesn't print an error.
Could you explain me the possible causes for this situation please? Any areas I have overlooked when configuring FreeRADIUS proxy(indicated below)?
There is nothing you can configure in FreeRADIUS to change the size of the packets sent by a client. Alan DeKok.
Hi, Thanks Alan for your response. The reasoning you provided could be very likely the situation. The objective in my case is simply to send selected set of AVPs like Acct-Session-Id and Framed-IP-Address to the home server. I need to achieve two things. 1) Need to satisfy successful delivery of Accounting-Request to the home server. 2) This Accounting transaction has to be transparent to the Client(NAS). (With the general Proxy setup this is quite difficult achieve and I see Duplicate requests originated from NAS for incomplete transactions. Explanation of the problem: Rep. of my archi: NAS ---- FreeRADIUS Proxy(192.168.0.107) ---- WAP gateway(Home Server-192.168.1.6) --../radius.log...on Proxy(192.168.0.107) ---------------------------- Thu May 29 11:33:14 2008 : Error: WARNING: Malformed RADIUS packet from host 192.168.1.6: too short (received 10 < minimum 20) Thu May 29 11:33:16 2008 : Error: Discarding duplicate request from client NAS port 1813 - ID: 140 due to unfinished request 32 Thu May 29 11:33:20 2008 : Error: Discarding duplicate request from client NAS port 1813 - ID: 140 due to unfinished request 32 ----------------------------- Here when the proxy receives a malformed packet from the home server..Accounting transaction is unfinished thus the NAS retries with duplicate requests. That's why I want to make the Proxying of Accounting transparent to the NAS. Would it be possible to achieve these with the proxy configuration? Theoretically it may not sound sensible, however I would like to have your expert opinion on this. Thanks, srg. On Wed, May 28, 2008 at 7:03 PM, Alan DeKok <aland@deployingradius.com> wrote:
rsg wrote:
I see malformed packets received by the Proxy. The same client when used with xtradius (+ an external perl script) to simply forward the accounting request to the wap gateway it works well.
I have a hard time seeing how changing the proxy can change the packets sent by the client.
My guess (I am biased) is that xtradius just ignores the malformed packets, and doesn't print an error.
Could you explain me the possible causes for this situation please? Any areas I have overlooked when configuring FreeRADIUS proxy(indicated below)?
There is nothing you can configure in FreeRADIUS to change the size of the packets sent by a client.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
rsg wrote:
The objective in my case is simply to send selected set of AVPs like Acct-Session-Id and Framed-IP-Address to the home server.
That's nice. It doesn't solve the problem that the home server is broken. Fix it. If you can't fix it, replace it with a RADIUS server that works.
I need to achieve two things.
1) Need to satisfy successful delivery of Accounting-Request to the home server.
2) This Accounting transaction has to be transparent to the Client(NAS). (With the general Proxy setup this is quite difficult achieve and I see Duplicate requests originated from NAS for incomplete transactions.
Both of these are possible with a home server that works. Your home server does not work, so these requirements are impossible to achieve. No amount of playing with FreeRADIUS or the NAS will fix the home server.
Here when the proxy receives a malformed packet from the home server..Accounting transaction is unfinished thus the NAS retries with duplicate requests. That's why I want to make the Proxying of Accounting transparent to the NAS.
It *is* transparent to the NAS... when the home server works. Your home server does not work.
Would it be possible to achieve these with the proxy configuration? Theoretically it may not sound sensible, however I would like to have your expert opinion on this.
Your home server is broken. I really can't emphasize this enough. Throw it away. It's garbage. Your home server is *not* a RADIUS server. Alan DeKok.
I agree it's not a RADIUS server. It's a WAP gateway running on Kannel with minimal support for RADIUS as described by http://www.kannel.org/download/1.4.1/userguide-1.4.1/userguide.html#AEN1038 I understand your point. However, there's no better alternative for the moment. Thanks, srg. On Thu, May 29, 2008 at 12:16 PM, Alan DeKok <aland@deployingradius.com> wrote:
rsg wrote:
The objective in my case is simply to send selected set of AVPs like Acct-Session-Id and Framed-IP-Address to the home server.
That's nice. It doesn't solve the problem that the home server is broken. Fix it. If you can't fix it, replace it with a RADIUS server that works.
I need to achieve two things.
1) Need to satisfy successful delivery of Accounting-Request to the home server.
2) This Accounting transaction has to be transparent to the Client(NAS). (With the general Proxy setup this is quite difficult achieve and I see Duplicate requests originated from NAS for incomplete transactions.
Both of these are possible with a home server that works. Your home server does not work, so these requirements are impossible to achieve.
No amount of playing with FreeRADIUS or the NAS will fix the home server.
Here when the proxy receives a malformed packet from the home server..Accounting transaction is unfinished thus the NAS retries with duplicate requests. That's why I want to make the Proxying of Accounting transparent to the NAS.
It *is* transparent to the NAS... when the home server works. Your home server does not work.
Would it be possible to achieve these with the proxy configuration? Theoretically it may not sound sensible, however I would like to have your expert opinion on this.
Your home server is broken. I really can't emphasize this enough. Throw it away. It's garbage. Your home server is *not* a RADIUS server.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
rsg wrote:
I agree it's not a RADIUS server. It's a WAP gateway running on Kannel with minimal support for RADIUS as described by http://www.kannel.org/download/1.4.1/userguide-1.4.1/userguide.html#AEN1038
Nit-picking games aren't necessary. If it's supposed to receive Accounting-Request packets and send Accounting-Response packets, it's supposed to be a RADIUS server. In any case, it's not a STANDARDS COMPLIANT RADIUS server, if that sounds better.
I understand your point. However, there's no better alternative for the moment.
Then fix their code. It's broken. Alan DeKok.
Hi Alan, Many thanks... It really helped me narrowing down the scope of the problem. Very likely it's because of a buggy kernel being used by the home RADIUS server. I've tested with a different kernel version and didn't receive any malformed packets. with the buggy OS, roughly 20% of malformed incidents are guaranteed. srg. On Thu, May 29, 2008 at 12:59 PM, Alan DeKok <aland@deployingradius.com> wrote:
rsg wrote:
I agree it's not a RADIUS server. It's a WAP gateway running on Kannel with minimal support for RADIUS as described by http://www.kannel.org/download/1.4.1/userguide-1.4.1/userguide.html#AEN1038
Nit-picking games aren't necessary. If it's supposed to receive Accounting-Request packets and send Accounting-Response packets, it's supposed to be a RADIUS server.
In any case, it's not a STANDARDS COMPLIANT RADIUS server, if that sounds better.
I understand your point. However, there's no better alternative for the moment.
Then fix their code. It's broken.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
participants (2)
-
Alan DeKok -
rsg