I am getting failure while sending large data (neraly 9-10 MB) using C++ Libcurl, where as the data of lesser size works fine.
i am trying to send the data from linux machine to Exchange Server (windows 2008). from wireshark capture, i could see initial few packets are getting uploaded successfully, but then i could see errors like TCP retransmissions, TCP Zero size Window, TCP Window update etc. Apart from these packets i could see one packet related to HTTTP 400 , followed by TCP RST (thereby terminating the connection).
source Address (linux machine ): 10.65.156.77
Destination ipaddress (exchange server) = 10.76.214.38
libcurl version : 7.30
any help will be appreciated.
Related
My Goal is capturing incoming packet with DPDK, to do this I want to integrate DPDK library ETH API to my project to receive all incoming Packets (NIC rate:40Gbps, pkt size 1500 bytes) with zero packet loss.
I didn't know How can I do this ?
I installed DPDK from [DPDK Quick Installation.][1]
shared the debug session and showcased 4 *10gbps x710 (Fortville) is able to send 40Gbps of traffic from pkt-gen. On receiver end with examples/skeleton with 1 core how the total 40Gbps is received and processed.
pkt-size is 1500 as per request from #Alexanov.
Hence there is no issue in DPDK library to receive packets
This is related to: Sending packets over UDP from Windows
I making simple UDP client using Boost ASIO. When I run the client on Ubuntu, it can send to the server (listener) the data correctly. However, when I am running it on Windows, the server can not parse the data correctly.
Since I do not have access to the server code. I can not be sure what is happening there.
I am sure that it is not Networking (such as firewall) problem because I tried the code on Ubuntu VM inside a Windows Host and it worked.
My question is: Should I encode the message I sent from Windows in different manner? (I am not sure but something like UTF-8, UTF-16 differences.. maybe..)
The sending code:
socket_.send_to(boost::asio::buffer(message, sizeof(*message)), endpoint_);
Where message is pointer to some struct that the server expecting. end_point_ is correct. I printed it and the address and port are correct.
I am trying to do a data transfer over a wired network from one node to the other.
The sender node is running windows while the receiver is running RHEL7.
I have checked that the same packet is being received on RHEL6 properly (Qt 4.8). Also, a C++ socket on RHEL7 is also able to receive the data flawlessly.
But when the same data is received on the RHEL7 machine via Qt(tried 4.4, 4.8 and 5.5) UDP socket, the socket is not picking any data larger than 65535 bytes.
Increasing the MTU for the interface does not provide any help. I have not found any file in Qt stating any MTU limit either.
Would love for some advice regarding the same.
P.S I was using broadcast receiver for receiving the data while sending near gibberish on the sender and printing the packet size received.
I’m using Wireshark to monitor telnet server/client transmissions. Occasionally the server's incoming text buffer pulls in multiple instances of the same incoming data string like so:
*1890000000000900000000A00000000B000000000064/\r*1890000000000900000000A00000000B000000000064/\r*1890000000000900000000A00000000B000000000064/\r*1890000000000900000000A00000000B000000000064/\r
When this happens Wireshark says they are retransmissions. TCP wouldn't be responsible for the duplicated data would it? Should I focus more on the client code as the source of duplication?
I might add that this application is communicating over 2.4ghz WiFi with 23 access points. It is a very congested network.
Does Wireshark show any unusually colored entries just before the perceived re-transmission? If wireshark says the packet is a re-transmission, you can assume the server (via TCP) is re-sending it. You can verify this if may appear the client does not send an ACK for that packet initially, or subsequently.
I am writing a RTSP client in Android. I am able to receive the Responses for all the requests
i.e.,
DESCRIBE it sends back the 200 OK
SETUP with transport: RTP/AVP:unicast:client_port=4568:4569 got the 200 OK Message back
Sent PLAY, and got the OK Message
After that how to get the audio and video frames?
I have searched on blogs, but all say to listen at client_port but I am not receiving any packets.
Please let me know am I doing correctly.
You may or may not know this, but Android has built in support for RTSP using the VideoView.
http://developer.android.com/reference/android/widget/VideoView.html
This may cut down on your development time...or it may be totally useless if you're trying to roll your own RTSP stack.
RTSP is only used to start the streaming. It gives you an SDP description of the real streams. You have to manage an RTCP connection and a RTP connection per channel (audio / video). The ports to use are the "client_port" ones.
It is pretty complex to code a RTSP/RTCP/RTP stack from scratch. You can have a look at the live555 library that implement such a stack in c++.
Put a sniffer on the network, you should see UDP packet with destination port 4568 targeted at your IP address.
With a decent sniffer, you will be able to see the rtsp dialog. Maybe you are missing something in the answers
You should also check the content of the SETUP response, to see if the port you requested were accepted.
Things to check :
Listening in UDP.
Firewall rules.
Range of the play request : Don't specify any to be sure the server will be playing something.
If you are behind a router or firewall, you probably won't receive anything, because your router / firewall don't know what to do with incoming UDP packets
Try first with a local Darwin Streaming server installed within your LAN.that way Firewall wont matter.Streaming will work.
If you want to try from external server then:
1) Check the client_ports mentioned in the SERVER response,some servers suggest different ports from the one requested.you have to use the ports suggested by server.
2) If the ports are correct, then you can send 64byte empty packets from each of the UDP ports to the server(called "door openers").
3) If the above two don't fix it, check the server side logs.The server might be closing the UDP ports.