I am using OCB mode based on ath9k driver for my wireless connections between different nodes. I need to know the signal strength of received packets in my user-space application to do some calculation based on that. In order to communicate I am using socket APIs and udp packets.
So, here is the question: Is there any function or API in C to get signal strength of a received packet in a user-space application?
I don't know if the signal strengh "of a received packet" really makes sense, but you can get some information on the wifi signal where you are connected by reading /proc/net/wireless
$ cat /proc/net/wireless
Inter-| sta-| Quality | Discarded packets | Missed | WE
face | tus | link level noise | nwid crypt frag retry misc | beacon | 22
wlan0: 0000 69. -41. -256 0 0 0 1 274 0
Generally speaking, /proc provides runtime information about your system. Technically speaking, if you wish to read this from a C program you should probably try to find if there is an API for this, otherwise read/open/close the file and parse its content. See this thread for details about reading the /proc filesystem.
You should use cfg80211, see http://www.linuxwireless.org/en/developers/Documentation/cfg80211/
Related
I am using a python tool to generate packets in one VM and I capture them in my program running as a linux process in another VM. Both the VMs are ubuntu and they are running on the same subnet. I notice that some of the packets get dropped in my program. What is the best tool to know where the packets are dropped?
I see that RcvbufErrors in netstat output gets increased as I send new packets.
# netstat -us
IcmpMsg:
InType0: 14
InType3: 1493
InType5: 204
InType8: 54
InType13: 5
InType17: 5
OutType0: 54
OutType3: 645946
OutType8: 584
OutType14: 5
Udp:
7686124 packets received
646545 packets to unknown port received.
33928069 packet receive errors
7157259 packets sent
RcvbufErrors: 33928069
IgnoredMulti: 345772
UdpLite:
IpExt:
InMcastPkts: 4
InBcastPkts: 363522
InOctets: 13243409806
OutOctets: 8445992434
InMcastOctets: 144
InBcastOctets: 114457552
InNoECTPkts: 100191590
InECT0Pkts: 143
Well, if you think that you need to find out where some packets get dropped, this might not be useful since you already know that at least RcvbufErrors figure is growing. This means that the NIC is able to deliver the packets to the kernel but the latter is unable to deliver the packets to the application, obviously, because a fixed-size receive buffer gets full faster than the application could read the data out (or just flush it).
So, I'd say such a result just gives an impression of poor application design. Perhaps, you should consider some good technique to enhance packet capture in your application so that more packets are captured/examined/dropped per second. A good example is PACKET_MMAP Rx ring which has an exhaustive description and is widely used in libpcap-based applications. The latter aspect makes it indeed reasonable to use wireshark or just tcpdump instead of your hand-made app to inspect the real capture rate, etc.
I have a client and a server, where server sends the audio data by RTP packets encapsulated inside UDP. Client receives the packets. As UDP has no flow control, client checks for the sequence number of the packet and rearranges them if they come out of order.
My question here is, I see client never receives packet with some sequence number, as show below in the wireshark -
If this is the case, when i play the audio at client side, it is distorted(obvious). How do i avoid it? What factors effect these? Should i set the socket buffer size to a large value?
Appreciate reply in advance.
EDIT 1: This issue is on QNX platform and not on Linux.
I observed the output of "netstat -p udp" to see if that gives any hint about why packets are getting dropped on QNX and not on Linux.
QNX:
SOCK=/dev/d_usb3/ netstat -p udp
udp:
8673 datagrams received
0 with incomplete header
60 with bad data length field
0 with bad checksum
0 dropped due to no socket
2 broadcast/multicast datagrams dropped due to no socket
0 dropped due to full socket buffers
8611 delivered
8592 PCB hash misses
On Linux I see netstat shows no packet drops with the same server and same audio!
Any leads? Why this might be? Driver issue? Networking stack?
You need to specify how you are handling lost packets in your client.
If you lose packets, that means you have missing data in your audio stream. So your client has to "do something" where it is missing data. Some options are
- play silence (makes a cracking noise due to sharp envelop to 0)
- fade to silence
- estimate waveform by examining adjacent data
- play noise
You play cannot misalign packets or play them with missing packets. For example, suppose you you get packet 1,2,3,4 and 6. You are missing packet 5. You cannot play packet 4 then play packet 6. Something has to happen to fill the space of packet 5.
See this post for more info.
We want to receive packets from udp sockets, the udp packets have variable length and we don't know how long they really are until we receive them (parts of them exactly, length were written in the sixth byte).
We tried the function lrs_set_receive_option with MarkerEnd only to find it has no help on this issue. The reason why we want to receive by packets is that we need to respond some packet by sending back user-defined udp packets.
Is there anybody knows how achieve that?
UPDATE
The LR version seems to be v10 or v11.
We need respond an incoming udp packet by sending back a udp packet immediately.
The udp packet may be like this
| orc code | packet length | Real DATA |
Issue is we can't let loadrunner return data for each packets, sometimes it returns many packets in a buffer, sometimes it waits until timeout though when there has been an incoming packet in the socket buffer. While in the c programming language world, when calling recvfrom(udp socket) we are returned only one udp packet per time (per call) which is want we really want.
If you need raw socket support to intercept at the packet level then you are likely going to have to jump to a DLL virtual user in Visual Studio with the raw socket support.
As to your question on UDP support: Yes, a Winsock user supports both core transport types, UDP and TCP. TCP being the more common variant as connection oriented. However, packet examination is at layer 3 of the OSI model for the carrier protocol IP. The ACK should come before you receive the dataflow for your use in the script. You are looking at assembled data flows in the data.ws when you jump to the TCP and UDP level.
Now, you are likely receiving a warning on receive buffer size mismatch which is taking you down this path with a mismatch to the recording size. There is an easy way to address this. If you take your send buffer and construct it using the lrs_set_send_buffer() function, then anything that returns will be taken as correct, ignoring the previously recorded buffer size and not having to wait for a match or timeout before continuing.
Please excuse me as I am unable to frame the question without depicting my scenario. My scenario is as expalined below,
I have two machines machine1 and machine2 both having its own IP address. Now I want to exchange messages between them, I want to send a message to machine2 from amachine1 in one port say 50 and recv a message from machine2 at port number 51.
How can I implement this, I am in confusion whether to create two socket for send and recv in each machine? or just different ports will do the job. I am using C language and Ubuntu linux. Thanks in advance.
MACHINE1 MACHINE2
| |
| sendto |
port 50 ----------------------------------> |
| |
| recvfrom |
port51 <-------------------------------- |
| |
| |
If you just want to send and receive data, a TCP/IP connection will do. You need to choose one of these machines to be the server, for example, one will listen at port 50 (the server) and the client will connect to it.
You can also use UDP and use the same port on two different machines. It is a matter of choice and it depends on what you are going to do on your application.
With TCP:
Machine 1 - Listens on port 50
Machine 2 - Connects to Machine1:50
With this connection, you are able to send and receive data.
With UDP:
Machine 1 - Binds to port 50
Machine 2 - Binds to port 50
The IP of Machine 1 and Machine 2 are different. Now you can send and receive data from the combination IP:port.
You can find examples here (TCP/IP): http://www.thegeekstuff.com/2011/12/c-socket-programming/
and for UDP, here: http://gafferongames.com/networking-for-game-programmers/sending-and-receiving-packets/
Regarding the number of sockets, you need one socket for each side of the connection, or one per machine, on your example. When you open a socket, you are able to send and receive data. We say that a connection is bidirectional.
If you want to use two port, then you will need two sockets in Machine1.
On first socket, you send data to Machin2.
On second socket, you will listen on port 51, and recv message.
It is also possible to use only one port,
In which case, a single socket will do both send/recv on Machine1.
I'm writing a C/C++ client-server program under Linux. Assume a message m is to be sent from the client to the server.
Is it possible for the client to read the TCP sequence number of the packet which will carry m, before sending m?
In fact, I'd like to append this sequence number to m, and send the resulting packet. (Well, things are more complicated, but let's keep it that simple. In fact, I'd like to apply authentication info to this sequence number, and then append it to m.)
Moreover,
is it possible for the server to read the TCP sequence number of the packet carrying m?
You can do something very nearly equivalent to this. You can count all the bytes you send and put a count of all the bytes sent before the message at the end of your message.
I get really nervous anytime anybody talks about 'packets' with TCP. Because if you talk about packets and TCP at the same time you are mixing protocol levels that shouldn't be mixed. There is no meaningful correspondence between data you send in TCP and the packets that are sent via IP.
Yes, there are sequence numbers in IP packets used to send TCP information. These sequence numbers are a count of the number of bytes (aka octets) sent so far. They identify where in the stream the bytes in the packet belong, but they are otherwise unrelated to the packet.
If a resend happens, or if you're using the Nagle algorithm, or if the TCP stack feels like it that day, you may end up with two send operations ending up in the same packet. Or, you might end up with half of one send operation ending up in one packet, and half in another packet. And each of those packets will have their own sequence numbers.
As I said, there is absolutely no meaningful relationship between send operations you perform at the transport layer and the packets sent at the network layer. I'm not talking theoretically either. It's not 'really all packets underneath and the send generally, barring some weird condition, puts all the bytes in a single packet'. No, the scenarios I outlined above where the bytes from a single send operation are spread to multiple packets happen frequently and under unpredictable conditions.
So, I don't know why you want to know anything about the sequence numbers in packets. But if you were using the sequence number as a proxy for number of bytes sent, you can keep that count yourself and just stuff it into the stream yourself. And remember to count those bytes too.
no, you can't do that -- at least not with expected result
This is because:
TCP is stream based, not packet based.
TCP sequence number is in byte, not packet.
Underlying TCP layer do the segmentation for you.
TCP window size / packet size are dynamic
These means you might send a "packet" with the sequence number at the end of "packet". It turns out, the underlying magics re-segment your packet.
What you want:
1 2 3 4
+---+---+---+---+
| A | B | C |"1"| packet 1, seq=1, len=4
+---+---+---+---+
5 6 7 8
+---+---+---+---+
| A | B | C |"5"| packet 2, seq=5, len=4
+---+---+---+---+
What you might get:
1 2 3 4
+---+---+---+---+
| A | B | C |"1"| packet 1 (seq=1, len=4)
+---+---+---+---+
(packet 1 got lost)
1 2 3 4 5 6
+---+---+---+---+---+---+
| A | B | C |"1"| A | B | packet 1, resent, seq=1, len=6
+---+---+---+---+---+---+
7 8
+---+---+
| C |"5"| packet 2, seq=7, len=2
+---+---+
TCP/IP stack does all the things for you. You receive only payload. Stack removes all the headers and provides payload at user space.
If you really want to add or modify at packet header level, try out RAW sockets. RAW sockets receives/sends packet directly from Network card irrespective of transport type (TCP or UDP). In this case you have to strip/add all the headers (TCP/UDP Header, IP Header and Ethernet Header) with your payload.
Checkout a very good video tutorial on RAW Sockets