commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Himsley <m...@mdsh.com>
Subject commons/net whois fails with whois.opensrs.net
Date Mon, 28 Jul 2003 12:52:14 GMT
Hi,

Please excuse this long email: I have searched bugzilla and the 
commons-user and commons-dev email lists on jakarta.apache.org.

I've just replaced a really simple whois search with that from commons/net 
and I'm having some problems.

The code is running from within Tomcat 4.1.17 on:

$ java -server -version
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Server VM (build 1.4.1_01-b01, mixed mode)

$ uname -a
Linux kweb1 2.4.18-19.7.x #1 Thu Dec 12 07:58:06 EST 2002 i586 unknown

My simple search worked by just creating a socket to connect to the 
destination host, printing the domain to search for followed by a "\r\n" 
and reading all the lines sent back in response.

------------------------ CUT ------------------------
    public String getWhois () {

        StringBuffer result = new StringBuffer();

        try {
            final Socket          s = new Socket (host, port);
            final PrintWriter    pw = new PrintWriter (s.getOutputStream());
            final BufferedReader in = new BufferedReader (
                                new InputStreamReader (s.getInputStream()));

            pw.print(domain);
            pw.print("\r\n");
            pw.flush();

            for (;;) {
                final String line = in.readLine();
                if (line==null) break;
                result.append(line);
                result.append("\r\n");
            }

            s.close();
        }
        catch (IOException e) {
			String error = "Error I/O exception: " + e.getMessage();
			System.err.println(error);
			result.append(error);
        }
        return(result.toString());
    }
------------------------ CUT ------------------------

This has been replaced by the following much more elegant version:

------------------------ CUT ------------------------
    public String getWhois () {

		WhoisClient whois = new WhoisClient();
		StringBuffer result = new StringBuffer();

		try {
			whois.connect(host, port);
			result.append(whois.query(domain));
			whois.disconnect();
		}
		catch (IOException e) {
			String error = "Error I/O exception: " + e.getMessage();
			System.err.println(error);
			result.append(error);
		}
		
		return (result.toString());
	}
------------------------ CUT ------------------------

To my simple eyes I would expect these to function basically the same, but 
looking at a snort trace of the actual packets sent there is a fundamental 
difference.

My version does the usual three stage TCP handshake, sends the domain in 
one packet and gets the response in one or more packets.

The replaced version does the same usual TCP handshake but then sends the 
first character of the domain in a single packet with the TCP 'PSH' flag 
and then sends the rest of the domain in another packet, also with the TCP 
'PSH' flag.

The problem is that it appears that the whois server at whois.opensrs.net 
does not wait for the EOL "\r\n" string before replying. The whois server 
application must see the first character, because of the 'PSH' flag, and 
then replies saying that there is no match for the first character.

Here is a complete snort of that failing whois lookup.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

07/27-18:15:40.669548 62.49.203.75:37420 -> 216.40.33.170:43
TCP TTL:63 TOS:0x0 ID:21483 IpLen:20 DgmLen:60 DF
******S* Seq: 0xC7E661A6  Ack: 0x0  Win: 0x16D0  TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 657928781 0 NOP WS: 0

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

07/27-18:15:40.809558 216.40.33.170:43 -> 62.49.203.75:37420
TCP TTL:41 TOS:0x60 ID:5161 IpLen:20 DgmLen:60 DF
***A**S* Seq: 0xC739A4CA  Ack: 0xC7E661A7  Win: 0x7D78  TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 2755865110 657928781 NOP WS: 0

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

07/27-18:15:40.809558 62.49.203.75:37420 -> 216.40.33.170:43
TCP TTL:63 TOS:0x0 ID:21484 IpLen:20 DgmLen:52 DF
***A**** Seq: 0xC7E661A7  Ack: 0xC739A4CB  Win: 0x16D0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 657928795 2755865110

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

07/27-18:15:40.819559 62.49.203.75:37420 -> 216.40.33.170:43
TCP TTL:63 TOS:0x0 ID:21485 IpLen:20 DgmLen:53 DF
***AP*** Seq: 0xC7E661A7  Ack: 0xC739A4CB  Win: 0x16D0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 657928796 2755865110
6D                                               m

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

07/27-18:15:40.959569 216.40.33.170:43 -> 62.49.203.75:37420
TCP TTL:41 TOS:0x60 ID:5162 IpLen:20 DgmLen:52 DF
***A**** Seq: 0xC739A4CB  Ack: 0xC7E661A8  Win: 0x7D78  TcpLen: 32
TCP Options (3) => NOP NOP TS: 2755865125 657928796

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

07/27-18:15:40.959569 62.49.203.75:37420 -> 216.40.33.170:43
TCP TTL:63 TOS:0x0 ID:21486 IpLen:20 DgmLen:61 DF
***AP*** Seq: 0xC7E661A8  Ack: 0xC739A4CB  Win: 0x16D0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 657928810 2755865125
64 73 68 2E 63 6F 6D 0D 0A                       dsh.com..

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

07/27-18:15:40.959569 216.40.33.170:43 -> 62.49.203.75:37420
TCP TTL:41 TOS:0x60 ID:5164 IpLen:20 DgmLen:68 DF
***AP*** Seq: 0xC739A4CB  Ack: 0xC7E661A8  Win: 0x7D78  TcpLen: 32
TCP Options (3) => NOP NOP TS: 2755865125 657928796
20 4E 6F 20 6D 61 74 63 68 20 66 6F 72 20 4D 0A   No match for M.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

07/27-18:15:40.969570 62.49.203.75:37420 -> 216.40.33.170:43
TCP TTL:63 TOS:0x0 ID:21487 IpLen:20 DgmLen:52 DF
***A**** Seq: 0xC7E661B1  Ack: 0xC739A4DB  Win: 0x16D0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 657928811 2755865125

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

07/27-18:15:40.969570 216.40.33.170:43 -> 62.49.203.75:37420
TCP TTL:41 TOS:0x60 ID:5165 IpLen:20 DgmLen:52 DF
***A***F Seq: 0xC739A4DB  Ack: 0xC7E661A8  Win: 0x7D78  TcpLen: 32
TCP Options (3) => NOP NOP TS: 2755865126 657928796

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

07/27-18:15:40.969570 62.49.203.75:37420 -> 216.40.33.170:43
TCP TTL:63 TOS:0x0 ID:21488 IpLen:20 DgmLen:52 DF
***A***F Seq: 0xC7E661B1  Ack: 0xC739A4DC  Win: 0x16D0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 657928811 2755865126

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

07/27-18:15:41.099579 216.40.33.170:43 -> 62.49.203.75:37420
TCP TTL:232 TOS:0x60 ID:5166 IpLen:20 DgmLen:40
*****R** Seq: 0xC739A4CB  Ack: 0x0  Win: 0x0  TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

07/27-18:15:41.109580 216.40.33.170:43 -> 62.49.203.75:37420
TCP TTL:232 TOS:0x60 ID:5167 IpLen:20 DgmLen:40
*****R** Seq: 0xC739A4DB  Ack: 0x0  Win: 0x0  TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

07/27-18:15:41.109580 216.40.33.170:43 -> 62.49.203.75:37420
TCP TTL:232 TOS:0x60 ID:5168 IpLen:20 DgmLen:40
*****R** Seq: 0xC739A4DC  Ack: 0x0  Win: 0x0  TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

My basic question is: how do I stop commons/net from setting the TCP push 
flag on the socket connection.

I've looked through the source of WhoisClient, FingerClient, SocketClient, 
SocketFactory, DefaultSocketFactory and as yet don't have a clue why the 
push flag is set ant the query is fragmented.

Thanks very much in advance.

-- 
Mark Himsley

Mime
View raw message