Page MenuHomeVyOS Platform
Create Task
Maniphest T9505

RADIUS rate-limit silently does nothing when the vendor name has the wrong case (`vendor mikrotik`)
Open, LowPublic
Actions

Description

set service <pppoe-server|ipoe-server|l2tp|pptp|sstp> authentication radius rate-limit vendor <vendor> accepts any string. accel-ppp looks the name up in its RADIUS dictionary with a case-sensitive comparison. The dictionary file calls the vendor Mikrotik (VENDOR Mikrotik 14988 in /usr/share/accel-ppp/radius/dictionary.mikrotik), so vendor mikrotik is not found. There is no error message and the commit succeeds. The RADIUS server's Mikrotik-Rate-Limit is received and logged, but no rate limit is applied to the session.

How to reproduce (seen with pppoe-server on a rolling image with VPP, RADIUS server answering with Mikrotik-Rate-Limit "2M/2M")

set service pppoe-server authentication radius rate-limit enable
set service pppoe-server authentication radius rate-limit attribute Mikrotik-Rate-Limit
set service pppoe-server authentication radius rate-limit vendor mikrotik
commit

Bring up a PPPoE session. Result:

  • the Access-Accept in the log contains <Mikrotik-Rate-Limit "2M/2M">
  • show pppoe-server sessions / accel-cmd show sessions has an empty rate-limit column
  • no limiter is installed (with VPP: vppctl show policer lists nothing)
  • no message in the log, because the shaper stops reading its options and does not log anything for this case

With vendor Mikrotik (capital M) the same setup works: rate-limit shows 2000/2000 and VPP has the policers.

What the shaper does (I read the values of the running daemon with gdb)

rad_dict_find_vendor_name() compares with strcmp(). For mikrotik the lookup fails and parse_vendor_opt() falls back to atoi("mikrotik"), which is 0. The attribute name is then looked up as a global attribute, which fails as well, and load_config() returns early. With vendor mikrotik: conf_vendor = 0, conf_attr_down = 0, conf_attr_up = 0. With vendor Mikrotik: conf_vendor = 14988, conf_attr_down = 8.

I have only checked this with the VPP PPPoE server. The lookup is in accel-ppp's shaper and the CLI node is shared by all accel-ppp services, so I expect the same for the others, but I did not test them.

Expected behaviour

Either the vendor name is matched case-insensitive, or the CLI refuses a name that is not in the dictionaries, or at least the commit prints a warning. The documentation already says to use a vendor name from /usr/share/accel-ppp/radius and shows vendor Mikrotik, so it is the CLI that gives no hint.

Notes

  • The interface definition is interface-definitions/include/accel-ppp/radius-additions-rate-limit.xml.i, the vendor leaf has only a help text and no constraint. The value goes unchanged into [shaper] vendor= (data/templates/accel-ppp/config_shaper_radius.j2).
  • Possible fixes, in the order of how little they change: a warning in the conf-mode script when the value is not a vendor of the installed dictionaries, a completion/validator that lists the vendor names, or a case-insensitive lookup in accel-ppp-ng (rad_dict_find_vendor_name()). I have not tried any of them.

Details

Version
rolling
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Unspecified (please specify)

Event Timeline

rherold created this task.Fri, Oct 23, 11:20 AM
rherold created this object in space S1 VyOS Public.
Viacheslav subscribed.Fri, Oct 23, 11:35 AM

RADIUS rate-limit silently does nothing when the vendor name has the wrong case (vendor mikrotik)

I think it is expected
What RFC says how to handle a wrong attribute if the vendor name is wrong?

rherold added a comment.Fri, Oct 23, 11:38 AM

@Viacheslav thanks. I do not think the RFC decides this, so let me explain what I mean.

RFC 2865 (section 5.26) identifies a vendor by its number (the IANA enterprise number, here 14988 for Mikrotik), and it says that an attribute that the receiver does not understand is to be ignored. It does not know vendor names at all. The name Mikrotik is a label in accel-ppp's dictionary file, and the option rate-limit vendor is a VyOS CLI option. So the RADIUS side is handled correctly: the Access-Accept with the vendor attribute is received and the attribute is not treated as an error.

The case I am describing is a different one: the value of a VyOS configuration option that matches nothing in the installed dictionaries. commit accepts it and prints nothing, and the only effect is that the rate limit that the operator configured is never applied. The operator sees no error and no log message, and the RADIUS server looks fine.

I agree that it is not wrong by itself, it is how accel-ppp works. If you see it as expected, I understand that, and maybe a note in the documentation that the name is case-sensitive is enough. The command reference already tells to use a name from /usr/share/accel-ppp/radius, and its example uses Mikrotik. A warning at commit time when the name is not in the dictionaries would be the smallest change, if you think it is worth having. I can look at that, or leave the task as it is, as you prefer.

pasik subscribed.Fri, Oct 23, 12:15 PM