I require some informations like the amount of resend packages/packet-loss occurred for a specific TCP-Socket I created. Does somebody know a way how to access or request such informations directly from my C/C++ program? Maybe something Linux specific?
Or do I need (as a workaround) to capture and analyze my own traffic?
Thanks in advance!
By using getsockopt() to get or setsockopt() to set TCP socket options, you can use TCP_INFO option on linux machines in order to get information about a socket. This option should be avoided if you want the code to be portable.
What you will get back is a struct tcp_info from the kernel that contains information such as retransmissions, lost packets, states etc.
Related
All,
I am working on an embedded linux application that is to use a cellular connection to communicate with a database.
I know that I can use AT commands to create socket to the server, but how do I get access to the socket from a C++ program? That is, after I issue the AT commands, how do I use it from an application?
Sorry if this is a stupid question, but I can't find an answer...
Thanks for all your help!
:bp:
Check the documentation for your modem. Multitech has one online here for their modems which may or may not be helpful (if yours is compatible).
Generally, after doing the WIPCREATE, you need to wait for a WIPREADY or WIPACCEPT from the modem; you can then do WIPDATA to put your connection to the modem into data mode, at which point everything you write will be sent to the socket, and anything received on the socket will be sent back to you (so you can treat the fd connected to the modem as if it was a socket, you just need to be careful not to send escape sequences accidentally -- or at least escape the escape sequences properly).
That depends on your OS. On most normal Unix OS's you can simply use /dev/tty*, open it, set the baudrate etc and issue AT commands.
I have a controller which has a serial port and ethernet. I want to retrieve an event and the data associated with this event from the event directory through the serial or ethernet port of the controller. I do have a packet format (request packet data) for the specified event to be retrieved. Can anyone tell me how to retrieve the data by sending a request through the serial port? I am beginner and not that much well-versed in programming.
You will need to have some kind of a program running on your embedded platform, listening to the serial port and answering requests. This kind of program is usually called a "daemon" (pronounced the same as "demon"; just like "Caesar" rhymes with "sea star").
If you already have a daemon, you will need to figure out what format it uses. Since I have no idea what you might have I cannot even guess.
If you will be writing your own daemon, you will need to choose some sort of protocol. Personally I like the JSON format for a serial protocol; it is simple enough that you can extract data just using sscanf() from the C library if there is not a better library available, and of course it's easy to build JSON strings just using sprintf().
http://json.org/
What you want is the Serial Programming Guide for POSIX Operating Systems. If you are bound to Windows for some reason, you get POSIX through installing Cygwin. Expect to become familiar with man pages like termios and fcntl since you'll first have to set the serial port parameters to work with your device, though they're likely to be the standard 8-N-1 at some rate. Then it's a matter of reading and writing bytes to the port's file descriptor. You're more likely to be using the low level open(), close(), read(), and write(), which are a level below the stdio (printf, fopen, stdout) you're more likely to be used to as a newer programmer.
Computers these days often lack the RS232 serial port, so if you need one you can find a cheap USB adapter. Be aware that USB adapters don't necessarily implement some of the ancillary signals (RTS,CTS,etc.) in my experience.
Also look into libraries for your specific needs and situation.
You should specify the controller for more useful answers.
Your controller should support any data exchange protocol. You can find this info in documenttion. May be, it supports MODBUS or MODBUS TCP. In this case you can use any modbus compatible software.
I would like to write a program and run it on two machines, and send some data from one machine to another in an Ethernet frame.
Typically application data is at layer 7 of the OSI model, is there anything like a kernel restriction or API restriction, that would stop me from writing a program in which I can specify a destination MAC address and have some data sent to that MAC as the Ethernet payload? Then write a program to listen for incoming frames and grab the frames from a specified source MAC address, extracting the payload of data from the frame?
(So I don't want any other overhead like IP or TCP/UDP headers, I don't want to go higher than layer 2).
Can this be done in C++, or must all communication happen at the IP layer, and can this be done on Ubuntu? Extra love for pointing or providing examples! :D
My problem is obviously I'm new to network programming in c++ and as far as I know, if I want to communicate across a network I have to use a socket() call or similar, which works at an IP layer, so can I write a c++ program to work at OSI layer 2, are there APIs for this, does the Linux kernel even allow this?
As you already mentioned sockets, probably you would just like to use a raw socket. Maybe this page with C example code is of some help.
In case you are looking for an idea for a program only using Ethernet while still being useful:
Wake on LAN in it's original form is quite simple. Note however that most current implementations actually send UDP packets (exploiting that the receiver does not parse for packet headers etc. but just a string in the packet's payload).
Also the use of raw sockets is usually restricted to privileged users. You might need to either
call your program as root
or have it owned by root and setuid bit set
or set the capability for creating raw socket using setcap CAP_NET_RAW+ep /path/to/your/program-file
The last option gives more fine grained privileges (just raw sockets, not write access to your whole file system etc.) than the other two. It is still less widely known however, since it is "only" supported from kernel 2.6.24 on (which came with Ubuntu 8.04).
Yes, actually linux has a very nice feature that makes it easy to deal with layer 2 packets. You can use a TAP device, which allows your userspace program to read/write ethernet traffic through the kernel.
http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/networking/tuntap.txt
http://en.wikipedia.org/wiki/TUN/TAP
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.
Lots of questions, I am sorry!
I am doing a voice-chat (VoIP) application and I was thinking of doing a custom implementation of the IP&UDP headers, along with small, extra information mainly seq number. Sounds alot like RTP yes, but I'm mainly just interested in the seq number or timestamp, and trying to implement my own whole RTP sounds like a nightmare with all the complexity involved and data im not likely to use.
Target OS for the application is windows xp and above. I have read http://msdn.microsoft.com/en-us/library/ms740548%28v=vs.85%29.aspx on the topic of Raw sockets in windows, and now I just want some confirmation.
I also have some general networking questions.
Here's the following questions;
1) According to MSDN, you cannot send custom IP packets with a source that is not on the network list. I understand it from a security PoV, but is there any way around this? My idea was to have for example two clients open UDP communication to a non-NAT protected server, and then have the clients spoof the source-header to make it look like packets come from the server instead of each other, thereby eliminating the need for a server as a relay of data to get through NAT, which would improve latency.
I have heard of winpcap but I don't want each client to have to install any 3rd party apps. Considering the number of DoS attacks surely there must be some way around this, like spoofing the network table the OS uses to check if source-header is legit? Will this trigger anti-virus systems?
I feel it would be really fun to actually toy with IP headers and above instead of just using predefined headers.
2) I've been having issues with free RTP libraries like JRTPLIB(which probably is very good anyway it just dosn't want to work for me) to make them work, more than I could almost tolerate, and am thinking of just writing my own interpretation ontop of UDP. Does application-level protcols like RTP simply build their header directly inside the UDP payload with the actual data afterwards? I suspect this considering the encapsulation process but just want to make sure.
If so, one does not need to create a RAW socket to implement application-level protocol, just an ordinary UDP socket and then your own payload interpretation above?
3) RTP does not give any performance boost compared to UDP since it adds more headers, all it does is making sure packets arrive in a sort-of correct manner based on timestamps and sequence numbers, right?
Is it -really- that usefull to use an RTP implementation for your basic VoIP project needs instead of adding basic sequencing yourself? I realise for video conferencing perhaps you reaally don't want frames to play out of order, but in audio conversations, would you really notice it?
4) If my solution in #1 is not applicable and I would have to use a server as a data relay between clients, would multicast be a good solution to reduce server loads? Is multicast supported enough in routing hardware?
5) It is related to question 1). Why do routers/firewalls allow things like UDP hole punching? For example, two clients first conenct to the server, then the server gives a client port / ip on to other clients, so the clients can talk to each other on those ports.
Why would firewalls allow data to be received from another IP than the one used in making the connection on that very port? Sounds like a big security hole that should easly be filtered? I understand that source IP spoofing would trick it, but this?
6) To set up a UDP session between two parties (the client which is behind NAT, server whic his non-NAT) does the client simply have to send a packet to the server and then the session is allowed through the firewall? Meaning the client can receive too from the server.
Based on article at wiki, http://en.wikipedia.org/wiki/UDP_hole_punching
7) Is SIP dependant on RTP? For some reason I got this impression but I cant find data to back it up. I may plan to add softphone functionality to my VoIP client in the future and want to make sure I have a good foundation (RTP if I really must, otherwise my own UDP interpretation)
Thanks in advance!
1, Raw sockets seems unnecessary for this application
2, Yes
3, RTP runs on top of UDP, of course it adds overhead. In many ways RTP (ignoring RTCP) is pretty much the bare minimum already and if you implemented a half-way decent alternative it would save you a few bytes at best and you wouldn't be able to use any of the many RTP test tools.
7, SIP is completely independent of RTP. SIP is used to Initiate Sessions. SDP is the protocol commonly transported by SIP, and it is SDP that negotiates and controls RTP video/voice voice.