Re: wget ipv6
By the way, can you please clarify the intention behind AI_V4MAPPED and AI_ALL, which configure tests for, but nothing uses?
Re: wget ipv6
On Thu, 20 Nov 2003, Hrvoje Niksic wrote: Maybe we should concentrate on the contents rather than style. :-) you're right ;-) i would also suggest renaming configure.in to configure.ac... Sure. I've never understood the conceptual difference between the two anyway. I'm already using AC_PREREQ(2.57)... basically, the configuration script for autoconf 2.5 should be named configure.ac. configure.in is supported only for backward compatibility. since we are using autoconf = 2.57, we should use configure.ac for consistency. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Grouphttp://www.ferrara.linux.it
wget ipv6
hi to hrvoje and all, i am still alive ;-) and i am finally catching up with the changes you've done at wget ipv6 code. from what i've seen so far, it seems that you've done a great job (especially on lookup_host and resolve_bind_address and on the transport_map)!!! only a few suggestions: change this code in address_list_contains: if (cur-type == IPV4_ADDRESS (ADDRESS_IPV4_IN_ADDR (cur).s_addr == ADDRESS_IPV4_IN_ADDR (ip).s_addr)) to the more readable: if (cur-type == IPV4_ADDRESS (ADDRESS_IPV4_IN_ADDR (cur).s_addr == ADDRESS_IPV4_IN_ADDR (ip).s_addr)) and rename address_list_connected_p to address_list_is_connected. now we have to add the checks for sockaddr_storage in configure.in. what about adding this test (taken from nc6): AC_DEFUN([TYPE_STRUCT_SOCKADDR_STORAGE],[ ds6_have_sockaddr_storage= AC_CHECK_TYPES([struct sockaddr_storage],[ ds6_have_sockaddr_storage=yes ],[ ds6_have_sockaddr_storage=no ],[ #include sys/types.h #include sys/socket.h ]) if test X$ds6_have_sockaddr_storage = Xyes; then : $1 else : $2 fi ]) to aclocal.m4, adding the test: TYPE_STRUCT_SOCKADDR_STORAGE(AC_DEFINE(HAVE_STRUCT_SOCKADDR_STORAGE, 1, Define if the system supports struct sockaddr_storage.)) to configure.in and changing: #ifndef ENABLE_IPV6 # ifndef HAVE_SOCKADDR_STORAGE # define sockaddr_storage sockaddr_in # endif #endif /* ENABLE_IPV6 */ to: #ifndef ENABLE_IPV6 # ifndef HAVE_STRUCT_SOCKADDR_STORAGE # define sockaddr_storage sockaddr_in # endif #endif /* ENABLE_IPV6 */ in connect.h? i would also suggest renaming configure.in to configure.ac... BTW, i'm doing few more tests on ftp support. after those tests, hrvoje, i'll let you delete all those ugly assertions in the ftp code :-) -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Grouphttp://www.ferrara.linux.it
Re: wget ipv6
Mauro Tortonesi [EMAIL PROTECTED] writes: hi to hrvoje and all, i am still alive ;-) and i am finally catching up with the changes you've done at wget ipv6 code. from what i've seen so far, it seems that you've done a great job (especially on lookup_host and resolve_bind_address and on the transport_map)!!! Thanks. change this code in address_list_contains: if (cur-type == IPV4_ADDRESS (ADDRESS_IPV4_IN_ADDR (cur).s_addr == ADDRESS_IPV4_IN_ADDR (ip).s_addr)) to the more readable: if (cur-type == IPV4_ADDRESS (ADDRESS_IPV4_IN_ADDR (cur).s_addr == ADDRESS_IPV4_IN_ADDR (ip).s_addr)) The indentation is not accidental. It's more readable (to me) because the ADDRESS_* macros are aligned. and rename address_list_connected_p to address_list_is_connected. The _p suffix stands for predicate comes from the Lisp world, as a convention to mark boolean function. There are other examples of it in Wget. I guess it's a matter of taste. Maybe we should concentrate on the contents rather than style. :-) now we have to add the checks for sockaddr_storage in configure.in. what about adding this test (taken from nc6): AC_DEFUN([TYPE_STRUCT_SOCKADDR_STORAGE],[ ds6_have_sockaddr_storage= AC_CHECK_TYPES([struct sockaddr_storage],[ ds6_have_sockaddr_storage=yes ],[ ds6_have_sockaddr_storage=no ],[ #include sys/types.h #include sys/socket.h ]) if test X$ds6_have_sockaddr_storage = Xyes; then : $1 else : $2 fi ]) This check looks good to me. #ifndef ENABLE_IPV6 # ifndef HAVE_SOCKADDR_STORAGE # define sockaddr_storage sockaddr_in # endif #endif /* ENABLE_IPV6 */ to: #ifndef ENABLE_IPV6 # ifndef HAVE_STRUCT_SOCKADDR_STORAGE # define sockaddr_storage sockaddr_in # endif #endif /* ENABLE_IPV6 */ in connect.h? OK. i would also suggest renaming configure.in to configure.ac... Sure. I've never understood the conceptual difference between the two anyway. I'm already using AC_PREREQ(2.57)...
Re: wget ipv6 patch
On Wed, 8 Oct 2003, Hrvoje Niksic wrote: Mauro Tortonesi [EMAIL PROTECTED] writes: I still don't understand the choice to use sockaddr and sockaddr_storage in a application code. They result in needless casts and (to me) uncomprehensible code. well, using sockaddr_storage is the right way (TM) to write IPv6 enabled code ;-) Not when the only thing you need is storing the result of a DNS lookup. i agree, in fact for that case we use the ip_address struct. I've seen the RFC, but I don't agree with it in the case of Wget. In fact, even the RFC states that the data structure is merely a help for writing portable code across multiple address families and platforms. Wget doesn't aim for AF independence, and the alternatives are at least as good for platform independence. i think we are talking about two different things. i am talking about storing generic socket addresses (IPv4 or IPv6) and i'm saying that for this task the ideal structure is sockaddr_storage. notice that my code uses sockaddr_storage (typedef'd as wget_sockaddr) only when dealing with socket addresses, not for ip address caching. and i am not trying to write af-indipendent code, anyway. For example, this cast: (unsigned char *)(addr-addr_v4.s_addr) would not be necessary if the address were defined as unsigned char[4]. in_addr is the correct structure to store ipv4 addresses. using in_addr instead of unsigned char[4] makes much easier to copy or compare ipv4 addresses. moreover, you don't have to care about the integer size in 64-bits architectures. An IPv4 address is nothing more than a 32-bit quantity. I don't see anything incorrect about using unsigned char[4] for that, and that works perfectly fine on 64-bit architectures. ok, but in this way you have to call memcmp each time you want to compare two ip addresses and memcpy each time you want to copy an ip address. i prefer the in_addr approach (and i don't understand why we shouldn't use structures like in_addr and in_addr6 which have been created just to do what we want: storing ip addresses) as i think it is a more elegant solution, but if you still wish to use unsigned char[4] and unsigned char[16] i cannot force you to change your mind. however, notice that using unsigned char[4] and unsigned char[16] is a less portable solution and is potentially prone to problems with the alignement of the sockaddr_in and sockaddr_in6 structs. Besides, you seem to be willing to cache the string representation of an IP address. Why is it acceptable to work with a char *, but unacceptable to work with unsigned char[4]? I simply don't see that in_addr is helping anything in host.c's code base. i would prefer to cache string representation of ip addresses because the ipv6 code would be much simpler and more elegant. I don't understand the new PASSIVE flag to lookup_host. well, that's a problem. to get a socket address suitable for bind(2), you must call getaddrinfo with the AI_PASSIVE flag set. Why? The current code seems to get by without it. the problem is when you call lookup_host to get a struct to pass to bind(2). if you use --bind-address=localhost and you don't set the AI_PASSIVE flag, getaddinfo will return the 127.0.0.1 address, which is incorrect. There must be a way to get at the socket address without calling getaddrinfo. not if you want to to use --bind-address=ipv6only.domain.com. If it would make your life easier to add TYPE in !ENABLE_IPV6 case, so you can write it more compactly, by all means do it. By more compactly I mean something code like this: [...] that's a question i was going to ask you. i supposed you were against adding the type member to ip_address in the IPv4-only case, Maintainability is more important than saving a few bytes per cached IP address, especially since I don't expect the number of cache entries to ever be large enough to make a difference. (If someone downloads from so many addresses that the hash table sizes become a problem, the TYPE member will be the least of his problems.) i agree. P.S. please notice that by caching the string representation of IP addresses instead of their network representation, the code could become much more elegant and simple. You said that before, but I don't quite understand why that's the case. It's certainly not the case for IPv4. sure, but that would be of great help, especially for IPv6. the code (and in particular the translation from ip addresses to socket addresses and viceversa) would be much simpler and elegant. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Grouphttp://www.ferrara.linux.it
Re: wget ipv6 patch
Mauro Tortonesi [EMAIL PROTECTED] writes: and i'm saying that for this task the ideal structure is sockaddr_storage. notice that my code uses sockaddr_storage (typedef'd as wget_sockaddr) only when dealing with socket addresses, not for ip address caching. Now I see. Thanks for clearing it up. An IPv4 address is nothing more than a 32-bit quantity. I don't see anything incorrect about using unsigned char[4] for that, and that works perfectly fine on 64-bit architectures. ok, but in this way you have to call memcmp each time you want to compare two ip addresses and memcpy each time you want to copy an ip address. Well, you can copy addresses with the assignment operator as well, as long as they're in a `struct', as they are in the current code. You do need `memcmp' to compare them, but that's fine with me. i prefer the in_addr approach (and i don't understand why we shouldn't use structures like in_addr and in_addr6 which have been created just to do what we want: storing ip addresses) Because they're complexly defined and hard to read if all you want is to store 4 and 16 bytes of binary data, respectively. however, notice that using unsigned char[4] and unsigned char[16] is a less portable solution and is potentially prone to problems with the alignement of the sockaddr_in and sockaddr_in6 structs. Note that I only propose using unsigned char[N] for internal storing of addresses, such as in Wget's own `struct ip_address'. For talking to system API's, we can and should copy the address to the appropriate sockaddr_* structure. That's how the current code works, and it's quite portable. Besides, you seem to be willing to cache the string representation of an IP address. Why is it acceptable to work with a char *, but unacceptable to work with unsigned char[4]? I simply don't see that in_addr is helping anything in host.c's code base. i would prefer to cache string representation of ip addresses because the ipv6 code would be much simpler and more elegant. I agree. My point was merely to point out that even you yourself believe that struct in_addr* is not the only legitimate way to store an IP address. I don't understand the new PASSIVE flag to lookup_host. well, that's a problem. to get a socket address suitable for bind(2), you must call getaddrinfo with the AI_PASSIVE flag set. Why? The current code seems to get by without it. the problem is when you call lookup_host to get a struct to pass to bind(2). if you use --bind-address=localhost and you don't set the AI_PASSIVE flag, getaddinfo will return the 127.0.0.1 address, which is incorrect. There must be a way to get at the socket address without calling getaddrinfo. not if you want to to use --bind-address=ipv6only.domain.com. I see. I guess we'll have to live with it, one way or the other. Instead of accumulating boolean arguments, lookup_host should probably accept a FLAGS argument, so you can call it with, e.g.: lst = lookup_host (addr, LH_PASSIVE | LH_SILENT); ...
Re: wget ipv6 patch
On Fri, 10 Oct 2003, Hrvoje Niksic wrote: Mauro Tortonesi [EMAIL PROTECTED] writes: An IPv4 address is nothing more than a 32-bit quantity. I don't see anything incorrect about using unsigned char[4] for that, and that works perfectly fine on 64-bit architectures. ok, but in this way you have to call memcmp each time you want to compare two ip addresses and memcpy each time you want to copy an ip address. Well, you can copy addresses with the assignment operator as well, as long as they're in a `struct', as they are in the current code. You do need `memcmp' to compare them, but that's fine with me. i prefer the in_addr approach (and i don't understand why we shouldn't use structures like in_addr and in_addr6 which have been created just to do what we want: storing ip addresses) Because they're complexly defined and hard to read if all you want is to store 4 and 16 bytes of binary data, respectively. i guess that depends from the development style you are used to. Besides, you seem to be willing to cache the string representation of an IP address. Why is it acceptable to work with a char *, but unacceptable to work with unsigned char[4]? I simply don't see that in_addr is helping anything in host.c's code base. i would prefer to cache string representation of ip addresses because the ipv6 code would be much simpler and more elegant. I agree. My point was merely to point out that even you yourself believe that struct in_addr* is not the only legitimate way to store an IP address. I don't understand the new PASSIVE flag to lookup_host. well, that's a problem. to get a socket address suitable for bind(2), you must call getaddrinfo with the AI_PASSIVE flag set. Why? The current code seems to get by without it. the problem is when you call lookup_host to get a struct to pass to bind(2). if you use --bind-address=localhost and you don't set the AI_PASSIVE flag, getaddinfo will return the 127.0.0.1 address, which is incorrect. There must be a way to get at the socket address without calling getaddrinfo. not if you want to to use --bind-address=ipv6only.domain.com. I see. I guess we'll have to live with it, one way or the other. Instead of accumulating boolean arguments, lookup_host should probably accept a FLAGS argument, so you can call it with, e.g.: lst = lookup_host (addr, LH_PASSIVE | LH_SILENT); ... -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi [EMAIL PROTECTED] [EMAIL PROTECTED] Deep Space 6 - IPv6 on Linuxhttp://www.deepspace6.net Ferrara Linux Users Group http://www.ferrara.linux.it
wget ipv6 patch
here is my first patch to improve ipv6 support of wget. please, notice that the code compiles, but is still buggy and will probably not work. i am sending this preliminary patch only to gather feedback from wget developers and to coordinate with other developers who are working on ipv6 support for wget. so, i am asking you: what do you think of these changes? -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Grouphttp://www.ferrara.linux.it wget-ipv6.diff.bz2 Description: Binary data
Re: wget ipv6 patch
Mauro Tortonesi [EMAIL PROTECTED] writes: so, i am asking you: what do you think of these changes? Overall they look very good! Judging from the patch, a large piece of the work part seems to be in an unexpected place: the FTP code. Here are some remarks I got looking at the patch. It inadvertently undoes the latest fnmatch move. I still don't understand the choice to use sockaddr and sockaddr_storage in a application code. They result in needless casts and (to me) uncomprehensible code. For example, this cast: (unsigned char *)(addr-addr_v4.s_addr) would not be necessary if the address were defined as unsigned char[4]. I don't understand the new PASSIVE flag to lookup_host. In lookup_host, the comment says that you don't need to call getaddrinfo_with_timeout, but then you call getaddrinfo_with_timeout. An oversight? You removed this code: - /* ADDR is defined to be in network byte order, which is what -this returns, so we can just copy it to STORE_IP. However, -on big endian 64-bit architectures the value will be stored -in the *last*, not first four bytes. OFFSET makes sure that -we copy the correct four bytes. */ - int offset = 0; -#ifdef WORDS_BIGENDIAN - offset = sizeof (unsigned long) - sizeof (ip4_address); -#endif But the reason the code is there is that inet_aton is not present on all architectures, whereas inet_addr is. So I used only inet_addr in the IPv4 case, and inet_addr stupidly returned `long', which requires some contortions to copy into a uchar[4] on 64-bit machines. (I see that inet_addr returns `in_addr_t' these days.) If you intend to use inet_aton without checking, there should be a fallback implementation in cmpt.c. I note that you elided TYPE from ip_address if ENABLE_IPV6 is not defined. That (I think) results in code duplication in some places, because the code effectively has to handle the IPv4 case twice: #ifdef ENABLE_IPV6 switch (addr-type) { case IPv6: ... IPv6 handling ... break; case IPv4: ... IPv4 handling ... break; } #else ... IPv4 handling because TYPE is not present without ENABLE_IPV6 ... #endif If it would make your life easier to add TYPE in !ENABLE_IPV6 case, so you can write it more compactly, by all means do it. By more compactly I mean something code like this: switch (addr-type) { #ifdef ENABLE_IPV6 case IPv6: ... IPv6 handling ... break; #endif case IPv4: ... IPv4 handling ... break; }
Re: wget ipv6 patch
On Wed, 8 Oct 2003, Hrvoje Niksic wrote: Mauro Tortonesi [EMAIL PROTECTED] writes: so, i am asking you: what do you think of these changes? Overall they look very good! Judging from the patch, a large piece of the work part seems to be in an unexpected place: the FTP code. yes, i have added support for LPRT and LPSV, and refactored existing code. i still have to work on the code, but the main problem remains probably the duplication of ftp_port and ftp_pasv, which have two different versions (one for the IPv6-enabled case and the other for IPv4-only case). Here are some remarks I got looking at the patch. It inadvertently undoes the latest fnmatch move. sorry. i am working on an old wget cvs release. i will get up-to-date with the latest cvs changes ASAP. I still don't understand the choice to use sockaddr and sockaddr_storage in a application code. They result in needless casts and (to me) uncomprehensible code. well, using sockaddr_storage is the right way (TM) to write IPv6 enabled code ;-) quoting RFC3493 section 3.10: One simple addition to the sockets API that can help application writers is the struct sockaddr_storage. This data structure can simplify writing code that is portable across multiple address families and platforms. This data structure is designed with the following goals. - Large enough to accommodate all supported protocol-specific address structures. - Aligned at an appropriate boundary so that pointers to it can be cast as pointers to protocol specific address structures and used to access the fields of those structures without alignment problems. The sockaddr_storage structure contains field ss_family which is of type sa_family_t. When a sockaddr_storage structure is cast to a sockaddr structure, the ss_family field of the sockaddr_storage structure maps onto the sa_family field of the sockaddr structure. When a sockaddr_storage structure is cast as a protocol specific address structure, the ss_family field maps onto a field of that structure that is of type sa_family_t and that identifies the protocol's address family. using a union like: struct wget_sockaddr { struct sockaddr; struct sockaddr_in; struct sockaddr_in6; }; is not an elegant solution, and is probably not safe because of compiler alignments. see the chapter about struct sockaddr_storage in: http://www.kame.net/newsletter/19980604 For example, this cast: (unsigned char *)(addr-addr_v4.s_addr) would not be necessary if the address were defined as unsigned char[4]. in_addr is the correct structure to store ipv4 addresses. using in_addr instead of unsigned char[4] makes much easier to copy or compare ipv4 addresses. moreover, you don't have to care about the integer size in 64-bits architectures. I don't understand the new PASSIVE flag to lookup_host. well, that's a problem. to get a socket address suitable for bind(2), you must call getaddrinfo with the AI_PASSIVE flag set. for instance, if you call: getaddrinfo(NULL, ftp, hints, res) with the AI_PASSIVE flag, you get the :: port 21 and 0.0.0.0 port 21 socket addresses, while calling getaddrinfo without the AI_PASSIVE flag returns the ::1 port 21 and 127.0.0.1 port 21 addresses. the passive flag for lookup_host is a very unelegant hack, but i haven't found a way to get rid of it, yet. any suggestion? In lookup_host, the comment says that you don't need to call getaddrinfo_with_timeout, but then you call getaddrinfo_with_timeout. An oversight? You removed this code: - /* ADDR is defined to be in network byte order, which is what - this returns, so we can just copy it to STORE_IP. However, - on big endian 64-bit architectures the value will be stored - in the *last*, not first four bytes. OFFSET makes sure that - we copy the correct four bytes. */ - int offset = 0; -#ifdef WORDS_BIGENDIAN - offset = sizeof (unsigned long) - sizeof (ip4_address); -#endif But the reason the code is there is that inet_aton is not present on all architectures, whereas inet_addr is. So I used only inet_addr in the IPv4 case, and inet_addr stupidly returned `long', which requires some contortions to copy into a uchar[4] on 64-bit machines. (I see that inet_addr returns `in_addr_t' these days.) If you intend to use inet_aton without checking, there should be a fallback implementation in cmpt.c. are there __REALLY__ systems which do not support inet_aton? their ISVs should be ashamed of themselves... however, yours seemed to me an ugly hack, so i have temporarily removed it. as you say, it would be probably better to provide a fallback implementation of inet_aton in cmpt.c. I note that you elided TYPE from ip_address if ENABLE_IPV6 is not defined. That (I think) results in code duplication in some places, because the code effectively has to handle the IPv4 case twice: #ifdef
Re: wget ipv6 patch
Mauro Tortonesi [EMAIL PROTECTED] writes: I still don't understand the choice to use sockaddr and sockaddr_storage in a application code. They result in needless casts and (to me) uncomprehensible code. well, using sockaddr_storage is the right way (TM) to write IPv6 enabled code ;-) Not when the only thing you need is storing the result of a DNS lookup. I've seen the RFC, but I don't agree with it in the case of Wget. In fact, even the RFC states that the data structure is merely a help for writing portable code across multiple address families and platforms. Wget doesn't aim for AF independence, and the alternatives are at least as good for platform independence. For example, this cast: (unsigned char *)(addr-addr_v4.s_addr) would not be necessary if the address were defined as unsigned char[4]. in_addr is the correct structure to store ipv4 addresses. using in_addr instead of unsigned char[4] makes much easier to copy or compare ipv4 addresses. moreover, you don't have to care about the integer size in 64-bits architectures. An IPv4 address is nothing more than a 32-bit quantity. I don't see anything incorrect about using unsigned char[4] for that, and that works perfectly fine on 64-bit architectures. Besides, you seem to be willing to cache the string representation of an IP address. Why is it acceptable to work with a char *, but unacceptable to work with unsigned char[4]? I simply don't see that in_addr is helping anything in host.c's code base. I don't understand the new PASSIVE flag to lookup_host. well, that's a problem. to get a socket address suitable for bind(2), you must call getaddrinfo with the AI_PASSIVE flag set. Why? The current code seems to get by without it. There must be a way to get at the socket address without calling getaddrinfo. are there __REALLY__ systems which do not support inet_aton? their ISVs should be ashamed of themselves... Those systems are very old, possibly predating the very invention of inet_aton. If it would make your life easier to add TYPE in !ENABLE_IPV6 case, so you can write it more compactly, by all means do it. By more compactly I mean something code like this: [...] that's a question i was going to ask you. i supposed you were against adding the type member to ip_address in the IPv4-only case, Maintainability is more important than saving a few bytes per cached IP address, especially since I don't expect the number of cache entries to ever be large enough to make a difference. (If someone downloads from so many addresses that the hash table sizes become a problem, the TYPE member will be the least of his problems.) P.S. please notice that by caching the string representation of IP addresses instead of their network representation, the code could become much more elegant and simple. You said that before, but I don't quite understand why that's the case. It's certainly not the case for IPv4.
Re: wget ipv6 patch
Mauro Tortonesi wrote: are there __REALLY__ systems which do not support inet_aton? their ISVs should be ashamed of themselves... Solaris, for example. IIRC inet_aton isn't in any document which claims to be a standard. however, yours seemed to me an ugly hack, so i have temporarily removed it. as you say, it would be probably better to provide a fallback implementation of inet_aton in cmpt.c. But standards define inet_pton, which can do what inet_aton does, so that should be checked for before using the fallback implementation. -- .-. .-.Yes, I am an agent of Satan, but my duties are largely (_ \ / _) ceremonial. | |[EMAIL PROTECTED]
Re: WGET+IPv6
Thomas Lussnig [EMAIL PROTECTED] writes: 1. without IPv6 there is no longer used new syscalls (gethostbyname2,inet_ntop,inet_pton) 2. It can on runtime downgreade to IPv4 3. In IPv6 mode it can handle IPv4 Adresses 4. Checked with following input www.ix.de , 217.110.115.160 , www.ipv6.euronet.be + Adress is shown as expected + Connection work clean :-) + checked also with IPv4 only where www.ipv6.euronet.be don't work (as expected because its ipv6 only) Cool, good work. There are still things to work on, though: * Autoconf support. Since I don't want to support broken IPv6 implementations, we don't need to get fancy here. Checking for several IPv6-specific calls and defining IPv6 only if all of them are there. There should also be a flag to turn off IPv6 entirely at compile-time. * FTP. You said you'd look for help there, but I'd at least like to make sure that IPv4 sites work with FTP, even in IPv6 mode. In fact, I dislike the idea of a mode, and I think it should be used only to downgrade to IPv4 and for debug purposes. * You haven't answered my question about scopes. Is it really safe to just store the IP address and then call it later, without also storing the address scope? Please take a careful look at this. * Style. Please take a look at Wget's coding standards (described in PATCHES file), and the accompanying GNU coding standards. Please don't use C++ comments. Please use lower-case variable names (`hostent' or `hptr' instead of HOSTENT).
Re: WGET+IPv6
On Wed, 16 Jan 2002, Hrvoje Niksic wrote: So we can just ignore the scope? I hope you are right -- I certainly don't know enough about this to judge for myself. The so called scope in IPv6 is emeddeded in the address, so you can't use IPv6 addresses without getting the scope too. Most nodes in IPv6 will have a number of different addresses, using different scope. -- Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77 ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: WGET+IPv6
On Wed, 16 Jan 2002, Hrvoje Niksic wrote: The so called scope in IPv6 is emeddeded in the address, so you can't use IPv6 addresses without getting the scope too. Are you sure? Here is what itojun said in [EMAIL PROTECTED]: due to the IPv6 address architecture (scoped), 16 bytes does not identify a node. we need 4 byte more information to identify the outgoing scope zone. Am I misunderstanding him that Wget needs to keep 20 bytes of information to successfully connect? Well, if itojun said it then that's so. I have the greatest respect for his IPv6 abilities. This is news to me and I don't really understand what a outgoing scope zone is... Sorry for the added confusion to this thread. -- Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77 ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: WGET+IPv6
Daniel Stenberg [EMAIL PROTECTED] writes: On Wed, 16 Jan 2002, Hrvoje Niksic wrote: The so called scope in IPv6 is emeddeded in the address, so you can't use IPv6 addresses without getting the scope too. Are you sure? Here is what itojun said in [EMAIL PROTECTED]: due to the IPv6 address architecture (scoped), 16 bytes does not identify a node. we need 4 byte more information to identify the outgoing scope zone. Am I misunderstanding him that Wget needs to keep 20 bytes of information to successfully connect? Well, if itojun said it then that's so. I have the greatest respect for his IPv6 abilities. That may be so, but I'm not entirely convinced that it is really important that Wget care about scopes in this context. I'm still discussing it with Thomas. For example, the gethostbyname2 and getipnodebyname calls don't return the scope at all. Does it mean that all applications that use them are broken? Somehow I doubt it. (And yes, I know that both seem to be obsolete, but I still find it strange that such a feature of such importance would be missing.) If someone here understands IPv6 enough to explain this, I'd be grateful to hear the clarification.
cleaner wget+ipv6
Hi, i worked on it :-) The good thing is http works not with IPv4 and IPv6 sites if commpiled with IPv6. 3 things have to be done now: 1. make command line siwtch to change the default 4/6 2. if IPv6 enabled and IPv4 address found make an IPv6 address from whem ( clean caching ) 3. Make the ftp protocol part. I think 1+2 i can handle. Cu Thomas Lußnig Only in wget-1.8.1_ipv6/src: .libs Only in wget-1.8.1_ipv6/src: Makefile Only in wget-1.8.1_ipv6/src: cmpt.o Only in wget-1.8.1_ipv6/src: config.h diff -ubr wget-1.8.1/src/connect.c wget-1.8.1_ipv6/src/connect.c --- wget-1.8.1/src/connect.cTue Nov 27 14:55:40 2001 +++ wget-1.8.1_ipv6/src/connect.c Tue Jan 15 11:17:18 2002 @@ -55,6 +55,8 @@ extern int errno; #endif +#define IPV6 + /* Variables shared by bindport and acceptport: */ static int msock = -1; static struct sockaddr *addr; @@ -78,14 +80,11 @@ int connect_to_one (const unsigned char *addr, unsigned short port, int silent) { - struct sockaddr_in sock_name; + SOCKADDR_IN sock_name; int sock, save_errno; - + int sockaddr_len=get_socklen(ip_default_family); /* Set port and protocol */ - sock_name.sin_family = AF_INET; - sock_name.sin_port = htons (port); - memcpy ((unsigned char *)sock_name.sin_addr, addr, 4); - + set_ip_address(ip_default_family,port,addr,(struct sockaddr *)sock_name); if (!silent) { char *pretty_addr = pretty_print_address (addr); @@ -99,15 +98,14 @@ } /* Make an internet socket, stream type. */ - sock = socket (AF_INET, SOCK_STREAM, 0); + sock = socket (ip_default_family, SOCK_STREAM, 0); if (sock 0) goto out; if (opt.bind_address) { /* Bind the client side to the requested address. */ - if (bind (sock, (struct sockaddr *)opt.bind_address, - sizeof (*opt.bind_address))) + if (bind (sock, (struct sockaddr *)opt.bind_address,sockaddr_len)) { close (sock); sock = -1; @@ -116,7 +114,7 @@ } /* Connect the socket to the remote host. */ - if (connect (sock, (struct sockaddr *)sock_name, sizeof (sock_name)) 0) + if (connect (sock, (struct sockaddr *)sock_name,sockaddr_len) 0) { close (sock); sock = -1; @@ -151,7 +149,7 @@ address_list_get_bounds (al, start, end); for (i = start; i end; i++) { - unsigned char addr[4]; + ip_address addr; int sock; address_list_copy_one (al, i, addr); @@ -210,11 +208,13 @@ bindport (unsigned short *port) { int optval = 1; - static struct sockaddr_in srv; + static SOCKADDR_IN srv={0}; + int sockaddr_len=get_socklen(ip_default_family); + msock = -1; addr = (struct sockaddr *) srv; - if ((msock = socket (AF_INET, SOCK_STREAM, 0)) 0) + if ((msock = socket (ip_default_family, SOCK_STREAM, 0)) 0) return CONSOCKERR; if (setsockopt (msock, SOL_SOCKET, SO_REUSEADDR, (char *)optval, sizeof (optval)) 0) @@ -222,14 +222,13 @@ if (opt.bind_address == NULL) { - srv.sin_family = AF_INET; - srv.sin_addr.s_addr = htonl (INADDR_ANY); + set_ip_address(ip_default_family,htons(*port),NULL,(struct sockaddr*)srv); } else srv = *opt.bind_address; - srv.sin_port = htons (*port); - if (bind (msock, addr, sizeof (struct sockaddr_in)) 0) + set_port(*port,(struct sockaddr*)srv); + if (bind (msock, addr, sockaddr_len) 0) { CLOSE (msock); msock = -1; @@ -241,14 +240,14 @@ /* addrlen should be a 32-bit type, which int is not guaranteed to be. Oh, and don't try to make it a size_t, because that can be 64-bit. */ - int addrlen = sizeof (struct sockaddr_in); + int addrlen = sockaddr_len; if (getsockname (msock, addr, addrlen) 0) { CLOSE (msock); msock = -1; return CONPORTERR; } - *port = ntohs (srv.sin_port); + *port=get_port((struct sockaddr*)srv); } if (listen (msock, 1) 0) { @@ -292,7 +291,7 @@ uerr_t acceptport (int *sock) { - int addrlen = sizeof (struct sockaddr_in); + int addrlen = get_socklen(ip_default_family); #ifdef HAVE_SELECT if (select_fd (msock, opt.timeout, 0) = 0) @@ -322,8 +321,8 @@ unsigned char * conaddr (int fd) { - static unsigned char res[4]; - struct sockaddr_in mysrv; + static ip_address res; + SOCKADDR_IN mysrv; struct sockaddr *myaddr; int addrlen = sizeof (mysrv);/* see bindport() for discussion of using `int' here. */ @@ -331,7 +330,11 @@ myaddr = (struct sockaddr *) (mysrv); if (getsockname (fd, myaddr, (int *)addrlen) 0) return NULL; - memcpy (res, mysrv.sin_addr, 4); +#ifdef IPV6 + memcpy (res, mysrv.sin6_addr, sizeof(ip_address)); +#else + memcpy (res, mysrv.sin_addr, sizeof(ip_address)); +#endif return res; } Only in wget-1.8.1_ipv6/src: connect.o Only in wget-1.8.1_ipv6/src: cookies.o Only in wget-1.8.1_ipv6/src: err Only in