ability to get "string key" from Attribute Type?

[seanenck]

Sorry if I missed it in the code but I can get the Type (as an int) of an attribute. Is there a way to know that, for example, UserName_Type radius.Type = 1 == "User-Name"? (I'd like to dump attribute key/value pairs in a debugging mode)

[ghost]

Not at the moment. In order to put a String() string method on radius.Type, there would have to be a "global" map inside of the radius package that each loaded dictionary would register itself to. I wanted to avoid this, as conflicts could arise if dictionaries with conflicting types were loaded simultaneously.

I'll give some though to how this additional information can be generated in the dictionary packages. I'll also consider how this could support VSAs as well.

[seanenck]

Yeah I started looking at it and I know I maybe would have to filter by type I'm interested to map/it would "belong" in the "rfc" generated modules you have. For dumping/debugging I can definitely live with just the ints, but it'd be pretty awesome to not have to cross-reference myself!

My only use case is just for dumping/debugging and I imagine suppoting a "attribute by string name" would be ill-advised but maybe there is an interesting way to do that. Anyway, any time you spend on this, thanks a lot (let me know if I can help)!

[ghost]

suppoting a "attribute by string name"

That will definitely not be added (this was how the library was initially implemented, and was not ideal due to decreased type safety). The debugging information is useful though.

[seanenck]

Certainly agree! Debugging is the only use case I have and I can start to track to that if I need it for some attributes and I figured maybe it could be generated but didn't dive in. Again thanks and this library is super useful!

[seanenck]

There was some discussion in #15 about this, I've closed that and if there is more conversation to follow we can have it here (sorry for the non-linear conversation future readers)

[ghost]

One thing I would like to avoid with a debug package is auto registering information. IE, there should be no:

func init() {
    debug.RegisterDictionary(...)
}

As this would likely cause interference if you are trying to work several dictionaries whose types overlap (not common, but still possible).

(one new debug package?)

debug/rfc2865.go
debug/debug.go

I think this might be the way to go. The dictionary generator would generate an exported variable in the form:

var RFC2865 = ...debug information...

var RFC2866 = ...debug information...

There would then be helper functions defined with signatures like:

func DebugPacket(p *radius.Packet, ...*DebugType) (string, error)

Or something similar.

We also need to consider vendor specific attributes, and being able to convert them into a stringified form.

[ghost]

Alright, I've taken a go at implementing this. There is a new package called layeh.com/radius/debug that exports a method for dumping a packets into strings that look like:

Access-Request Id 33
  User-Name = "Tim"
  User-Password = "12345"

Not currently feature complete at the moment, so API and output format may break in the future. Let me know how this works for you and if you have any suggestions.

[seanenck]

I was looking at this, any chance (you are still updating so I figured a PR would get in the way)

func DumpPacket(c *Config, p *radius.Packet) string {

could instead be

func DumpPacket(c *Config, p *radius.Packet, w io.Writer) {

If I want to dump packets to a variety of places, I can deal with getting a string back but passing a writer directly would be nice

[seanenck]

Thanks for the effort on this!

func Dump(w io.Writer, c *Config, p *radius.Packet)

^ pretty much solves my use case entirely. I'll do some more testing on my end but this is great!

[seanenck]

I did start using this and it fulfills my needs perfectly (thanks!)

Feel free to close this issue if you feel the work is completed on your end

[ghost]

Superseded by #35