steveharman Posted March 22, 2022 Share #1 Posted March 22, 2022 Hi, My DSM install has got itself very confused. For a couple of years it has been running fine on a Dell Optiplex, but since I powered it down to upgrade the HDDs it's proving impossible for Surveillance Station to see my cameras. As part of trying to debug this; when I ssh into the box on its IP of say 192.168.1.1 it insists on sending traffic out on one of the other NICs which isn't physically on the 192.168.1.0 LAN - so there's no way of reaching my cameras that are also on the 192.168.1.0 LAN. I've spent days on this with the assistance of numerous people and none of it makes any sense. I'm assuming this is also the reason Surveillance Station can't see my cameras as there's no route from the second NIC to my internal 192.168.1.0 LAN. I'm happy to rebuild from scratch as if it's a fresh setup, to see if that helps. Is that going to be possible? Can I boot with the XPenology USB stick installed and perform a fresh install over my existing setup? Thanks Quote Link to comment Share on other sites More sharing options...
IG-88 Posted March 23, 2022 Share #2 Posted March 23, 2022 (edited) ssh into the system and do "ifconfig" and "route -v" the results may tell us about whats configures in the nic's and how the routing is done you should also do a traceroute to the destination address of the camera On 3/22/2022 at 5:13 PM, steveharman said: Can I boot with the XPenology USB stick installed and perform a fresh install over my existing setup? in theory there is a 2nd boot menu entry about "reinstall" that is supposed to reset to factory defaults (and keep data in the volume) Edited March 23, 2022 by IG-88 Quote Link to comment Share on other sites More sharing options...
steveharman Posted March 24, 2022 Author Share #3 Posted March 24, 2022 Thanks for the reply @IG-88 I have a simple LAN setup - all my LAN kit is on 192.168.1.0 and in fact the NAS and my two Reolink cameras and only a few IPs apart. Crucially I can browse to both cameras perfectly fine via the Reolink web interface and they're both streaming video as expected - so I'm pretty confident about the credentials I'm adding to Surveillance Station - yet for some reason my cameras that have been working fine for a year or more can no longer be reached by Surveillance Station running on the NAS. I've tried removing & re-adding both cameras into Surveillance Station I've tried uninstalling Surveillance Station itself, clearing its settings when prompted and re-installing it I've tried powering down both cameras I've tried powering down the NAS I've tried specifying ONVIF on 8000 as the connexion method to the cameras and also using http on 80 & specifying the make & model Both cameras are on DHCP with the router set to permanently assign their IPs based on their MAC address. I have three NICs in my NAS; 192.168.1.42, 192.168.1.43 and 192.168.1.158. 192.168.1.158 is the "main" address I use for file service etc. I also have Virtual Machine Manager running pfSense and PiHole in separate containers I don't have anything active in the Docker package these days but it's running. So I eventually tried ssh'ing into the NAS itself to see what happens and that's where the weirdness began (to my mind!) My NAS is 192.168.1.158 and in this example the camera IP is 192.168.1.138. This is what I get after ssh'ing into the NAS: $ssh adminusername@192.168.1.158 NAS:$ sudo ping 192.168.1.138 PING 192.168.1.138 (192.168.1.138) 56(84) bytes of data. From 192.168.1.43 icmp_seq=1 Destination Host Unreachable From 192.168.1.43 icmp_seq=2 Destination Host Unreachable From 192.168.1.43 icmp_seq=3 Destination Host Unreachable i.e; I'm ssh'ing into 192.168.1.158 but when I issue a ping to the camera, the 192.168.1.43 interface seems to be doing the work (!). On paper not being able to reach hosts on 192.168.1.0 from "192.168.1.43" is perfectly understandable as the "192.168.1.43" NIC is physically connected to my WAN so it won't ever reach LAN hosts such as my camera. The 192.168.1.43 address isn't used by anything on the NAS, I'm simply using the physical NIC in pfSense (Virtual Machine Manager) for its WAN leg. And obviously the 192.168.1.43 address isn't valid on the WAN, it's simply configured as the NIC address in DSM. Here's the output I get from route -v on the NAS: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.1 0.0.0.0 UG 0 0 0 ovs_eth2 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ovs_eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ovs_eth2 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ovs_eth1 And here's what ifconfig returns: docker0 Link encap:Ethernet HWaddr 02:42:CF:4A:5C:5E inet addr:172.17.0.1 Bcast:172.17.255.255 Mask:255.255.0.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) eth0 Link encap:Ethernet HWaddr A4:1F:72:79:2A:0D UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:39131471 errors:0 dropped:0 overruns:0 frame:0 TX packets:22725715 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:37684363821 (35.0 GiB) TX bytes:6163089642 (5.7 GiB) Interrupt:17 memory 0xf7dc0000-f7de0000 eth1 Link encap:Ethernet HWaddr 00:1B:21:C1:AA:59 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:51379518 errors:0 dropped:0 overruns:0 frame:0 TX packets:61036565 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:39673733123 (36.9 GiB) TX bytes:52430085407 (48.8 GiB) Interrupt:18 memory 0xf7cc0000-f7ce0000 eth2 Link encap:Ethernet HWaddr 00:1B:21:3A:2A:72 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:92065458 errors:0 dropped:0 overruns:0 frame:0 TX packets:60263170 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:110007541961 (102.4 GiB) TX bytes:45581811386 (42.4 GiB) Interrupt:45 base 0x2000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:18165254 errors:0 dropped:0 overruns:0 frame:0 TX packets:18165254 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2706815313 (2.5 GiB) TX bytes:2706815313 (2.5 GiB) ovs_eth0 Link encap:Ethernet HWaddr A4:1F:72:79:2A:0D inet addr:192.168.1.43 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:641 errors:0 dropped:0 overruns:0 frame:0 TX packets:107987 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:118049 (115.2 KiB) TX bytes:11969621 (11.4 MiB) ovs_eth1 Link encap:Ethernet HWaddr 00:1B:21:C1:AA:59 inet addr:192.168.1.42 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4112711 errors:0 dropped:0 overruns:0 frame:0 TX packets:2854435 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2407853859 (2.2 GiB) TX bytes:6354451639 (5.9 GiB) ovs_eth2 Link encap:Ethernet HWaddr 00:1B:21:3A:2A:72 inet addr:192.168.1.158 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:70158309 errors:0 dropped:0 overruns:0 frame:0 TX packets:34560756 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:85517754564 (79.6 GiB) TX bytes:34325679558 (31.9 GiB) tap021132 Link encap:Ethernet HWaddr EE:E9:37:7F:F6:2C inet6 addr: fe80::ece9:37ff:fe7f:f62c/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:20643311 errors:0 dropped:0 overruns:0 frame:0 TX packets:11013658 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:20019102906 (18.6 GiB) TX bytes:2360227078 (2.1 GiB) tap021132 Link encap:Ethernet HWaddr 3E:B1:BF:90:04:F2 inet6 addr: fe80::3cb1:bfff:fe90:4f2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:204594 errors:0 dropped:0 overruns:0 frame:0 TX packets:444167 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:19705035 (18.7 MiB) TX bytes:192693047 (183.7 MiB) tap021132 Link encap:Ethernet HWaddr 4A:58:67:4E:25:3D inet6 addr: fe80::4858:67ff:fe4e:253d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:189323 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:588 (588.0 B) tap021132 Link encap:Ethernet HWaddr 0E:FF:2B:42:A6:CE inet6 addr: fe80::cff:2bff:fe42:a6ce/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:11873550 errors:0 dropped:0 overruns:0 frame:0 TX packets:21870046 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2821255623 (2.6 GiB) TX bytes:20938108104 (19.5 GiB) There are no rules on the firewall preventing internal traffic flow. Any help would be very much appreciated! Thanks Quote Link to comment Share on other sites More sharing options...
IG-88 Posted March 24, 2022 Share #4 Posted March 24, 2022 3 hours ago, steveharman said: PING 192.168.1.138 (192.168.1.138) 56(84) bytes of data. From 192.168.1.43 icmp_seq=1 Destination Host Unreachable looks like the connection is goint out to ovs_eth0/eth0 and then it ends if all 3 ports of the switch are connected to the same switch i'd say check you vlan config on that switch if you disable eth0 and eth1 (or disconnect the cables) it should work you would need to find out why eth0 is not able to connect to the camera even if they are in the same network ovs_eth0 has a very low data count compared with ovs_eth1/ovs_eth2 i dont know how you connected the 3 nic's and how switch(es) are configures but if possible try to swap cable from eth0 with eth1 or eth2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.