- NANOG - lists.nanog.org

FORGED EMAIL POSTED TO NANOG
by Reid B. Fishler 27 Oct '01

27 Oct '01

Hi all- Someone is having fun tonight, getting 1010WINS, a local radio stations web site to send mail as me to nanog: Received: from mail.cbsig.net (mail32.nyc01.cbsig.net [63.240.57.32]) by segue.merit.edu (Postfix) with SMTP id 441835DD8F for <nanog(a)merit.edu>; Thu, 25 Oct 2001 23:16:14 -0400 (EDT) Received: (qmail 7985 invoked from network); 26 Oct 2001 03:16:13 -0000 Received: from web145.nyc01.cbsig.net (63.240.56.145) by mail02.cbsig.net with SMTP; 26 Oct 2001 03:16:13 -0000 1010WINS is a CBS owned station, and as you can see this email came from cbsig.net, which is NOT me. Can the mailing list program be fooled by sending mail from a web program like this? Perhaps this should be looked at. Anyhow, I just wanted to mention I did NOT send this email. Reid Fishler Lightning.net

2 1

Re: Pinging Yahoo! (WAS: Getting hacked by Digital Isle?)
by Patrick W. Gilmore 27 Oct '01

27 Oct '01

At 10:09 PM 10/26/2001 -0400, mike harrison wrote: >Now, here's a real issue, many of us probably have similiar systems >that ping upstream connections and page/alert/log when there are >problems. My 'watcher' could also grab a web page (checking port 80) >or do other tests, but I have always assumed that the ping was the least >amount of traffic easily and reliably sent to check connectivity. > >Whats the best way to monitor upstream connectivity for this purpose? Personally, I do not see anything wrong with pinging your upstream. You PAY them, they will take any and all traffic you send them (unless otherwise stated in something like an AUP). Ping away. Of course, that leaves the question as to whether your upstream can get to the rest of the world.... -- TTFN, patrick

1 0

Physical diversity in a meshed Frame Relay network
by JC Dill 27 Oct '01

27 Oct '01

I'm in the process of spec'ing out a meshed Frame Relay network and would like to have as much physical diversity in the mesh as possible. The plan is to have 2 or more FR lines into each location, running in separate bundles, preferably in separate conduits and thru separate paths back to the CO, and then have each FR line terminated on a different switch. I'd love suggestions on how to actually achieve this. Are there any special terms to use to specify this? Is there any way to determine if we are actually *getting* it, if it's so specified? Thanks! jc (please don't wander off into discussions of "why FR?" as this has already been decided)

2 1

Does 'the good of the net' still exist? Yes? Maybe you can help it out...
by Ben Ryan 27 Oct '01

27 Oct '01

I think this is within the broad spectrum of NANOG's charter. Central resources like this are a dying breed, hopefully there's someone from the tech community who is in a position to help/host/etc... maybe someone's out there who doesn't have a bean-counter watching over their shoulder and can recognize value beyond current share price... http://www.faqs.org/ http://www.faqs.org/save_faqs-org.html thanks for your time, i have no personal interest in this beyond supporting the efforts of people trying to maintain the 'spirit' that brought this whole thing together. Pity much of the corp's who survive via global IP forget where the net came from and to whom they owe gratitude for putting in the effort to make it what it is today... cheers ben ________.-~-.________ Ben Ryan, MCP Network Engineer Lansys Technologies Bendigo, Victoria Australia Phone +61-[0]417 502061 email: ben(a)bssc.edu.au URL: http://thrasher.impulse.net.au/index.htm

1 0

Re: FBI is at it again
by herb＠tomobiki.urusei.net 27 Oct '01

27 Oct '01

Forwardee message: > > Per the following article: = > http://www.foxnews.com/story/0,2933,37203,00.html it appears as if the = > FBI now wants to route ALL Internet traffic through it's central = > servers!!!! > > What gall!! What nerve!!!! > > Now, for all of you who said, "Hey, I'm not doing anything wrong, let = > the FBI monitor what it wants to." can go shove hot spikes up your nose. > > I don't think the FBI really wants to control the Internet, they want to = > destabilize it. As tyranny approaches the only thing more dangerous = > than an armed populace is an informed one. If they can monitor all the = > traffic, they can certainly control it. > > The ISP's (whatever those are) need to collectively tell the FBI to go = > jump off a bridge. Information campaigns need to be sent to the = > customers to alert them of the potential loss of civil liberties. > > I'm gonna stop before I say something that will get me arrested. > > Regards, > > Larry Diffey Here's an idea: Shove it at them! If they want to have a running log of everything that goes on in the 'Net, let them try to keep up. I hope they have a lot of solid state disks... /herb

1 0

The Cidr Report
by CIDR Report 27 Oct '01

27 Oct '01

This is an auto-generated mail on Fri Oct 26 23:00:00 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 26Oct01 0) General Status Table History ------------- Date Prefixes 191001 104997 201001 104988 211001 104985 221001 105173 231001 105209 241001 104135 251001 103926 261001 104244 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 8804 Number of ASes announcing only one prefix: 3995 (3995 cidr, 0 classful) Largest number of cidr routes: 846 announced by AS701 Largest number of classful routes: 0 announced by 1) Gains by aggregating at the origin AS level --- 26Oct01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1223 940 283 23.1% Telstra Pty Ltd AS4151 298 164 134 45.0% USDA AS13999 136 9 127 93.4% Mega Cable S.A. de C.V. AS16473 196 75 121 61.7% Bell South AS4293 364 257 107 29.4% Cable & Wireless USA AS2048 215 116 99 46.0% State of Louisiana AS271 158 71 87 55.1% University of British Columbia AS4755 215 133 82 38.1% Videsh Sanchar Nigam Ltd. Autonom AS1239 476 400 76 16.0% Sprint AS12302 106 35 71 67.0% MobiFon S.A. AS17557 138 71 67 48.6% Pakistan Telecom AS4200 131 66 65 49.6% Apex Global Information Services, AS3464 161 96 65 40.4% Alabama SuperComputer Network AS19632 72 7 65 90.3% Metropolis Intercom S.A. AS16758 63 6 57 90.5% IKON Office Solutions AS209 304 249 55 18.1% Qwest AS226 144 91 53 36.8% Los Nettos AS4323 273 221 52 19.0% Time Warner Communications, Inc. AS3908 298 247 51 17.1% Supernet, Inc. AS17561 111 60 51 45.9% Internet service provision to Wes AS376 121 73 48 39.7% Reseau Interordinateurs Scientiqu AS10620 69 21 48 69.6% TVCABLE BOGOTA AS1 517 469 48 9.3% BBN Planet AS16814 65 18 47 72.3% NSS, S.A. AS15288 71 24 47 66.2% Alcanet International NA AS15290 247 201 46 18.6% AT&T Canada IES AS2652 129 85 44 34.1% Government Telecommunications and AS10292 70 27 43 61.4% TELECOMMUNICATIONS OF JAMAICA AS5416 51 9 42 82.4% BATELCO-BH AS5103 76 34 42 55.3% Ameritech Advanced Data Services, For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

FWD: RE: FW: Getting hacked by Digital Isle?
by Christopher Wolff 27 Oct '01

27 Oct '01

Here is the official Digital Isle party line. The part that I like is "3) Respond to this message requesting we stop pinging your server. In this event our pinging will cease in several days." Several days? I'm wondering if I can send a bill to Digital Isle for beta testing their product on my time and bandwidth without even asking me. Regards, Christopher ---------- Original Message ---------------------------------- From: Sean Gleason <sgleason(a)digisle.net> Date: Fri, 26 Oct 2001 01:02:21 +0000 (GMT) Chris, We apologize for any inconvenience caused by pings (ICMP_ECHO packets) coming from our machines. Your server was being pinged as part of our real-time "network weather" mapping system called Best Distributor Selection. BDS is an essential part of Footprint, Digital Island's intelligent network service offering. It is used to optimize performance when your customers access the web resources of our customers. Many large web publishers, such as AOL, CNBC and Blue Mountain, use our Footprint service to speed up the delivery of their web content. Our system intelligently matches browsers to the servers on our Footprint network that will provide the best performance. The dynamic nature of routing and congestion on the Internet make it necessary for us to constantly update our maps. Our network was pinging your system because it appeared to be a name server with a sufficient number of resolution requests for our customer web sites to be placed on the list of network nodes to be constantly observed for Internet congestion. By pinging your name server, we can provide better quality of service to your users when they access the web sites of our expanding customer list. We hope you will consider granting us permission to continue pinging a name server in your domain. Sandpiper Networks merged with Digital Island in December 1999, which is why some of the machines pinging you were in digisle.net. At this point you can: 1) Do nothing. Please accept our apologies and be assured that your machines are not being pinged by a hostile party. 2) Tell us if there is an alternate name server in your IP address space that you would like us to ping. We will direct future ping traffic to it. 3) Respond to this message requesting we stop pinging your server. In this event our pinging will cease in several days. Regards, Sean Gleason Digital Island, Inc. On Thu, 25 Oct 2001, Christopher J. Wolff wrote: > Hello, thank you for your response. Here are the source addresses. > > > IDS246/dos_dos-large-icmp ICMP 167.216.210.50:na 64.212.9.100:na > ns1.bblabs.net 17:30 10-25 > IDS246/dos_dos-large-icmp ICMP 198.30.3.4:na 64.212.9.100:na > ns1.bblabs.net 17:29 10-25 > IDS246/dos_dos-large-icmp ICMP 24.30.1.7:na 64.212.9.100:na > ns1.bblabs.net 17:27 10-25 > IDS246/dos_dos-large-icmp ICMP 212.177.57.41:na 64.212.9.100:na > ns1.bblabs.net 17:27 10-25 > IDS118/scan_Traceroute ICMP ICMP 216.200.14.119:na 64.212.9.100:na > ns1.bblabs.net 17:27 10-25 > IDS118/scan_Traceroute ICMP ICMP 216.32.118.78:na 64.212.9.100:na > ns1.bblabs.net 17:27 10-25 > IDS118/scan_Traceroute ICMP ICMP 207.46.144.74:na 64.212.9.100:na > ns1.bblabs.net 17:27 10-25 > IDS118/scan_Traceroute ICMP ICMP 208.148.96.52:na 64.212.9.100:na > ns1.bblabs.net 17:26 10-25 > IDS246/dos_dos-large-icmp ICMP 212.157.128.115:na 64.212.9.100:na > ns1.bblabs.net 17:26 10-25 > IDS171/icmp_ping zeros ICMP 139.95.253.3:na 64.212.9.100:na > ns1.bblabs.net 17:25 10-25 > IDS171/icmp_ping zeros ICMP 139.95.253.3:na 64.212.9.100:na > ns1.bblabs.net 17:25 10-25 > IDS171/icmp_ping zeros ICMP 139.95.253.3:na 64.212.9.100:na > ns1.bblabs.net 17:25 10-25 > IDS246/dos_dos-large-icmp ICMP 216.235.98.98:na 64.212.9.100:na > ns1.bblabs.net 17:25 10-25 > IDS171/icmp_ping zeros ICMP 139.95.253.3:na 64.212.9.100:na > ns1.bblabs.net 17:24 10-25 > IDS171/icmp_ping zeros ICMP 139.95.253.3:na 64.212.9.100:na > ns1.bblabs.net 17:24 10-25 > IDS171/icmp_ping zeros ICMP 139.95.253.3:na 64.212.9.100:na > ns1.bblabs.net 17:24 10-25 > IDS246/dos_dos-large-icmp ICMP 216.117.43.196:na 64.212.9.100:na > ns1.bblabs.net 17:24 10-25 > IDS246/dos_dos-large-icmp ICMP 216.206.190.125:na 64.212.9.100:na > ns1.bblabs.net 17:23 10-25 > IDS246/dos_dos-large-icmp ICMP 213.174.86.3:na 64.212.9.100:na > ns1.bblabs.net 17:22 10-25 > IDS246/dos_dos-large-icmp ICMP 208.174.0.131:na 64.212.9.100:na > ns1.bblabs.net 17:22 10-25 > IDS118/scan_Traceroute ICMP ICMP 216.200.14.119:na 64.212.9.100:na > ns1.bblabs.net 17:19 10-25 > IDS118/scan_Traceroute ICMP ICMP 216.32.118.78:na 64.212.9.100:na > ns1.bblabs.net 17:19 10-25 > IDS118/scan_Traceroute ICMP ICMP 207.46.144.74:na 64.212.9.100:na > ns1.bblabs.net 17:19 10-25 > IDS118/scan_Traceroute ICMP ICMP 208.148.96.52:na 64.212.9.100:na > ns1.bblabs.net 17:19 10-25 > IDS246/dos_dos-large-icmp ICMP 64.56.69.38:na 64.212.9.100:na > ns1.bblabs.net 17:19 10-25 > IDS246/dos_dos-large-icmp ICMP 213.174.86.3:na 64.212.9.100:na > ns1.bblabs.net 17:19 10-25 > IDS246/dos_dos-large-icmp ICMP 208.172.32.131:na 64.212.9.100:na > ns1.bblabs.net 17:18 10-25 > IDS246/dos_dos-large-icmp ICMP 200.52.171.211:na 64.212.9.100:na > ns1.bblabs.net 17:18 10-25 > IDS246/dos_dos-large-icmp ICMP 206.24.208.131:na 64.212.9.100:na > ns1.bblabs.net 17:18 10-25 > IDS246/dos_dos-large-icmp ICMP 216.44.45.4:na 64.212.9.100:na > ns1.bblabs.net 17:18 10-25 > IDS246/dos_dos-large-icmp ICMP 157.238.44.132:na 64.212.9.100:na > ns1.bblabs.net 17:14 10-25 > IDS246/dos_dos-large-icmp ICMP 148.122.172.38:na 64.212.9.100:na > ns1.bblabs.net 17:14 10-25 > IDS246/dos_dos-large-icmp ICMP 212.155.204.88:na 64.212.9.100:na > ns1.bblabs.net 17:13 10-25 > IDS246/dos_dos-large-icmp ICMP 209.240.197.84:na 64.212.9.100:na > ns1.bblabs.net 17:13 10-25 > IDS118/scan_Traceroute ICMP ICMP 64.242.62.92:na 64.212.9.100:na > ns1.bblabs.net 17:13 10-25 > IDS246/dos_dos-large-icmp ICMP 65.32.4.170:na 64.212.9.100:na > ns1.bblabs.net 17:13 10-25 > IDS118/scan_Traceroute ICMP ICMP 216.200.14.119:na 64.212.9.100:na > ns1.bblabs.net 17:10 10-25 > IDS118/scan_Traceroute ICMP ICMP 216.32.118.78:na 64.212.9.100:na > ns1.bblabs.net 17:10 10-25 > IDS118/scan_Traceroute ICMP ICMP 207.46.144.74:na 64.212.9.100:na > ns1.bblabs.net 17:10 10-25 > IDS118/scan_Traceroute ICMP ICMP 208.148.96.52:na 64.212.9.100:na > ns1.bblabs.net 17:10 10-25 > IDS246/dos_dos-large-icmp ICMP 209.240.77.196:na 64.212.9.100:na > ns1.bblabs.net 17:09 10-25 > IDS246/dos_dos-large-icmp ICMP 207.189.78.249:na 64.212.9.100:na > ns1.bblabs.net 17:08 10-25 > IDS246/dos_dos-large-icmp ICMP 167.216.150.53:na 64.212.9.100:na > ns1.bblabs.net 17:08 10-25 > IDS246/dos_dos-large-icmp ICMP 64.78.164.100:na 64.212.9.100:na > ns1.bblabs.net 17:07 10-25 > IDS118/scan_Traceroute ICMP ICMP 204.201.228.130:na 64.212.9.100:na > ns1.bblabs.net 17:06 10-25 > IDS171/icmp_ping zeros ICMP 163.181.249.3:na 64.212.9.100:na > ns1.bblabs.net 17:06 10-25 > IDS171/icmp_ping zeros ICMP 163.181.249.3:na 64.212.9.100:na > ns1.bblabs.net 17:06 10-25 > IDS171/icmp_ping zeros ICMP 163.181.249.3:na 64.212.9.100:na > ns1.bblabs.net 17:06 10-25 > IDS246/dos_dos-large-icmp ICMP 207.230.26.4:na 64.212.9.100:na > ns1.bblabs.net 17:05 10-25 > IDS246/dos_dos-large-icmp ICMP 216.206.179.5:na 64.212.9.100:na > ns1.bblabs.net 17:05 10-25 > IDS246/dos_dos-large-icmp ICMP 167.216.218.245:na 64.212.9.100:na > ns1.bblabs.net 17:04 10-25 > IDS246/dos_dos-large-icmp ICMP 167.216.216.117:na 64.212.9.100:na > ns1.bblabs.net 17:03 10-25 > IDS118/scan_Traceroute ICMP ICMP 198.31.3.44:na 64.212.9.100:na > ns1.bblabs.net 17:01 10-25 > IDS246/dos_dos-large-icmp ICMP 167.216.133.82:na 64.212.9.100:na > ns1.bblabs.net 16:59 10-25 > IDS118/scan_Traceroute ICMP ICMP 24.130.30.75:na 64.212.9.100:na > ns1.bblabs.net 16:58 10-25 > IDS246/dos_dos-large-icmp ICMP 64.232.139.108:na 64.212.9.100:na > ns1.bblabs.net 16:57 10-25 > IDS171/icmp_ping zeros ICMP 64.92.138.196:na 64.212.9.100:na > ns1.bblabs.net 16:57 10-25 > IDS171/icmp_ping zeros ICMP 64.92.138.196:na 64.212.9.100:na > ns1.bblabs.net 16:57 10-25 > IDS171/icmp_ping zeros ICMP 64.92.138.196:na 64.212.9.100:na > ns1.bblabs.net 16:57 10-25 > IDS246/dos_dos-large-icmp ICMP 64.78.164.100:na 64.212.9.100:na > ns1.bblabs.net 16:57 10-25 > -----Original Message----- > From: Sean Gleason [mailto:sgleason@digisle.net] > Sent: Thursday, October 25, 2001 4:44 PM > To: Christopher J. Wolff > Cc: noc-team(a)digisle.net > Subject: Re: FW: Getting hacked by Digital Isle? > > > > > Could you provide me an IP address so we can investigate further. > > Sean Gleason ---- Digital Island > > > > On Thu, 25 Oct 2001, Christopher J. Wolff wrote: > > > > > I just received a log from my IDS claiming the following attack is taking > > place from your network. If this is true what are you doing and why are > you > > ICMP flooding my primary name server. > > > > > > Log entry: > > > > mailto:abuse@digisle.com for questions > > This ICMP ECHO REQUEST/REPLY is part of the real-time network monitoring > > performed by Digital Island Inc. It is not an attack. If you have > > questions please contact > > > abuse(a)digisle.com........................................................... > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > ............................................... > > > > > > Regards, > > Christopher J. Wolff, VP, CIO > > Broadband Laboratories, Inc. > > http://www.bblabs.com > > email:chris@bblabs.com > > phone:520.622.4338 x234 > > > > > > >

16 18

RE: Digital Island sponsors DoS attempt?
by Quibell, Marc 27 Oct '01

27 Oct '01

I don't believe I have it backwards, since RFC1191, the one you quoted, states: "A host doing PMTU Discovery must obey the rule that it not send IP datagrams larger than 576 octets unless it has permission from the receiver." So really, unless it get's permission to send larger packets from the receiver, it'll send them at less than 576 bytes. I imagine this'll all change though whenever IPv6 comes about since the min. MTU size will be (approx.) 1200. As another poster stated, IPv6 requires PMTU, so this could become a nasty little problem. Thanks for the rest of the info on the HOW as I am not quite sure either and your scenarios make sense.. Marc -----Original Message----- From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Friday, October 26, 2001 1:46 PM To: Quibell, Marc Cc: nanog(a)merit.edu Subject: Re: Digital Island sponsors DoS attempt? On Fri, 26 Oct 2001 13:19:51 CDT, "Quibell, Marc" said: > path. Nobody I know, nor have I ever had a problem with "PMTU" and shutting > off ICMP routing. And no I do not believe it is used across the internet, Some of us *have* seen it. > and if it does, it is probably hindering performance since it's probably > using a lower mtu than is allowed, such as 576 or smaller. It would also > have problems running across multi-level routing hierarchies. You have this backwards. RFC791, section 2.1, says: impractical for most hosts and networks. All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments). It is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is prepared to accept the larger datagrams. The number 576 is selected to allow a reasonable sized data block to be transmitted in addition to the required header information. For example, this size allows a data block of 512 octets plus 64 header octets to fit in a datagram. The maximal internet header is 60 octets, and a typical internet header is 20 octets, allowing a margin for headers of higher level protocols. So if you're on a LAN that the MTU is 1500, you can be reasonably sure that the other end can catch 1500 byte packets. If you're *leaving* the subnet, you have only send 576-byte packets unless you have reason to believe you can send bigger (PMTU discovery). Some sites just blindly send 1500 bytes anyhow, and *hope* that things get fragmented - but *THAT* behavior is actually against-standard. So the two most prevalent ways to cut the number of packets by 65% or so are to use PMTUd, or to blindly throw 1500 and hope it works..... > Finally, I do not believe PMTU uses pings to discover the PMTU. I believe it > uses TCP or UDP packets at the layers above IP, and it DOES use "ICMP Packet RFC1191 is silent on HOW to do it. IBM specifically chose to use ICMP ECHO to test, rather than the TCP packets, so that PMTU discovery could be done *before* it might actually be needed (since many TCP applications such as SMTP and HTTP don't send a full MTU-sized packet right off the bat because the first few packets are doing negotiation - if you can do PMTU discovery in parallel with that, it can be a win - if you hit a 'frag needed' only after several packets, you get to flush the slow-start timers, retransmit, and a lot of other ugliness.... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech

2 1

Better than ping
by Kevin Loch 26 Oct '01

26 Oct '01

Aside from the silliness of "can I ping you?", someone did make the valuable observation that ping might not be the best way to measure content delivery performance. A better way would be to measure the actual delivery performance by noting the size and delivery time for an actual bonafide request. The traffic directing system could default to random source servers (perhaps with coarse regional constraints) until enough data is gathered to guide future server decisions. As more client requests are received, occasional testing with other source servers could be done to ensure best server selection. A significant drop in throughput could also trigger some re-testing. An additional benefit would be a reasonable guess as to the bandwidth of the end user (dialup, broadband, etc). I see that Apache already has an optional custom-log attribute for transfer time in integer seconds (%T). It would be trivial to modify that to give milliseconds. If you could get this to work right it would be completely non-invasive and should produce better overall results. KL

2 1

Union: 'Close the Facility'
by redhead＠freebsd.redbird.com 26 Oct '01

26 Oct '01

Greetings from 1010wins.com! Reid Fishler recommends you check out this story from 1010 WINS: Union: 'Close the Facility' http://1010wins.com/StoryFolder/story_1648051444_html

2 1