| User's Guide |
6. Troubleshooting and Technical Information
6.2. Format of NetProxy Log Files
The addition of new functionality in NetProxy 3.0 has necessitated a number of changes to the log file format from that used in NetProxy 2.0. The most far-reaching of these is the decision to record dates in standard CERN httpd log format - this particular change affects all log entries, but adds the ability to correctly indicate timezone changes (such as the twice-yearly change to and from daylight savings time that happens in most countries).
The full specification of the log file format, with notes for those porting scripts from version 2.0 is as follows:-
File
names
Log files are placed in the directory of your choice (as defined
in NPConfig) and are named "yyyymmdd.log" (e.g.
"19980610.log"). They are auto-rotated at midnight each
night.
DIALUP
Log entries now have their date recorded in CERN-httpd log format
(dd/mmm/yyyy:hh:mm:ss [+|-]hhmm). In addition, the IP address of
the machine that initiated the dialup session is recorded if
available.
| NetProxy 2.0 Format | NetProxy 3.0 Format |
| DIALUP [31 Aug 1997 12:09:48] | DIALUP 192.168.0.12 [06/Jun/1998:13:28:52 +0100] |
HANGUP
Log entries now have their date recorded in CERN httpd log
format. In addition, the disconnection cause is recorded if
known.
| HANGUP [31 Aug 1997 14:23:04] | HANGUP [02/Jun/1998:19:44:13 +0100] 000-Normal disconnect. Idle Timeout |
Some of the more commonly-occurring disconnect causes include:-
000-Normal
disconnect. Idle Timeout
601-Invalid port handle
602-Port already open
629-The port was disconnected by the remote machine
631-The port was disconnected by the user
676-Line busy
677-Voice answer
678-No answer
679-No carrier
680-No dialtone
691-Access denied because username and/or password is incorrect
718-Timed out waiting for a valid PPP response from server
DNS
Unchanged from v2.0, other than timestamp format.
DNS 192.168.0.1:1815 [01 Sep 1997 14:19:16]
The IP address and port number of the requesting host (separated by a colon) appear in the second column.
TELNET
Unchanged from v2.0, other than timestamp format.
TELNET
127.0.0.1:3326 [31 Aug 1997 12:10:25] "finger
status@gate.demon.co.uk"
TELNET 127.0.0.1:3326 [31 Aug 1997 12:10:49] "open
pop3.demon.co.uk 110"
The IP address and port number of the requesting host (separated by a colon) appear in the second column.
The time of the request appears in square brackets and represents the system time on the NetProxy PC at the time the request was initiated.
The final column, contained within quote characters describes the operation requested. Finger requests are logged in the form "finger user@remotehost", Telnet sessions are logged in the form "open remotehost portnum". If no port number appears, the default telnet port (port 23) can be assumed.
FTP
Unchanged from v2.0, other than timestamp format.
FTP 192.168.0.1:2853 [02 Sep 1997 11:48:58] anonymous@src.doc.ic.ac.uk
The IP address and port number of the requesting host (separated by a colon) appear in the second column.
The time of the request appears in square brackets and represents the system time on the NetProxy PC at the time the request was initiated.
The final column identifies the FTP username and the name of the remote FTP server.
HTTP
This has changed significantly in order to allow for the
performance of the cache to be recorded, and to more closely
mimic the standard CERN httpd log format.
HTTP 195.153.161.131:1066 [09/Jun/1998:07:08:59 +0100] "GET http://www.knowledge.com/index.html HTTP/1.0" 200 1539
Which can be broken down as follows:-
HTTP requestingIPaddress:TCPport [standard date] "Full HTTP request" ResultCode BytesTransferred
Apart from the new date format, everything up to and including the "Full HTTP request" is the same as a NetProxy 2.0 log file. There are two new fields at the end of the line; ResultCode is a three digit code that can be one of the following:-
| ResultCode | Meaning |
| 200 | OK |
| 203 | Resource was served from local cache (i.e. a successful cache hit) |
| 304 | Not Modified. The browser made a Get page if modified since request and the requested resource had not been modified. |
| 404 | Resource not found or an error occurred during transfer. |
The BytesTransferred field is recorded as follows:-
For a "200" result, this usually shows the number of bytes of the document body excluding any HTTP header information. This may be less than the total document size if the transfer is interrupted partway through.
For a "203" result, this shows the number of bytes of the entire document, including the HTTP header that were transferred. This may be less than the total document size if the transfer is interrupted partway through.
For "304" and "404" results, this field is not relevant and contains just a single hyphen.
SOCKS4
Barring the date format, this is the same as for NetProxy 2.0
except that the SOCKS username is added to the end of the
request:-
| NetProxy 2.0 Format | NetProxy 3.0 Format |
| SOCKS4 192.168.0.2:3124 [31 Aug 1997 12:09:48] 158.152.1.65:79 | SOCKS4 192.168.0.2:3124 [31/Aug/1997:12:09:48 +0100] 158.152.1.65:79 fred |
If no username was specified, the field contains a single hyphen character ( - ).
SOCKS5
This is a new entry that indicates SOCKS v5.0 traffic. The format
is exacly the same as the SOCKS4 entry, apart from the fact the
text "UDP" may appear at the end of the line to
indicate an UDP port association rather than a mapped TCP port.
SOCKS5 192.168.0.2:3124 [31/Aug/1997:12:09:48 +0100] 158.152.1.65:79 fred UDP
DHCP
This is another new entry that describes DHCP (Dynamic Host
Configuration Protocol) activity. There are three sub-types,
DISCOVER, REQUEST, and RELEASE, defined as follows:-
DHCP DISCOVER - The client with the specified ethernet MAC address has broadcast a DHCP DISCOVER message to all DHCP servers on it's local network. The IP address offered by NetProxy in response to this is recorded at the end of the log entry.
DHCP REQUEST - The client with the specified ethernet MAC address has requested to use the IP address offered by NetProxy. If NetProxy authorises this use the log entry end with "Offered IP: a.b.c.d", otherwise it ends "Declined IP: a.b.c.d".
DHCP RELEASE - The client with the specified ethernet MAC address has released it's allocated IP address. The released IP address appears at the end of the log entry.
DHCP
DISCOVER 00:40:95:04:C3:0A [10/Jun/1998:17:36:19 +0100] Offered
IP: 192.168.0.2
DHCP REQUEST 00:40:95:04:C3:0A [10/Jun/1998:17:36:19 +0100]
Offered IP: 192.168.0.2
DHCP REQUEST 00:40:95:04:C3:0A [10/Jun/1998:16:43:52 +0100]
Declined IP: 10.1.1.2
DHCP RELEASE 00:40:95:04:C3:0A [10/Jun/1998:17:43:22 +0100]
Released IP: 192.168.0.2
BLOCKED
The blocked entry has been enhanced to provide more information
about unauthorised attempts to use NetProxy. The new format looks
like this:-
BLOCKED
10.1.1.2 [10/Jun/1998:17:36:19 +0100] INCOMING TO HTTP
BLOCKED 192.168.37.12 [10/Jun/1998:17:36:19 +0100] INCOMING TO
TELNET
BLOCKED 192.168.0.14:3201 [10/Jun/1998:17:36:19 +0100] OUTGOING
TO 158.152.1.65 (TELNET)
BLOCKED 192.168.0.23:1198 [10/Jun/1998:17:36:19 +0100] OUTGOING
TO 194.159.255.135 (FTP)
Connections blocked at the incoming stage have the connecting host's IP address logged, along with the name of the NetProxy service that the connecting host attempted to use in brackets.
Connections blocked at the outgoing stage have the connecting host's IP address and port number logged, along with the IP address of the destination host and the name of the NetProxy service being used in brackets.