How to turn off [PSH]

Kernel
1

hello world

I’m Trying to window TCP communication
But [PSH] is in the way

Is there a way to turn this [PSH] off?

wire shark
wire shark1567×349 90 KB

2

Why do you want that? What problem are you trying to solve?

Which TCP stack are you using? Which of 192.168.101.100 and 192.168.101.201 is your device?

3

thank you for your reply

My device is 192.168.101.201.

Commercially available devices add [PSH] only to the last data when sending data of 1460bytes or more, but my device adds [PSH] to all data.

DMM wire shark Data
DMM wire shark Data1084×202 52.4 KB

In other words, it cannot be said that it is normal for all data to have [PSH] attached.

4

I don’t know if it’s because of this [PSH], but my device sometimes returns [ACK] between split data.

RA wire shark Data
RA wire shark Data988×154 38.1 KB

Because of this [ACK], the communication time is unstable and I’m in trouble.
Therefore, I would like to remove [PSH] so that [ACK] is not returned in the middle of the data.

5

Hi @S.FUKAYA

Can you please let us know which TCP stack you are using to check it further?

6

This may be related to the peer’s advertised small window size (513).

7

thank you for contacting

I am using [FreeRTOS + TCP]
The stack size when creating a socket is set to (100)*5=(500) in the config.

Please let me know if you need any other information !

8

Thank you for your comment.

I’m concerned about the window size (513).
This is because the end of the 3-way handshake as seen in Wireshark is the window size (513).

However, the same (513) was displayed during the 3way handshake even with a ready-made digital multimeter.
It is strange that [PSH] disappears in off-the-shelf products.

Is there a way to increase this (513)?

9

From what I can tell, the 513 are advertised from the peer, so that is something you can not influence. What network software does the peer execute?

Can you share the full 3 way handshake when the connection is established? In partcular, what are the MTU Options negotiated?

10

The peer will be Windows 10 64-bit. Connected via Ethernet.

I wanted to share some Wireshark data, but it seems that new users cannot upload files. sorry
(´; ω ;｀)

I don’t know what MTU option is negotiated
The capacity remains at 1500. I am not consciously touching

11

Please show us the three full wireshark packets that contain the TCP connection establishment (SYN/ACK/SYN-ACK)

12

I can’t attach data, so I will send it as an image.
I can’t send the image without dividing it, so I will send it 3 times
(1/3)

【１】SYN
【１】SYN1366×728 240 KB

13

(2/3)

【２】SYN-ACK
【２】SYN-ACK1366×728 247 KB

14

（3/3）thank you for being so kind

【３】ACK
【３】ACK1366×728 220 KB

15

Almost there. Please unfold the “option bytes” in the first two packets. It is almost at the end of each packet.

16

You should now be able to upload data.

17

thank you. very helpful！！

3 way handshake.zip (702 Bytes)

18

Sorry, from this location I can not open pcap files, please add the screenshots as requested (too tedious to decode the bit stream manually), thanks. if need be use pm

19

It’s okay no problem
How about this?

SYN_Options
SYN_Options1366×728 174 KB

SYN-ACK_Options
SYN-ACK_Options1366×728 179 KB

20

This looks unsuspicious to me. The thing that puzzles me is the shrinking of the peer’s window. Normally that happens when the peer APPLICATION does not flush its input buffer in time. What is the application running on your Windows peer? I believe we had a similar issue a few weeks ago where replacing a Phyton based client with another one on the peer solved the issue. From superficial glance it looks as if the problem is on the peer’s side, not FreeRTOS.