Re: diald slow to be useful...

I solved Matt's problem according to Mike's description (alt. 3) and by
fixing the buffering in diald (I use diald 0.94 if I recall it
correctly).

This hack buffers all (unmasqueraded) packets in diald, waits for the
link to come up, resends the packets that then get masqueraded correctl=
y
and enters the internet. It works like a charm most of the time and
there is no need for a TCP/IP retransmission.

The uptime of the server (and diald) is 440 days or so and I have had
very few problems with this setup.

I haven't posted this anywhere because:
- It only works from the workstations, not from the server itself
- Sometimes the kernel warns for martians etc
- The hack is for an outdated diald
- I started to write a buffering device driver instead
- My time budget hit the ground
- (Fill in any bad excuses you can come up with here and below)
-    :
-    :
-    :

I am quite busy at the moment, but if anyone is *SERIOUSLY* interested
in more details, i.e. intends to solve this once and for all, I will
gladly do what I can to help. My intention is to fix this properly when
I have the time some day but if someone wants to give it a shot before
that I wouldn't complain so much ;-)

If you're just curious, or wants the same suboptimal although working
setup as I have, I can always send you a tar ball of my setup and my
hacked diald. There is no magic, just some tweaking and utilization of
diald, ipchains, masquerading, routing etc. With some knowledge about
networking, diald, and the kernel you'd probably come up with a better
solution yourself.

Cheers,

Bj=F6rn


Mike Jagdis wrote:
>=20
> Matt Garman wrote:
>=20
> > Diald works almost as expected (connects to the Internet, hangs up
> > after timeout).  Diald dials and gets PPP up and running rather
> > quickly.  However, the connection that triggered diald has to=20
> > timeout and retry before it does anything useful.
>
> 3. Hacker voodoo :-). If you know what you are doing you can
> change your firewall set up so that it *doesn't* masquerade
> traffic sent to diald's proxy interface. How you do that depends
> on whether your use ipchains (-i ! sl+) or iptables (-o ! sl+),
> and how your distribution does firewall config. In dynamic
> (or sticky) mode diald forwards buffered packets back in to
> the kernel via the proxy rather than straight out on the
> real link. So the kernel first routes the packet to diald
> *without* masquerading it, diald brings the link up and
> sends the packet back to the kernel, which then routes
> it to the link and *does* masquerade it - with the correct
> address! This should work for all connections even if you
> get a different address every time. But you're probably
> going to have to understand firewalling, read man pages,
> and edit shell scripts to do it[*].
>=20
>                                 Mike
>=20
> [*] If anyone does this *please* let us know what you needed
> to change!

----------------------------------------------------------------------
Bjorn Hammarberg, PhD student in Neurophysiological Signal Processing

Dep. of Neuroscience     <MEDICINE   ENGINEERING>  Signals and Systems
Clinical Neurophysiology  =A8=A8=A8=A8=A8=A8=A8|+|o|=A8=A8=A8=A8=A8=A8=A8=
=A8=A8=A8    Uppsala University
University Hospital Uppsala      |-+-|                      PO Box 528
SE-751 85 Uppsala, SWEDEN        |o|+|       SE-751 20 Uppsala, SWEDEN
http://www.neurofys.uu.se        `---'         http://www.signal.uu.se

Mobile E-mail: [email protected] (max 160 chars)
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" =
in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html