Ask Your Question

Timeout occurring quite regularly

asked 2022-03-29 14:27:52 +0000

sugar76 gravatar image

updated 2022-04-03 07:22:03 +0000

I have a small network with a local database server (PostgreSQL) and 6 clients. It's all Windows.

Several times per day a timeout occurs when one of the clients sends SQL Queries to the server.

E.g. the client reports a 2022-04-01 15:24:06,959. tshark is running constantly on both ends and I looked for packets at about 15:23:51 (timeout is 15 seconds).

In the trace I see that the corresponding SQL query is not sent out to the server at 15:23:51.

The clients ip address is fe80::d9db:dcdf:58d3:2d03, the server's ip address is fe80::804b:e959:60b:e90b.

Client trace:!AphLkdj_V9pOqAE6W...

Server trace:!AphLkdj_V9pOqAB-R...

My question is: does the trace show any hints why the server's response does not reach the client? Is it maybe a DNS issue?

EDIT: The traces are anonymized using TraceWrangler. Therefore no PGSQL queries are included in the trace and the DNS queries are cut down to UDP packets.

edit retag flag offensive close merge delete


You could use TraceWrangler to mask or remove sensitive data.

André gravatar imageAndré ( 2022-03-30 15:54:24 +0000 )edit

I anonymized traces using TraceWrangler and updated the issue.

sugar76 gravatar imagesugar76 ( 2022-04-03 07:20:29 +0000 )edit

2 Answers

Sort by » oldest newest most voted

answered 2022-04-07 18:57:15 +0000

André gravatar image

The client capture contains ICMPv6 "Packet Too Big" frames (filter: icmpv6.type == 2) containing "MTU: 1492". The server side does not.

So the maximum MTU in the network path is 1492 bytes. The value 1492 suggests that there is a VPN or tunnel in between. PPPoE maybe?

The TCP-SYN from the client shows a MSS of 1440. Thus MTU = 1440 + 40 (IPv6) + 20 (TCP) = 1500 bytes.

So a transmission fails when full packets are send (no fragmentation for IPv6 possible), like a large query. Small queries will pass.

Quick fix: lower the MTU of the client. Better fix the MTU in the network path.

edit flag offensive delete link more

answered 2022-03-29 19:53:28 +0000

grahamb gravatar image

In general cases such as this, you would need to capture at both ends of the link and possibly at intermediate points to determine where packets go missing.

edit flag offensive delete link more


I attached traces from both ends now.

sugar76 gravatar imagesugar76 ( 2022-04-03 07:20:53 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2022-03-29 14:26:12 +0000

Seen: 577 times

Last updated: Apr 07 '22