I have a C++ program that uses Boost ASIO to communicate with a network device over a TCP socket. The program is working fine on Linux, but with Windows 7 I'm finding that the communication is not working very well. After some experimentation, I found that there's a 0.5-second delay between command and response when communicating with the device using the ASIO example telnet program, even though the response shows up in Wireshark much more quickly.
I gather that the problem is that the network device is not setting the PSH flag after it completes a chunk of data. See: http://smallvoid.com/article/winnt-tcp-push-flag.html.
I need to somehow set up my app so that it receives data from the TCP socket regardless of whether a packet has arrived with the PSH bit set. I know this must be possible because PuTTY can communicate with my device normally. I'd rather not use a registry key to get the effect, because I want to change the behavior only for this one socket, not the entire system.
What do I need to do to get Windows to ignore the PSH flag for this connection?
You could try specifying the MSG_PUSH_IMMEDIATE flag on the receiving side (https://msdn.microsoft.com/en-us/library/windows/desktop/ms741688(v=vs.85).aspx).
Related
I would like to create a linux app which appears as a serial port (eg /dev/ttyTEST). This app will listen for commands sent to the port, and respond back.
Is this possible using Qt/C++ ? I haven't done kernel programming so I'm hoping this is possible in user space.
Everything depends on what the application using such device expects.
If /dev/ttyTEST is to behave like a real serial device and respond properly to all ioctl's that set its speed etc., then this can't be done from userspace. It wouldn't be too hard to implement in the kernel space, though.
If /dev/ttyTEST only needs to be a tty, then provide a pseudo tty.
If /dev/ttyTEST is merely to be something another application can write to and read from then socketpair() does it.
If you have control over the application's code, then you can have it check whether the device is a socket pair or a real character device, and ignore the failures of the serial-port-specific APIs on a socket.
I going to create kernel mode driver level app that establish a TCP connection, here is my requirement:
I don’t want pass data to user-mode
I don’t want use winsocket and OS socket library
I need to just pass tcp packet to a library and
the library create simple TCP-client or TCP-Server connection for me. It should perform all TCP connection requirements such as tcp handshake, generate packet, calculate checksum, set TCP flags and acknowledgment then give the new packet to me so I can send the packet to my network adapter.
Do you know exiting TCP implementation that it does not use OS socket library?
I think the proper way to ask this question is this:
What is the proper way to do TCP sockets within kernel code?
And I'm not sure you want to do TCP just at the packet level, because you'll also likely want to handle TCP segmentation, IP fragmentaion, sending only when the remote window size permits it, and ACK generation. In other words, if you're doing a TCP server within kernel mode, you want the whole kernel TCP stack.
In any case, Bing or Google around for "kernel sockets" or "ksocket".
For Linux: http://ksocket.sourceforge.net/ Also, check out this example for UDP.
For Windows: Go to this page and downlaod both the HttpDisk and KHttpd samples. Both feature a windows device driver than makes use of a similar "ksocket" library. (Look for ksocket.c and ksocket.h in each)
For Linux, use the kernel_*() versions of the usual socket API, i.e. kernel_bind(), kernel_listen(), kernel_accept(), kernel_connect(). They're in #include <linux/net.h> and are used in ways very similar to "normal" sockets.
Solaris has very similar interfaces, there named ksocket_*(), see #include <sys/ksocket.h> for references.
For the *BSD UN*X flavours, Apple's Network Kernel Extensions Guide gives some details (also with references to the corresponding interfaces on Free/Net/OpenBSD).
Don't know about Windows.
I have a small project that I've been working on in C++, and due to the nature of what it does, I need to insert packets in to a live TCP stream. (The purpose is innocent enough, http://ee.forumify.com/viewtopic.php?id=3299 if you MUST know)
I'm creating a level editor for a game, and due to the nature of the handshakes, I can't simply establish a new connection with a high level library such as WinSock. Until now, it has relied on Winsock Packet Editor to do the dirty work, but if I were to let the application handle it all, it would make everyone happy.
So my question is this: Is there an API somewhere that will allow me to take control of a live TCP stream, and preferably one that keeps it valid after it finishes? And I would prefer to not have to inject any DLLs. Also, Detours is a no-no as I'm using GCC/Mingw.
I've toyed around with WinPCap and I have some working code (I can collect a packet, and from that generate a proper packet to send) but since it operates at such a low level, I cannot anticipate all of the potential protocols that the end user might use. Yes, chances are that they'll be using IPv4 over Ethernet, but what about those people who still use PPP, or some other obscure protocol? Also, the connection gets dropped by the client application after mine is done with it, as the latest ID values in the packets have changed and the client assumes that it has disconnected.
So, if anyone could provide a high-level TCP stream manipulator, I would be very happy. If not, I'll just continue tinkering with WinPCap and tell all the dial-up users to go get better internet.
Target platform: Microsoft Windows XP through Windows 7
Create a separate process to bind to a local port. When the initial tcp stream is created, proxy it through that process, which can then forward it on to the network. When you need to 'inject' into the stream you can have this proxy process do it. Just a thought.
you should look at the source code of ettercap http://ettercap.sourceforge.net/
or hunt, tcp hijacker http://packetstormsecurity.org/files/view/21967/hunt-1.5.tgz
Those 2 softs do what you're after.
I don't think there's any sensible API that will allow you to hijack a TCP stream. Such a thing would, inherently, be a security problem.
Can you insert your program as a proxy for the connection in question? That is, get the program that opens the connection to open it to your program, then have your program open the connection to the real target.
The idea is that if all the packets pass through your program anyway, then modifying the TCP stream becomes relatively trivial.
I'm having a peculiar problem with boost::asio and a boost::asio::serial_port device. The code is finally working pretty well with asynchronous reads and stuff, but I can't figure out how to change the speed of the serial port on the fly.
What I'm trying to do right now is just telling the device connected in my serial port to change the serial port speed to say 38400 baud, then I'm setting my computers serial port to the same speed via:
port_.set_option(boost::asio::serial_port_base::baud_rate(rate));
But what's really happening is that if I do the set_option part, the device never receives the command to change the speed. If I don't do the set_option part the device changes speed correctly. From what I gather what's happening is that the (blocking, synchronous) write puts stuff in the hardware buffer on my computer and returns, then does the set_option which discards the buffer (before it has had time to send data to the device). So I need to think of some way to check if the hardware buffer is empty and the device really has received the command to change the speed, before reconfiguring my computers serial port. I also cannot find any info on if I have to do close() and open() on the port for the speed change to take affect. I'm also wondering if close() discards the stuff in the buffer or not... I'm using a USB->serial port adapter and my platform is Ubuntu 10.10 if it makes any difference.
Have you looked at man 3 termios? It seems tcdrain does what you need
tcdrain() waits until all output
written to the object referred to by
fd has been transmitted.
You can get the native descriptor from the boost::asio::serial_port::native method.
Did you try flushing the buffer or looking for an appropriate flush alternative?
Are the client and server in the same process?
Boost.Asio iostream flush not working?
I have an iPhone VOIP app that copes with multi-multi transmit and receive (ie teleconferencing) set up using BSD sockets. I would like it to be able to respond to incoming requests when it is in the background but from what I can understand of the iOS 4 docs I can only do this on an NSStream object (or CFRead/WriteStream) by setting the property to NSStreamNetworkServiceTypeVoIP. This is a bit of a problem as my system is a UDP BSD sockets based application. Everything is received and sent on a single UDP socket.
Am I going to need to re-write my audio transmit/receive core to handle NSStreams or is there a way I can get iOS 4 to handle my BSD socket in a similar way to an NSStream? I assume this may be a problem as an NSStream is event based.
Would it be possible to detect when the application goes into the background and build a temporary NSStream object that will pass the data on to through the relevant handling and then continue as normal? Is it even possible to create a UDP NSStream?
Any ideas?
You can create a socket from a file descriptor with CFSocketCreateWithNative(), and then create a pair of streams with CFStreamCreatePairWithSocket(). It might let you use them on a UDP socket. Provided the streams don't read data unless you ask, you might be able to get away with using the FD directly.
Good luck with that though!