Hi Jeelani;
You're right, it definitely sounds like my diald script is screwed, so
without further ado, here it/they are:
/etc/diald/diald.options
mode ppp
connect /etc/diald/connect
device /dev/ttyS1
speed 38400
modem
lock
crtscts
local 203.96.155.2
remote 203.96.152.50
defaultroute
include /etc/diald/standard.filter
/etc/diald/connect
#!/bin/sh
/usr/sbin/chat -v \
TIMEOUT 3 \
ABORT '\nBUSY\r' \
ABORT '\nNO ANSWER\r' \
ABORT '\nRINGING\r\n\r\nRINGING\r' \
'' \rATZ \
TIMEOUT 40 \
OK ATDT4778181 \
CONNECT ''
/etc/diald/standard.filter
accept tcp 30 tcp.syn
ignore tcp tcp.dest=tcp.domain
ignore tcp tcp.source=tcp.domain
ignore tcp tcp.source=tcp.netbios-ns,tcp.dest=tcp.netbios-ns
accept tcp 5 ip.tot_len=40,tcp.syn
ignore tcp ip.tot_len=40,tcp.live
ignore tcp !tcp.live,tcp.dest=tcp.www
ignore tcp !tcp.live,tcp.source=tcp.www
accept tcp 180 tcp.dest=tcp.www
accept tcp 180 tcp.source=tcp.www
keepup tcp 5 !tcp.live
ignore tcp !tcp.live
accept tcp 120 tcp.dest=tcp.ftp
accept tcp 120 tcp.source=tcp.ftp
accept tcp 300 any
ignore udp udp.dest=udp.who
ignore udp udp.source=udp.who
ignore udp udp.dest=udp.route
ignore udp udp.source=udp.route
ignore udp udp.dest=udp.ntp
ignore udp udp.source=udp.ntp
ignore udp udp.dest=udp.timed
ignore udp udp.source=udp.timed
#ignore udp udp.dest=udp.domain,udp.source=udp.domain
accept udp 30 udp.dest=udp.domain
accept udp 30 udp.source=udp.domain
ignore udp udp.source=udp.netbios-ns,udp.dest=udp.netbios-ns
accept udp 30 udp.dest=udp.netbios-ns
accept udp 30 udp.source=udp.netbios-ns
ignore udp tcp.dest=udp.route
ignore udp tcp.source=udp.route
accept udp 120 any
accept icmp 30 any
....my subnetwork is haning on a 10Mb LAN, connected to the router, with
the following firewalling rules brought up in /ettc/init.d/network:
## IP Forwarding Setup - first deny all, then add a route for
203.96.152.16/29
# Deny All
ipfwadm -F -p deny
# Flush all commands
ipfwadm -F -f
ipfwadm -I -f
ipfwadm -O -f
# Forward the traffic for the subnet 203.96.155.232/29 - 6 hosts
ipfwadm -F -a accept -S 0.0.0.0/0 -D 203.96.155.232/29
ipfwadm -F -a accept -S 203.96.155.232/29 -D 0.0.0.0/0
# Whoops, almost forgot to forward the router traffic!
ipfwadm -F -a accept -S 203.96.155.2/32 -D 0.0.0.0/0
ipfwadm -F -a accept -S 0.0.0.0/0 -D 203.96.155.2/32
....anyway, if you think I'm doing something badly wrong, please let me
know! I'm sure it's something small and simple that I've overlooked, but
it doesn't seem to make a difference if I'm firewalling or not (if I
rebuild the kernel) - masquerading works 100%, and nothing else does, iot
just drops the idle link.
Many thanks
Richard
On Thu, 30 Apr 1998, Jeelani Gulam wrote:
> Seems like your time outs are going wrong...
>
> Please include ur diald script .....
>
> I have had lot of success with it
>
> Cheers
> Jeelani
>
> -----Original Message-----
> From: Richard Parry [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, April 30, 1998 12:14 PM
> To: [EMAIL PROTECTED]
> Subject: DialD Closing Idle Link?
>
> Hi All;
>
> I'm having a bit of a problem with DialD closing down an idle link that is
> not idle :)
>
> Well, that's incorrect, but only partially. Let me explain.
>
> I used to use DialD with a masquerading setup, and it worked 100%, and
> beautifully. I've recently conned my ISP out of a /29, so I didn't need
> masquerading. My LAN is a couple of machines, the diald machine is only
> doing that - it's a router, nothing else.
>
> Recompiled the kernel (Debian linux running 2.0.33, standard diald and ppp
> packages) for IP Forwarding, Firewalling, etc, set up some ipfwadm
> forwarding rules, and Bob's your uncle, it happily brings the link up and
> forwards traffic.
>
> Had a small hiccup when I forgot that named -> named transfers were
> blocked, but now I allow that - my diald/router machine is just a caching
> DNS server, so no problems there.
>
> Now, when the link is up, it leaves it up for a staggering 30 seconds or
> so, and then reports that it dropped the idle link.
>
> It doesn't matter if the traffic was web, ftp, ping, whatever, that
> initiated the link, it doesn't seem to respect the rules in
> standard.filter (the one shipped with the product incidentally, suits me
> fine). Now, it _used_ to work with masquerading - but not with a "real"
> subnet.
>
> If you keep some constant traffic generating task like ping going, it'll
> leave the link up - but about five seconds after the ping has stopped, it
> drops the link. So, it'll never drop the link on data in progress, or as
> long as there's steady constant traffic, but doesn't seem to follow the
> time rules in the filter.
>
> I'm figuring that I've forgotten something small and stupid, but I can't
> for the life of me figure out what it is. I've raked the examples and
> FAQ, but can't seem to locate help there. Probably a mere configuration
> issue, but I'm blowed if I know what's going on. I'm not a diald master
> :)
>
> Does anyone know what this could be, or how I could solve it? I'm
> currently reading through the mailing list archives, which is slow with
> over 2000 messages there, but I'll persevere :) Any help would be
> appreciated.
>
> Many thanks
>
> Richard
>
> --
> Richard Parry Network Controller/Analyst
> National Library of New Zealand [EMAIL PROTECTED]
> Phone 64 4 474 3010 Mobile 021 664 655 Fax 64 4 474 3140
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-diald" in
> the body of a message to [EMAIL PROTECTED]
>
--
Richard Parry Network Controller/Analyst
National Library of New Zealand [EMAIL PROTECTED]
Phone 64 4 474 3010 Mobile 021 664 655 Fax 64 4 474 3140
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
