9

Using Ubuntu 14

I have a Linux machine where there are two interfaces: eth1: 172.16.20.1 ppp0: 192.168.0.2

ppp0 is connected to a device which has a PPP interface (192.168.0.1) and a WAN interface (172.16.20.2). I can verify that this device can reach 172.16.20.1

The problem I am having is if I send a packet using Python on the same machine:

client.py

import socket
cl = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
cl.sendto("Hello", ("172.16.20.1", 5005))

server.py

import socket
srv = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
srv.bind(("", 5005))
while True:
    data, addr = srv.recvfrom(2048)
    print("Message: ", data)

the script works fine but I cannot see the packet on Wireshark coming out of eth1 (I can only see it when I choose to capture on the lo interface). I assume the OS has detected the packet is for one of its local interface and does not send it through the 192.168.0.2 socket created.

When I add the following rules to prevent this from happening:

sudo ip route del table local 172.16.20.1 dev eth1
sudo ip route add table local 172.16.20.1 dev ppp0
sudo ip route flush cache

What happens is:

  • I can see the packets on Wireshark now arriving at eth1, the source address is the address of the WAN (172.16.20.2)
  • I cannot see any output from server.py after restarting the program.

Ignoring the ppp0 interface and using two ethx interfaces: If I try to run the program in two (client and server) separate machines (without applying the rules), I can see the packets arriving at eth1 in Wireshark, and the output on server.py. If I try to run the program in two separate machines AND I apply the rules above for the ppp0 connection (I have not removed it), I can no longer see any output from server.py but can still see packets arriving on Wireshark. My knowledge of the TCP/IP stack is not good, but it looks like the link layer is no longer forwarding to the application layer?

5
  • 2
    Even if the packet is delivered locally, Wireshark should be able to capture it if you choose "any" or "loopback" as the interface to capture on. If you change routes so that the packets go out on an interface, then the local server process does not receive it, unless somthing on the other end of the wire sends it back. Jan 17, 2018 at 7:31
  • @JohanMyréen I've updated the answer, I can see the packet locally using the lo interface. But I want to make it go through the WAN via the PPP interface. This only happens if I update the rules as such (the packet shows up arriving at eth1), but the Python socket can no longer talk to the link layer
    – nnja
    Jan 17, 2018 at 7:36
  • You mix up eth0 and eth1: "eth0: 172.16.20.1", "sudo ip route del table local 172.16.20.1 dev eth1" Jan 17, 2018 at 7:39
  • @HaukeLaging I've updated it, it should be between eth1 and ppp0.
    – nnja
    Jan 17, 2018 at 7:44
  • 1
    Your question is confusing. You are sending the packet to an address on the local machine (127.16.20.1), but you expect the packet to be sent to the other device? On which host is the client and on which host is the server running? What does the routing table look like (all of them)? Jan 17, 2018 at 7:53

3 Answers 3

0

it looks like the link layer is no longer forwarding to the application layer

The link layer is not the problem; it is not affected by your configuration. This is about the network layer (IP).

The local table is the kernel's way to determine whether a packet can be delivered locally. You delete the IP address, the packet is routed or dropped.

I guess this works only because the MAC address is in the other system's ARP cache. I would expect the receiving system not to answer to ARP requests if the address is missing in the local table.

2
  • I see...is there a way to make this setup possible? The PPP connection already performs NAT, any packet received at 192.168.0.1 goes to the WAN interface
    – nnja
    Jan 17, 2018 at 7:52
  • @nnja I guess the answer is: Don't delete local IPs from the local table... Jan 17, 2018 at 7:53
-1

Make sure the UDP and IP4 checksums of received packets are correct. Enable checksum computation in wireshark and check for capture.

-1

In my case, initially, I can not see and capture the local traffic.

After investigation, the root cause is I captured the network traffic on the wrong network interface.
For example, I capture the eth0 network interface traffic instead of the loopback network interface traffic.

So to see and capture the local network traffic, you should choose loopback or any which captures the traffics for all available network interfaces.

1
  • I don't think this answers the question. While it's true that traffic can be captured only using the correct interface, I see no indication OP:s capturing in wrong interface per se. Capturing traffic in all interfaces makes no sense (it very seldom does) as this does not help OP to determine why the packets aren't arriving in application socket. I don't see how capturing traffic on loopback interface helps either. You should edit your question to explain how exactly this answer is applicable, or if it's not I'd recommend deleting it. Feb 15, 2023 at 16:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .