Re: Parsing a Section of Binary String Data!


Nick Keighley wrote:
zoltan wrote:
Nick Keighley wrote:
zoltan wrote:
Nick Keighley wrote:
zoltan wrote:
dotnetdotcn@xxxxxxx wrote:
zoltan wrote:

<snip>

I am supposed to implement a DNS Query. The Information to be processed
resides in RRs ( Resource Records). The header <arpa/nameser.h>
contains the following structure to store the data of these RRs as :

typedef struct __ns_rr {
char name[NS_MAXDNAME];
uint16_t type;
uint16_t rr_class;
uint32_t ttl;
uint16_t rdlength;
const uchar_t *rdata;
} ns_rr;

Now, the rdata part can have several fields depending on the specific
type of Record.
For instance, the SRV type has only the following fields : priority,
weight, port ( all of unsigned int type) and a target string ( the
hostname).

For my requirement, I have to use the data stored in a NAPTR record.
The "rdata" contains the following fields for this type of record :

order, preference ( unsigned int) and
flags, services, regexp and replacement ( all of type char *).

Now, because the definition of the rdata in the ns_rr structure is
generic, I have defined ( as I need to ) a structure as follows, to
store the actual data :

struct NAPTR
{
unsigned int order;
unsigned int preference;
char * flags;
char * services;
char * regexp;
char * replacement;
};


So my question is this : How can I extract the string fields from the
rdata portion of the ns_rr structure and store them into the respective
fields in my user-defined structure?

The integer fields ( order and preference ) are easy enough, being of
fixed size. What about the strings which can be of variable size?

I hope that is clear enough to elicit a suggestion or a positive
response in the least!

I gather uchar_t is an unsigned char. How about:-

struct NAPTR *naptr;
ns_rr ns_rr_data;

/* load somehow ns_rr_data */

naptr = (struct NAPTR*)ns_rr_data.rdata;
printf ("services = \"%s\"\n", naptr->services);

this assumes your structure is laid out in the same way as the data in
ns_rr.
Check if they define something like your struct NAPTR and use that.

To test the hypothesis, I wrote this sample program.... Can u tell
me why it does not work? The program segment faults... ( after the
printf("%s",record.rdata); statement).


// Program to test the rdata parsing capability.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <malloc.h>

struct NAPTR
{

unsigned int order;
unsigned int preference;
char * flags;
char * services;
char * regexp;
char * replacement;
};

struct nsrr
{

char name[255];
unsigned type;
unsigned class;
unsigned ttl;
unsigned rdlength;
char *rdata;
};


int main(void)
{

struct NAPTR *naptr;
struct nsrr record;

record.rdata=(char*)malloc(1024);

cast not needed. Test for malloc failure

strcpy(record.name,"www.foo.com");



record.type=1;
record.class=1;
record.ttl=8640;
strcpy(record.rdata,"100 10 s sip+e2u !http://[^/:](.*)!\1!i
www.foo.com");
record.rdlength=sizeof(record.rdata);

try your debugger (I can't believe I said that...). The rdata doesn't
seem
to be in the same format as NAPTR...


printf("%s",record.rdata);

naptr=(struct NAPTR*)(record.rdata);

this trick is dangerous if the data is not formatted as struct NAPTR.
and yours isn't

printf("\nThe Record contents are : ");

printf("%s",naptr->flags);
printf("\n%s",naptr->services);
printf("\n%s",naptr->regexp);
printf("\n%s",naptr->replacement);
return 0;
}


--



- Show quoted text -
I suppose u are referring to the fact that I havent' mentioned anything

about the Domain Name, class etc.


The structure of the NAPTR record acc to RFC 2915 is :


Domain TTL Class Type Order Preference Flags Services Regexp
Replacement. ( in this order ).

The ns_rr structure defined is <arpa/nameser.h> actually
has separate fields for Domain, TTL, Type and Class. These are
considered as the Header. The remaining fields form the rdata portion.


I just require to extract the fields in the rdata section, so I wrote
this simple program. How is the RDATA section not the same as the one
in the example?


Thanks and Regards,


Timmy Jose.
Nick Keighley

.

Relevant Pages