search

jayduhon / inferno-os

Automatically exported from code.google.com/p/inferno-os
2 stars 0 forks source link

no ipv6 support for hosted inferno (with patch for linux) #193

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
hosted inferno only does ipv4.  i've wanted ipv6 for quite some time.  it
turns out it isn't very hard.  i attached a patch that gives linux ipv6
support.  all sockets are simply created as AF_INET6, and ipv4-mapped
addresses are used for ipv4 addresses.  this fits well with the existing
inferno/plan 9 code.

the other OS'es supported have their own (almost identical) copies of
ipif.c.  these must all be changed because of the changes in interface as
used by the portable devip.c.  as it stands, the attached linux ipv6 patch
cannot be integrated as it would break all other host OS'es code.

does this patch seem reasonable?  if it is, i can continue working in this
direction.  i see that it's also used by Hp and Irix.  i don't have access
to such machines to test on...

wouldn't it be best if more ipif.c's were merged (where reasonable)?  it
seems they are very similar already.  and based on what i read online, all
of linux,freebsd,netbsd,windows and probably mac os x support ipv4-mapped
addresses on AF_INET6 sockets in this standard way.  only openbsd does not
(for "security reasons").  i guess openbsd will simply be out of luck (but
it will need different code to cope).

i can install freebsd & netbsd to test on.  and probably install a compiler
on windows xp too.

another thing:
i keep getting warnings:
../port/ipif-posix.c: In function ‘resolve’:
../port/ipif-posix.c:320: warning: comparison between pointer and integer

which is here:
                if(inet_ntop(r->ai_family, addr, buf, r->ai_addrlen) != nil)

it doesn't like the != nil check.  though inet_ntop returns a char*.  no
idea what's going on there.

i've tested that things still work, including udp with all types of
(legacy) headers.  the attached testudp.b listens for udp messages, with
the various types of headers.  i ran it as follows:

on unix, for sending:
echo test | nc -u $host4 $port
echo test | nc -u $host6 $port

on inferno, for listening.  first 3x on *, then a specific ip4 address,
then a specific ip6 address.  -h sets the header lengths from headers4,
oldheaders and the current headers.  they all work.  for headers4 with
messages from ipv6 addresses an error is returned.

testudp -h 12 -d
testudp -h 36 -d
testudp -h 52 -d

testudp -h 12 -d udp!$host4!$port
testudp -h 36 -d udp!$host4!$port
testudp -h 52 -d udp!$host4!$port

testudp -h 12 -d udp!$host6!$port
testudp -h 36 -d udp!$host6!$port
testudp -h 52 -d udp!$host6!$port

i have ipv6 connection through www.sixxs.net.  it's free to get a tunnel
from them.

Original issue reported on code.google.com by mechiel@ueber.net on 19 Jul 2009 at 8:49

Attachments:

GoogleCodeExporter commented 9 years ago 
here are the full versions of the files changed in the diff.

Original comment by mechiel@ueber.net on 19 Jul 2009 at 8:56

Attachments:

GoogleCodeExporter commented 9 years ago 
i've improved the patch, made it work on freebsd & netbsd too (which means it
probably also works on macosx, but i don't have access to such a machine).  i 
moved
the ipv6 support to a separate ipif-posix6.c, and updated the current 
ipif-posix.c to
the changed interface from ip.h & devip.c.  that means the ipv4-only ipif-posix
behaviour can be had by just specifying that in the emu config file.

it seems that windows xp does not have the right dual stack socket 
functionality that
allows a simple ipv6 implementation.  that only comes with vista and higher.  
i've
modified the Nt ipif.c to work with the changed interface too.  that compiles &
works, at least on windows xp sp3 with a relatively recent microsoft c++ 
compiler
(free download).

if i can arrange an (sdram) memory upgrade for my machine, i'll see if i can add
windows >= vista ipv6 code too, on a windows 7 release candidate machine.

other ports (Hp, Unixware, Irix) seem to use ipif-posix.c and perhaps also 
freebsd's
ipif.c.  i cannot test those, but they can always use the unchanged 
ipif-posix.c code.

anyway, no patch attached yet.  i'll do a bit more testing tomorrow.

Original comment by mechiel@ueber.net on 20 Jul 2009 at 11:42

GoogleCodeExporter commented 9 years ago 
update attached.  the .tgz has all new versions for the files (against latest 
hg at
this time, rev 333).  the diff makes rev 333 updated to ipv6.

files involved:

modified:
emu/FreeBSD/emu
emu/Linux/emu
emu/Linux/emu-g
emu/MacOSX/emu
emu/NetBSD/emu
emu/OpenBSD/emu
emu/Unixware/emu
emu/Nt/emu
emu/Nt/mkfile
emu/port/devip.c
emu/port/ip.h
emu/Nt/ipif.c
emu/port/ipif-posix.c

new:
emu/Nt/ipif6.c
emu/port/ipif6-posix.c

removed:
emu/FreeBSD/ipif.c
emu/MacOSX/ipif.c
emu/NetBSD/ipif.c
emu/OpenBSD/ipif.c
emu/Unixware/ipif.c

description:
the interface used by devip.c (ip.h & ipaux.c) is updated to always
pass around ipv6 addresses (so with ipv4 addresses mapped in them).
existing ipif*.c's are updated to this interface.  new ipv6-enabled
implementations ipif6*.c of course use this interface too.

- left SO_REUSEADDR in so_bind() disabled because it was disabled
  on Nt/ipif.c
- perhaps emu/Linux/emu-wrt should have ipv6 too.
- so_setsockopt and so_mustbind are not used, and so are not tested.
- Unixware, Irix, Hp & OpenBSD use port/ipif-posix.c, their own
  copies are removed.
- Linux, FreeBSD, MacOSX and NetBSD have their ipif.c copy removed too.
  they now use port/ipif6-posix.c.  MacOSX should probably use this
  too.
- Nt gets its own ipif6.c, it's a cross between its (updated) ipif.c
  and ipif6-posix.c.  i tested on windows 7, it should work on
  windows >= vista.  it does not work on windows xp (that's why
  ipif.c is updated).  i updated the mkfile to link against the new
  windows socket library.  windows xp can link against this too,
  the ipv6 socket creation will fail at runtime though.  i update
  Nt's emu config file, but this means builds won't work on windows
  xp.  one solution would be to split Nt into two versions for
  windows (at least both can be build on a single new windows system,
  i think).
- all ipif*.c files have been modified so that diffs between them are small (eg 
Nt &
port's ipif for v4, Nt & port's ipif for v6, and between the v4 & v6 versions).
- i haven't put thought into behaviour of multicast yet.  i have no idea on how 
that
works.  it seems to be just part of the address space.
- the various stacks have slightly different behaviour for binding to 
addresses:  ::
(the v6 any address) listens on v4 too of course, but on eg freebsd :: 
explicitly
binds ipv4 0.0.0.0 too, and that cannot be overridden by a later bind.  i think 
that
is possible on linux & windows.  all systems do seem to allow binds to explicit
addresses, taking them away from the any address listening socket.  i don't 
think
this difference in implementation is very relevant for us.

the following has been tested:
- linux,freebsd,netbsd with port/ipif6-posix.c & port/ipif-posix.c
- windows 7 with Nt/ipif.c & Nt/ipif6.c
- windows xp with sp3 with Nt/ipif.c
- openbsd with port/ipif-posix.c

i have probably updated the code for tiny bits while forgetting to run the tests
again... still, a lot has been tested.

the biggest thing to solve is the windows xp vs vista problem.  needing two
executables isn't too nice.  otherwise perhaps ipv4-only is the reasonable 
default
for now...

Original comment by mechiel@ueber.net on 22 Jul 2009 at 12:33

Attachments:

GoogleCodeExporter commented 9 years ago 
although emu seems to work just fine on windows 7, there seems to be a problem 
when
you specify bad command-line options (i ran emu -c^U.  emu -ca or similarly 
invalid
causes it too):

Usage: emu [options...] [file.dis [args...]]
        -gXxY
        -c[0-9]
        -d file.dis
        -s
        -v
        -p<poolname>=maxsize
        -f<fontpath>
        -r<rootpath>
        -7
        -B
        -C<channel string>
        -S
alloc:D2B: 1451d18 not in pools
panic: alloc:D2B 1451d18 (from 435fcf/527a74)
alloc:D2B: 14507c8 not in pools
panic: alloc:D2B 14507c8 (from 435fcf/5207c1)

i thought an atexit handler might be causing the problem, but replacing
exits("usage") in port/main.c with _exit(1) does not make a difference.  i 
don't know
how to turn the pc's into file+lines on windows...

windows xp does not seem to have this problem.  windows 7 with Nt/ipif6.c 
prints two
panic's, windows 7 with Nt/ipif.c prints one panic.

it seems windows is somehow (mistakenly?) calling alloc at exit.  perhaps we're
overriding a windows symbol?  with Nt/ipif.c

Original comment by mechiel@ueber.net on 22 Jul 2009 at 11:39

GoogleCodeExporter commented 9 years ago 
apparently i broke the port/ipif-posix.c so_connect(), for ipv4.  not sure why i
didn't catch this... the following patch (attached as ipv6-f-fixv4connect.diff)
corrects it.  if i find more regressions, i'll make a new version of the patch.

diff -r 638cc0f2b1f0 emu/Nt/ipif.c
--- a/emu/Nt/ipif.c     Wed Jul 22 01:45:38 2009 +0200
+++ b/emu/Nt/ipif.c     Mon Jul 27 16:08:05 2009 +0200
@@ -196,7 +196,7 @@
        sin = (struct sockaddr_in*)&sa;
        sin->sin_family = AF_INET;
        hnputs(&sin->sin_port, rport);
-       ipw6(raddr, sin->sin_addr.s_addr);
+       memmove(&sin->sin_addr.s_addr, raddr+IPv4off, IPv4addrlen);

        osenter();
        r = connect(fd, &sa, sizeof(sa));
diff -r 638cc0f2b1f0 emu/port/ipif-posix.c
--- a/emu/port/ipif-posix.c     Wed Jul 22 01:45:38 2009 +0200
+++ b/emu/port/ipif-posix.c     Mon Jul 27 16:08:05 2009 +0200
@@ -172,7 +172,7 @@
        sin = (struct sockaddr_in*)&sa;
        sin->sin_family = AF_INET;
        hnputs(&sin->sin_port, rport);
-       ipw6(raddr, sin->sin_addr.s_addr);
+       memmove(&sin->sin_addr.s_addr, raddr+IPv4off, IPv4addrlen);

        osenter();
        r = connect(fd, &sa, sizeof(sa));

Original comment by mechiel@ueber.net on 27 Jul 2009 at 2:45

GoogleCodeExporter commented 9 years ago 
forgot to attach...

Original comment by mechiel@ueber.net on 27 Jul 2009 at 2:46

Attachments:

GoogleCodeExporter commented 9 years ago 
Merging into current source

Original comment by Charles....@gmail.com on 27 Nov 2010 at 3:38

GoogleCodeExporter commented 9 years ago 
20101127-1632

committed changeset 467:085fb7fa2b4c
pushing to https://Charles.Forsyth:***@inferno-os.googlecode.com/hg
searching for changes
1 changesets found

Original comment by Charles....@gmail.com on 27 Nov 2010 at 4:33