Open dogi opened 8 years ago
Maybe best thing is to write a test with curl -X GET http://<ipaddress>:5984
to determine if firewall is turned on:
also wrote already a script to turn off firewall for windows for ports 5984 (and 6984 for https) missing there is:
I learned that there are two kind of firewalls in mac. One is application-based and the other is package-based. Both of them are turn off by default. In other words, all the ports of a mac system are free to access under the same network by default.
I think this is correct since I am able to access the bell app on my mac with my cellphone without any extra modifications.
Let's consider the situation when these two kinds of firewalls are turn on purposely by whoever. For the application-based firewall, since I believe that the bell app is not recognized as an "application" by the mac system yet, it will not be a concern for the bell app.
As for the package-based firewall, this is something a little bit more complicated and I need more time to know how it work. By the way, it is called "pf".
As for the third-party firewall, due to my limited knowledge to networking programming, I don't even know if I can revert the blocking from them.
So should I dive more into this issue for mac or should I move on to another issue? What do you think, @dogi ?
I think we should write a script to test if there is a firewall first ;)
script in meta language kinda:
detect all possible IPaddress(es)
if `curl -X GET http://127.0.01:5984` != curl -X GET http://<your IPaddress(es)>:5984 then
firewall
fi
@xinglunxu does this kinda make sense?
What should the script do if it detect the firewall is on? Should it notify the user that the firewall is on and ask him to turn it off? thanks.
@xinglunxu yes - that would be a good start ;)
I just made a better understanding of the package filter service in mac.
So when we find out that the port is blocked, we can solve this problem in two ways.
I think the first solution is so much better because:
As indicated earlier, each packet is evaluated against the filter ruleset from top to bottom. By default, the packet is marked for passage, which can be changed by any rule, and could be changed back and forth several times before the end of the filter rules. The last matching rule "wins". There is an exception to this: The quick option on a filtering rule has the effect of canceling any further rule processing and causes the specified action to be taken.
think I was search for this http://www.ibiblio.org/macsupport/ipfw/
anyhow think also first step here is to write the script which checks if couchdb is accessible
Oh, so 6984 is the port number for the database of community-bell, and we need to make sure both ports, for server and database, are not blocked. Am I correct?
Just realize that the port for couchdb is not map to any host port so it is not accessible, according to Vagrantfile. So, what do you mean by checking if couchdb is accessible in the previous post? And what is port 6984 used for? Thanks!
we are not using port 6984 right now, but it is the default port of couchdb for https
@dogi For Windows, the problem I had was not only with firewall, but with enabling the VM in my computer. So, the test should also check somehow whether VM is enabled or not. I do not know if this check should come before or after we check for firewall.
@mhalqurashi Hi, just a suggestion, I think the script about the firewall should only concern about the firewall. In other words, it should be functional. I would assume that the caller of this firewall checking script would have already handled the VM machine enable issue before calling it.
@mhalqurashi think you mean https://github.com/dogi/ole--vagrant-community/issues/1
and yes we want also a script for that ;)
@dogi So I created this script file to detect if a specific port is accessible through http protocol. It also take port number as argument in command line argument. If none provided, then use port 5984. It output "on" if port is unaccessible or "off" otherwise. No side effect.
Here is the script, not sure if this is what you wanted.
#!/bin/bash
COMMAND="ifconfig | grep \"inet \" | grep -v 127.0.0.1 | cut -d' ' -f2"
INET_IP=`eval $COMMAND`
PORT=$1
if [ "$PORT" = "" ] ; then
PORT=5984
fi
HTTP_RES_CODE=`curl -Is http://${INET_IP}:${PORT} | head -1 | cut -d' ' -f2`
if [ "$HTTP_RES_CODE" = "200" ] ; then
echo "off"
else
echo "on"
fi
Run like this:
sh detectfirewall.sh
or
sh detectfirewall.sh 5984
@dogi Hi, so after some time of searching and thinking, I am still very convinced that turning off the whole PF service is better than turning off individual ports. The reason is that I cannot find out a very good way of turning on/off individual ports. First, please read my response here if you haven't. https://github.com/dogi/ole--vagrant-community/issues/5#issuecomment-228587820 Since the mac firewall(PF) is a package filtering service so there is no interface to individually "turn on/off a port". If the mac user or other applications set up the rules to filter out the packet sending to 5984, I will have to find a way to attach a rules at the end of all current rules to explicitly allow packet going 5984 to pass. This is something I have problem doing.
In other words, I think the pf service is not designed for coordination between different users(applications and system administrator). If a firewall application is in charge of the pf service then it will be hard for bell app to make a small change to the pf service configuration and reverse it later. It will be better to turn off the PF service for running bell and turn it on again after closing bell.
@xinglunxu I know that this is the case ... since that is the low hanging fruit ;) let's start there
So... Since turning on and off the pf can be achieved with command line, I think there is no need to write a script for that.
Use sudo pfctl -e
to turn on pf and sudo pfctl -d
to turn off pf
Never mind I think I should still write the script for it just for record.
Never mind I think I should still write the script for it just for record.
+1
I will try to work on the windows version
Firewall_rules_reverse.bat
:: Delete the rules "CouchDB/HTTP"(dir = in && out) and "CouchDB/HTTPS" (dir = in && out)
netsh advfirewall firewall delete rule name="CouchDB/HTTP" protocol=tcp localport=5984 netsh advfirewall firewall delete rule name="CouchDB/HTTPS" protocol=tcp localport=6984
firewall_port_checking.bat
:: Change cmd language to english chcp 437
:: Parse IPv4 ipconfig for /f "tokens=1-2 delims=:" %%a in ('ipconfig^|find "IPv4"') do set ip=%%b set ip=%ip:~1% set ip_full_5984="%ip%:5984"
:: Check whether IPv4:5984 exists netstat -aon|find %ip_full_5984% if %errorlevel% == 0 (echo "Port 5984 FOUND")
Our Bell-Apps system is basically a service and by that every system gets transformed into a server. In other words this means that other devices (e.g. tablets) on the same network can also access this service ... ... if they are able to access the port 5984 on that machine
Some systems are blocking this ports from external access which is always the case on windows and macosx (where the firewall by default is turned on) and gets specially finicky when additional firewall software installed (mostly for windows)
General tests
http://127.0.0.1:5984/apps/_design/bell/MyApp/index.html
http://localhost:5984/apps/_design/bell/MyApp/index.html
http://<your ip>:5984/apps/_design/bell/MyApp/index.html