[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: diald




Thanks for the tip.  I found the packets that were keeping the diald
connection open.  About every 3 or 4 seconds (with no traffic passing through)
I get something like
18:49:41.343057 204.248.89.2 > 224.0.0.5: OSPF v2-hello 44: rtrid 208.4.41.173
backbone [tos 0xc0] [ttl1]

Not quite sure what it means.  The 18:49:41 seems to be the time.
The 343057 changes from packet to packet in a seemingly random manner
(sequence number?). The 204.248.82.2 is the Remote address reported at login.
When I attempt to ping 224.0.0.5, I get a reply from 204.248.89.2 (the Remote
address). When I tried to telnet to 208.4.41.173, I received a "WElcome to
Accessus Mt. Vernon Pop#1" and a login prompt.

The ospf suggests that it is a routing protocol.


I don't know why I babled all that much.  I guess what I am asking is what
goes in the filter to prevent these packets from keeping the diald connection
open?

Thanks




On Sun, 9 Jul 2000, Jeff Licquia wrote:

> On Sun, Jul 09, 2000 at 05:23:51PM -0500, Alan Wilson wrote:
> > 
> > I have an older machine that I wanted IP masquerading and diald configured on.
> > (RH5.1 2.0.34 kernel).  I got the IP masquerading working.  finally got diald
> > to dial.  Problem: diald will not hang up.  I have played with the
> > configuration files quite a bit; nothing obvious. My only suspect is the if I
> > run ifconfig a couple of time, it appears that ppp0 is receiving a packet
> > every 5 seconds or so.  Since I don't think I am causing this to happen, it
> > appears that my ISP is sending the packet.  The phone.filter file seemed to
> > have some filters which I thought would cause the timers to ignore such
> > packets.  (oh, using diald16-o.16.5a-2.i386.rpm; the new one wanted libc.so.6
> > which isn't on this computer)
> > 
> > Does anyone have any suggestions to make diald work -- that is hang up after a
> > reasonable time?
> 
> You'll probably need to identify the packet and configure diald to
> ignore it.
> 
> The best tool for identifying the packet is tcpdump, which should be
> on the Red Hat CD.  You'll want to run it with a command line
> something like:
> 
> tcpdump -ni ppp0
> 
> (so you don't pick up Ethernet traffic, and you don't create name
> lookup traffic for every packet)
> 
> This will tell you the source and destination ports and IP addresses,
> and whether the traffic is being initiated or received by you.  Don't
> be surprised to find that you're generating the traffic - lots of
> protocols, most notably any Microsoft protocols, can be quite chatty.
> Also make sure that none of the traffic isn't a security risk and
> shouldn't be permanently disabled; you can use other tools (such as
> lsof) to determine what process on your system is generating/receiving
> the traffic in this case.
> 
> Assuming none of the traffic poses a security risk, you'll then need
> to tell diald to ignore the traffic.  Pick a suitable place in your
> standard.filter file and add lines something like this:
> 
> ignore tcp tcp.source=tcp.31337
> ignore udp udp.dest=udp.31337
> 
> These are just examples.  Put in the port numbers and so on you're
> concerned about, and make sure the underlying protocol matches too
> (tcp/udp).  Remember that standard.filter is evaluated in a
> short-circuit manner, so the order of "ignore" and "accept" statements
> counts.
> 
> -
> To unsubscribe, send email to majordomo@luci.org with
> "unsubscribe luci-discuss" in the body.
> 

-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.