Probably should find a linux networking specific community for this one…

I have a strange issue that feels very familiar, like I’ve fixed it before, but I can’t remember how.

I try to rtsp to security cam:

ffplay rtsp://user:[email protected]:554/h264Preview_01_main

And I get a no route:

Connection to tcp://192.168.19.137:554?timeout=0 failed: No route to host

rtsp://user:[email protected]:554/h264Preview_01_main: No route to host

Strange, I’m in the same subnet 192.168.19.129/24, and it worked a few days ago.

Check ping:

ping 192.168.19.137

PING 192.168.19.137 (192.168.19.137) 56(84) bytes of data.

64 bytes from 192.168.19.137: icmp_seq=1 ttl=64 time=5.69 ms

Of course… So I run the command again;

ffplay rtsp://user:[email protected]:554/h264Preview_01_main

And now it works.

I could bandaid by crontabbing a ping every hour or something, but I would really like to know why I’m getting a ‘no route’ until I ping.

My routing table is pretty basic:

default via 192.168.19.1 dev enp4s0 proto dhcp src 192.168.19.129 metric 100

default via 192.168.19.1 dev enp4s0 proto dhcp src 192.168.19.129 metric 1002

172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

172.18.0.0/16 dev br-68c1e0344e27 proto kernel scope link src 172.18.0.1 linkdown

192.168.19.0/24 dev enp4s0 proto dhcp scope link src 192.168.19.129 metric 1002

192.168.19.1 dev enp4s0 proto dhcp scope link src 192.168.19.129 metric 1024

And I don’t think I have any rules in firewall for LAN.

Any ideas?

  • jet@hackertalks.com
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Im rusty. So don’t trust this.

    It looks like you have a routing issue with your default route. The fact that a ping gets the IP to start working, tells me that you need a broadcast packet on the local network, that broadcast excites the other computer to send a message out, that updates the IP to Mac table, which then makes the machine routable because now there is a direct ethernet pathway.

    So I think the magic here is the initial broadcast ping is doing.

    Ideally this isn’t necessary, ethernet should be sending out a broadcast packet for the Mac to IP table anyway for your TCP traffic. I don’t know why that’s not happening. I would do an TCP dump in both scenarios, and see if the broadcast is going out.

    My intuition is that there’s something fucky going on with your default route, that ping is not being affected by. I bet you don’t send out a broadcast address discovery packet in the TCP scenario but you do in the ping scenario