who do I report this to?

[韓家標 Bill Hacker]

Aryeh M. Friedman wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
>> To be fair, Aryeh - your report was of a sort that indicated it
>> could very well have been an upstream issue. Torrents in particular
>> are unpredictable critters, and - given you've said you had only the
>> one box - I don't see how/where you could have emulated that 'locally'.
> 
> If it wasn't for the following facts (which where in the orginal
> message and/or the immediate followup to Pyun):
> 
>     * All applications are effected for example here is something that
> happened earlier tonight (if I was organized I could of copied many of
> these over the last few days [was doing a portupgrade -afk] but this
> is the only one I copied):
> 
>  >
>  > => Attempting to fetch from
>  > http://heanet.dl.sourceforge.net/sourceforge/xine/.
>  > xine-lib-1.1.7.tar.gz                           9% of 8660 kB   40
>  > kBps 03m13s
>  > fetch: xine-lib-1.1.7.tar.gz appears to be truncated:
> 868700/8868650 bytes
> 
>     FTP also was sending garbagged data
>  
> 

Do a traceroute to that server from your 'seat' at one-hour intervals.

Then do so from the looking-glass server on/near its own backbone.

Meanwhile, there are plenty of compliants about the spotty performance of your 
local bandwidth provider. You'll find those online if you look.

>     * It is time triggered plus to some extent the only common
> denominator being time and re(4)
>

Not so. The common denominator throughout has been your *external link*.

I can suggest a number of ways to quantize its characteristics, but it *doesn't 
matter*. They change over time and are not under your control.

If you want to provide meaningful traffic tests on a NIC, you must get that 
unpredictable portion out of the mix!

You will need at least one other 'local' box. It need not be fancy, but it has 
to be under your observation and control.

>     * Rebooting the FreeBSD machine [static IP and DMZ] (and nothing
> else on the network) always solves the problem

There are plenty of reasons unrelated to the re (or any other) driver that can 
contribute to that. There is more to the world than driver code.

>> As to the re(4) 'issue' - we are scp'ing seriously large container
>> files over local switches internal to the rack, AND both
>> carrier-grade and sod-awful residential cable-modem links, csuping
>> often, etc --- all  w/o *any* of the reported 're' problems (so far).
> 

> This seems to only have appeared recently in 8-current (say last two
> weeks or so)

It may well have.  Or just as easily NOT.

You are not equipped to ascertain that.

>> Meanwhile - more accurate / detailed research & reporting, and a bit
>> less sarcasm would be useful.
> 
> If you can tell me how to capture a phantom I would be able to do this.
> 

What you are calling a 'phantom' is the product of a combination of 
circumstances - too many of which are literally 'outside the house'.

Fault isolation on networks is a precise science.

The most basic part is fault *isolation*.

IOW - you have to break the link down into its components, and test each part of 
the link from each end.

If you can get down to a back-to-back CAT5E between two Gig-E NICs each on a 
*BSD box, and/or a single, 'decent', GigE switching hub between, then you can 
tcpdump both ends, set up a dummynet and emulate marginal links, run test suites 
with known characteristics - whatever it takes.

Having your erratic uplink in the mix is not helping anyone.

Bill