Tom Wyley <twxxxxxx@hooya.com> 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 Fri, 18 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <NKydneYyoK-x9xzVnZ2dnUVZ_qninZ2d@oco.net>, Tom Wyley wrote:

>> Phone companies are only required to provide a "voice grade" type of
>> connection, which can be pretty horrible.

>However, the inquiry led me to a many years old local newspaper
>investigation (way back when most people were on dialup) about a sudden
>drop in everyone's connection speed. Apparently the Telco was
>massively installing these combiner things all over the area. The
>reporter was told that nobody at the phone company was authorized to
>give any info or comment on the matter.

The more appropriate contact would be your state's public utilities
commission - the organization that actually oversees the telephone
(and electric, and water, and gas) service providers. They would only
step in if the utility was violating some standard[s], and as noted
the standard for telephone service is that the call goes through and
you can converse with the other party. It won't be hi-fi, and despite
the ads, you won't be able to "hear a pin drop" - you'll get have a
good enough connection to be able to understand the words spoken at
the other end.

>> The one you are interested in is 'netstat -anptu' which shows all
>> connections (-a), using numbers (-n) rather than hostnames, displays
>> the process name/ID that "owns" the connection on "this" end (-p)

>Netstat gives a ton of info.

That is bad news. On my system at the moment, there are _two_ items
listed besides the header - the LISTENING ssh server, and the
ESTABLISHED connection to port 119 on the remote news server.

So - how many 'LISTENING' lines do you have? Those are network servers
you are running whether you know it or not. How many 'ESTABLISHED'
lines do you have? Those are active conversations you are holding.
Now unless the port number on your end is port 9 (the bit bucket),
you are running something, and you'll need to find out why. Now, you
can ignore anything to/from 127.0.0.1 (which is one application on your
computer talking to another application on your computer). It's the
rest of the stuff you need to be concerned with.

>So far I am still just playing with it and not trying to trap anything
>real, but I did see one 2 minute session to data.coremetrics.com after
>my dialup connect and before I did anything. Still googling for who or
>what they are.

What was the port number on "your" end? What process was that? It's
generally easier to determine what stuff is by looking at your end,
because that is the stuff that's under your control.

>I don't think so. When I install Debian, I do it from scratch, apt by
>apt rather than use a canned version. Just the kernel and enough stuff
>to be able to access the machine and then just the packag(es) I need.

Don't forget that apt will install dependencies automagically.

Old guy

On 2008-07-19, Moe Trin <ibuprofin@painkiller.example.tld> wrote:
> On Sat, 19 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
> article <slrng828c1.ajo.allergic-to-spam@no-spam-allowed.invalid>,
> Jim Cochrane wrote:
>
>>Moe Trin <ibuprofin@painkiller.example.tld> 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


--

On Mon, 21 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <slrng883a6.uf1.allergic-to-spam@no-spam-allowed.invalid>,
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

Moe Trin wrote:
> On Mon, 21 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
> article <slrng883a6.uf1.allergic-to-spam@no-spam-allowed.invalid>,
> 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.

OH Really was that like version 1

SpinRite is a computer software program for scanning magnetic data
storage devices such as hard disks, recovering data from them and
refreshing their surfaces

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.


Ya back in the good old days...... Guess its been a while since you
looked at shields up a scan of "common ports" is now 26 and a you cam
select a "all service ports" which will scan your system's first 1056 ports


>
> 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

On Thu, 24 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <0ff96g.f5p.ln@freebee.ddns.org>, Send wrote:

>Moe Trin wrote:

>> 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.
>
>OH Really was that like version 1

Version 1.2 from 1988 apparently. It's hard for modern computer experts
to believe, but a 3000 RPM MFM drive connected to an 8 bit ISA bus
drive controller was far faster at delivering bits than the 4.77 MHz
8088, or even the 6 MHz 80286 of the IBM PC, PC-XT, and PC-AT (and
clones) could handle. Putting the terms 'hard disk interleave ratio'
into a search engine should provide you with a fair amount of reading
material.

>SpinRite is a computer software program for scanning magnetic data
>storage devices such as hard disks, recovering data from them and
>refreshing their surfaces

Originally, SpinRite, and the somewhat similar Htest/Hformat from Paul
Mace Software could be used to optimize the interleave ratio. The
need for this hack went away in the late 1980s when 16 bit drive
controllers became the default, and new drives came pre-formatted
without interleave. It's not even possible to set the interleave on
drives built after about 1990. I guess Gibson reused the product name
for something completely different. I haven't bothered with those
types of programs as I got rid of windoze in 1992.

>> His "Shields Up" scanner was pretty much pure hype - initially
>> scanning just _ten_ TCP ports. By mid-2003, it was up to thirteen!!!

>Ya back in the good old days...... Guess its been a while since you
>looked at shields up a scan of "common ports" is now 26 and a you
>cam select a "all service ports" which will scan your system's first
>1056 ports

I have no reason to use such a shoddy tool. Wow - 26 ports! I suspect
you really mean the first 1024 TCP ports, and 32 others that windoze
normally has open. It's laughable to compare that to even the "Fast
Scan Mode" of nmap uses (ports listed in the services file which comes
with nmap - a bit over 2200 tcp ports _alone_). Want something even
faster and not subject to the vagaries of your ISP filtering? Try
running the command 'netstat -anptu'.

Old guy

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

On 2008-07-22, Moe Trin <ibuprofin@painkiller.example.tld> wrote:
> On Mon, 21 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
> article <slrng883a6.uf1.allergic-to-spam@no-spam-allowed.invalid>,
> 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. :-)

--

Jim Cochrane wrote:
> [I'm a little late responding...]
>
> On 2008-07-22, Moe Trin <ibuprofin@painkiller.example.tld> wrote:
>> On Mon, 21 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
>> article <slrng883a6.uf1.allergic-to-spam@no-spam-allowed.invalid>,
>> 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. :-)
>

Ditto... I find myself saving a lot of what you post to refer back to
down the road.
I'm glad I followed a post from over a.o.l.u and found you here.
Is this group new? Only see posts from a month back.

On Mon, 04 Aug 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <4yOlk.20514$N87.8769@nlpi068.nbdc.sbc.com>, clay wrote:

>Ditto... I find myself saving a lot of what you post to refer back to
>down the road.

Flattery will get you nowhere ;-)

>Is this group new? Only see posts from a month back.

Not by a _long_ shot. The headers of the article I'm replying to shows

Xref: number1.nntp.dca.giganews.com comp.os.linux.networking:484936

while a post in a.o.l.u I replied to yesterday had

Xref: number1.nntp.dca.giganews.com alt.os.linux.ubuntu:78914

The number on the end is sequential - incremented for each article that
a news server has in a specific newsgroup. Thus, the giganews server
has seen about 79,000 articles in a.o.l.ubuntu since the group was
created in November 2005. This group (c.o.l.n) has seen around 485,000
articles since it was created in December 1994. This is one of 17
Linux newsgroups in the official "Big Eight" hierarchy:

[compton ~]$ zgrep linux big.8.list.07.15.08.gz | cut -f1 | column
comp.os.linux.advocacy comp.os.linux.misc
comp.os.linux.alpha comp.os.linux.networking
comp.os.linux.announce comp.os.linux.portable
comp.os.linux.answers comp.os.linux.powerpc
comp.os.linux.development.apps comp.os.linux.security
comp.os.linux.development.system comp.os.linux.setup
comp.os.linux.embedded comp.os.linux.x
comp.os.linux.hardware comp.os.linux.xbox
comp.os.linux.m68k
[compton ~]$

and these groups should be carried by every news server. There are
_also_ a large bunch of other groups in the 'alt.*' hierarchy and may
be a huge number that merely include the string 'linux' in the name:

[compton ~]$ grep -c ^alt.*linux .newsrc
95
[compton ~]$ grep -c linux .newsrc
1159
[compton ~]$

The problem with these groups is that they are unofficial, and are
carried at the whim of the individual news server administrator. The
recent fiasco with the New York Attorney General "negotiating" with
several ISPs to remove ~80 child-pr0n groups from the 'alt.binar*'
groups illustrates this, as several dropped all 'alt.*' groups, while
at least one eliminated Usenet entirely.

As for how many posts you see, that is a function of the storage space
available on the news server, and how many articles your news reader
is configured to read. A quick check at giganews shows 65687 articles
_claimed_ to be available in comp.os.linux.networking, which would be
about 5 years worth of posts (if my logs are to be believed). I haven't
checked this claim. A month back in this group is about 510 articles
which seems to be a low number for a commercial news server.

Old guy

Moe Trin wrote:
> On Mon, 04 Aug 2008, in the Usenet newsgroup comp.os.linux.networking, in
> article <4yOlk.20514$N87.8769@nlpi068.nbdc.sbc.com>, clay wrote:
>
>>Ditto... I find myself saving a lot of what you post to refer back to
>>down the road.
>
> Flattery will get you nowhere ;-)
>
>>Is this group new? Only see posts from a month back.
>
> Not by a _long_ shot. The headers of the article I'm replying to shows
>
> Xref: number1.nntp.dca.giganews.com comp.os.linux.networking:484936
>
> while a post in a.o.l.u I replied to yesterday had
>
> Xref: number1.nntp.dca.giganews.com alt.os.linux.ubuntu:78914
>
> The number on the end is sequential - incremented for each article that
> a news server has in a specific newsgroup. Thus, the giganews server
> has seen about 79,000 articles in a.o.l.ubuntu since the group was
> created in November 2005. This group (c.o.l.n) has seen around 485,000
> articles since it was created in December 1994. This is one of 17
> Linux newsgroups in the official "Big Eight" hierarchy:
>
> [compton ~]$ zgrep linux big.8.list.07.15.08.gz | cut -f1 | column
> comp.os.linux.advocacy comp.os.linux.misc
> comp.os.linux.alpha comp.os.linux.networking
> comp.os.linux.announce comp.os.linux.portable
> comp.os.linux.answers comp.os.linux.powerpc
> comp.os.linux.development.apps comp.os.linux.security
> comp.os.linux.development.system comp.os.linux.setup
> comp.os.linux.embedded comp.os.linux.x
> comp.os.linux.hardware comp.os.linux.xbox
> comp.os.linux.m68k
> [compton ~]$
>
> and these groups should be carried by every news server. There are
> _also_ a large bunch of other groups in the 'alt.*' hierarchy and may
> be a huge number that merely include the string 'linux' in the name:
>
> [compton ~]$ grep -c ^alt.*linux .newsrc
> 95
> [compton ~]$ grep -c linux .newsrc
> 1159
> [compton ~]$
>
> The problem with these groups is that they are unofficial, and are
> carried at the whim of the individual news server administrator. The
> recent fiasco with the New York Attorney General "negotiating" with
> several ISPs to remove ~80 child-pr0n groups from the 'alt.binar*'
> groups illustrates this, as several dropped all 'alt.*' groups, while
> at least one eliminated Usenet entirely.
>
> As for how many posts you see, that is a function of the storage space
> available on the news server, and how many articles your news reader
> is configured to read. A quick check at giganews shows 65687 articles
> _claimed_ to be available in comp.os.linux.networking, which would be
> about 5 years worth of posts (if my logs are to be believed). I haven't
> checked this claim. A month back in this group is about 510 articles
> which seems to be a low number for a commercial news server.
>
> Old guy

Ok, so I knew it was a silly question/observation when I made it.
TB showed ~ a half million posts:
comp.os.linux.networking: 1-499837
Apparently (whoever) my ISP (is contracting with) feels compelled to
retain even less of this group than a.o.l.u. Over two months over there,
~two weeks here... And they've dropped the binary groups too.
Well, I'm glad I stumbled in. Learned more about ports in the last day
than since I've been playing with these computer things.
Tried netstat -anptu soon as I got home last night, curious to see who's
peeking in. Got a page of stuff. Mostly my two boxes chatting with
themselves or each other. Thunderbird and ssh listening and that's about it.
Now to rtfm and learn what it all means.
Stay well.