I'm trying to connect to a device on COM3 and the code runs until I call open("COM3"), which causes a stack overflow. Here's the relevant code:
asio::io_service io;
asio::basic_serial_port<asio::serial_port_service> scope(io);
//Open the connection and configure it
cout << "OPENING\n";
system::error_code error;
scope.open(PORT, error);
After opening the connection I configure it with the baud rate, etc.
It's hanging in win_iocp_serial_port_service.ipp, inside of SetCommState(handle, &dcb).
I also have some labview code to connect, send a command, and disconnect, which works. If I've run the labview code since starting up my computer, then my C++ program works (connects without hanging), but if I haven't yet run the labview code it gives me a stack overflow. This makes me think that I'm not starting up some driver or setting something persistent but I'm not sure what it would be.
If anyone's run into this issue or has any insight I appreciate the help!
Info from further testing: Connecting from non-labview serial connection clients seems to enable boost to connect as well. If I first connect via hyperterminal it works, and if I connect via command line (per this guide https://learn.sparkfun.com/tutorials/terminal-basics/command-line-windows-mac-linux) then I can subsequently connect via boost as well, which might be a workable solution, even if its dumb. Unfortunately I couldn't successfully send data with System.IO.Ports.SerialPort so the temporary solution is connect using System.IO.Ports.SerialPort, disconnect, then connect using boost asio now that it works. This works reasonably well but the code now only works on windows.
Since you can use your serial instrument from LabVIEW, your hypothesis that you're "not starting up some driver or setting something persistent" is probably correct.
You can see how LabVIEW and VISA are configuring the port and sending commands using a tool provided by NI called I/O Trace [1]. Once you have the working settings and commands in hand, you can match them with your calls to boost::asio and determine if you are over- or under-configuring the port.
In the I/O trace logs, you'll see VISA setting the baud, flow control, and the other traits before opening a session. The driver doesn't share much more than that, however, so if your program is using the same settings and sequence but still hanging, then scrutinize how you're programming to the asio interface [2].
References
[1] Performing a Good NI I/O Trace Capture for Debugging/Troubleshooting
http://digital.ni.com/public.nsf/allkb/282C5D41E2BA04F2862574BA007803B9
[2] Serial ports and C++
http://www.webalice.it/fede.tft/serial_port/serial_port.html
Related
I'm trying to use Boost Asio to make some code that talks to a remote system over UDP. The remote system in question is a bit of a pain in that once you connect to it once, if you close the connection (like you end your program) and then try to connect again, if it doesn't see the same port# used on my end of that connection it will refuse it.
I'm trying to figure out how I can specify the port that gets used on my side of the connection, but nothing I'm trying seems to work and I'm getting a bit frustrated. I have no control over the remote endpoint, so I really need to get this working on my end.
Here's the relevant code I'm using to try to make the connection and send my data over:
boost::asio::io_service io_context;
socket= new udp::socket(io_context);
remoteendpoint = boost::asio::ip::udp::endpoint(
ip::address::from_string(remoteipaddress_), 50200);
localendpoint = boost::asio::ip::udp::endpoint(
ip::address::from_string(localipaddress_), 50103);
socket->bind(localendpoint,ec);
socket->open(boost::asio::ip::udp::v4());
int sent = socket->send_to(boost::asio::buffer(buf, len),remoteendpoint, 0, ec);
When I go run my code, the remote side is reporting back that it's seeing the connection coming in from a different port# (on my side, which I'm trying to set to 50103) every time I run. I really need it to ALWAYS see it as 50103.
ie: How do I ensure that the socket is ALWAYS (every time I run my program):
LocalIP:50103 <------> RemoteIP:50200
Ideas??? I'm stumped...
Thanks!
Ok, I THINK I fixed it. Needed to do the bind() call AFTER the socket->open(). Remote side now consistently is reporting that my side is coming from port 50103 which is what I wanted.
Seems a bit weird that you have to open before binding, but ok.
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).
I implemented the Bluetooth server according to the example shown in http://www.codeproject.com/Articles/252882/Bluetooth-Server-Programming-on-Windows.
I modified it a bit to use AF_BTH, SOCK_STREAM, BTHPROTO_RFCOMM.
It works fine.
However, if I restart the computer, the program hangs at accept().
If I then un-pair the two devices and then re-pair them again, the program works.
Any clues as to why this is happening.
So the program hangs on accept, from what I know accept in windows bluetooth sockets and other Bluetooth sockets platforms, accept like functions are a blocking asynchronous call, it pretty much block/freezes the thread that is on, and waits a client to connect, now winsock2 handles one thread operations much better than other platforms yes i'm looking to you android ,but still the program might get unstable if two of those calls occur , furthermore the guy only checks for one error in accept , so try referring to this complete list of winsock errors
(retrieved by winsockgetlasterror()) ,
also can you pls provide the client code and more info like on what platform, ide,devices , you are using ?
I'm writing program that should control a piece of scientific hardware over COM-port. The program itself is written in wxWidgets and uses ctb library. To test, it before I connect it to 300k€ equipment, I use com0com (Null-modem emulator) to forward COM2 port. To emulate my hardware I use wxTerminal (COM3). Altogether it works nice. One can debug not only in VS or DB but also see the whole data transfer in wxTerminal.
Now to my problem. I use to send data to COM-port ctb::SerialPort::Write() function.
device->Write( (char*)line.c_str(), line.size() );
However, if I disconnect the connection on the side of wxTerminal (i.e. COM2->NULL) than program hangs in this function.
It's obvious that I should add some function to test if my equipment is still there, but to do it I need to send data-packet to it and expect some answer. So I'm back to the Write().
"Just in case" I've also tried ctb::IOBase::Writev (char ∗ buf, size_t len, unsigned int timeout_in_ms) with timeout set to 100ms and I've still got program hanging in the same line. It's actually expected behavior as in this case timeout means only that the connection line is blocked till whole buffer is transferred or timeout is reached.
Connecting of wxTerminal to COM3 leads to un-freezing of debugger or stand-alone program. The Sun is shining, the birds are singing.
Can somebody give me a hint how to overcome my problem? I'd appreciate if comments would be restrained to wxWidgets-world - I really do not want to re-write whole program with other toolkit.
If you COM port library does not provide effective timeouts on write block, (presumably because of hardware flow-control), you could implement your own by threading off the write. You could use a couple of events/semaphores/condvar/whatever. One to signal to the thread that there is something in a buffer to send and another that you can wait on with a timeout that is signaled by the thread after it has sent the buffer. If the 'ack' wait times out, your COM port is stuck and you can pop up some 'Check cable' messageBox. I don't know what other calls your port lib supports, so I don't know how you could implement flushes/retries.
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.