[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.
- Follow-Ups:
- Re: diald
- From: Tim Grossner <tg@wintermute.cityscape.net>