>> >> >Hmmm.... I just tried it, and now it works! I thought it didn't used to.
>> >> >Either I misremembered, or it's been fixed.
>> >> 
>> >> um...what works?  a more current nat can mux pings?
>> >
>> >Yes. My 1.5 NAT box seems to be multiplexing pings. I had one box ping
>> >ftp.netbsd.org, and another ping cvs.netbsd.org, and they both worked. My
>> >nat config looks like yours, except that I have my hard IP in there
>> >instead of 0.0.0.0, and I am using the outgoing ethernet card. :-)
>> 
>> make it more interesting, just to amuse me?  ping the same outside
>> address ( i usually use 137.39.1.3) from two machines inside the nat
>> and lemme know if it works.
>
>Yes, it works.  libalias (used by user-ppp) recognises icmp traffic, 
>and nat's the sequence number and IP.

no...what i meant was (a) using the nat built into netbsd-current, (b)
ping one destination from (c) more than one machine behind the nat.

that, i believe, is what doesn't work (at least, not for me).  that is
what works using the userspace ppp implementation.

>> >> >All my machines are running 1.5.
>> >> 
>> >> all my machines are running current with less than a two month lag
>> >> behind today.
>> >
>> >I hope it didn't get fixed then broken.
>> 
>> me too.
>
>It still works (and will continue to).

using the in-kernel nat, or the userspace one?  i know the userspace
one works.

>> >> >If it really works with userland ppp (which I thought was a downgrade from
>> >> >1.5's ppp) but not kernel ppp, then there's a ppp bug.
>> >> 
>> >> the userspace ppp is, afaik, a *completely* separate and distinct
>> >> implementation of ppp.  all it requires of the kernel is a serial
>> >> interface (with a modem) and a tunnel interface (for packets to go
>> >> through).  it's not a downgrade...perhaps a "sidegrade".
>> >
>> >I thought they were based on the same ppp project. The reason for the ppp
>> >package was that it's set to version 2.3.11, which is newer than the ppp
>> >in 1.4. But 1.5 and current are using ppp 2.4, which is newer, thus an
>> >overall downgrade.
>> 
>> they might have some common roots, if you dig far enough back (like
>> netbsd and freebsd), but the userspace one and the kernel space one
>> are very different.
>
>user-ppp was originally written by IIJ and was picked up by me and 
>almost entirely re-written (multi-link support made this necessary) 
>since then.

are there any common roots with the kernel one, or is it a completely
clean-room re-implementation?  i expect that it's completely
independent.

>>                      some examples: the userspace one doesn't use
>> chat...it does it all itself;
>
>Although it can use an external chat program too (see the man page).

can...can't.  doesn't have to.

>>                               the userspace one does nat all by
>> itself, it doesn't rely on the kernel;
>
>Using libalias.  libalias does a whole bunch of things, including 
>non-passive ftp, irc, cuseeme, transparent proxying, pptp, NetBIOS 
>and realaudio (smedia).

it's a separate implementation.

>>                                        the userspace one also claims
>> to support mppp, which i've not tried,
>
>Yep, works nicely with i4b :-)

good to know.  :)

>>                                        whereas pppd says that only
>> works under linux.  that might sounds a bit slanted, but those were
>> the first things i thought of.
>
>The only downside with user-ppp is the overhead of passing everything 
>out then back into the kernel.  This is being addressed (albeit 
>slowly) by making user-ppp use netgraph(4) if it's available.

...which, on a fast enough machine, with not too much traffic, ought
not to matter that much.  but still...

>> >> the nat (called aliasing) in the userspace ppp is what actually
>> >> handles the multiple outbound pings.  i imagine it's fiddling with the
>> >> icmp echo request identifier and using it as it uses the local port
>> >> number rewriting for udp and tcp.
>> >
>> >Does it work with that aliasing off?
>> 
>> not for me, no, since none of my inside machines addresses are routed
>> back to me properly.  that's something i've been meaning to deal with,
>> but haven't yet.
>
>It'll work with ipnat turned off, but not with user-ppp's -nat (or 
>``nat enable yes'') disabled.

of course.  i'm beginning to suspect that some people are confusing
what i'm saying.

>> on a side note, i just thougfht about it a tiny bit more and
>> remembered that my nat rules rewrite traffic over ppp0, not tun0,
>> which is what the userspace ppp uses.  so, no conflict.
>
>They shouldn't get in eachother's way.

nope.  not at all, unless programmed to.  i *could* have the kernel
nat things that go in and out of the tunnel device *before* the
userspace ppp gets it, but that would be wasteful.  the userspace
ppp's nat (aka aliasing) is better than ipnat in the kernel.

>I've been intending to make a ppp package for NetBSD, and now see 
>that there already is one :-)  Now that sup.NetBSD.org exports 
>pkgsrc, I'll look into keeping things more ``available'' :-)

yeah...those package guys are really good.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."