diald slow to be useful...

diald slow to be useful...

[Matt Garman]

I'm running Debian "potato" as my firewall/lan gateway/diald server.
The box is running diald 0.99.1-1.

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 timeout
and retry before it does anything useful.

Here's a concrete example: diald runs on septictank, my workstation is
sewage.  On sewage, I try to do a google search.  Immediately the
modem dials, and after a few seconds, the PPP connection is up and
running---I can use any Internet protocol except http.  I have to wait
for the browser to timeout trying to reach google, then retry the
search.  But during that waiting period, I could do a fetchmail.

The diald FAQ addresses this and says to try the option
"buffer-packets on".  I've tried with this option both on and off, and
the problem persists both ways.  Another suggestion I found on the
'net was to set /proc/sys/net/ipv4/ip_dynaddr to 1.  I did this on
septictank, and it also had no effect.

Does anyone have a fix for this or any suggestions?

Thanks for your help!
Matt

-- 
Matt Garman, garman@raw-sewage.net
``I ain't never seen no whiskey, the blues made my sloppy drunk!''
        -- Sleepy John Estes, ``Leaving Trunk''

Re: diald slow to be useful...

[Mike Jagdis]

Matt Garman wrote:
> I'm running Debian "potato" as my firewall/lan gateway/diald server.
> The box is running diald 0.99.1-1.
> [...]
> Does anyone have a fix for this or any suggestions?

Abandon Debian Potato. 0.99.1 is *ancient*. It goes back
to something like June 1999. Try something newer?

				Mike

Re: diald slow to be useful...

[Matt Garman]

On Fri, May 10, 2002 at 05:53:03PM +0100, Mike Jagdis wrote:
> Matt Garman wrote:
> > I'm running Debian "potato" as my firewall/lan gateway/diald server.
> > The box is running diald 0.99.1-1.
> > [...]
> > Does anyone have a fix for this or any suggestions?
> 
> Abandon Debian Potato. 0.99.1 is *ancient*. It goes back
> to something like June 1999. Try something newer?

Well, I removed the old 0.99.1 Debian package, and installed
diald-1.0-1.i386.rpm (downloaded from the Diald sourceforge site).  (I
used "alien", a rpm-to-deb package converter for the install).

Anyway, the problem persists.

Any ideas?

Thanks again,
Matt

-- 
Matt Garman, garman@raw-sewage.net
``I ain't never seen no whiskey, the blues made my sloppy drunk!''
        -- Sleepy John Estes, ``Leaving Trunk''

Re: diald slow to be useful...

[Mike Jagdis]

Matt Garman wrote:

> Well, I removed the old 0.99.1 Debian package, and installed
> diald-1.0-1.i386.rpm (downloaded from the Diald sourceforge site).  (I
> used "alien", a rpm-to-deb package converter for the install).


What was the problem again?

				Mike

Re: diald slow to be useful...

[Matt Garman]

On Wed, May 29, 2002 at 10:09:13AM +0100, Mike Jagdis wrote:
> Matt Garman wrote:
> 
> > Well, I removed the old 0.99.1 Debian package, and installed
> > diald-1.0-1.i386.rpm (downloaded from the Diald sourceforge site).  (I
> > used "alien", a rpm-to-deb package converter for the install).
> 
> What was the problem again?

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 timeout
and retry before it does anything useful.

Here's a concrete example: diald runs on septictank, my workstation is
sewage.  On sewage, I try to do a google search.  Immediately the
modem dials, and after a few seconds, the PPP connection is up and
running---I can use any Internet protocol except http.  I have to wait
for the browser to timeout trying to reach google, then retry the
search.  But during that waiting period, I could do a fetchmail.

The diald FAQ addresses this and says to try the option
"buffer-packets on".  I've tried with this option both on and off, and
the problem persists both ways.  Another suggestion I found on the
'net was to set /proc/sys/net/ipv4/ip_dynaddr to 1.  I did this on
septictank, and it also had no effect.

Any thoughts?

Thanks for your help!
Matt

-- 
Matt Garman, garman@raw-sewage.net
``I ain't never seen no whiskey, the blues made my sloppy drunk!''
        -- Sleepy John Estes, ``Leaving Trunk''

Re: diald slow to be useful...

[Mike Jagdis]

Matt Garman wrote:

> 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 timeout
> and retry before it does anything useful.
> 
> Here's a concrete example: diald runs on septictank, my workstation is
> sewage.  On sewage, I try to do a google search.  Immediately the
> modem dials, and after a few seconds, the PPP connection is up and
> running---I can use any Internet protocol except http.  I have to wait
> for the browser to timeout trying to reach google, then retry the
> search.  But during that waiting period, I could do a fetchmail.
> 
> The diald FAQ addresses this and says to try the option
> "buffer-packets on".  I've tried with this option both on and off, and
> the problem persists both ways.  Another suggestion I found on the
> 'net was to set /proc/sys/net/ipv4/ip_dynaddr to 1.  I did this on
> septictank, and it also had no effect.
> 
> Any thoughts?


I _think_ I know what's going on. Your Internet connection is PPP with
dynamic addressing, your proxy address is just a random local address,
you surf from a browser on a workstation, and your Linux gateway uses
masquerading to give you access to the Internet.

What happens is that when the browser starts a connection it sends a
SYN packet to the remote server. This goes to your Linux gateway,
*gets masqueraded*, and is routed to diald's proxy interface. Diald
brings the link up and forwards the buffered packet but because it
has already been masqueraded with the wrong address you're stuffed.
Worse, there is now an entry for this connection in the masquerade
table *with the wrong address*, so it will never work and you have
to abort it.

(ip_dynaddr works for connections originated on the gateway *only*.
These connections don't get masqueraded and setting ip_dynaddr tells
the kernel network code to reselect the source address for the
connection each time the initial SYN has to be resent)

Ok, that's not good. But if that *is* what's happening there are
three solutions. In order of ease:

1. Do you normally get allocated the same IP address? Some ISPs do
it by account, some by modem port. If you generally get the same
IP address change "dynamic" to "sticky" in your diald config. This
causes diald to use the IP address last used on the link for the
proxy. So once it has seen a connection the proxy address will be
the same as the (expected) link address and the masquerade address
will be right. If you set the proxy address to your expected address
in diald's config this will only fail for the first connection
after your address changes.

2. Run a proxy such as squid or junkbuster on the gateway and
either configure your browser to talk to it or configure the
gateway to do transparent redirection to it. Now your browser
talks to the proxy and the proxy talks to the remote server.
Since the proxy's connection is originated on the gateway the
ip_dynaddr thing works. This only works for protocols which
have available proxies - if you need the link to come up for
telnet, ssh, ftp, pop3, imap etc. squid and junkbuster won't
help - but an offsite home page might be sufficient?

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[*].

				Mike

[*] If anyone does this *please* let us know what you needed
to change!

Re: diald slow to be useful...

[Jonathan Goldblatt]

Mike Jagdis <jaggy@purplet.demon.co.uk> writes:

> 
> 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[*].
> 
> 				Mike

> [*] If anyone does this *please* let us know what you needed
> to change!

In the script where I turned on IP masquerading with:

# Do masquerading
echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/ipchains -A forward  -j MASQ

I changed it to:

# Do masquerading
echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/ipchains -A forward -i ! sl+ -j MASQ
/sbin/ipchains -P forward ACCEPT

The last line was because I set all the policies to DENY when I
started the script for safety.  Took the time to make sure that the
problem was duplicated on my setup.  Your suggestion works like a
charm.

Hope this is helpful.  Wondering whether 2.0 is a redesign or
somesuch, what the TODOs might be, what goes into making a release, etc.  

Re: diald slow to be useful...

[Bjorn Hammarberg]

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 correctly
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Шrn


Mike Jagdis wrote:
> 
> Matt Garman wrote:
> 
> > 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 
> > 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[*].
> 
>                                 Mike
> 
> [*] 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  еееееее|+|o|ееееееееее    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: Bjorn.Hammarberg@gsm.uu.se (max 160 chars)
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: diald slow to be useful...

[Robert Jenkins]

Hi,

I'm using diald 0.99.4 on a Redhat 7.2 system.

It works perfectly without any patches or messing about, all I've done
is tweak some rules to control how it connects.
It's set to work 'on demand' most of the time, plus a couple of sessions
locked on each day.

If I bring the connection up by starting Internet Explorer on a windows
machine, it's online and working in a few seconds. 

I'm using iptables for both NAT & firewall on the machine with diald,
and I've got both ip_dynaddr and routingf enabled.


I seem to remember some time ago (Redhat 5.x ???) that the browser
needed restarting after allowing time for the link to come up, but that
is not
needed with the current setup. I believe that problem was down to how
the kernel routing works & is not due to diald - the only way round it
is a newer kernel.


If you want better control of the connection, try dialmon - I've also
got this on the Windows box & it shows the state of the Diald
connection, amount of traffic, and allows the connection to be forced up
or down if required.


Regards,

Robert Jenkins.

Re: diald slow to be useful...

[Mike Jagdis]

Robert Jenkins wrote:

> I'm using iptables for both NAT & firewall on the machine with diald,
> and I've got both ip_dynaddr and routingf enabled.


I believe the current iptables recommendation is to use
a "-o $PUB_IF" on the masquerade rule to only masquerade
packets going out on the Internet facing interface. Do you
know if that's true? Is it true for PPP interfaces too?

				Mike

RE: diald slow to be useful...

[Robert Jenkins]

Hi Mike,

This is basically what I'm using for the firewall (I've changed my Ip
addresses & trimmed out some port forwards & other junk).
It's based on a template I found on the internet, but I can't remember
where...

Using iptables makes it a fraction of the size of my old ipchains
firewall!

Regards,
Robert Jenkins.
mailto:raj@jrw.co.uk


#!/bin/bash
#

#Point this to your copy of ip_tables
IPT="/sbin/iptables"

#Load the modules. (Moved to rc.local)
#modprobe ip_tables
#echo 1 > /proc/sys/net/ipv4/ip_forward


#Flush old rules, delete the firewall chain if it exists
$IPT -F
$IPT -F -t nat
$IPT -X firewall

#Setup Masquerading. Change the IP to your internal network and
uncomment
#this in order to enable it.
$IPT -A POSTROUTING -t nat -s 192.168.0.0/24 -j MASQUERADE
$IPT -P FORWARD ACCEPT

#Set up the firewall chain
$IPT -N firewall
$IPT -A firewall -j LOG --log-level info --log-prefix "Firewall:"
$IPT -A firewall -j DROP


#Accept ourselves
$IPT -A INPUT -s 127.0.0.1/32 -d 127.0.0.1/32 -j ACCEPT
#If you're using IP Masquerading, change this IP to whatever your
internl
#IP addres is and uncomment it
$IPT -A INPUT -s 192.168.0.0/24 -d 0/0 -j ACCEPT

#Accept DNS
$IPT -A INPUT -p udp --source-port 53 -j ACCEPT
#And NTP
$IPT -A INPUT -p udp --source-port 123 --destination-port 123 -j ACCEPT
$IPT -A INPUT -p tcp --source-port 123 --destination-port 123 -j ACCEPT

#Allow ftp to send data back and forth.
$IPT -A INPUT -p tcp ! --syn --source-port 20 --destination-port
1024:65535 -j ACCEPT

#Accept SSH.
#$IPT -A INPUT -p tcp --destination-port 22  -j ACCEPT

#Send everything else to the firewall.
$IPT -A INPUT -p icmp -j firewall
$IPT -A INPUT -p tcp --syn -j firewall
$IPT -A INPUT -p udp -j firewall

#
# End.
#