I'm trying to send raw UDP datagrams using a raw IP socket on Linux (I specify both IP and UDP headers).
Should I check the mmsghdr.msg_len field after sendmmsg? This field designates a number of bytes of a datagram sent, but since I send IP datagrams I think it should always equal to a length of a whole datagram (or not?).
Notes
I construct a UDP datagram completely by myself. Only one UDP packet (UDP header + data) is encapsulated into an IP datagram.
Related
When we use recvfrom() to read a packet from UDP socket, we cannot read it partially. Because if we read a small part of UDP packet first(by passing a small buffer), the reminder of packet is dropped as mentioned here:
All receive operations return only one packet. When the packet is
smaller than the passed buffer, only that much data is returned; when
it is bigger, the packet is truncated and the MSG_TRUNC flag is set.
But I wonder if the same thing happens if we just inspect packet using MSG_PEEK flag. Will reminder of packet is dropped if I just peek the UDP message?
Will reminder of packet is dropped if I just peek the UDP message?
Nothing will be dropped, since with the MSG_PEEK flag set, the state of the socket's incoming-data-buffer is not modified; the entire packet will remain in the socket's buffer.
Only the first part of the packet's data will be copied into your too-small destination-data-buffer, of course.
I am learning about codecs,and I get this question that I didnt understood the answers.
Assuming CODEC G.711 where each datagram carries 20ms of voice, indicate:
3) [E] How many bytes of G.711 encoding does each datagram carry?
A- 20ms/8*0,02=160
4) What is the byte size of each frame carrying G.711 on an Ethernet network?
Note: The dimensions (in bytes) of the base headers of some of the protocols that might be involved in the communication: Ethernet = 18, IP = 20, TCP = 20, UDP = 8, ICMP = 8, RTP = 12
A-18+20+8+12+160=218
I didnt get this math..
g711 codecs pure bandwidth(codec only) is 64kbit, exact
g711 packet length can be 10,20(default),30.. upto 150ms.
So for default settings you have 20ms packet(50 packet/sec) at 64kbit = 160Bytes without udp packet header
Full length of g711(default 20ms) packet is
TPS = 18 bytes+20 bytes+8 bytes+12 bytes+160 bytes
You have 160 bytes of raw data, first you make it rtp packet(timestamp mostly), see packet size at https://en.wikipedia.org/wiki/Real-time_Transport_Protocol
RTP required fore reorder when you get two packet in different order(sometimes happens).
Now you have rtp, BUT it not suitable for send, need know where to send, need address and port. For port part you use UDP packet https://en.wikipedia.org/wiki/User_Datagram_Protocol
For address you use IP packet header, without address it not go destination machine
https://en.wikipedia.org/wiki/Internet_Protocol
Okay, now you have packet. But you still need actually send it. For send you use some hardware level protocol, in this case it is ETHERNET. Ethernet have mac address, which allow fast switching without parse of IP. That is last 18 bytes
https://scialert.net/fulltext/?doi=ajsr.2017.110.115
In some cases you can prefer TCP(when you have packet loss or complex networking), in this case you not use UDP, use TCP instead of it. So you swap 8bytes UDP for 20 bytes TCP.
In traceroute while revising the source code, I saw that the ICMP inbound packet size is hard coded to 512.
I don't know why the size is limited to 512 bytes. What happen if the ICMP inbound packet size is greater than 512 bytes?
In general, there are 3 ways(I am not familiar with implementation using GRE protocol) to implement traceroute, sending ICMP Echo requests, UDP packets or TCP SYN packets with gradually increasing TTL value, starting with TTL value of 1.
if it sends ICMP echo request, it expects ICMP TIME Exceed message(8 bytes + IP header(20 bytes) + first 8 bytes of original datagram's data) or the destination is reached and returns an ICMP echo reply which is 20 + 8 bytes long. Though according to rfc 792, it allows for an arbitrary data length for echo request or reply , but traceroute needn't that.
if it sends UDP pakcets, it expects ICMP TIME Exceed message or the destination is reached and return a port unreachable message which is 20 + 8 + 20 bytes long. Maybe some implementations add some data, but it wouldn't be too much.
if it sends TCP SYN packets, the inbound packets should be ICMP TIME Exceed message, TCP SYN+ACK packet or TCP RST packet, all of them are much less than 512 bytes.
I'm looking for a detailed documentation about content of files /proc/net/nf_conntrack and/or /proc/net/ip_contrack on Linux systems.
Yes, I know, there are many utilities which can show me the content of these files in human readable format, but... I'd like to do it on a SOHO router, with Tomato USB firmware (by Shibby).
The optware AFAIK deprecated and the entware doesn't contain any of these utilities, so I'd like to write a script instead of them, but I didn't find a detailed description of these files :(
The format of a line from /proc/net/ip_conntrack is the same as for /proc/net/nf_conntrack, except the first two columns are missing.
I'll try to summarize the format of the latter file, as I understand it from the net/netfilter/nf_conntrack_standalone.c, net/netfilter/nf_conntrack_acct.c and the net/netfilter/nf_conntrack_proto_*.c kernel source files. The term layer refers to the OSI protocol layer model.
First column: The network layer protocol name (eg. ipv4).
Second column: The network layer protocol number.
Third column: The transmission layer protocol name (eg. tcp).
Fourth column: The transmission layer protocol number.
Fifth column: The seconds until the entry is invalidated.
Sixth column (Not all protocols): The connection state.
All other columns are named (key=value) or represent flags ([UNREPLIED], [ASSURED], ...). A line can contain up to two columns having the same name (eg. src and dst). Then, the first occurrence relates to the request direction and the second occurrence relates to the response direction.
Meaning of the flags:
[ASSURED]: Traffic has been seen in both (ie. request and response) direction.
[UNREPLIED]: Traffic has not been seen in response direction yet. In case the connection tracking cache overflows, these connections are dropped first.
Please note that some column names appear only for specific protocols (eg. sport and dport for TCP and UDP, type and code for ICMP). Other column names (eg. mark) appear only if the kernel was built with specific options.
Examples:
ipv4 2 tcp 6 300 ESTABLISHED src=1.1.1.2 dst=2.2.2.2 sport=2000 dport=80 src=2.2.2.2 dst=1.1.1.1 sport=80 dport=12000 [ASSURED] mark=0 use=2 belongs to an established TCP connection from host 1.1.1.2, port 2000, to host 2.2.2.2, port 80, from which responses are sent to host 1.1.1.1, port 12000, timing out in five minutes. For this connection, packets have been seen in both directions.
ipv4 2 icmp 1 3 src=1.1.1.2 dst=1.1.1.1 type=8 code=0 id=32354 src=1.1.1.1 dst=1.1.1.2 type=0 code=0 id=32354 mark=0 use=2 belongs to an ICMP echo request packet from host 1.1.1.2 to host 1.1.1.1 with an expected echo reply packet from host 1.1.1.1 to host 1.1.1.2, timing out in three seconds.
The response destination host is not necessarily the same as the request source host, as the request source address may have been masqueraded by the response destination host.
Please note that the following information might not be up-to-date!
Fields available for all entries:
bytes (if accounting is enabled, request and response)
delta-time (if CONFIG_NF_CONNTRACK_TIMESTAMP is enabled)
dst (request and response)
mark (if CONFIG_NF_CONNTRACK_MARK is enabled)
packets (if accounting is enabled, request and response)
secctx (if CONFIG_NF_CONNTRACK_SECMARK is enabled)
src (request and response)
use
zone (if CONFIG_NF_CONNTRACK_ZONES is enabled)
Fields available for dccp, sctp, tcp, udp and udplite transmission layer protocols:
dport (request and response)
sport (request and response)
Fields available for icmp transmission layer protocol:
code (request and response)
id (request and response)
type (request and response)
Fields available for gre transmission layer protocol:
dstkey (request and response)
srckey (request and response)
stream_timeout
timeout
Allowed values for the sixth field:
dccp transmission layer protocol
CLOSEREQ
CLOSING
IGNORE
INVALID
NONE
OPEN
PARTOPEN
REQUEST
RESPOND
TIME_WAIT
sctp transmission layer protocol
CLOSED
COOKIE_ECHOED
COOKIE_WAIT
ESTABLISHED
NONE
SHUTDOWN_ACK_SENT
SHUTDOWN_RECD
SHUTDOWN_SENT
tcp transmission layer protocol
CLOSE
CLOSE_WAIT
ESTABLISHED
FIN_WAIT
LAST_ACK
NONE
SYN_RECV
SYN_SENT
SYN_SENT2
TIME_WAIT
The file ip_conntrack contains only ipv4 specific conntrack entries whereas nf_conntrack includes both ipv4 and ipv6 protocol conntrack entries.
nf_conntrack file is registered with proc file system using code in
net/netfilter/nf_conntrack_standalone.c
whereas ip_conntrack file is registered with proc file system through the code in
net/netfilter/nf_conntrack_l3proto_ipv4_compat.c
I need to capture packets from all network interfaces on Linux machine.
In order to do it I'm planning to use pcap_open_live() API and pass "any" as a device argument.
I have different types of ports: Ethernet ports (say eth0) and GRE tunnels (say tun0)
The packets that coming from different types of interfaces has different headers format:
Packets from Ethernet port has MAC header
Packets from tunnel coming with a Linux "cooked" capture encapsulation (16 bytes) header
How can I check into pcap_loop() callback handler what type of packet header I got?
All packets you receive get the same type of packet header; that's the type you get when you call pcap_datalink() on the pcap_t. The values that pcap_datalink() returns are the DLT_ values as shown in the Link-Layer Header Types page on the tcpdump.org site.
If you've opened the any device, pcap_datalink() will return DLT_LINUX_SLL, meaning that ALL packets you capture will have the "cooked" capture header - even the ones from eth0! You'd have to capture on eth0, rather than any, to get Ethernet headers for those packets.