Unsupported Vendor Specific Attribute results in incorrect behavior of rc_avpair_gen()

[Alan DeKok]

On Jan 26, 2015, at 10:52 PM, Amol Lad <Amol.Lad at 4rf.com> wrote:
> The problem is still there; as my embedded client does not recognize Cisco-AVPair and it is last in the list, rc_avpair_gen() returns NULL.

  Then add Cisco-AVPair to the dictionaries.

> Why do you think return NULL from below is not wrong? Why should caller return NULL if rc_avpair_gen returns NULL?

  For a host of reasons.

  In an embedded system, you want to produce the packet you expect, with all of the attributes you want.  Silently discarding an attribute means that the client does unexpected, and unknown things.

  In an embedded system, you control which attributes get created.  There’s no editable configuration file that an administrator can screw up by mistyping an attribute.  So if your code is doesn’t generate the correct attribute… it’s a bug.  Fix your code, rather than trying to push the library into working around it.

  If the library did as you wanted, you’d still be posting here.  “Hi, I asked the library to create 4 attributes, and it only created 4.  That’s a bug.  Why does it do that?”

  Fix your code to create *valid* attributes.  It’s as simple as that.

  Alan DeKok.