Timeout occurring quite regularly

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

sugar76
9 ●3 ●5 ●8

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: https://1drv.ms/u/s!AphLkdj_V9pOqAE6W...

Server trace: https://1drv.ms/u/s!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

Comments

You could use TraceWrangler to mask or remove sensitive data.

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

I anonymized traces using TraceWrangler and updated the issue.

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

add a comment

2 Answers

Sort by » oldest newest most voted

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

André

176 ●63 ●3

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

add a comment

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

grahamb

flag of United Kingdom of Great Britain and Northern Ireland

23790 ●4 ●950 ●227 https://www.wireshark.org

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

Comments

I attached traces from both ends now.

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

add a comment

Your Answer

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

Add Answer

Timeout occurring quite regularly

Comments

2 Answers

Comments

Your Answer

Question Tools

Stats

Related questions

Timeout occurring quite regularly edit

Comments

2 Answers

Comments

Your Answer

Question Tools

Stats

Related questions

Timeout occurring quite regularly