This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: DNS big-endian bitfield
- From: Andrew Lunn <andrew dot lunn at ascom dot ch>
- To: Roland Caßebohm <roland dot cassebohm at visionsystems dot de>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Wed, 28 Aug 2002 13:05:29 +0200
- Subject: Re: [ECOS] DNS big-endian bitfield
- References: <200208281057.g7SAvQM15389@hhlx01.visionsystems.de>
Hi Roland.
When i wrote the DNS code i did not have a big endian system to test
on. Hence im not supprised you are having problems.
Maybe we can work together to fix this and test it on both a big and
little endian system?
Andrew
On Wed, Aug 28, 2002 at 12:57:22PM +0200, Roland Caßebohm wrote:
> Hi,
>
> there is a problem with the DNS-package.
> I think the order of the bits in the third and the fourth byte in the
> dns_header is wrong.
>
> The declaration of the dns header structure in dns_impl.inl is as follows:
>
> struct dns_header {
> unsigned id :16; /* query identification number */
> /* fields in third byte */
> unsigned rd :1; /* recursion desired */
> unsigned tc :1; /* truncated message */
> unsigned aa :1; /* authoritive answer */
> unsigned opcode :4; /* purpose of message */
> unsigned qr :1; /* response flag */
> /* fields in fourth byte */
> unsigned rcode :4; /* response code */
> unsigned cd: 1; /* checking disabled by resolver */
> unsigned ad: 1; /* authentic data from named */
> unsigned unused :1; /* unused bits */
> unsigned ra :1; /* recursion available */
> /* remaining bytes */
> unsigned qdcount :16; /* number of question entries */
> unsigned ancount :16; /* number of answer entries */
> unsigned nscount :16; /* number of authority entries */
> unsigned arcount :16; /* number of resource entries */
> };
>
> but the RFC defines:
>
> RFC 1035:
>
> 4.1.1. Header section format
>
> The header contains the following fields:
>
> 1 1 1 1 1 1
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> | ID |
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> |QR| Opcode |AA|TC|RD|RA| Z | RCODE |
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> | QDCOUNT |
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> | ANCOUNT |
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> | NSCOUNT |
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> | ARCOUNT |
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>
>
> I am using a big-endian system. Maybe for a little endian system this is the
> right order? But I don't think so.
>
> Allthough there is another thing, in build_query() in dns.c the opcode value
> is set via htons(). Since this is a 4 bit value I think it shouldn't use
> htons().
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss