What is going on with my Dialup?

I am using Debian loaded from DVDs so the following is not some Windows
update phenomenon.

Since I left college this summer, I no longer have access to the campus
Hi-speed Internet. So for now I am stuck on a rural dial up line that
somehow the phone company has limited to about 26k throughput. I am
trying to find out from the telco what is going on and why not 56k, but
for now I am watching the lights on an external modem and they are
revealing some stuff that I don't like.

I am not much of a telecommunications guru (read: not at all) but it would
appear that most of the traffic on my link is not mine. I realize that
there is a certain amount of handshaking on initial connect, and some may
be Firefox looking for updates (although I have turned off all of that I
can find). But there is a lot left over that I can't explain.

As an example... I was adding a couple of DVDs to my Netflix queue. It
seemed very slow, taking almost a minute between screens even with the
pictures turned off. Then I noticed the lights on the modem which
indicated a continual receive with an occasional send even after the page
was loaded and Firefox indicated "Done". It would continue for two
minutes or so. I went to google and the same thing happened.

Then I went through Firefox and turned off every update, feed and
automatic check I could find. Made no difference. So I loaded Konqueror
and surfed with that and got the same results - an unasked for receipt of
something that is minutes long and that happens at random intervals of
about 2 to 5 minutes.

Next I logged off and dialed back in with no browser at all. I should
have just talked to the ISP hardware and then dropped into a passive mode
with an occasional keep alive blip. But sure enough, in about 20 seconds
in comes a 3 minute continuous receive.

The above post indicates two problems. Something is stealing a bunch of
what little bandwidth I have, and (I think) somebody is talking to me
unasked. This would never be noticed on a broadband link unless someone
was running some kind of trace.

What is the easist way to determine what is incoming on an Internet
connection? I know that I could learn Snort or such like, but I am just
starting my first career and there isn't a whole lot of time left for
playing. A Linux utility of some kind, maybe?

Thanx any
Tom

Am Wed, 16 Jul 2008 21:46:16 -0500 schrieb Tom Wyley:

> Next I logged off and dialed back in with no browser at all. I should
> have just talked to the ISP hardware and then dropped into a passive mode
> with an occasional keep alive blip. But sure enough, in about 20 seconds
> in comes a 3 minute continuous receive.

keepalive? (your isp drops the connection after a while)

> The above post indicates two problems. Something is stealing a bunch of
> what little bandwidth I have, and (I think) somebody is talking to me
> unasked. This would never be noticed on a broadband link unless someone
> was running some kind of trace.

Usually you'll have a p2p connection, so you don't get other packets
except the packet ist for you.

> What is the easist way to determine what is incoming on an Internet
> connection? I know that I could learn Snort or such like, but I am just
> starting my first career and there isn't a whole lot of time left for
> playing. A Linux utility of some kind, maybe?
>
> Thanx any
> Tom


Snort is an ids an sniffer like tcpdump, wireshark etc. is what you are
looking for.

cheers

Tom Wyley <(E-Mail Removed)> wrote:
> I am using Debian loaded from DVDs so the following is not some Windows
> update phenomenon.

> Since I left college this summer, I no longer have access to the campus
> Hi-speed Internet. So for now I am stuck on a rural dial up line that
> somehow the phone company has limited to about 26k throughput. I am
> trying to find out from the telco what is going on and why not 56k, but

You may have to accept 26k in a rural area since modems negotiate speed
and long phone lines to the ISP will limit what speed can be negotiated.
But the particular modem or modem configuration can also limit speed.
So it's a good idea to learn all you can about the modem to make sure
the configuration is the best it can be.

You won't get 56k in the U.S., all I've ever gotten is 50667 bps and
that's a rare exception, most of the time it's 48000 or 49999 bps.
And there's a FCC limit of 53kbps, if I remember correctly.

> for now I am watching the lights on an external modem and they are
> revealing some stuff that I don't like.

....

> Next I logged off and dialed back in with no browser at all. I should
> have just talked to the ISP hardware and then dropped into a passive mode
> with an occasional keep alive blip. But sure enough, in about 20 seconds
> in comes a 3 minute continuous receive.

> The above post indicates two problems. Something is stealing a bunch of
> what little bandwidth I have, and (I think) somebody is talking to me
> unasked. This would never be noticed on a broadband link unless someone
> was running some kind of trace.

If there is an Internet connection there will be kiddies trying to break
into it and cause trouble. Even on a PPP connection a firewall is a good
idea.

> What is the easist way to determine what is incoming on an Internet
> connection? I know that I could learn Snort or such like, but I am just
> starting my first career and there isn't a whole lot of time left for
> playing. A Linux utility of some kind, maybe?

This dumps traffic on ppp0 to standard output:
tcpdump -v -i ppp0

This dumps traffic without DNS lookup for the IP addresses:
tcpdump -vn -i ppp0

There will be a lot of output over 3 minutes in either case, most
of which won't be of much more value than what you see in 3 seconds.
There will be a learning curve. I don't know what, if any, GUI traffic
sniffing tools are available.

> Thanx any
> Tom

--
Clifford Kite
/* Speak softly and carry a +6 two-handed sword. */

On Wed, 16 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <KY2dnepobYPlL-(E-Mail Removed)>, Tom Wyley wrote:

>So for now I am stuck on a rural dial up line that somehow the phone
>company has limited to about 26k throughput. I am trying to find out
>from the telco what is going on and why not 56k, but for now I am
>watching the lights on an external modem and they are revealing some
>stuff that I don't like.

1. Are you using the "correct" init-string according to the manufacturer
of your un-named modem?
2. "rural dial up" suggests you are some distance from town - how noisy
is the phone line? 56K (and indeed anything over about 26K tends to
want to see a "clean" phone line - 26-33.6K is almost harder than 37-56K
on a noisier line.
3. Looking at modem lights isn't as informative as looking at the actual
data transfers.

>I am not much of a telecommunications guru (read: not at all) but it
>would appear that most of the traffic on my link is not mine.

You're possibly seeing windoze "messenger spam" (UDP to ports 1025-1035)
but that should be relatively light. OTHER THAN THAT, your connection
is a point-to-point link, and the only traffic on that link is to/from
your computer.

>I realize that there is a certain amount of handshaking on initial
>connect, and some may be Firefox looking for updates (although I have
>turned off all of that I can find). But there is a lot left over that
>I can't explain.

Let's start by not using a browser. Most browsers are happy to try to
load every piece of eye-candy and other crap. What traffic do you see
when the browser isn't running?

>Next I logged off and dialed back in with no browser at all. I should
>have just talked to the ISP hardware and then dropped into a passive mode
>with an occasional keep alive blip. But sure enough, in about 20 seconds
>in comes a 3 minute continuous receive.

Figure out where the command line is, and run 'netstat -anptu' and see
what is talking to what. See the man page for netstat so you understand
what it's telling you.

>The above post indicates two problems. Something is stealing a bunch of
>what little bandwidth I have, and (I think) somebody is talking to me
>unasked. This would never be noticed on a broadband link unless someone
>was running some kind of trace.

Depending on what all you installed, there shouldn't be that much open
for "others" to connect to you. Nearly all of that traffic is _probably_
due to client things you are running - but you won't know that until
you find out what the traffic is. Most people install all kinds of
extra trash that they think might be interesting, and don't know what
it's actually doing.

>What is the easist way to determine what is incoming on an Internet
>connection?

[compton ~]$ netstat -anptu
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 8972/sshd
[compton ~]$

Doesn't really tell you, but the firewall is only accepting connections
from two ranges totalling 1500 addresses (a /22 and two /24s).

>I know that I could learn Snort or such like, but I am just starting my
>first career and there isn't a whole lot of time left for playing.

-rw-rw-r-- 1 gferg ldp 155096 Jan 23 2004 Security-HOWTO
-rw-rw-r-- 1 gferg ldp 278012 Jul 23 2002 Security-Quickstart-HOWTO

Should be on your system in /usr/share/HOWTO (or use your favorite search
engine) - and there are a number of other good ones.

Old guy

O
> You may have to accept 26k in a rural area since modems negotiate speed
> and long phone lines to the ISP will limit what speed can be negotiated.
> But the particular modem or modem configuration can also limit speed.
> So it's a good idea to learn all you can about the modem to make sure
> the configuration is the best it can be.
>
>

As it turns out, the Telco has put "combiners" on the lines to get two
customers on one piece of copper. So I will never get over 26k from here.

Tome

>
> 1. Are you using the "correct" init-string according to the manufacturer
> of your un-named modem?
> 2. "rural dial up" suggests you are some distance from town - how noisy
> is the phone line? 56K (and indeed anything over about 26K tends to
> want to see a "clean" phone line - 26-33.6K is almost harder than 37-56K
> on a noisier line.

I found today that the phone company has put combiners on the lines around
here so as to get two customers on one piece of copper. The bandwidth is
only 30k on each side.

> Let's start by not using a browser. Most browsers are happy to try to
> load every piece of eye-candy and other crap. What traffic do you see
> when the browser isn't running?
>
> Figure out where the command line is, and run 'netstat -anptu' and see
> what is talking to what. See the man page for netstat so you understand
> what it's telling you.
>
I can handle the command line ok but netstat is a big little program so I
am RTFMing to figure it out. Looks to be about a zillion combinations of
options.

> Depending on what all you installed, there shouldn't be that much open
> for "others" to connect to you. Nearly all of that traffic is _probably_
> due to client things you are running - but you won't know that until you
> find out what the traffic is. Most people install all kinds of extra
> trash that they think might be interesting, and don't know what it's
> actually doing.

This is just a basic Debian install with stuff for a programmer (C, Perl,
Tk, Mysql, and so forth). Not much else. I have a Smoothwall box
between me and the modem with all ports except 80 and 441 closed. I can
see all the Windows trojan junk hitting me but nothing in the firewall
shows anything that I can corrilate to a 2 and 3 minute unrequested receive
package.

Like I said, what is happening probably also happens on broadband lines
also - it is just the speed of my line that makes it obvious.

Will check out netstat.

Thanks
Tom

On 2008-07-18, Moe Trin <(E-Mail Removed)> wrote:
> On Thu, 17 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
> article <5IudndO9Xp7Nf-(E-Mail Removed)>, Tom Wyley wrote:
>
> ...
>
> That's it - maybe 40-70 bytes in each direction, and the connection is
> ended. If there is no server, then the only traffic will be in response
> to something your system initiated.
>
> Your_systemort_$NUMBER -> Remote_systemort_$BAR "Hello"
> Remote_systemort_$BAR -> Your_systemort_$NUMBER "Hi - what?"
> Your_systemort_$NUMBER -> Remote_systemort_$BAR "Good to see you"
> Your_systemort_$NUMBER -> Remote_systemort_$BAR "Send me $CRAP"
> Remote_systemort_$BAR -> Your_systemort_$NUMBER "Here it comes!!!"
> and away we go, with three tons of what-ever it was that you asked
> them for. (Yes, this is a bit simplified, but the concept is accurate.)
>
> Bottom line - no servers on your end means only a tiny blip of traffic
> as your computer tells the remote "I'm sorry, but the number you dialed
> is not in service - CLICK!". If there _is_ a server, you have to figure

Cannot a firewall be configured to simply ignore any incoming requests,
so that there would be no response at all, instead of saying the
equivalent of "not in service"?


--

Tom Wyley <(E-Mail Removed)> wrote:
> I noticed the lights on the modem which
> indicated a continual receive with an occasional send even after the page
> was loaded and Firefox indicated "Done". It would continue for two
> minutes or so. I went to google and the same thing happened.

Are you sure it is not a background prefetch being done by the browser?
The newer browsers do this. I think on broadband, the browser
performance has greatly improved, but I have seen some dog slow browsers on
dial up connections, but I haven't yet managed to get round to tracing
this. (This problem has been occuring on third party systems using
Micros~1dows, but most people are planning to switch over to a broadband
provider, so the priority for investigating this has been low.)

I would run tcpdump in a console window, do your browsing, then switch
to the terminal window and have a look what is happening when the modem
light starts to come on.

Let us know what you find.

Regards,

Mark.

--
Mark Hobley,
393 Quinton Road West,
Quinton, BIRMINGHAM.
B32 1QE.

On 2008-07-19, Moe Trin <(E-Mail Removed)> wrote:
> On Sat, 19 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
> article <slrng828c1.ajo.allergic-to-(E-Mail Removed)>,
> Jim Cochrane wrote:
>
>>Moe Trin <(E-Mail Removed)> wrote:
>
>>> Bottom line - no servers on your end means only a tiny blip of traffic
>>> as your computer tells the remote "I'm sorry, but the number you dialed
>>> is not in service - CLICK!".
>
>>Cannot a firewall be configured to simply ignore any incoming requests,
>>so that there would be no response at all, instead of saying the
>>equivalent of "not in service"?
>
> In addition to the regular HOWTOs from then LDP, see
>
> http://www.netfilter.org/documentation/HOWTO/
>
> That's the "default" result when using 'iptables' "DROP" rule. To have
> the firewall reject with an ICMP Type 3 Code 3 (Port Unreachable) or
> similar, you have to provide an extra rule of "REJECT with". In most
> cases, you provide a "default" rule which would be a DROP, but you can
> also forward it to an unused port, and have that port provide the
> "normal" RST flagged TCP packet.

Thanks, Moe, for the excellent response.

I guess the situation is a lot less black-and-white than one would be
led to believe by using GRC's port test:

https://www.grc.com/x/ne.dll?bh0bkyd2

You're one of those rare persons from whose posts people can actually
gain good, detailed knowledge, rather than just reading opinions with
perhaps a little bit of data to back them up.


Thanks.

> There is a huge debate of whether it's better to provide no response
> verses the RST or ICMP 3,3. Some feel this makes their computer
> invisible, neglecting to note that were their computer non-existent,
> the upstream router would normally provide an ICMP Type 3 Code 1 (Host
> Unreachable). I've actually seen idiots who configured their firewall
> to mimic the 'Host Unreachable' response - I say 'idiots' because the
> resulting ICMP error comes from the IP address that is supposedly
> unreachable. The lack of response causes the remote computer to make
> additional tries - so you aren't saving any bandwidth by silently
> discarding unwanted packets. As far as the bad guys are concerned, the
> lack of response confirms that the computer does exist, is reachable,
> and is using some form of firewall. This _MAY_ attract more attention
> compared to the effect of a more normal RST or ICMP 3,3. Your choice.
>
> Others think that by not responding to unwanted packets, they can hide
> information about their computer, such as operating system type and
> version. See the documentation that comes with the popular 'nmap' tool
>
> [compton ~]$ whatis nmap
> nmap (1) - Network exploration tool and security scanner
> [compton ~]$
>
> for considerably more details on this technique, and some simple means
> of defeating such probes.
>
> There is one situation when it _IS_ desirable to ignore unwanted
> packets. This is the case for UDP. Messenger spam (usually messages
> that appear to be windoze warning messages, directed to UDP ports 1025
> to 1030 or so) are often using spoofed source addresses. Looking at the
> IP headers of such packets, there are usually some glaringly obvious
> indications that the source is spoofed (such as using IP addresses that
> haven't been released by IANA - see that one fairly often). This means
> that there is no reason to send a FOAD packet to a non-existent or
> innocent host that had nothing to do with the UDP spam.
>
> Finally, there is a case where dropping packets causes you problems.
> The most common problem is 'identd' or 'auth' on tcp/113. You connect
> to a remote system, and it sends a query to this port - basically
> asking "who is your user who is connecting to my port <mumble>?". It
> waits until it gets an answer - either a response from the identd that
> is running on your system, or a port rejection from the network stack
> because you aren't running identd. If you DROP these packets, rather
> than rejecting or answering them, you have to wait ten to thirty
> seconds for the remote client to time out before your desired
> connection goes through. I see this on a number of servers I connect
> to on a regular basis. My solution is to have a special rule for
> these known servers to this specific port.
>
> The gotcha if you are silently discarding unwanted packets is that you
> have to do so for all 65536 ports and all 256 possible protocols (there
> is more to the world of IP than TCP, UDP, and ICMP). See the 'nmap'
> documentation for a lot more details and concepts.
>
> Old guy


--

[I'm a little late responding...]

On 2008-07-22, Moe Trin <(E-Mail Removed)> wrote:
> On Mon, 21 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
> article <slrng883a6.uf1.allergic-to-(E-Mail Removed)>,
> Jim Cochrane wrote:
>
>>Thanks, Moe, for the excellent response.
>>
>>I guess the situation is a lot less black-and-white than one would be
>>led to believe by using GRC's port test:
>
> I don't know what to think about Mr. Gibson. In the mid-1980s, his
> 'Spin-Rite' application was useful for setting hard disk interleave
> ratios. When he got into network security, he seems to have decided
> to take short-cuts, and ignore the problems those create. His
> "Shields Up" scanner was pretty much pure hype - initially scanning
> just _ten_ TCP ports. By mid-2003, it was up to thirteen!!! (21, 23,
> 25, 79, 80, 110, 113, 135, 139, 143, 443, 445 and 5000). While that
> might catch some windoze vulnerabilities (didn't know windoze ran a
> finger daemon), it misses just about everything else. If you run a
> packet sniffer while getting a scan today, you'll see more ports
> checked, but still far from complete.
>
> You do have to look at the tool you are trying to use. I find that
> nmap is very useful (I'm told this is what the grc.com port scan is
> actually using), but you have to read the large amount of documentation
> that comes with it to get the best results.
>
>>You're one of those rare persons from whose posts people can actually
>>gain good, detailed knowledge, rather than just reading opinions with
>>perhaps a little bit of data to back them up.
>
> Yeah, I do tend to get long winded at times. Thanks!
>
> Old guy

Maybe so sometimes, but your long-winded posts tend to be full of good/useful
information. :-)

--