ndt-users list created

[Matt Mathis <>]

+Tiziana

Thanks for the discussion on the web100 list!  Can you guys be ready
to test NDT IPv6 on M-Lab when they get IPv6 connectivity?   I don't
have an ETA yet, but real soon now I am sure.

(FYI to everyone else) There was a web100 library patch (attached)
from ~2008 to fix dual stack IPv6.  We failed to get it into a release
somehow.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay


On Tue, Mar 1, 2011 at 3:49 PM, Jason Zurawski 
<>
 wrote:
> Hey Matt;
>
> Aaron Brown (cc'ed) will mail his patch to the discussion list ASAP.  We
> haven't thoroughly tested this beyond a couple of users currently.
>
> Thanks;
>
> -jason
>
> On 3/1/11 3:27 PM, Matt Mathis wrote:
>> Please send your library fix with a little summary to 
>> .
>>
>> Thanks,
>> --MM--
>> -------------------------------------------
>> Matt Mathis    Home/Cell:412.654.7529
>>
>> On Mon, Feb 28, 2011 at 2:52 PM, Jeremy 
>> Palmer<>
>>   wrote:
>>> Fist thing to do is to make sure your server is actually listening on the
>>> appropriate NDT ports on V6. See below examples.
>>>
>>> - This port for fakewww is listening on IPV6.
>>> # netstat -anp | grep 7123
>>> tcp        0      0 :::7123                     :::*
>>> LISTEN      27107/fakewww
>>>
>>> - This port for web100srv is only listening on IPV4.
>>> # netstat -anp | grep 3001
>>> tcp        0      0 0.0.0.0:3001                0.0.0.0:*
>>> LISTEN      27100/web100srv
>>>
>>> In the above example, I can connect to the NDT page over v6 but would not 
>>> be
>>> able to run a NDT test since web100srv/3001 is only listening on V4.
>>>
>>> Also, I believe there are at least two bugs related to IPV6 in the current
>>> implementation of the PerfSonar toolkit (assuming you are running the 
>>> toolkit).
>>>
>>> - The first bug appears to be a redirect issue to the toolkit homepage 
>>> itself.
>>> For example if I go to the IPV6 base URL of one of my PSToolkit boxes:
>>> http://[2600:3000:2400::10]
>>> I get an "Unable To Connect" error in FFox. I believe this is because its 
>>> trying
>>> to redirect to "/toolkit" with a IPV4 URL. I'm assuming Ffox wont follow 
>>> a v4
>>> redirect when accessed via a v6 URL (just a guess). The workaround is to 
>>> use
>>> /toolkit at the end of the v6 URL so it doesn't try to redirect:
>>> http://[2600:3000:2400::10]/toolkit/
>>>
>>> - The second bug appears to be related to NDT and the web100 userland 
>>> libs. My
>>> issue is if I enable IPV6 in the WEB100SRV_OPTIONS in /etc/sysconfig/ndt, 
>>> NDT
>>> tests over V6 works fine, but when trying to run tests over v4 I get the
>>> infamous "protocol error!". Switching NDT back to ipv4-only cures the 
>>> error but
>>> disables V6 testing. According to a response to my post on this issue, 
>>> there is
>>> an unsupported but fixed version of the web100 userland libs available:
>>>
>>>> I've got an web100 userland RPM with a bugfix that seems to fix this 
>>>> issue on
>>> the hosts here. If you don't mind being a guinea pig, you can grab the 
>>> RPM from
>>> http://software.internet2.edu/branches/aaron-testing/rpms/i386/RPMS.main/web100_userland-1.7-4.el5.i386.rpm
>>> . Install it by running "rpm -Uvh web100_userland-1.7-4.el5.i386.rpm" as 
>>> root.
>>> Then, restart NDT by running "/sbin/service ndt restart". In testing 
>>> locally,
>>> we've found that this new RPM seems to fix this "protocol error" issue on 
>>> our
>>> dual-stack hosts. Let us know if it works for you.
>>>
>>> Hope this helps!
>>>
>>> On 2/28/2011 6:59 AM, 
>>> 
>>>  wrote:
>>>> Hi all ,
>>>>
>>>> I have try to  using ipv6 address instead of a DNS name  and start 
>>>> fakewww ,
>>>> web100srv -4 and web100srv -6,  But cann't  open the ndt site with ipv6 
>>>> address.
>>>>
>>>> I have try to using the format http://[ipv6-addr]:port to connect my ndt 
>>>> server
>>>> site, But still can't connect .
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Am I missing anything ? any hint ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks and best regards
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Matt
> _______________________________________________
> Web100-discussion mailing list
> 
> https://lists.psc.edu/mailman/listinfo/web100-discussion
>
> To UNSUBSCRIBE visit 
> https://lists.psc.edu/mailman/unsubscribe/web100-discussion
>
Index: lib/web100.c
===================================================================
RCS file: /afs/psc.edu/usr/web100/cvsroot/userland/lib/web100.c,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- lib/web100.c	14 Apr 2008 04:00:41 -0000	1.40
+++ lib/web100.c	20 Apr 2008 07:03:23 -0000	1.41
@@ -25,7 +25,7 @@
  * See http://www-unix.mcs.anl.gov/~gropp/manuals/doctext/doctext.html for
  * documentation format.
  *
- * $Id: web100.c,v 1.40 2008/04/14 04:00:41 jheffner Exp $
+ * $Id: web100.c,v 1.41 2008/04/20 07:03:23 jheffner Exp $
  */
 
 #include "config.h"
@@ -754,9 +754,6 @@
     socklen_t namelen; /* may not be POSIX */
     struct web100_connection_spec spec; /* connection tuple */
     struct web100_connection_spec_v6 spec6;
-    struct sockaddr_in *ne4 = (struct sockaddr_in *)&ne6;
-    struct sockaddr_in *fe4 = (struct sockaddr_in *)&fe6;
-
 
     /* XXX TODO XXX: Should we only allow local agents? */
     
@@ -775,6 +772,9 @@
     switch (((struct sockaddr *)&fe6)->sa_family) {
     case AF_INET:
     {
+        struct sockaddr_in *ne4 = (struct sockaddr_in *)&ne6;
+        struct sockaddr_in *fe4 = (struct sockaddr_in *)&fe6;
+        
         spec.src_addr = ne4->sin_addr.s_addr;
         spec.src_port = ntohs(ne4->sin_port);
         spec.dst_addr = fe4->sin_addr.s_addr;
@@ -782,14 +782,30 @@
         return web100_connection_find(agent, &spec);
     }
     case AF_INET6:
+    	/* V4 mapped addresses are kind of tricky.  It turns out that
+    	 * if we create a v6 socket and initiate a connection, it will
+    	 * have an v6 addrtype.  However, if we listen on a v6 socket
+    	 * and accept a connection from a v4 addr, we will have a v6
+    	 * socket but a v4 addrtype.  This can be viewed as a bug
+    	 * in the web100 kernel, but now we have o work around that.
+    	 *
+    	 * The solution here is to just try to find both v4 and v6
+    	 * when we see a mapped address.
+    	 */
         if (IN6_IS_ADDR_V4MAPPED(&fe6.sin6_addr)) {
+            web100_connection* conn;
+            
             memcpy(&spec.src_addr, &ne6.sin6_addr.s6_addr[12], 4);
+            spec.src_port = ntohs(ne6.sin6_port);
             memcpy(&spec.dst_addr, &fe6.sin6_addr.s6_addr[12], 4);
-        } else {
-            memcpy(&spec6.src_addr, &ne6.sin6_addr, 16);
-            memcpy(&spec6.dst_addr, &fe6.sin6_addr, 16);
+            spec.dst_port = ntohs(fe6.sin6_port);
+            conn = web100_connection_find(agent, &spec);
+            if (conn)
+            	return conn;
         }
+        memcpy(&spec6.src_addr, &ne6.sin6_addr, 16);
         spec6.src_port = ntohs(ne6.sin6_port);
+        memcpy(&spec6.dst_addr, &fe6.sin6_addr, 16);
         spec6.dst_port = ntohs(fe6.sin6_port);
         return web100_connection_find_v6(agent, &spec6);
     default: