21–30 of 42 posts
Feature request: TCP over Facebook Messenger, TCP over Whatsapp For use on flights where they give you "messenger only" internet access. Feature request: TCP over JPEG cat pictures on HTTP port 80 It would likely do a better job at circumventing the China firewall than existing VPNs that can be flagged as VPN protocols.
> on flights You could just sniff the traffic for an already-logged-in MAC and clone it.
reminds me how the other day I circumvented disabled SSH port forwarding by using https://github.com/nwtgck/yamux-cli + ncat already on the machine to do something like: yamux -l lport | ssh server -- .sh good thing I needed HTTP access or else i had to find that socks5 server that's actually working again.
Neat idea. For better performance, you might want to use native filesystem APIs, for example on windows use CreateFile with the FILE_WRITE_THROUGH flag to prevent caching and and extra flushing.
The key to high performance as you rightly pointed out was preventing flushing. In the end, what worked best was reducing the number of writes to disk (which is the bottleneck). I did that by buffering 10-50 ms worth of TCP data, coupled with only flushing explicitly (using a large buffer so that neither BinaryWriter or FileStream flush automatically).
What's the benefit of this over netcat + mkfifo?
1. It gracefully supports each side of the tunnel turning on and off.
2. It accepts any number of clients, and forwards them through the tunnel.
3. It recycles the shared file.
So there’s multiple writers to the file? How is this arbitrated? Also how does either side know when the file has been updated?
Arbitration was indeed one of the trickiest bits. Originally I pre-reallocated the full file size (10 MB). Then used an integer at the beginning of the file to signal to the other side that a block was ready. The other side repeatedly read that int, and read the corresponding part of the file. But writing twice (once for the data, once for the int) had a significant performance impact.
In the end, what worked best was not pre-allocating the file. Rather letting the file grow whenever the writer writes to it. The reader knows when data is available by doing a PeekChar() in a tight loop. It's surprisingly fast, and accurately reflects the state of the file.
So there’s multiple writers to the file? How is this arbitrated? Also how does either side know when the file has been updated?
It looks like one file per direction, and this is a point to point connection. It looks like each side just reads to the end of the file and then tries to read more to see if any new data is available.
In the future I will implement a single file to handle both directions.
There's a more complete version of this with nncp: https://www.complete.org/nncp/
For RDP you can use virtual channels so you don't need to use a file over drive redirection
Neat idea. For better performance, you might want to use native filesystem APIs, for example on windows use CreateFile with the FILE_WRITE_THROUGH flag to prevent caching and and extra flushing.
I think you can use named pipes if you are using SMB. Here is a example code in python (not tested). import socket import win32pipe import win32file import sys BUFFER_SIZE = 4096 def create_pipe(pipe_name): return win32pipe.CreateNamedPipe(pipe_name, win32pipe.PIPE_ACCESS_DUPLEX, win32pipe.PIPE_TYPE_BYTE | win32pipe.PIPE_READMODE_BYTE | win32pipe.PIPE_WAIT, 1, BUFFER_SIZE, BUFFER_SIZE, 0, None) def open_pipe(pipe_nam…