Random IP, Random Port

Semidragon·2022년 11월 14일

Network Basics

목록 보기

5/6

Scenario

Trying to send packets from JY server to B1 server.
Wants to send size 64 UDP packets with different Source IP/Port address (Dest Address fixed as 10.0.1.3:1234)
Trial Scenario HERE

Problem

Packets captured at L2 using Tshark / TCPdump.
However, packets do not arrive to the application layer

Trials

1. Server Application Problem?

Thought that the server application code itself might have been the problem, thus changed the server application to a simple server.py code:

import socket


localIP     = "10.0.1.3"

localPort   = 1234

bufferSize  = 1024


msgFromServer       = "Hello UDP Client"

bytesToSend         = str.encode(msgFromServer)


# Create a datagram socket

UDPServerSocket = socket.socket(family=socket.AF_INET, type=socket.SOCK_DGRAM)

# Bind to address and ip

UDPServerSocket.bind((localIP, localPort))

print("UDP server up and listening")


# Listen for incoming datagrams

while(True):

    bytesAddressPair = UDPServerSocket.recvfrom(bufferSize)

    message = bytesAddressPair[0]

    address = bytesAddressPair[1]

    clientMsg = "Message from Client:{}".format(message)
    clientIP  = "Client IP Address:{}".format(address)
    
    print(clientMsg)
    print(clientIP)

However, I was able to find that this pyhon program also was not able to capture the packets (Simple UDP client program successfully sent packet / TCPdump captured packet at L2)

2. Random IP / Port Address problem?

Next up was thinking would the random IP/Port Address be the problem.
Using Packit, I was able to generate packets at different scenarios.
[Without Randomness]
The following is a packet hexa output that was able to arrive to the server program at JY server.

[With Randomness]

However, packets with randomness were not able to arrive to the socket programming

3. Checksum problem?

Then, I was doubting whether the Checksum was the problem.
Due to fast packet generating needs, packet-gen and packit might not be correcting the right packet checksum.
(With Packit)

(With Packet-gen)

However, after checking the checksum of the packet via udp.check_cheksum:TRUE , I was able to find that no packets were generating checksum false packets, on both DPDK_packet_gen and Packit.

4. UDP Protocol Problem?

After doubting the Checksum, I've continued with doubting the packet contents. (because its the only possibility when it arrives at L2 but not at the application level..)
Then, I tried to go back and see if the application will be able to recieve raw packets, not only the UDP packets.
So, instead of UDP socket and binding:

UDPServerSocket = socket.socket(family=socket.AF_INET, type=socket.SOCK_DGRAM)
UDPServerSocket.bind((localIP, localPort))

I changed to (where the "ens6f0" is the interface name):

ETH_P_ALL = 3
UDPServerSocket = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, socket.htons(ETH_P_ALL))
UDPServerSocket.bind(("ens6f0", 0))

Then, Wala!

I was finally able to get some packets at the application level.
Now, I had 2 choices to make.
1)Go back to the experiment with raw packet
2) Continue the dig of why UDP packets do not arrive.
With my curiosity, I had to cotinue and find out why UDP packets did not arrive. (Might stop if no hope comes out..)

5. MAC Address Problem?

So then, I came back to see the packet information once again:
(Packet header: may differ from UDP -> TCP)

(Right arrived packet with Socket programming)

(Right arrived packet with Packit)

(Right arrived packet from Packet-gen)

(Wrong Random ip/port packet from Packit)

(Wrong Random ip/port packet from Packet-gen)

I was able to find that the Mac address was showing 00:00:00:00:00:00
Thus, I had to change the mac address range,
and apply range in packet-gen using enable 0 range
AND THIS WORKED!

However, from further trials I was able to find that another reason that this worked was bacause I have set the src IP address range as range 0 src ip 10.0.1.0 10.0.1.0 10.0.1.99 0.0.0.1 (start/min/max/interval)
I have found that when I change the range as range 0 src ip 10.0.0.0 10.0.0.0 10.0.0.99 0.0.0.1, (10.0.1 -> 10.0.0) then the packet did not arrive again.
Thus, the question still remained of why actual RANDOM packets do not arrive.

6. Local Remote?

I noticed that the difference of 10.0.1 -> 10.0.0 was local and remote.
And also found that the packets arrived successfully with the wrong MAC address.
Thus, I speculated if there were some errors on there.
The above is 10.0.0.4 (remote, not arrived) and the below is 10.0.1.4(local, arrived)

From this packets, I was able to find 3 difference:
1. Identification field (c8 19 <> 88 4f)
2. Header Checksum (9d 9f <> dc 69)
3. Source IP (0a 00 00 04(10.0.0.4) <> 0a 00 01 04(10.0.1.4))

In IPv4, the Identification (ID) field is a 16-bit value that is unique for every datagram for a given source address, destination address, and protocol, such that it does not repeat within the maximum datagram lifetime

Identification field and source IP are different as ofcourse as IP is changed, and both packet's header checksum was found to be correct.
?
Then, WHY IS THE PACKET NOT ARRIVING ONLY FOR REMOTE IP ADDRESS!!!!!!!!!

Then I found,

if the destination IP address belong to the same IP subnetwork the ARP module
will send a broadcast ethernet message (ARP query) asking the MAC address for the destination IP address, if the destination is not on your local network the ARP module will send an ARP query using the IP address of your router.
The device that has that IP address, or it's also valid for other devices to respond to the query will send a response directed to your device which will include the MAC address of the destination that you must use to establish the connection with the remote node or the router to forward the packet beyond your network.

Upper layer software, such as the IP stack, typically does not examine the MAC address on the basis that if the frames passed thru the NIC is must be for this host. This means that an IP packet with a broadcast or multicast MAC address will be accepted by the stack.