Unable to delete unwanted attributes from Disconnect-Request

[Alan DeKok]

On Jan 8, 2021, at 8:01 AM, Tasos Kotaras <akota at intracom-telecom.com> wrote:
> 
> I'm struggling to remove some unwanted attributes from the disconnect message emitted after a failure in the rest module.

  You can use the "update" section, or the "attr_filter" module.  Both work.

  There's no example of doing this in the default config, so I added one:

https://github.com/FreeRADIUS/freeradius-server/commit/b2adf9c620c6239da7baec871212b968ca9f3edc  

  That may help, depending on what else you're doing.

> More specifically, in accounting mode, when I receive a Accounting-Request, I either return an Accounting-Response or Disconnect-Request, depending on the HTTP status returned in a REST interaction. Both cases work properly, the only issue is that the disconnect message also contains these attributes that nag NAS (they cause it to return a NAK):

  The NAS is supposed to return errors when a Disconnect packet contains unexpected attributes.  So that's OK.

> |NAS-Port Teardown-Indicator (as 3GPP VSA) |
> 
> These attributes are not present in the request. If they were, I could easily remove them and this would also affect the generated disconnect. But apparently, these attributes are added at some point that I have no control.

  *Something* is adding them.  Likely the REST API.  You have full control over the RADIUS server.  These attributes are not added in the default configuration.  So something *local* is adding them,

> The "/update disconnect {...}/" has no effect, as I guess it is relevant only to received messages (not clear from the documentation).

  Read the debug output to see what methods it's running.

> I understand that disconenct belongs to a different connection, so it cannot be related and handled by tampering with 'reply' or anythig that freeradius provides me as variables. Still, I badly need to somehow solve the issue, as I have no control over the NAS itself.
> 
> Configuration details:

   Not needed.

> 
> _mod-enabled/rest:_
> 
> |accounting { uri = "http://x.x.x.x:yyyy/..." method = 'post' body = 'json' tls = ${..tls} } |
> 
> 
> _sites-enables/default:_
> 
> |accounting { rest # this has no effect (same if placed inside rest {...}): update disconnect { NAS-Port !* ANY Teardown-Indicator !* ANY } } |
> 
> radius -X writes these:
> 
> |(0) rest: Sending HTTP POST to "http://x.x.x.x:yyyy/..." (0) rest: Encoding attribute "User-Name" (0) rest: Encoding attribute "Framed-IP-Address" (0) rest: Encoding attribute "Acct-Status-Type" (0) rest: Encoding attribute "Acct-Session-Id" (0) rest: Processing response header (0) rest: Status : 503 (Service Unavailable) (0) rest: ERROR: Server returned no data rlm_rest (rest): Released connection (0) Need 5 more connections to reach 10 spares rlm_rest (rest): Opening additional connection (5), 1 of 27 pending slots used rlm_rest (rest): Skipping pre-connect, connect_uri not specified (0) [rest] = fail (0) } # accounting = fail (0) WARNING: Unknown destination 127.0.0.1:3799 for CoA request. (0) Not sending reply to client. (0) Finished request |

  That seems pretty clear.  You didn't define a home server 127.0.0.1:3799 for CoA packets.  But you're telling FreeRADIUS to send packets there.

> REST works OK and the 503 is expected for this particular case. I cannot see something wrong (the ERROR and WARNING are not a huge surprise)
> 
> I wonder if there is some workaround to persuade freeradius not to add these naughty attributes, or otherwise, give me the chance to remove them?

  FreeRADIUS does NOT add these attributes.  YOU do, in your local configuration.  This isn't magic.  FreeRADIUS doesn't magically know that it's your system, and then adds a bunch of 3GPP stuff.  That's just impossible.

  You also need to read the full debug output.  ALL OF IT.  If you can get it to send CoA packets to the NAS and get a NAK back, then you can ABSOLUTELY filter the outbound CoA packets.  You just need to put the filtering in the right place.

  Again, there's no magic here.  Nothing is magically added.  It doesn't magically prevent filtering of attributes for Disconnect / CoA packets.  If you read the debug output, you'll see where you need to put the filtering.  If it's not filtering, it's because you're putting that in the wrong place.

  http://wiki.freeradius.org/list-help

  Alan DeKok.