network-programmingtcpiptcpdumpicmp

Troubleshooting network connectivity issues in a local network environment after adding dummy interface to the local subnet


As part of studying the network stack, I am conducting various experiments in a local network. Here's a question about one of them.

In the local network, I have two devices, with addresses 192.168.1.25 and 192.168.1.232. I connected via SSH from the first device to the second device (the address belonged to the wlo1 interface). After that, in a tmux session, I executed the commands:

sudo ip link add vvv_0 type dummy
ifconfig vvv_0 192.168.1.250

(this address is not assigned to anyone else).

After executing the second command, the connection to the second device was interrupted, and after some time the SSH session ended automatically with a Broken pipe message.

When trying to run

ping 192.168.1.232

on the first device and the command

sudo tcpdump icmp

on the second, the following was observed: On the first device:

PING 192.168.1.232 (192.168.1.232): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3

On the second device (packets were basically caught):

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wlo1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
00:37:46.518117 IP MBP-Device > device-VivoBook-ASUSLaptop-X515JAB-X515JA: ICMP echo request, id 56678, seq 0, length 64
00:37:46.856042 IP MBP-Device > device-VivoBook-ASUSLaptop-X515JAB-X515JA: ICMP echo request, id 56678, seq 1, length 64
00:37:47.988090 IP MBP-Device > device-VivoBook-ASUSLaptop-X515JAB-X515JA: ICMP echo request, id 56678, seq 2, length 64
00:37:48.808157 IP MBP-Device > device-VivoBook-ASUSLaptop-X515JAB-X515JA: ICMP echo request, id 56678, seq 3, length 64

Then I executed directly on the second device the command:

sudo ifconfig vvv_0 0.0.0.0

After that, I was able to reconnect via SSH to the second device from the first device.

What could have been the cause of the loss of connection between the first and second devices?


Solution

  • The reason is found. After assigning 192.168.1.250/24 to vvv_0, route table changed on the second device.

    ip route show output before assigning:

    default via 192.168.1.1 dev wlo1 proto dhcp metric 600 
    169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 
    172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
    192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.232 metric 600 
    192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
    

    After:

    default via 192.168.1.1 dev wlo1 proto dhcp metric 600 
    169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 
    172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
    192.168.1.0/24 dev vvv_0 proto kernel scope link src 192.168.1.250
    192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.232 metric 600 
    192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
    

    So ICMP echo request packet was received on wlo1, and ICMP echo reply packet was sent through vvv_0, due to route table.