UDP packets are sent to a Linux client. If those packets are not sent for a particular time interval(1 min) and sent again to the same UDP port, then the recv function returns -1 and error is EAGAIN. This problem occurs only when the client is connected to the network through the LAN switch. Why this problem occurs, when using a switch?
And this problem was fixed temporarily, when the UDP client uses the send function to send dummy data to the server whenever recv function returns EAGAIN error. Please someone clarify on this behaviour.
recv function returns -1 and error is EAGAIN
This means that the socket is non-blocking. If that is the case, then you might likely be missing the packet (may be calling recv() before the datagram made it to the receiver). Purely for debugging, you should make it blocking and try.
If those packets are not sent for a particular time interval(1 min) and sent again to the same UDP port
This should have anything to do with UDP datagram reception. If the sender sends a data, then the receiver's UDP buffer should store hte packet until the application calls recvfrom().
I would suggest two things.
First, you can use ss (or its earlier (deprecated on Linux) version netstat, if ss is not available). You would see something like this. If you have received the packet (datagram), then the second column (Recv-Q) pertaining to your flow should show the number of received packets; you can identify the flow using the port number on which your receiver is bound.
# ss -upan
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 *:48408 *:* users:(("dhclient",22086,20))
UNCONN 0 0 *:7000 *:* users:(("udp_server",23994,3))
UNCONN 0 0 *:68 *:* users:(("dhclient",22086,6))
UNCONN 0 0 *:631 *:* users:(("cupsd",1549,13))
UNCONN 0 0 :::47798 :::* users:(("dhclient",22086,21))
#
# netstat -upan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:48408 0.0.0.0:* 22086/dhclient
udp 0 0 0.0.0.0:7000 0.0.0.0:* 23994/./udp_server
udp 0 0 0.0.0.0:68 0.0.0.0:* 22086/dhclient
udp 0 0 0.0.0.0:631 0.0.0.0:* 1549/cupsd
udp 0 0 :::47798 :::* 22086/dhclient
#
Second, if you see nothing in the receive queue (Recv-Q), then you should use a packet capturing tool like tcpdump and see if packets are making it through?
The above problem has been resolved. Its the UDP timeout (30 sec) setting in the router which affects the packet flow after 30 seconds if there is no flow of packets to the client.
Related
I'm trying to send data from my PC to FPGA with ethernet cable.
I used this code for receiving packet's that send from my PC to FPGA (through Ethernet cable). I capture received packets on FPGA with ila(integrated logic debugger).
After programming FPGA when i used ifconfig on my linux pc, i see below: (I hidden my MAC Address)
enp7s0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1490
ether xx:xx:xx:xx:xx:xx txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1427 bytes 199195 (199.1 KB)
TX errors 1071 dropped 0 overruns 0 carrier 0 collisions 0
As i knew from this similar question, My FPGA don't have any specific ip address and even port number. it's listen on every packets that sent on RXD (ethernet mii) according to it's MAC Address.
How i can send packets to FPGA when even i haven't any specific IP and Port?
I think i should set port and IP for my FPGA in my PC(no need to change hardware) but i don't know how do it?
there are few options.
if the FPGA is directly connected to your interface, then it will receive anything you send, so no worry about the network config
if you have a switch between, you could send a broadcast message, that would be forwarded to all device in the network (assuming you don't have a complex config in your switch like vlan or similar) .
about broadcast: https://en.wikipedia.org/wiki/Broadcasting_(networking)
it is simply a dest mac with FFs
as for the actual sending, you could be using python to generate and send your packet.
scapy is a very simple package that should help you for that
doc: https://scapy.readthedocs.io/en/latest/usage.html
look at this particular example:
sendp(Ether()/IP(dst="1.2.3.4",ttl=(1,4)), iface="eth1")
I know that control bits in tcp define the flags of TCP connection like SYN, FIN, ACK. But from my network traffic sometimes for some packets control bits are 0 (not-set).
What does this behaviour mean?
Those are flags of a TCP segment, not connection.
When a flag bit isn't set that indicates the absence of the meaning and behavior defined for the corresponding flag.
It means ACK and only ACK flag is set. RFC says ACK is 16, however it's only 16 when used in combination with another flag e.g. SYN/ACK (18), FIN/ACK (17). Flags value 0 could also indicate a 'null' scan.
If you see a flow record with value 2 and there are 8 packets in it, that means there are both SYN packet(s) and ACK packets.
If you see 18 and there are more than 1 packet in the flow that means there is at least one SYN/ACK and the rest are ACK.
I am using tcpdump/wireshark to capture tcp packets while tcp client sending data to tcp server. The client simply sends 4096 bytes to server in one "send()" call. And I get different tcp packets on two sides, two packets on the sender side seem to be "compacted" on the receiver side, this conflicts with how i understand the tcp protocol and I stuck on this issue for a few days and really need some help.
Please notice the packet length in following packets:
client (sender) sends 2 packets 0Xbcac (4) and 0xbcae (5), sends 2896 + 1200 = 4096 bytes in all.
(0xbcac) 4 14:31:33.838305 192.168.91.194 192.168.91.193 TCP 2962 59750 > 9877 [ACK] Seq=1 Ack=1 Win=14720 **Len=2896** TSval=260728 TSecr=3464603 0
(0xbcae) 5 14:31:33.838427 192.168.91.194 192.168.91.193 TCP 1266 59750 > 9877 [PSH, ACK] Seq=2897 Ack=1 Win=14720 **Len=1200** TSval=260728 TSecr=3464603 0
However on the server (receiver) side, only one packet is presented, with ip.id=0xbcac and length = 4096 (receiver.packet.0xbcac = sender.packet.0xbcac + 0xbcae):
(0xbcac) 4 14:31:33.286296 192.168.91.194 192.168.91.193 TCP 4162 59750 > 9877 [PSH, ACK] Seq=1 Ack=1 Win=14720 **Len=4096** TSval=260728 TSecr=3464603 0
I'm aware that tcp is a stream protocol and data sent can be divided into packets according to MSS (or MTU), but i guess the division happens before packets are sent to NIC, thus before captured. I'm also aware that the PSH flag in packet 0xbcae lead to writing data from buffer to NIC, but that cannot explain the "compacted" packet. Also I tried in client to send 999999 bytes in one "send" call and the data are divided into small packets and sent, but still mismatch the packets captured on server side. At last I disable tcp nagle, get the same result, and ruled out that reason.
So my question is the mismatching i encountered normal? If it is, what caused this? If not, i'm using ubuntu 12.04 and ubuntu 13.10 in LAN, and what is the possible reason to this "compacted" packet?
Thanks in advance for any help!
two packets on the sender side seem to be "compacted" on the receiver
side
It looks like a case of generic receive offload or large receive offload. Long story short, the receiving network card does some smart stuff and coalesces segments before they hit the kernel, which improves performance.
To check if this is the case you can try to disable it using:
$ ethtool -K eth0 gro off
$ ethtool -K eth0 lro off
Something complementary happens on the sending side: tcp segmentation offload or generic segmentation offload.
After disabling these don't forget to reenable them: they seriously improve performance.
[root#:/]# netstat -eont
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Timer
tcp 0 0 10.99.92.201:2000 10.99.92.82:63407 ESTABLISHED 0
keepalive (2.28/0/0)
tcp 0 29200 10.99.92.201:2004 10.99.92.82:63408 ESTABLISHED 0
unkn-4 (50.92/0/0)
[root#:/]# netstat -eont
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode Timer
tcp 0 0 10.99.92.201:2000 10.99.92.82:63407 ESTABLISHED 0 385
keepalive (0.35/0/0)
tcp 0 29201 10.99.92.201:2004 10.99.92.82:63408 FIN_WAIT1 0 0
unkn-4 (33.99/0/0)
[root#:/]# netstat -es
Ip:
195 total packets received
0 forwarded
0 incoming packets discarded
194 incoming packets delivered
260 requests sent out
Icmp:
0 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
0 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
Tcp:
0 active connections openings
2 passive connection openings
0 failed connection attempts
0 connection resets received
1 connections established
131 segments received
255 segments send out
1 segments retransmited
0 bad segments received.
0 resets sent
Udp:
10 packets received
0 packets to unknown port received.
0 packet receive errors
4 packets sent
RcvbufErrors: 0
SndbufErrors: 0
[root#:/]#
I have an Linux (2.6.33) application running on ARM embedded system. The TCP socket is
showing the with "netstat" are pasted above.
What is the meaning of unkn-4 state for timer( in this state the Send-Q is showing 29200
and socket is ESTABLISHED. But after some time socket goes to FIN WAIT 1 state but and
Send-Q is increased by 1 packet. I expect that this packet is sent with RST flag.
But i didn't see this RST captured with tcpdump which is running in background.
Please help me to find out what is happening here which puts socket from ESTABLISh state
to FIN wait 1 state. I guess the RST is sent out from application but it is not sent out
on ethernet interface and lying in the tcp OUT Send-Q buffer. So i was not able to capture.
Is this correct & how to verify this?
Followed the reference but still didn't get the answer.
http://vzkernel.blogspot.in/
it's a zero window probe timer
Source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=96282
This can happen if the other side doesn't receive your SYN packet, or your side didn't receive their ACK packet.
In general terms, this is usually a symptom of packet loss.
If the TTL of a IP packet becomes 0, then who will discard the IP packet i.e., either router or host.
The router.
If the TTL is 0, the packet is discarded, and never reaches the host.
More information in wikipedia
It's the router that discards it. From this post on CiscoPress:
Time To Live (TTL) is a well-known mechanism thanks to IP. In the IP header is a field of 8 bits that signifies the time that a packet still has before its life ends and is dropped. When an IP packet is sent, its TTL is usually 255 and is then decremented by 1 at each hop. If the TTL reaches 0, the packet is dropped. In such a case, the router that dropped the IP packet for which the TTL reached 0 sends an Internet Control Message Protocol (ICMP) message type 11 and code 0 (time exceeded) to the originator of the IP packet.