Search the web
Sign In
New User? Sign Up
dnrd · DNRD discussion list
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Real people. Real stories. See how Yahoo! Groups impacts members worldwide.

Best of Y! Groups

   Check them out and nominate your group.
Having problems with message search? Fill out this form to ensure your group is one of the first to be migrated to the new message search system.

Messages

  Messages Help
Advanced
[t.steffen@tu-harburg.de: Re: dnrd "bombs" on SPARCclassic]   Message List  
Reply | Forward Message #179 of 261 |
Hi Brad,


I'm forwarding you three mails that contain more information (plus a patch)
about the sparc classic problem. I hope this helps you.


Thomas

----- Forwarded message from Thomas Steffen <t.steffen@...> -----

To: Thomas Schoepf <schoepf@...>
Cc: 78225@...
Subject: Re: dnrd "bombs" on SPARCclassic
From: Thomas Steffen <t.steffen@...>
Date: 30 Dec 2000 19:43:40 +0100

Thomas Schoepf <schoepf@...> writes:

> Hi,
>
> did you try to upgrade to dnrd version 2.8?

Yes, I did today compile dnrd 2.8-4. *Very* hard to find though,
something is seriously missing on the debian master server...

> Did it help?

Yes and no. It bombs no more, but it doesn't work either.
nslookup returns an "error(1). no such host/domain." when I try to
look up a host in /etc/hosts.

What is strange: when I start dnrd -d, it shows all the addresses it
"bind" for. Among them are

0.0.1.in-arpa
3.3.3.in-arpa
etc.

which correspond to 127.0.0.1 and 10.3.3.3 in /etc/hosts. Now if I
understand the dns-protocol correctly, it should be 0.0.127.in-arpa
and 3.3.10.in-arpa. So something is still seriously wrong.

(I hope I haven't mistyped that, sorry, my setup is a bit a mess
and the sun is a realy slow thing where I have no mail-program set up)

Now that I know how to compile debian packages, further tests should
be easy. I will try to compile it for debugging and see whether I can
find anything. Hmpf, I hope gdb is installed...

Thomas <t.steffen@...>


----- End forwarded message -----

----- Forwarded message from Thomas Steffen <t.steffen@...> -----

To: Thomas Schoepf <schoepf@...>
Subject: Re: dnrd "bombs" on SPARCclassic
From: Thomas Steffen <t.steffen@...>
Date: 31 Dec 2000 12:25:51 +0100

Thomas Schoepf <schoepf@...> writes:

> did you try to upgrade to dnrd version 2.8? Did it help?

So, I did get the debugger working and had a look around. 4 bugs found
so far, but still no end in sight.

The problem is imho, that dnrd is not written with anything but intel
architecture in mind. It does assume endianes in several places and
several ways, and it does unaligned writes. In detail:

* ntohl is used to swap bytes
(that's the reason it doesn't work. reverse dns lookup gets the 4
bytes in the wrong order, as I speculated in the last message.
__bswap_32 works, but is gcc specific.)
* (short *) is used to access (int *)
(that's the reason the parsing goes wrong)
* (short *) is used unaligned
(and that's the reason the program bombs)

Apart from that, the code relies heavily on short being 2 bytes long
and int being 4 bytes long. Maybe that's the case for gcc, but
certainly not for other compilers. int16_t and int32_t should be a lot
better for that.

I am sure that an unaligned write is possible on a sparc (not in
hardware, but in software emulation), but I have no idea how to switch
that on.

Thomas <t.steffen@...>


----- End forwarded message -----

----- Forwarded message from Thomas Steffen <t.steffen@...> -----

To: Thomas Schoepf <schoepf@...>
Cc: Thomas Steffen <t.steffen@...>, 78225@...
Subject: Re: dnrd "bombs" on SPARCclassic
From: Thomas Steffen <t.steffen@...>
Date: 31 Dec 2000 18:40:21 +0100

Thomas Schoepf <schoepf@...> writes:

> did you try to upgrade to dnrd version 2.8? Did it help?

3rd reply, and this time final:

No, it doesn't, but I have traced down the obvious error and corrected
them. See the diff file for details. Basically, these are the
problems:

* ntohl is assumed to swap bytes
* (short*) is used to access an int
* writes to unaligned shorts
* bitfield is assumed in litte endian layout (the order of bit fields
is reversed on a sparc!)

So it works for me, both on intel and sparc. I have checked master,
relay and cache as well as lookup miss, no problem so far. I have been
careful not to break anything as well. But please have a look at the
changes.

The changes should only have an effect on mashines where __BYTE_ORDER
is defineds, that is big endian mashines with glibc header files.
Other compiles may not work, but I don't know a really portable way
for what is necessary.

Can you pass on the fixes to the author of dnrd, or shall I do that?

So here is the unified diff:
Thomas Steffen
----------------------------------------------------------------------
diff -Naur dnrd-2.8/src/dns.c dnrd-2.8-new/src/dns.c
--- dnrd-2.8/src/dns.c Thu Jun 15 17:20:59 2000
+++ dnrd-2.8-new/src/dns.c Sun Dec 31 10:39:57 2000
@@ -161,6 +161,7 @@
unsigned char *here, int question)
{
int k, len;
+ unsigned short int conv;

/*
* Read the name of the resource ...
@@ -173,16 +174,16 @@
* ... the type of data ...
*/

- memcpy(&y->type, here, sizeof(unsigned short int));
- y->type = ntohs(y->type);
+ memcpy(&conv, here, sizeof(unsigned short int));
+ y->type = ntohs(conv);
here += 2;

/*
* ... and the class type.
*/

- memcpy(&y->class, here, sizeof(unsigned short int));
- y->class = ntohs(y->class);
+ memcpy(&conv, here, sizeof(unsigned short int));
+ y->class = ntohs(conv);
here += 2;

/*
diff -Naur dnrd-2.8/src/dns.h dnrd-2.8-new/src/dns.h
--- dnrd-2.8/src/dns.h Sat Oct 23 23:24:49 1999
+++ dnrd-2.8-new/src/dns.h Sun Dec 31 16:21:04 2000
@@ -35,10 +35,25 @@
#define PACKET_DATABEGIN 12


+#ifndef __BYTE_ORDER
+#pragma warning Could not determine byte order (no glibc headers), assuming
small endian.
+#define __BYTE_ORDER
+#endif
+
typedef union _packetflags {
unsigned short flags;

struct {
+#if __BYTE_ORDER == __BIG_ENDIAN
+ unsigned short int question:1;
+ unsigned short int opcode:4;
+ unsigned short int authorative:1;
+ unsigned short int truncated:1;
+ unsigned short int want_recursion:1;
+ unsigned short int recursion_avail:1;
+ unsigned short int unused:3;
+ unsigned short int rcode:4;
+#else
unsigned short int rcode:4;
unsigned short int unused:3;
unsigned short int recursion_avail:1;
@@ -47,6 +62,7 @@
unsigned short int authorative:1;
unsigned short int opcode:4;
unsigned short int question:1;
+#endif
} b;
} pflag_t;

diff -Naur dnrd-2.8/src/master.c dnrd-2.8-new/src/master.c
--- dnrd-2.8/src/master.c Thu Jun 15 17:55:57 2000
+++ dnrd-2.8-new/src/master.c Sun Dec 31 17:34:21 2000
@@ -1,4 +1,3 @@
-
/*

File: master.c - Small master DNS for local hosts
@@ -133,8 +132,13 @@
}

nameip->ipnum = ntohl(ipnum.s_addr);
- ipnum.s_addr = nameip->ipnum;

+#if __BYTE_ORDER == __BIG_ENDIAN
+ ipnum.s_addr = __bswap_32(ipnum.s_addr);
+ /* this is correct and endian-insensitive, but not portable to other
compilers t.steffen@... */
+#else
+ ipnum.s_addr = ntohl(ipnum.s_addr);
+#endif
mkstring(&nameip->arpa, inet_ntoa(ipnum));

return (DNS_NAMEIP);
@@ -528,7 +532,8 @@

static unsigned char *compile_int(dnsheader_t *x, int number)
{
- *((unsigned short int *) x->here) = htons((unsigned short) number);
+ unsigned short conv = htons((unsigned short) number);
+ memcpy(x->here,&conv,2);
x->here += 2;

return (x->here);
@@ -536,7 +541,8 @@

static unsigned char *compile_long(dnsheader_t *x, long number)
{
- *((unsigned long *) x->here) = htonl((unsigned long) number);
+ unsigned long conv = htonl((unsigned long) number);
+ memcpy(x->here,&conv,4);
x->here += 4;

return (x->here);
@@ -552,11 +558,13 @@

static int end_rdata(dnsheader_t *x)
{
+ unsigned short int conv;
if (x->rdata != NULL) {
int rsize;

rsize = x->here - (x->rdata + 2);
- *((unsigned short int *) x->rdata) = htons((unsigned short int) rsize);
+ conv = htons((unsigned short int) rsize);
+ memcpy(x->rdata,&conv,2);
}

x->rdata = NULL;



----- End forwarded message -----

--
1024D/B0FA4F49: FA38 2D7E 408F 61E4 BF49 B48F 04BD F5BE B0FA 4F49
2048g/C631AF6E: B89D 7BF4 AA6B 569B D9D1 4BF6 3459 66AB C631 AF6E



Wed Jan 3, 2001 7:25 pm

schoepf@...
Send Email Send Email

Forward
Message #179 of 261 |
Expand Messages Author Sort by Date

Hi Brad, I'm forwarding you three mails that contain more information (plus a patch) about the sparc classic problem. I hope this helps you. Thomas ... To:...
Thomas Schoepf
schoepf@...
Send Email
Jan 3, 2001
7:40 pm

... [...] ... Somehow I missed one change, here it is. Thomas <t.steffen@...> PS: Keep in mind that I'm not on the list. ... +++...
Thomas Steffen
t.steffen@...
Send Email
Jan 7, 2001
4:48 pm
Advanced

Copyright © 2009 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines - Help