In my pcap file, I was expecting to see RTP packets, but has STUN packets. So in wireshark, I tried to do "decode as: RTP". Packets are decoded as RTP but as "malformed packets.". Is there any way to dissect STUN to RTP ??
Maybe they really are STUN packets, and your expectations weren't met. We'd have to see the capture in order to tell.
Related
Similar to How to set source address when sending using and UDP socket, but not identical:
I'm writing an experimental UDP packet relay.
The code works so far, but the problem is that the relayed packets have the address and port of the relay (instead of the original sender) as sending address in the outgoing packets, so any responses would also go to the relay, and not to the original sender.
Is there a standard way (without manipulating the packets directly) to do this?
Currently it has to work for IPv4 only.
It seems that packets sent through using gopacket/gopcap are somehow 'sent' as they are visible in a tshark trace:
444 143.613451037 127.0.0.1 → 127.0.0.1 UDP 66 6000 → 8888 Len=22
but these packets never arrive on a process on the same machine listening on 127.0.0.1:8888 (for example netcat -ul 8888).
Does anybody have any hints on why this is or things to try? As mentioned, the packets are in fact visible in a tshark trace... they just seem to completely vanish after that.
... irrelevant
out , err := pcap.OpenLive(*iface, 65535, true, -1 * time.Second)
out.WritePacketData(buf.Bytes())
... irrevelant
The idea is to construct packets and send them on lo so that a process listening on 127.0.0.1:<some port> can actually see those packets.
IP src/dst are both 127.0.0.1 and ethernet src/dst are both 00:00:00:00:00:00.
Edit:
As far as some more research goes it seems to be the case that sending packets with pcap bypasses IP network stacks in such a way that the packets can't be seen by processes. A workaround is to strip the lower levels of the packets in the trace and open a regular udp/tcp socket and send the payload through that socket.
As far as some more research goes it seems to be the case that sending packets with pcap bypasses IP network stacks in such a way that the packets can't be seen by processes. A workaround is to strip the lower levels of the packets in the trace and open a regular udp/tcp socket and send the payload through that socket.
I have written a C++ tool for my linux machine which receives UDP (OSC) packets and sends them back immediately (thats the only thing it does). But it seems that there is some amount of dropped packets. When I send 100 packets to my linux (from another machine), mostly only 64 packets are returned. I have looked at the incoming packets with tcpdump. It tells me the following:
64 packets captured
64 packets received by filter
0 packets dropped by kernel
So where are they?
UDP, by design, does not guarantee that the packets arrive at the destination. The packets missing might no have reached your machine at all, and thus will not appear in the incoming packets.
UDP is mostly used for streams and games, as loosing a few packets does not really matter.
If you want to be sure that all the packets arrive, you should use TCP.
Let me know if this helps.
I observed a surprising thing that when there are both udp-based and tcp-based applications sending packets, if the upd-based application sent the packets so fast that the bandwith are nearly filled with udp packets, then the tcp packets would be very hard to send out.
The surprising thing is that though tcp-based application is able to send a few packets out (observed by the return value of write()), the receiver of the tcp packets never receives them. Why? Is that because the tcp-packets arenot finally sent out by the network card? or the tcp packets are actually dropped by routers?
Thanks,
Steve
First, the return value of write() is not an indicator of whether packets were sent. It just indicates that the data was buffered.
Second, if you are saturating the network with UDP packets there will be a lot of packet loss, and TCP being adaptive will adapt to that by sending packets out more slowly. If the packet loss gets too high TCP can basically stop altogether. The solution is not to saturate the network with UDP packets.
This is a simplified answer. There are many articles you can read up on.
UDP is a layer built upon IP. Ditto for TCP. The network card just sends out IP packets. You can look up the various structures for these packets.
TCP is a protocol that uses IP packets but uses a mechanism to try to ensure delivery and rearranges packets in the correct order. See the article on Wikipedia.
Routers are free to drop packets. This can occur when the network is overloaded, network connections are down or the IP packet is corrupted.
So to answer your question their is no preference between UDP or IP to be transmitted from one end to the other.
I have to implement a little software that sends an audio stream between two pc in the same WiFi network..
In little words, I get audio from device like a mic and then I have to transmit this audio in real time..
maybe I'll use Java..
To transmit data trough UDP something like this:
//create UDP socket
DatagramSocket socket = new DatagramSocket();
//data to be sent
byte[] buf = (data).getBytes();
//create UDP packet
DatagramPacket packet = new DatagramPacket(buf, buf.length, address, port);
//send the packet
socket.send(packet);
...
Well, my question is, how can I split the audio source in packets that I'll store in buf?
how can I receive the packets in another pc and then "reassembly" or play directly?
It's the right way? Thanks very much. Hi!
Why don't you use TCP instead of UDP? With TCP sockets, you'll have stream functionality implemented with no extra hassle.
If you stick with UDP, you'll have to implement some kind of packet numbering, then reassembly, then play only when you have them all, and so on. Try to avoid it.