Subject | Connection lost/terminated. |
---|---|
Author | Aage Johansen |
Post date | 2008-11-01T23:21:11Z |
First: sorry for a looooong report!
I don't even know if this is the best group to post in - maybe the
IBO group more relevant?
Or, maybe this is stuff for the developers?
We are using Firebird 1.5 SS on Windows, client application written
in Delphi with IBO.
Problem:
Clients is disconnected (connection is "lost").
I've no idea whether this is a Firebird problem, a firewall problem,
or something else.
The network people did some tracing to see what was going on - see
traces below.
The Firewalls are Juniper, and the trace program is called WireShark (I think).
I hope the trace is of use (it's way beyond my knowledge).
The problem with "lost connection" was observed during the trace.
Any hint toward solving the problem is appreciated.
Remark:
I thought that the only port used would be 3050, but it looks like
some other port is used as well. In the trace below port 1887 seems
to be in use for something (in the second trace port 2225 is in
use). I don't know if this is of any importance, though.
The last part of a trace (after which the client had no connection)
+++++++++++++++++++++++++++++++++
No. Time Source Destination Protocol Info
5091 7773.355929 192.168.152.225 192.168.210.9 GDS
DB Commit
Frame 5091 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: 00:ff:a8:77:c9:81 (00:ff:a8:77:c9:81), Dst:
00:ff:ab:77:c9:81 (00:ff:ab:77:c9:81)
Internet Protocol, Src: 192.168.152.225 (192.168.152.225), Dst:
192.168.210.9 (192.168.210.9)
Transmission Control Protocol, Src Port: filex-lport (1887), Dst
Port: gds_db (3050), Seq: 5921, Ack: 5817, Len: 8
Source port: filex-lport (1887)
Destination port: gds_db (3050)
Sequence number: 5921 (relative sequence number)
[Next sequence number: 5929 (relative sequence number)]
Acknowledgement number: 5817 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Window size: 64720
Checksum: 0x022c [correct]
Firebird SQL Database Remote Protocol
Opcode: Commit (30)
No. Time Source Destination Protocol Info
5092 7773.357255 192.168.210.9 192.168.152.225 GDS
DB Response
Frame 5092 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:ff:a9:77:c9:81 (00:ff:a9:77:c9:81), Dst:
00:ff:a8:77:c9:81 (00:ff:a8:77:c9:81)
Internet Protocol, Src: 192.168.210.9 (192.168.210.9), Dst:
192.168.152.225 (192.168.152.225)
Transmission Control Protocol, Src Port: gds_db (3050), Dst Port:
filex-lport (1887), Seq: 5817, Ack: 5929, Len: 32
Source port: gds_db (3050)
Destination port: filex-lport (1887)
Sequence number: 5817 (relative sequence number)
[Next sequence number: 5849 (relative sequence number)]
Acknowledgement number: 5929 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Window size: 64699
Checksum: 0x023b [correct]
[SEQ/ACK analysis]
Firebird SQL Database Remote Protocol
Opcode: Response (9)
Response object: 0x00000000
Blob ID: 0x0000000000000000
Data:
Status vector
No. Time Source Destination Protocol Info
5093 7773.480817
192.168.152.225 192.168.210.9 TCP filex-lport >
gds_db [ACK] Seq=5929 Ack=5849 Win=64688 Len=0
Frame 5093 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: 00:ff:a8:77:c9:81 (00:ff:a8:77:c9:81), Dst:
00:ff:ab:77:c9:81 (00:ff:ab:77:c9:81)
Internet Protocol, Src: 192.168.152.225 (192.168.152.225), Dst:
192.168.210.9 (192.168.210.9)
Transmission Control Protocol, Src Port: filex-lport (1887), Dst
Port: gds_db (3050), Seq: 5929, Ack: 5849, Len: 0
Source port: filex-lport (1887)
Destination port: gds_db (3050)
Sequence number: 5929 (relative sequence number)
Acknowledgement number: 5849 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
Window size: 64688
Checksum: 0x0258 [correct]
[SEQ/ACK analysis]
+++++++++++++++++++++++++++++++++
=> After this there were no more responses from the server.
In another trace we saw messages with "malformed packet":
+++++++++++++++++++++++++++++++++
No. Time Source Destination Protocol Info
4 0.010741 192.168.210.9 192.168.152.225 GDS
DB Response[Malformed Packet]
Frame 4 (1414 bytes on wire, 1414 bytes captured)
Ethernet II, Src: 00:ff:a9:77:c9:81 (00:ff:a9:77:c9:81), Dst:
00:ff:a8:77:c9:81 (00:ff:a8:77:c9:81)
Internet Protocol, Src: 192.168.210.9 (192.168.210.9), Dst:
192.168.152.225 (192.168.152.225)
Transmission Control Protocol, Src Port: gds_db (3050), Dst Port:
rcip-itu (2225), Seq: 33, Ack: 413, Len: 1360
Source port: gds_db (3050)
Destination port: rcip-itu (2225)
Sequence number: 33 (relative sequence number)
[Next sequence number: 1393 (relative sequence number)]
Acknowledgement number: 413 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
Window size: 64283
Checksum: 0x4a50 [correct]
[SEQ/ACK analysis]
Firebird SQL Database Remote Protocol
Opcode: Response (9)
Response object: 0x00000000
Blob ID: 0x0000000000000000
[Malformed Packet: FB/IB GDS DB]
+++++++++++++++++++++++++++++++++
Here the "other port" is 2225!
No adverse effect on the client or communication AFAIK.
Longer traces can be provided should anyone be interested...
If more (or something else) is needed, don't hesitate to ask(!) -
I'll activate the network guys.
If it is a firewall problem, I would nevertheless like a comment on
the port numbers (1887 and 2225) and the "Malformed Packet" bit. If possible.
TiA
Aage J.
I don't even know if this is the best group to post in - maybe the
IBO group more relevant?
Or, maybe this is stuff for the developers?
We are using Firebird 1.5 SS on Windows, client application written
in Delphi with IBO.
Problem:
Clients is disconnected (connection is "lost").
I've no idea whether this is a Firebird problem, a firewall problem,
or something else.
The network people did some tracing to see what was going on - see
traces below.
The Firewalls are Juniper, and the trace program is called WireShark (I think).
I hope the trace is of use (it's way beyond my knowledge).
The problem with "lost connection" was observed during the trace.
Any hint toward solving the problem is appreciated.
Remark:
I thought that the only port used would be 3050, but it looks like
some other port is used as well. In the trace below port 1887 seems
to be in use for something (in the second trace port 2225 is in
use). I don't know if this is of any importance, though.
The last part of a trace (after which the client had no connection)
+++++++++++++++++++++++++++++++++
No. Time Source Destination Protocol Info
5091 7773.355929 192.168.152.225 192.168.210.9 GDS
DB Commit
Frame 5091 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: 00:ff:a8:77:c9:81 (00:ff:a8:77:c9:81), Dst:
00:ff:ab:77:c9:81 (00:ff:ab:77:c9:81)
Internet Protocol, Src: 192.168.152.225 (192.168.152.225), Dst:
192.168.210.9 (192.168.210.9)
Transmission Control Protocol, Src Port: filex-lport (1887), Dst
Port: gds_db (3050), Seq: 5921, Ack: 5817, Len: 8
Source port: filex-lport (1887)
Destination port: gds_db (3050)
Sequence number: 5921 (relative sequence number)
[Next sequence number: 5929 (relative sequence number)]
Acknowledgement number: 5817 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Window size: 64720
Checksum: 0x022c [correct]
Firebird SQL Database Remote Protocol
Opcode: Commit (30)
No. Time Source Destination Protocol Info
5092 7773.357255 192.168.210.9 192.168.152.225 GDS
DB Response
Frame 5092 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: 00:ff:a9:77:c9:81 (00:ff:a9:77:c9:81), Dst:
00:ff:a8:77:c9:81 (00:ff:a8:77:c9:81)
Internet Protocol, Src: 192.168.210.9 (192.168.210.9), Dst:
192.168.152.225 (192.168.152.225)
Transmission Control Protocol, Src Port: gds_db (3050), Dst Port:
filex-lport (1887), Seq: 5817, Ack: 5929, Len: 32
Source port: gds_db (3050)
Destination port: filex-lport (1887)
Sequence number: 5817 (relative sequence number)
[Next sequence number: 5849 (relative sequence number)]
Acknowledgement number: 5929 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Window size: 64699
Checksum: 0x023b [correct]
[SEQ/ACK analysis]
Firebird SQL Database Remote Protocol
Opcode: Response (9)
Response object: 0x00000000
Blob ID: 0x0000000000000000
Data:
Status vector
No. Time Source Destination Protocol Info
5093 7773.480817
192.168.152.225 192.168.210.9 TCP filex-lport >
gds_db [ACK] Seq=5929 Ack=5849 Win=64688 Len=0
Frame 5093 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: 00:ff:a8:77:c9:81 (00:ff:a8:77:c9:81), Dst:
00:ff:ab:77:c9:81 (00:ff:ab:77:c9:81)
Internet Protocol, Src: 192.168.152.225 (192.168.152.225), Dst:
192.168.210.9 (192.168.210.9)
Transmission Control Protocol, Src Port: filex-lport (1887), Dst
Port: gds_db (3050), Seq: 5929, Ack: 5849, Len: 0
Source port: filex-lport (1887)
Destination port: gds_db (3050)
Sequence number: 5929 (relative sequence number)
Acknowledgement number: 5849 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
Window size: 64688
Checksum: 0x0258 [correct]
[SEQ/ACK analysis]
+++++++++++++++++++++++++++++++++
=> After this there were no more responses from the server.
In another trace we saw messages with "malformed packet":
+++++++++++++++++++++++++++++++++
No. Time Source Destination Protocol Info
4 0.010741 192.168.210.9 192.168.152.225 GDS
DB Response[Malformed Packet]
Frame 4 (1414 bytes on wire, 1414 bytes captured)
Ethernet II, Src: 00:ff:a9:77:c9:81 (00:ff:a9:77:c9:81), Dst:
00:ff:a8:77:c9:81 (00:ff:a8:77:c9:81)
Internet Protocol, Src: 192.168.210.9 (192.168.210.9), Dst:
192.168.152.225 (192.168.152.225)
Transmission Control Protocol, Src Port: gds_db (3050), Dst Port:
rcip-itu (2225), Seq: 33, Ack: 413, Len: 1360
Source port: gds_db (3050)
Destination port: rcip-itu (2225)
Sequence number: 33 (relative sequence number)
[Next sequence number: 1393 (relative sequence number)]
Acknowledgement number: 413 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
Window size: 64283
Checksum: 0x4a50 [correct]
[SEQ/ACK analysis]
Firebird SQL Database Remote Protocol
Opcode: Response (9)
Response object: 0x00000000
Blob ID: 0x0000000000000000
[Malformed Packet: FB/IB GDS DB]
+++++++++++++++++++++++++++++++++
Here the "other port" is 2225!
No adverse effect on the client or communication AFAIK.
Longer traces can be provided should anyone be interested...
If more (or something else) is needed, don't hesitate to ask(!) -
I'll activate the network guys.
If it is a firewall problem, I would nevertheless like a comment on
the port numbers (1887 and 2225) and the "Malformed Packet" bit. If possible.
TiA
Aage J.