Creating Network Services Filter script -- Can this be done?

[JohnD5000]

Sorry, I don't know how to enter here so the Code is nice and formatted like you send.

 

[L&LD]

@JohnD5000 edit your post 21 and copy/paste your Code into an 'Insert, Code' box (right beside the Save Icon) in the toolbox.

 

[JohnD5000]

@JohnD5000 edit your post 21 and copy/paste your Code into an 'Insert, Code' box (right beside the Save Icon) in the toolbox.

Thanks

 

[ColinTaylor]

else  # phone appears disconnected
    iptables -L FORWARD | grep -q "192.168.1.211-192.168.1.213"    # checks to see if rule is there, if so deletes it
         echo $?
    if [ $? -eq 0 ]; then

Remove the "echo $?" line. After that line is executed $? is replaced by the return code of the echo command (which is always 0). So you've effectively just wiped out the return code from the iptables command.

 

[JohnD5000]

Remove the "echo $?" line. After that line is executed $? is replaced by the return code of the echo command (which is always 0). So you've effectively just wiped out the return code from the iptables command.

Thanks, makes sense, I entered that there as a debugging to tell me where in script I was, didn't know it replaced it to 0. There are probably better ways to tell where you are in script to follow---still learning.

John

 

[Maverickcdn]

Just to elaborate on what Colin mentioned. $? is the return code of the previous command. If a command succeeds it returns a 0 if it fails it returns a 1.

The 'IF [ $? -eq 0 ]' is controlling the next action of the script based on the result of the previous command, because the echo command was returning a 0 the script was trying to remove a rule that was already removed

 

[JohnD5000]

Just to elaborate on what Colin mentioned. $? is the return code of the previous command. If a command succeeds it returns a 0 if it fails it returns a 1.

The 'IF [ $? -eq 0 ]' is controlling the next action of the script based on the result of the previous command, because the echo command was returning a 0 the script was trying to remove a rule that was already removed

Yeah, I was thinking it was a holding for a variable and would remain the same until specifically changed..so I could echo its value and not change it.

On testing of removing the udp from the command, this worked, but too well. Apparently the camera needs an tcp connection. Looking at the System Logs/Connection from the GUI, there are always two tcp connections open. I tried using the Firewall and closing udp & 1 tcp connection. And still can get camera if a connection already established when UDP rule goes on, but if block both of them, it works...unfortunately, the cameras must need at least one connection open. Otherwise, when trying to connect, it somehow shuts the camera connection off (although can still see it on the GUI as connected) until holding the On/Off button on camera for 5 seconds. My guess is that if a connection is requested and UDP is off, the apps server is still somehow checking the camera has a connection (but isn't smart enough to connect with video). But if no tcp connection, it stops the ability to connect to the camera until the On/Off reset button is pushed on camera....If that makes sense. There probably is a way to not have a connection to camera when home, without the camera needing a reset, but I'm not sure how. Anyhow, what we had with the possibility of a connection being in place, then the udp rule put in, and the connection not dropping, is the best that can be done.

 

[Maverickcdn]

The UDP is an authentication channel likely.

So if I understand correctly if you also block TCP you need to reset the camera to establish a connection after the rule is removed?

How quickly are you testing all this? I'm wondering if you need to connect your phone. Apply the rule. Disconnect your phone, remove the rule and then wait a few minutes for any hung TCP connections to expire and refresh on there own.

 

[Maverickcdn]

Maybe add a line after removing the blocking rule to ping the camera, might help wake it up to establish its own connections again also. It shouldn't be losing its wireless connection to your router it just thinks its connection is dead I'm hoping

 

[JohnD5000]

Maybe add a line after removing the blocking rule to ping the camera, might help wake it up to establish its own connections again also. It shouldn't be losing its wireless connection to your router it just thinks its connection is dead I'm hoping

No, the camera still showed as a client to the network. However, when I went to the App and tried to connect, it gave me a "Device not found" message after trying for 1 minute or so. Then, even if I removed the rule, it still wouldn't connect.

When I ping I get:
admin@RT-AC86U-07F8:/tmp/home/root# ping -c3 -w2 192.168.1.212
PING 192.168.1.212 (192.168.1.212): 56 data bytes
--- 192.168.1.212 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

But the camera is showing as a client on the GUI.

If I go to System Logs/Connections. There are no connections to camera.
I had to press the on/off button on camera for a few seconds. My guess is that the app sends a code to some sort of central server, when it doesn't get a connection, assumes the camera is down and waits for a reset code to come from camera that is initiated from camera.

One test I did was to go to GUI, flick the Internet Connections to OFF. Do the same, try to connect, get nothing, then return Internet Connections to ON. Now it works.

Something else that is strange. When the rule is on, there is a tcp connection showing in the GUI Sytem Logs/Connections (the NAT PORT changes, but other data doesn't)

Proto NAT Address NAT Port Destination IP Port State
tcp 192.168.1.213 60255 47.254.33.118 1883 ESTABLISHED
tcp 192.168.1.211 65170 47.254.33.118 1883 ESTABLISHED

When I try to connect, (with the rule on) I get a "Device not found" message on app, and then the tcp connection that is still established is removed. See above after trying connection on 212. (Note, this happened right after I tried to connect, but eventually all the connections were lost (took time though). My guess, the cameras phone home every now and then, and if there is no tcp connection, they can't. If the server doesn't recieve a notice, it assumes the connection is bad, and waits for the camera to be reset (On/Off button click)?

When connecting through App and the rule is in place, it just removes it quickly (not sure how the GUI connection on router gets erased immediately since it shouldn't have a connection, unless it is getting it some other way?

Does any of that make sense?

 

[Maverickcdn]

Hmmm.

Well theres no saying the camera would reply to a ping in the first place, you may have to do more testing to confirm whether it even responds to pings or not.

If toggling the WAN connection restorted the cameras there may be a command you can put in the script for that, but it would interrupt Internet service and if anything went wrong with the script it would require a router reboot likely.

I hate to say this is starting to get beyond my already limited knowledge as it is a cloud based camera which seems to be picky about retaining its connection.

I think if you can live with just blocking the UDP connection for new connection attempts only that may be your best option short of more testing to find a way to force the camera to re-establish a connection to its server after the rule is removed.

 

[JohnD5000]

Hmmm.

Well theres no saying the camera would reply to a ping in the first place, you may have to do more testing to confirm whether it even responds to pings or not.

If toggling the WAN connection restorted the cameras there may be a command you can put in the script for that, but it would interrupt Internet service and if anything went wrong with the script it would require a router reboot likely.

I hate to say this is starting to get beyond my already limited knowledge as it is a cloud based camera which seems to be picky about retaining its connection.

I think if you can live with just blocking the UDP connection for new connection attempts only that may be your best option short of more testing to find a way to force the camera to re-establish a connection to its server after the rule is removed.

Yeah, I'm pretty happy with the UDP blocking (was all I was asking for in first place). I think the likelyhood of a connection being in place and then coming home and having the connection remain are slim anyhow.

One thing I notice through my testing is when the phone disconnects, then I run the script, it was pinging 100% packet loss, but then running the script as if it was connected. Further testing and I realize it takes about 45 seconds for the arp -n to recognize the phone is disconnected. The ping doesn't appear to have any affect on the arp. Does that make sense? Anyway to get arp to immediately recognize a disconnection as it does the connection with the ping? (If that didn't make sense, I disconnected my phone then kept entering arp -n in Putty until the arp showed it was disconnected). If I disconnected, Pinged, then arp, didn't matter--still took about 45 seconds.

Now, in real world, when I leave house and phone disconnects from WIFI, the cron will most likely run after 45 seconds (I have it set to every 15 minutes). If it runs in the first 45 seconds, 15 minutes later it will correct itself. But, thought I'd ask anyhow.

 

[Maverickcdn]

Back in the 4th post of this thread where I linked to the other thread, one of the site gurus has an ARP refresh script.... you could download it and call it in your script to see if it helps.

I also noticed it varied x secs before the arp would actually refresh showing a client was disconnected.
I wasnt positive the ping would help the arp refresh or not hence why I had the ?? on the comments... it was worth trying anyway.

I havent had a chance to read through his code to see what command hes actually using to force the router to refresh the ARP table.

 

[Maverickcdn]

You could rely on the ping command completely if you want and eliminate the arp -n. But I would test it heavily, Im thinking like when your phone is asleep or after a certain period of inactivity it would stop replying or something silly.

#!/bin/sh
if [ $(ping -q -c4 -w5 192.168.1.200 | grep "received" | cut -c 24- | cut -c -1) -ge 2 ]; then  # pings 4 times looking for at least 2 replies
        iptables -L FORWARD | grep -q "192.168.1.211-192.168.1.213"  # checks to see if rule already in place
        if [ $? -eq 0 ]; then
            exit 0
        else
            iptables -I FORWARD 1 -p udp -m iprange --src-range 192.168.1.211-192.168.1.213 -j DROP   #adds rule to drop .211 .212 .213
        fi
else  # phone appears disconnected
    iptables -L FORWARD | grep -q "192.168.1.211-192.168.1.213"    # checks to see if rule is there, if so deletes it
    if [ $? -eq 0 ]; then
        iptables -D FORWARD -p udp -m iprange --src-range 192.168.1.211-192.168.1.213 -j DROP
    else
        exit 0 # phone not connected and rules not in place
    fi
fi

 

[Maverickcdn]

Looking at Martineaus ARPrefresh script he is just using ping to update the ARP table, the issue is its cache time.

Linux by default has a 60 sec cache time, this can be confirmed by reading the value in /proc/sys/net/ipv4/neigh/ethX/gc_stale_time which is 60.
https://serverfault.com/questions/684380/default-arp-cache-timeout

If you're super concerned about the time between the disconnect and the entry being purged from the table you could lower this value for your wireless interface you connect to, but note I have NO idea what else this would affect on a day to day with your other clients.

My recommendation, just reduce your cron run time from 15 to 1 or 2 mins, the script is so low load it won't hurt anything to run it more often and will only execute the commands if the conditions are met.

 

[JohnD5000]

Looking at Martineaus ARPrefresh script he is just using ping to update the ARP table, the issue is its cache time.

Linux by default has a 60 sec cache time, this can be confirmed by reading the value in /proc/sys/net/ipv4/neigh/ethX/gc_stale_time which is 60.
https://serverfault.com/questions/684380/default-arp-cache-timeout

If you're super concerned about the time between the disconnect and the entry being purged from the table you could lower this value for your wireless interface you connect to, but note I have NO idea what else this would affect on a day to day with your other clients.

My recommendation, just reduce your cron run time from 15 to 1 or 2 mins, the script is so low load it won't hurt anything to run it more often and will only execute the commands if the conditions are met.

That is probably a good idea, however I am having issues with the cron. I thought I had it set correctly for every 10 minutes (I thought I set 15 but I set 10), but checking the logs, it is just running 1 time on the hour i.e. 18:00:00, 19:00:00.20:00:00. Should't it be running every 10 minutes? ie 18:00:00, 18:10:00,18:20:00 etc

admin@RT-AC86U-07F8:/tmp/home/root# cru l
30 3 * * * /jffs/scripts/FreshJR_QOS -check #FreshJR_QOS#
0/10 * * * * /jffs/scripts/CameraBlock.sh #camerablock#

doesn't the 0/10 mean every 10 minutes, ie 0/2 would be every 2 minutes?

 

[ColinTaylor]

doesn't the 0/10 mean every 10 minutes, ie 0/2 would be every 2 minutes?

No. You want it to look like this:

*/10 * * * * /jffs/scripts/CameraBlock.sh #camerablock#

 

[JohnD5000]

No. You want it to look like this:

*/10 * * * * /jffs/scripts/CameraBlock.sh #camerablock#

Thanks, I went to this site's cron schedule expressions, guess its not same on every system https://crontab.guru/#0/10_*_*_*_*

 

[ColinTaylor]

Thanks, I went to this site's cron schedule expressions, guess its not same on every system https://crontab.guru/#0/10_*_*_*_*

It says in red underneath that expression: "Non standard! May not work with every cron."

 

[JohnD5000]

It says in red underneath that expression: "Non standard! May not work with every cron."

Yeah, but on my browser that is a very muted red/on black in very small type....didn't even notice it when looking at it first time. Just noticed the huge font/ white bold on black telling me it was going to work