Allow for a connection to check if it's sending bytes #324

PeterZhizhin · 2024-11-10T00:31:40Z

This will be helpful for some strategies:

Split: check for bytes to get sent before sending next packet
Disorder, Fake: wait for bytes to get sent before changing TTL back

x/sockopt/is_sending_bytes_linux.go

derlaft · 2024-11-10T22:39:39Z

x/sockopt/is_sending_bytes_linux.go

+	// 1 == TCP_ESTABLISHED, but for some reason not available in the package
+	if tcpInfo.State != 1 {
+		// If the connection is not established, the socket is not sending bytes
+		return false, nil
+	}


could you confirm this does what we supposed the bye-dpi code does? I'm starting having some doubts looking at the list of states

https://github.com/hufrea/byedpi/blob/main/desync.c#L99

x/sockopt/is_sending_bytes_linux.go

x/sockopt/is_sending_bytes_not_implemented.go

x/sockopt/is_sending_bytes_linux.go

fortuna · 2024-11-12T01:53:21Z

x/sockopt/sockopt.go

+	return isConnectionSendingBytesImplemented()
+}
+
+func (o *tcpOptions) WaitUntilBytesAreSent() error {


This functionality is too high-level to live here.

I'd say we just need the bytes not sent and state options.

Then you can implement the logic to wait completely separate.

fortuna · 2024-11-12T18:25:01Z

x/sockopt/is_sending_bytes_linux.go

+	}
+
+	// 1 == TCP_ESTABLISHED, but for some reason not available in the package
+	if tcpInfo.State != 1 {


Why is this relevant? Won't tcpInfo.Notsent_bytes be zero if the connection is not established?

Also, we won't have the conenction object if it's not established.

Why is this relevant? Won't tcpInfo.Notsent_bytes be zero if the connection is not established?

I don't get this comment. This check is not about connection establishment

Also, we won't have the conenction object if it's not established.

This function should not be called when the connection is not yet established.

I'm saying we can remove the State test. It's not doing anything. tcpInfo.Notsent_bytes will be zero if it's not established.

Got it, thanks

Hmm, what about the cases when TCP connection is closing? This way we can abort waiting loop earlier. Maybe that's why it was there in the original code.

fortuna · 2024-11-12T18:37:50Z

x/sockopt/sockopt.go

@@ -50,15 +60,51 @@ var _ HasHopLimit = (*hopLimitOption)(nil)

 // TCPOptions represents options for TCP connections.
 type TCPOptions interface {
+	HasWaitUntilBytesAreSent


We can't have such high-level functionality here. As mentioned below, we should perhaps expose lower level functionality instead.

fortuna · 2024-11-12T18:38:47Z

x/sockopt/sockopt.go

I worry about having TCPOptions have options that are not cross-platform. I'm still trying to figure out what a good design for this stuff is, and we'll only know better when we try different things.

In favor of simpler APIs, for now, let's go with a simple standalone function BytesToSend(Rawconn) that lives in the fake code, since that's the only strategy that really needs it. It shouldn't be defined in platforms that don't support it.

that lives in the fake code, since that's the only strategy that really needs it. It shouldn't be defined in platforms that don't support it.

at least on linux, more strategies need it (split, esp. when it performs multiple small splits, disorder)

PeterZhizhin · 2024-11-12T21:03:26Z

Fixed some comments. For more fixes, I'd like more input.

Waiting for the socket to send all bytes is useful for pretty much all strategies.

split, tlsfrag: makes it more robust to kernel reassembling packets in it's memory buffer. I have seen split:1000*1 will write in chunks of 100-300 bytes instead of always 1 byte. Combining it with a strategy that always waits in between writes will help.
oob and disorder: guarantees that the data will be sent out of order. byeDPI currently does it on Linux, but not Windows. It's going to be "best effort" here. The strategies will work on all platforms, but will be more robust on Linux and Darwin.
fake: same as oob and disorder, but seems to be more important there, since the kernel will do more stuff (like reading a temporary file)

We'll use waiting when possible. And when it's not available on the platform we either wait for a defined duration, or don't wait at all.

PeterZhizhin · 2024-11-12T21:35:03Z

I've pushed a new strategy into this PR: waitstream.

This new strategy will call Write, and call the new WaitUntilBytesAreSent after it. Skipping the error if it's not implemented.

Baseline:

go run *.go -timeout 1000 -transport "override:host=104.16.208.90|split:10000*1" -method HEAD -v https://meduza.io/

WireShark screenshot:

Data got packaged together into 5 packets of 1, 2, 118, 110, 35 bytes

Using the strategy:

go run *.go -timeout 1000 -transport "override:host=104.16.208.90|waitstream|split:10000*1" -method HEAD -v https://meduza.io/

WireShark screenshot:

Wireshark shows that everything gets send 1 byte at a time, as expected

PeterZhizhin · 2024-11-12T21:49:19Z

Did a bit of debugging of waitstream strategy on the command I've shared above:

The code sleeps for about 1.1ms in between sends
tcpInfo.State seems to be always equal to 1, possibly hinting that our assumption that we wouldn't get the socket if the connection wasn't established.
Removing ReadFrom optimization from split does not change the situation: data still gets sent in chunks of up to 100 bytes

fortuna

I like the waitstream approach! It's a nice way to compose. But let's decouple from the TCPOptions. That's intended for low-level portable options.

x/sockopt/is_sending_bytes_not_implemented.go

fortuna · 2024-11-12T22:23:02Z

x/sockopt/is_sending_bytes_linux.go

+	}
+
+	// 1 == TCP_ESTABLISHED, but for some reason not available in the package
+	if tcpInfo.State != 1 {


I'm saying we can remove the State test. It's not doing anything. tcpInfo.Notsent_bytes will be zero if it's not established.

x/wait_stream/writer.go

fortuna · 2024-11-12T22:37:29Z

x/wait_stream/writer.go

+	written, err = w.conn.Write(data)
+
+	// This may not be implemented, so it's best effort really.
+	waitUntilBytesAreSentErr := w.tcpOptions.WaitUntilBytesAreSent()


I think this should be before the Write is done.

Also, this may significantly slow down communication. What's the performance impact? We will need to understand that for practical use.

We may want to restrict the wait for only when it's needed (on splits).

Used a fetch-speed tool:

go run *.go -timeout 100500s -transport "waitstream" http://speedtest.belwue.net/100M Downloaded 100.00 MiB in 9.01s Downloaded Speed: 11.10 MiB/s

Baseline:

go run *.go -timeout 100500s -transport "" http://speedtest.belwue.net/100M Downloaded 100.00 MiB in 9.75s Downloaded Speed: 10.26 MiB/s

derlaft reviewed Nov 10, 2024

View reviewed changes

x/sockopt/is_sending_bytes_linux.go Outdated Show resolved Hide resolved

derlaft reviewed Nov 10, 2024

View reviewed changes

x/sockopt/is_sending_bytes_linux.go Outdated Show resolved Hide resolved

derlaft reviewed Nov 10, 2024

View reviewed changes

x/sockopt/is_sending_bytes_not_implemented.go Outdated Show resolved Hide resolved

fortuna reviewed Nov 12, 2024

View reviewed changes

fortuna self-requested a review November 12, 2024 01:53

fortuna requested changes Nov 12, 2024

View reviewed changes

Allow for a connection to check if it's sending bytes

e3d398e

PeterZhizhin force-pushed the is_sending_bytes branch from 9a288f7 to e3d398e Compare November 12, 2024 20:32

PeterZhizhin force-pushed the is_sending_bytes branch from 64afbfd to fe99d36 Compare November 12, 2024 21:39

Add waitstream strategy

3f82afb

PeterZhizhin force-pushed the is_sending_bytes branch from fe99d36 to 3f82afb Compare November 12, 2024 21:54

fortuna requested changes Nov 12, 2024

View reviewed changes

fortuna reviewed Nov 12, 2024

View reviewed changes

Review fixes

6999756

PeterZhizhin mentioned this pull request Nov 13, 2024

Implementation OOB and disOOB strategies from byeDPI #329

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow for a connection to check if it's sending bytes #324

Allow for a connection to check if it's sending bytes #324

PeterZhizhin commented Nov 10, 2024

derlaft Nov 10, 2024

PeterZhizhin Nov 10, 2024

fortuna Nov 12, 2024

fortuna Nov 12, 2024

derlaft Nov 12, 2024

fortuna Nov 12, 2024

derlaft Nov 13, 2024

derlaft Nov 13, 2024

fortuna Nov 12, 2024

fortuna Nov 12, 2024

derlaft Nov 12, 2024

PeterZhizhin commented Nov 12, 2024 •

edited

Loading

PeterZhizhin commented Nov 12, 2024

PeterZhizhin commented Nov 12, 2024

fortuna left a comment

fortuna Nov 12, 2024

fortuna Nov 12, 2024

PeterZhizhin Nov 13, 2024

Allow for a connection to check if it's sending bytes #324

Are you sure you want to change the base?

Allow for a connection to check if it's sending bytes #324

Conversation

PeterZhizhin commented Nov 10, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PeterZhizhin commented Nov 12, 2024 • edited Loading

PeterZhizhin commented Nov 12, 2024

PeterZhizhin commented Nov 12, 2024

fortuna left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PeterZhizhin commented Nov 12, 2024 •

edited

Loading