Real Time Streaming Protocol (RTSP)

No, there’s no guest network set up.

All the cameras are on the same network SSID (VirusLoader2.4).

Oddly enough, although the Foscam works through the app (and through tinyCam) the MAC address that the Foscam app shows doesn’t match anything in the router device list. (??) Zoneminder shows it as being on 192.168.254.62 (where it was working until I plugged the PC into the router by wire).

Here are the network IDs of the 2 Wyze cams, plus the Amcrest.

wyzecams_SSID
amcrest_SSID

Hmmm … well, it sure does look like all the cameras are in the same subnet and on the same SSID, which makes this pretty weird.

What is that screenshot from? (Is that your Arris modem? I’m surprised that - from the images in the list - it looks like the software knows that the ips are cameras. My Arris modems have no images but they also show a bit more information than what’s in your list.)

Also, what’s the IP address of your PC, when it’s on the wired network, and when it’s on wireless?

When the PC is on the wired network, is it plugged directly into your Arris modem, or is there anything else between the PC and the modem?

1 Like
  1. Yes, it’s from the main screen of the Arris router. It’s not automatically recognizing the devices; the Arris interface lets you assign an icon to each item in the list.

  2. The Arris interface reports the PC running Zoneminder is on 192.168.254.10, port 4.

  3. The PC running ZM is plugged directly into the router/modem.

Okay, so right now with the PC on the wired network, it’s the amcrest that is not accessible, right?

On the PC running zoneminder, what do you get if you run

   arp 192.168.254.42 

(That’s the IP address of the amcrest from your screenshot. Substitute the correct IP address if it has changed. Ideally, you should see the mac address of the amcrest when you do this.)

Also, what do you get if you run

  route -n 

Lastly, when you ping and/or try to use telnet to port 554 on the ip address of the amcrest, what exactly happens? (i.e. no response at all, or do you see any kind of error message?)

(Sorry for the back and forth. This is turning out to be puzzling, although I still think it’s likely to be a slight misconfiguration somewhere.)

2 Likes

If I run “arp 192.168.254.42”, I get:

Address HWtype HWaddress Flags Mask Iface
AmcrestCam1.frontierloc ether 3c:ef:8c:aa:1c:48 C wlp1s0
AmcrestCam1.frontierloc (incomplete) enp0s25

When I run route -n", I get:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.254.254 0.0.0.0         UG    100    0        0 enp0s25
0.0.0.0         192.168.254.254 0.0.0.0         UG    600    0        0 wlp1s0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlp1s0
192.168.254.0   0.0.0.0         255.255.255.0   U     100    0        0 enp0s25
192.168.254.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp1s0

When I telnet to the Amcrest, this is what I get:

telnet 192.168.254.53.42  554
telnet: could not resolve 192.168.254.53.42/554: Name or service not known 

(Again, this is with the cable plugged in, I can try it after unplugging the ethernet cable if you want to try that.)

No trouble at all for the back and forth, I’m grateful for the help from someone that knows alot more about this than I, and who knows what to look for. :slight_smile:

Let’s focus on the wired network for now, and if we don’t get anywhere we can try the other way around.

One interesting thing that I see from your ifconfig output is that your PC is still connected to your wireless, but the routes are set up so that it will always prefer to send traffic on the wired network while the wired network is connected. From the arp output, the amcrest mac was visible only via wireless and not via the wired network … That doesn’t say exactly why the amcrest isn’t reachable but I’m wondering why it even tried the wired network – and perhaps the root of the problem is that it thinks your amcrest might be reachable directly via the wired network without going through the gateway. (I’m not sure, but less try to narrow it down.)

It would be nice to debug this without having 2 network interfaces active at the same time. Is it possible for you to turn off the wireless on your PC and then send the outputs again for:
route -n
arp 192.168.254.42
arp 192.168.254.53
telnet 192.168.254.42 554

(Btw, you mistyped the telnet command ip address in the last round of output.)

Shutting down the wireless on your PC will allow us to see if any of the wifi cameras can actually be accessed from the wired network.

If it’s not possible to turn off wireless on your PC, then unplug the wired network from the PC, and run the above commands, and we’ll try to figure out why the wyze cams aren’t reachable but the amcrest is.

Lastly – Is your Amcrest camera only connected to wireless, or does it happen to also be plugged into the wired network?

1 Like

Okay…here we go. :slight_smile:
I unplugged the network cable, and the other cameras came back online, including the Wyze camera that has the RTSP firmware. (errr, whut?)

Anyway, here’s the output of those commands:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.254.254 0.0.0.0 UG 600 0 0 wlp1s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlp1s0
192.168.254.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp1s0


arp 192.168.254.42
Address HWtype HWaddress Flags Mask Iface
AmcrestCam1.frontierloc ether 3c:ef:8c:aa:1c:48 C wlp1s0
secuser@secuser-control:/$ arp 192.168.254.53
Address HWtype HWaddress Flags Mask Iface
WyzeCam1-192.168.254.53 ether 2c:aa:8e:11:fe:1f C 

telnet 192.168.254.42 554
Trying 192.168.254.42...
Connected to 192.168.254.42.
Escape character is '^]'.
Connection closed by foreign host

Soooooo, maybe all I need to do is flash the second Wyze camera with the new FW. I’m confoozed. I could have sworn it was not working, which is why I came here in the first place. Maybe I have a head injury.

Okay, so it sounds like you’re fine now?

Now that you’ve disconnected the wired network, there is no ambiguity in your routing table as far as how to reach the cameras. (Notice that there’s only one entry for 192.168.254.0, whereas there were two previously.) I don’t know exactly what happened, but assuming you weren’t just imagining it, I think something on the PC was confused about which network interface to use to try to contact your cameras.

Anyway, if it happens again, please rerun those commands with the PC connected to just one network and we can look at it again :slight_smile:

2 Likes

InnocentBystander, thank you very much for all your help, I sincerely appreciate it. Wyze is lucky to have you here in their forums.

I’ll be hooking up some more cameras as I go about building my homebrew DVR system, so there’s a better than average chance I’ll be back, :slight_smile:

In any case, thank you again for all your help!

Hi there. Sorry about the wait. If you insert a SD card to the camera and hear the “Ding-Ding” sound, there would be a device log created on the SD Card.

Hi there. Thank you for the update. Could you help send me more information about the two beta2 cameras? Did the turn-off happen again later?

Thank you so much for the help troubleshooting this issue.

We have problems with continuous record if the cam doesn’t have internet connection. It stops recording after 2-2.5 hrs. You said a couple hours, would that be 2-2.5 hrs. You mention connection to the internet, your cams have access to WiFi but not the internet, is that what you are saying? The continuous recording problem I assumed was due to loss of WiFi but I’m thinking it’s actually due to loss of internet now if yours problem has WiFi still.

@minnix,

Check to see if you select RDP/UDP (or RDP/Unicast) on your Remote Method selection and use that. Note that my cams do not have access to the internet (have two network cards in same computer, with different IP addresses and cam network card has no gateway).

https://zoneminder.readthedocs.io/en/stable/userguide/definemonitor.html

Had the same problem on Blue Iris until I selected RDP/UDP and assigned a different port to the two I have (7100, 7200) and it’s been running 24/7 for several days (using the first V2 beta version). Note however, if I make a change via BI dialog for the camera, it looses the signal and I have to unplug/plug the AC on the cam.

Is UDP better for RTSP? I have a lot more visual artifacts appearing in my videos when I use UDP over TCP. If I was multicasting I get the benefit of UDP, but unicasting the overhead seems minimal and the quality appears much better (in my case anyway, I cant go more than about 10 seconds of video before compression error type pixellation / bleeding occurs).

TCP has a lot of overhead with a three-way handshake setup and teardown. UDP has no acknowledgment of data packets received and will drop packets received out of order, etc. TCP for live Video and VoIP can suffer from high latency and be choppy as it will wait for a missing or late packet. This can lead to more issues with the extra overhead in bandwidth use than the occasional dropped packets of UDP. TCP is good for routing and control like PTZ where you need confirmation of an action.
What RTSP does by specification is a combination of both.

RFC 2326
Reliability and Acknowledgements

Requests are acknowledged by the receiver unless they are sent to a multicast group. If there is no acknowledgement, the sender may resend the same message after a timeout of one round-trip time (RTT).
The round-trip time is estimated as in TCP (RFC 1123) [18], with an initial round-trip value of 500 ms. An implementation MAY cache the last RTT measurement as the initial value for future connections.

If a reliable transport protocol is used to carry RTSP, requests MUST NOT be retransmitted; the RTSP application MUST instead rely on the underlying transport to provide reliability.

If both the underlying reliable transport such as TCP and the RTSP application retransmit requests, it is possible that each packet loss results in two retransmissions. The receiver cannot typically take advantage of the application-layer retransmission since the transport stack will not deliver the application-layer retransmission before the first attempt has reached the receiver.

If the packet loss is caused by congestion, multiple retransmissions at different layers will exacerbate the congestion.

1 Like

Thanks. Looks like my problems were resolved by the commit I mentioned in the new version of Home Assistant though. I even bought and added another two Wyzecams and it’s all sitting up rather nicely now.

It hasn’t turned off on me again since that first night. Beta2 has been more stable than Beta1 (Beta1 has been pretty reliable for me as well).

I’m happy to help - just let me know what information you’re looking for.

Sorry - I’m not sure what link you’re looking for. Those firmware numbers are what I had installed on my 3 cameras.

2 of the cameras are running Beta2 and 1 of them is still on Beta1 (I need a ladder to get to that one so I’ll just wait until the final release of the RTSP firmware before updating that one).

When you say assigned a different port… Is this just within BI? I thought the RTSP feed was locked to 554? I do wonder if these cameras are somehow impacting themselves. Using the commonly discussed means to add these cameras to to BI, I see patterns where all my 4 V2 cameras drop at the same time with seems a bit coincidental. The drops got bad enough, I have just shut it all down until I get some answers as I was spending too much time trying to keep it all up and running.