🚀 go-pugleaf

In article <39991BA4.6CB0C24A@usa.net>,
	Ben Hardill <b.hardill@usa.net> writes:

> I run a small network of win95 boxs at work with a redhat 6.2 box as a
> Oracle 8i server. The Redhat box also runs diald and is setup to
> masquarad for the network. This all works fine execept that diald keeps
> bringing the line up every 10 mins for the minium time then drops it
> again.

I had exactly this problem when I ran Diald and Oracle on the same box. I
don't recall the exact details but I think the problem was that Oracle was
doing a DNS lookup of the hostname.

A caching nameserver made the problem more tolerable and the dodgy
solution of changing the hostname of the server to the 'internal' hostname
fixed it completely.

The problem went away for me because I moved Oracle onto a different box
for performance reasons (my 486 was groaning already and I wanted to
install the Apps Server and WebDB). However, if you can identify the
packets that are triggering the link you should be able to ignore them in
the Diald config files. Figuring out what was triggering Diald was always
a problem - the logging functionality of IP Chains in the newer kernels is
probably the best way these days.

Sorry I can't be more specific but hopefully this sets you along the right
lines.

-- 
Regards,

Richard

Richard Senior wrote:
> 
> In article <39991BA4.6CB0C24A@usa.net>,
>         Ben Hardill <b.hardill@usa.net> writes:
> 
> > I run a small network of win95 boxs at work with a redhat 6.2 box as a
> > Oracle 8i server. The Redhat box also runs diald and is setup to
> > masquarad for the network. This all works fine execept that diald keeps
> > bringing the line up every 10 mins for the minium time then drops it
> > again.
> 
> I had exactly this problem when I ran Diald and Oracle on the same box. I
> don't recall the exact details but I think the problem was that Oracle was
> doing a DNS lookup of the hostname.
> 
> A caching nameserver made the problem more tolerable and the dodgy
> solution of changing the hostname of the server to the 'internal' hostname
> fixed it completely.
> 
> The problem went away for me because I moved Oracle onto a different box
> for performance reasons (my 486 was groaning already and I wanted to
> install the Apps Server and WebDB). However, if you can identify the
> packets that are triggering the link you should be able to ignore them in
> the Diald config files. Figuring out what was triggering Diald was always
> a problem - the logging functionality of IP Chains in the newer kernels is
> probably the best way these days.
> 
> Sorry I can't be more specific but hopefully this sets you along the right
> lines.

DNS is probably the commonest cause of unwanted dialups. Windows boxes
have a nasty tendency in my experience to look up DNS names for no
apparant reason. I dialed into my home NT RAS server[1] from work today
and it promptly looked up "www.uk.ibm.com". No, I do not work for IBM.

To trap this run a caching nameserver with query logging turned on. Then
you can look in the system log to see what looked up what just before
the dialup. This is how I tamed my dial-on-demand ISDN before it broke
the bank.

Ian

[1] RAS is IMO the best thing about NT. Probably the only good thing.
It's one of the very few things I still use it for.

In article <3999A50C.69DBDBD8@house-from-hell.demon.co.uk>,
	Ian Northeast <ian@house-from-hell.demon.co.uk> writes:

> DNS is probably the commonest cause of unwanted dialups. Windows boxes
> have a nasty tendency in my experience to look up DNS names for no
> apparant reason. I dialed into my home NT RAS server[1] from work today
> and it promptly looked up "www.uk.ibm.com". No, I do not work for IBM.

Indeed; the first part of any conversation with a remote network resource
name will be to work out what address the name corresponds to, so it's not
unexpected to see DNS lookups going out first ...

I had many problems with Windows 95 and dial-on-demand. These were mainly
due to the MS Networking netbios name service browsing around for other
Windows resources. These can be fixed by setting up the Samba server
carefully, if you use one, and ensuring that the Windows clients don't try
to be Browse Masters. IP Chains can put a stop on any leaks; just block
out the netbios service across your dialup or virtual link. I'm a fan of
IP Chains, as you may have guessed!

I recall that Microsoft Outlook Express also seemed to make the unpleasant
assumption that, if you are 'online', e.g. to read pages from a local web
server, you don't mind it making connections to web sites without you
asking - obviously this brings up the link!

> To trap this run a caching nameserver with query logging turned on. Then
> you can look in the system log to see what looked up what just before
> the dialup. This is how I tamed my dial-on-demand ISDN before it broke
> the bank.

You are quite right of course; IP chains running into a syslog followed
with tail -f can tell you a lot about what comes after the DNS requests,
but it's the nameserver logging that tells you what is being looked up in
the first place.

-- 
Regards,

Richard

Hi thanks for the help.

So far i've tracked down the fact that its a udp packet thats bringing
the link up.

The best effort i've found so far is to make the filter not bring the
link up for udp packets but only keep it up, but i don't think this will
be too good as DNS requests won't bring it up.

Thanxs again i'll go didging with the ipchains stuff and look at moving
the diald off the oracle box.

Ben

Just a qyick note to the groupe

I seam to have solved this problem by filtering out all netbios
protocols and filtering out all the DHCP requests. I hope this helps
anybody else in a similar situation.

Ben

Ben Hardill wrote:
> 
> Hi thanks for the help.
> 
> So far i've tracked down the fact that its a udp packet thats bringing
> the link up.
> 
> The best effort i've found so far is to make the filter not bring the
> link up for udp packets but only keep it up, but i don't think this will
> be too good as DNS requests won't bring it up.
> 
> Thanxs again i'll go didging with the ipchains stuff and look at moving
> the diald off the oracle box.
> 
> Ben

Do you have the X-app dctrl installed ? You'll have to be root to run it.
That tells you, runtime, which packets are in the 'Alarm queue'. This starts
at what ever you set your line-drop timeout to be (Mines 200 seconds for
some daft reason), and counts down. No outstanding alarms - the clock goes
to zero and drops the line.

It is possible that your email client is checking the server every 10
minutes ? Because you have a _LAN_, as such,  Outlook Express/IE4/5 may not
have quite the same notion of 'on' and 'off' line. It will behave as if
everythings hardwired.

dctrl is v handy to tell you whats lifting/keeping the line up.

The file you need to configure to ensure that only appropriate traffic types
lift/keep the line up is (on my RH6.0 system) /etc/diald/phone.filter. This
is distinct from the firewall rules - only diald uses it.

Now, where'd I put that soldering iron.... :)

J0e


"Ben Hardill" <b.hardill@usa.net> wrote in message
news:399A98F9.CDF3AFEB@usa.net...
> Just a qyick note to the groupe
>
> I seam to have solved this problem by filtering out all netbios
> protocols and filtering out all the DHCP requests. I hope this helps
> anybody else in a similar situation.
>
> Ben
>
> Ben Hardill wrote:
> >
> > Hi thanks for the help.
> >
> > So far i've tracked down the fact that its a udp packet thats bringing
> > the link up.
> >
> > The best effort i've found so far is to make the filter not bring the
> > link up for udp packets but only keep it up, but i don't think this will
> > be too good as DNS requests won't bring it up.
> >
> > Thanxs again i'll go didging with the ipchains stuff and look at moving
> > the diald off the oracle box.
> >
> > Ben