Aage Johansen pisze:

>
>
> 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.
>

How often you have this problem ? How much time it works properly before
disconnecting ? What users are doing in meantime (maybe they go away
from computer ? ) ?
Do you have any "heart beat" function checking server response
periodically ?


Regards
Boguslaw