Are datagrams a protocol or not?
Is "Ping" (protocol ICMP) used in an IP DATAGRAM? Or is it using other protocols, such as TCP or UDP?
How do you know the message "Reply" the way back?
Why the Tel number stays the same?
https://en.wikipedia.org/wiki/IPv4#Protocol
Datagrams are basically the packets that go back an forth over the network at IP level. Each of these packets can specify a protocol. You can have TCP, UDP, ICMP, etc. (see https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers)
So to answer your question, yes the protocol for datagrams is basically IP.
You can have higher level protocols that run over IP such the one above.
See https://en.wikipedia.org/wiki/Internet_protocol_suite
Ping uses the ICMP protocol.
Are datagrams a protocol or no?
'Datagram' is the name of the unit of transmission in the UDP protocol.
Is "Ping" ( protocol ICMP ) used in a IP DATAGRAM?
The question doesn't make sense. It would make more sense to say that the ICMP protocol is transmitted via IP packets.
Or is it using other protocols, such as TCP or UDP ?
ICMP is a protocol: you said so yourself; and it is layered over the IP protocol.
Related
I know that SMTP is based on TCP, like HTTP, but how does Wireshark judge it as SMTP rather than TCP?
How does Wireshark judge it as SMTP rather than TCP?
It doesn't. SMTP is inside the payload of a TCP packet. So Wireshark will first dissect TCP and if it has dissectors available to parse the payload, it will also parse that, like SMTP in this case. In conclusion, your "SMTP packet" is also a TCP packet. E. g., you can filter your SMTP packets by TCP attributes like ports.
I am debugging some code which is using UDP communications.
My CLIENT is behind a NAT and a Firewall.
My Server is an AWS machine on which I opened said UDP ports.
However, part of this protocol involves the server answering my client. Which I expected not to work (NAT & Firewall). To my surprise, my client is recieving packets from the server!
How is this possible? I mean, TCP (over UDP) has a concept of a connection, so I guess that the NATs and routers can associate an incomming UDP packet as a reply to an egress connection. But how (and why) does this work for a pure UDP protocol? Would my NAT/Firewall let in random UDP into my client machine?
How is this possible?
That's how NAT works. You wrote that the server is answering you client. That means that the client initiated the conversation. It doesn't matter that you're using UDP and not TCP. The NAT device still creates an appropriate mapping to let answers trough. Otherwise all UDP would have been broken behind NAT.
I mean, TCP (over UDP) has a concept of a connection, so I guess that
the NATs and routers can associate an incomming UDP packet as a reply
to an egress connection. But how (and why) does this work for a pure
UDP protocol?
The fact that UDP isn't connection-oriented is irrelevant. Sure, TCP has the concept of sessions, but both have port numbers and that's really all the NAT needs.
Would my NAT/Firewall let in random UDP into my client machine?
It's not "some random UDP". It's a UDP segment from the same IP and port number that the client sent something to.
When a host needs to resend a packet (whatever the payload), is there any field in the header that gets modified, so that you can tell that it is a duplicate packet?
No. IP packet are not resent, that's a function of the higher protocol layers.
Some transport protocols, e.g. TCP or SCTP have retransmission built into them that re-sends packets at that protocol layer, some application protocols, e.g. DNS, applies retransmission at the application protocol layer.
The IP layer does not know or care about this, there is no protocol fields that identifies a retransmission from a higher layer.
As UDP is a connectionless protocol, once the forwarder gets a packet and sends it to a target ip, and the target ip responds with data, how can the forwarder know what ip to send the packet to?
If you are talking about a standard gateway, it knows where to send it because the packet has a destination IP address and port.
If you are talking about NAT, then the router must remember what it has recently sent out and accept corresponding incoming packets. The router maintains a session internally, which will stay alive for some configured period.
What is TCP response packets?
How to meet this requirement in access-list on a router?
You probably want to look up stateful firewalling for whatever router you're using.
TCP response packets are basically any related TCP packets that come back after an initial SYN has been sent. Typically this would be either a packet with SYN+ACK set, or one with RST if the connection was refused.
Stateful firewalls keep track of not just the source and destination of individual packets, but what connection the packets belong to. By doing this they are able to distinguish between expected, legitimate replies to SYN packets (and others) and random or malicious unrequested "replies".