Ethereal-dev: Re: [Ethereal-dev] Good location(s) for the radius dictionary

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date: Thu, 7 Jul 2005 20:11:52 +0200
That's what I call an answer...

Plus the answer to all the questions that would followed.

Here's what I'll do then:

I'll look first for ./radius/. in the user prefs directory, then in
the data dir.

as for report_failure() I build the string with any i/o problems
and/or parse errors in the scanner, If the scanner fails gives that
back to the user with all the errors in a single dialog (much like
MATE does).

The file formatS ARE thOSE of FreeRADIUS (It does not have realy an
uniform way to manage vendor attributes).

I'm using their unmodified dictionary ignoring the attributes whose
code > 255 (they use those  for configuration, not packets). I'll add
the stuff we have and they don't in the next few days and submit it to
them.

As for the filterable fields: I'm putting in everything I find there
converting their name
"User-Name" => "radius.User_Name".
   
Other than that it will allow other dissectors to register their own
avp dissectors (like GTP's QoS negotiation AVP). I aborted the Idea of
using dissector tables beacuse it was very cumbersome to have to
register an entire protocol for each avp to be dissected.

I'm at a good point but I'll wait anyway until after the next release
to check it in.

Luis

On 7/7/05, Guy Harris <gharris@xxxxxxxxx> wrote:
> LEGO wrote:
> > I'm rewriting packet-radius.c so that the fields info is loaded from
> > the dictionary, so far so good.
> >
> > I need advice in where to place the radius dictionary.
> >
> > I do not want this to be a protocol preference because that would
> > impose to register the protocol far after the register_handoff.
> >
> > I thought in looking for it in a "radius" directory in some of the
> > default directories.
> 
> A "radius" subdirectory of the "data directory" would be appropriate.
> 
> To get the pathname of a file in that directory, call
> "get_datafile_path()"; to get the pathname of that directory itself,
> call "get_datafile_dir()".
> 
> To install in that directory, add to Makefile.am (near where
> "diameterdir" is set) something such as
> 
>         #
>         # Install the RADIUS directory files in the "radius" subdirectory
>         # of that directory.
>         #
>         radiusdir = $(pkgdatadir)/radius
>         radius_DATA = {list of files to install there}
> 
> in the top-level Makefile.am (as well as checking in the files to be
> installed into the top-level directory and adding those files to the
> EXTRA_DIST macro), and add to packaging/nsis/ethereal.nsi (near where
> the "Install the Diameter DTD and XML files..." comment appears)
> something such as
> 
>         :
>         : Install the RADIUS directory files in the "radius" subdirectory
>         : of the installation directory.
>         :
>         SetOutPath $INSTDIR\radius
>         File "..\..\{first file to install there}
>         File "..\..\{second file to install there}
>                 ...
>         SetOutPath $INSTDIR
> 
> > In which order should I look for it?
> 
> I.e., you're talking about allowing both a system RADIUS directory file
> and a user RADIUS directory file?
> 
> If so, look for it in the user's directory first, and if that doesn't
> find the file, look for the system file.
> 
> To get the pathname of a file in the user's "personal configuration
> file" directory, call "get_persconffile_path()"; to get the pathname of
> that directory itself, call "get_persconffile_dir()".
> 
> See "read_prefs()" in epan/prefs.c for an example of code to do that -
> if the attempt to open a file fails, only treat it as an indication that
> the file doesn't exist if "errno" is ENOENT, treat any other error as an
> error to report to the user (don't report to the user the lack of a
> personal RADIUS directory file or files).
> 
> Call "report_open_failure()" to report a failure to open a file,
> "report_read_failure()" to report an error reading the file (in the
> sense of reading the bytes of the file, not parsing the file), and
> "report_failure()" for other errors (e.g., syntax errors in the file).
> 
> A format similar to that of FreeRadius dictionary files might make
> sense, although you might want to add an additional field to specify a
> filterable field name for a RADIUS field (if not present, just add it to
> the protocol tree with proto_tree_add_text()).  See the comments I put
> into packet-radius.c about that.
> 


-- 
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan