Re: No postings

Mike Jagdis <[email protected]> Wed, 29 May 2002 10:08:02 +0100
Newsgroups org.kernel.vger.linux-diald
Message-ID <[email protected]>
Michail Bachmann wrote:

> On Tue, 28 Mai 2002, Steve Martin wrote:
> 
> 
>>It may 'just work' but there are outstanding bugs on the home page, one > of which I had to fix tomake it 'just work'. 
>>
> The "CLK_TCK" bug? I posted a patch on this list and submitted it to sf long ago,
> don't know why Mike still did not include it... :-/


It's in CVS. One day I may even get round to making a new release...

>>                                                         Does it currently use the 
>>netfilter stuff as netlink is deprecated?
>>
> Diald 1.0 still uses netlink, I did not check the cvs version on sourceforge though.


The CVS version of diald can use tun, tap or slip. If the tun code was
in 1.0 it was probably broken :-).

>>I noticed that the version shipped with Mandrake 8.2 uses tap0 as the 
>>device, my compiled version uses sl0 (slip) which make sense.  Anyone know 
>>why?
>>
> Diald automagically chooses which interface to use, it first tries tap and then slip.
> If you dont have the ethertap module loaded, diald will use slip.


Using slip is a _last_ resort. Slip only does IPv4. Just about any
other network interface can do many protocols simultaneously. Yes,
even PPP! Using tun or tap as the proxy means diald can handle
IPv4, IPv6, IPX etc. The diald 2.0 code in CVS even extends the
diald.defs syntax so you can have non-IPv4 rules and see all protocols
in the monitor output.

Avoid slip. Tap is currently in more kernels than tun (although probably
very few people are using those kernels now) and is fine for our
purposes. Tun is newer and "the way to go" - so we went there. It makes
little difference unless you need lots of diald managed links - I think
tap was limited to 16 at once :-).

>>It's also a little slow on starting the proxy stuff, again anyone know 
>>why? No its not a slow machine - 1.3Ghz Athlon.
>>
> Can't help here, on my P120 it seems pretty fast... :-)


Most unexpected delays point to misconfigured systems and DNS
time outs. But they could be lack of memory, excessive swapping,
pr0n mpegs running in the background... :-)

				Mike