this post was submitted on 16 Aug 2023
1 points (100.0% liked)

Linux

48220 readers
584 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

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?

top 13 comments
sorted by: hot top controversial new old
[–] [email protected] 1 points 1 year ago

I had an issue where my docker networks started overlapping my network addresses and I had some issues to connect to the machine etc. so perhaps check to make sure your docker addresses don’t overlap your home network range somehow. Also keep the subnet mask in mind as the range might be bigger than what the first few numbers indicate.

[–] [email protected] 1 points 1 year ago

I can guess at some things but let me first start with what I think is happening:

You have a gateway set. Your device sends a broadcast arp message asking 'who has ip ' and the device with that ip is supposed to send back 'me with this mac address!'.

That device is either sending it so slowly that your machine says 'I can't go past the gateway, the gateway isn't responding' which in your error message is no route to host.

Assuming that you have no custom manual network route in play.

So things that can cause that are usually link layer and layer two issues and sometimes duplicate IPs. Two devices with the gateway ip.

You should watch your mac address table and arp table (arp a) and watch if the router gateway disappears or changes Mac addresses.

[–] [email protected] 1 points 1 year ago (1 children)

Are you sure the camera is not going into some kind of low power sleep mode and then has a wake-on-LAN functionality that only responds to icmp/magic packets? The number of embedded devices that have aggressive power saving measures built in is kinda stupid tbh.

Can you reliably rtsp from a different machine to rule out the routing table?

[–] [email protected] 0 points 1 year ago (1 children)

I can try test that.

The camera is always accessible via the android app, but that's not quite the same.

[–] [email protected] 3 points 1 year ago

The android app, if proprietary and manufacturer specific, could very well be sending its own magic wake-on-lan packet to check if the camera is alive.

I unfortunately don't know enough about nitty-gritty networking stuff to help with the actual routing though, refer to the other commenters for that.

[–] [email protected] 1 points 1 year ago

Why do you have two default routes?

The last line in your table also doesn't look right.

[–] [email protected] 1 points 1 year ago

Is there an IPSec tunel in the mix? Often, IPSec Phase2 goes down when idle, while Phase1 stays up. Upon traffic, Phase2 is brought up again, with a delay.

I usually work around this with a crontab on one of the remote servers that sends a single ping packet every minute to a local server, and pipe any output to /dev/null.

[–] [email protected] 1 points 1 year ago

Dunno how helpful this is but when I’ve had this problem in the past it was an IP conflict. Are you setting static IPs or are you using DHCP reserves for everything?

[–] [email protected] 1 points 1 year ago

I want to say ARP. Can I say ARP?

[–] [email protected] 1 points 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

[–] [email protected] 1 points 1 year ago

This is some Schrodinger's network address shit. The act of observing the network address modifies it so it can be accessed.

[–] [email protected] 0 points 1 year ago (1 children)

Do you have an IP address conflict?

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

I would check this first too, seems a bit like it. Check your arp table for anything nasty.