Hi,

I've adjusted the netdb code to actually fix some things and resolve ipv6 addresses, and follow cname pointers..

Attached is a patch :-)

Also attached is a test program but that will only work if you have ipv6 enabled and are connected to 6bone in some way. You can test the cname resolving anyway though.
And the test program needs my other patch with ipv6 structures to work.

johannes

Applied, thank you.

Also attached is a test program but that will only work if you have ipv6 enabled and are connected to 6bone in some way. You can test the cname resolving anyway though.

I've added the program.

And the test program needs my other patch with ipv6 structures to work.

I must have missed those. Can you please send them again ? (Unless someone else applied them already)

Michael.

Hi,

Applied, thank you.

Thanks :)

> And the test program needs my other patch with ipv6 structures to work. I must have missed those. Can you please send them again ? (Unless someone else applied them already)

No, I don't think they're applied, see attached.
Could you also apply this:
--- rtl/inc/sockets.inc 22 Nov 2003 21:58:09 -0000      1.10
+++ rtl/inc/sockets.inc 23 Nov 2003 10:31:13 -0000
@@ -105,7 +105,7 @@
   FileRec(SockOut).Handle:=Sock;
   FileRec(SockOut).RecSize:=1;
   FileRec(SockOut).userdata[1]:=S_OUT;
-  FileRec(SockOut).Mode := fmAppend;
+  FileRec(SockOut).Mode := fmOutput;

I messed up with that before and Marco fixed sock2text but apparently not sock2file. I thought fmAppend would be better, but apparently that flag is not supposed to ever be set in such a structure.

Also, netdb needs cleaning up, I'll do that soon and send another patch then. I also forgot to add CNAME records to the ipv4 functions (which will be just a code copy).

johannes

Johannes Berg wrote

Also, netdb needs cleaning up, I'll do that soon and send another patch then. I also forgot to add CNAME records to the ipv4 functions (which will be just a code copy).

Done most of that, but generally the code in netdb is not very error-checking, so I added a warning. Attached is a new patch that also adds ResolveAddress6 to find name(s) for a given address. I also made the ntoh* and hton* function parameters constant and fixed up all code where they were used, the code was generally very confused as to what should happen with the argument, some code assumed the argument would be changed and some assumed it would only return the flipped value.
I haven't had a chance to test any of the ipv6 stuff on a big-endian machine so I'd be very interested in hearing from someone who actually uses ipv6 on a big-endian machine, I would expect some problems.

johannes

Johannes Berg wrote

Done most of that,

Never mind. The code in netdb doesn't even properly handle results from multiple servers (the second results overwriting the first) and its hard to even extend it any further. Maybe I'll just rewrite a resolver library. Don't hold your breath though.

johannes

Can't use the libc loading trick here as well? I.e. only if ipv6 stuff is used, libc is loaded dynamically at run time?

Florian Klaempfl wrote

Can't use the libc loading trick here as well? I.e. only if ipv6 stuff is used, libc is loaded dynamically at run time?

Thats not really the problem, I managed to add ipv6 resolving (and, in a new patch that I'll send if the previous one gets applied, I also do IPv4->6 mapped addresses if no native ip6 addresses are found).

The problem is more that the general code looks rather buggy, even the old one for ipv4. The loading trick is not going to help there.

Looks like I was wrong though about the results being overwritten, only the results from the first server are ever considered unless it returned none. However, even if the first server gave an error, no second server is tried.

johannes

Johannes Berg wrote

However, even if the first server gave an error, no second server is tried.

Easily fixed, replace (Result = 0) with (Result <= 0) in ResolveName[6].

johannes