On my system (Librem 14) when using a simple http server, say python2.7 -m SimpleHTTPServer or python3 -m http.server or even node’s http-server -p <some_port>, I am NOT able to access the server it is running from via http://<lan_ip>:<port>/ on other machines connect to the same network, BUT I AM able to access this from a browser locally only, so on the host machine and even on a virtual machine running on the host machine.
When running this same simple http server application on other similar systems (debian) on my network it works fine. I have no firewalls running, I’ve tried running the server as root, no luck. I cannot figure why I cannot access the tcp port remotely.
I have the same problem with my Librem 14 running PureOS. I suspect that PureOS uses some unusual kind of firewall that nobody knows how to configure. See this other thread:
One idea is that it could be that “nftables” is used instead of the old “iptables” that everyone is used to, I wrote something about that in the other thread. Maybe then the problem can be sorted out using some nftables commands, but I did not get around to trying that myself yet.
If you solve it, please write about the solution here, I’m sure others will have the same problem.
Your description is vague at best.
Providing a full description with an working excmple is very helpful if someone tries to help you.
But here are some thoughts:
Nope my description was perfectly accurate in fully describing the issue. If you had read all of it you would have noticed the part where i stated “i have no firewalls running,” so obviously not a problem with iptables nor nftable (which i don’t even have installed). Also if the service was bound to the loopback i believe i would not be able to access the service from the LAN ip address on a virtual machine (however, this i may be wrong about). Whether or not i’m using the correct port is just insulting.
Thanks for sharing this thread - I will definitely post the solution when I find it. I do not have nftables installed, i do have iptables, although with no rules, and the service is not running. So perhaps i just need to keep digging.
I think you are right about that but it doesn’t hurt to include, or at least check, netstat ... output that demonstrates
a) that the server is listening, and
b) what it is bound to.
It also doesn’t hurt to explore the three web servers that you mention to see
a) what they bind to by default, and
b) whether you can explicitly specify what to bind to.
It may be good to take a step back and start by doing a ping from another computer on the LAN. (You may have done this already but as far as I can read, you have not mentioned it.)
If ping doesn’t work then there’s no point worrying about a web server.
If ping does work then maybe experiment with netcat to see whether UDP works and to see whether any other TCP ports can work.
Based on the earlier topic, I expect that there is just some weird unresolved bug / feature.
Based on the earlier topic, what happens if you shut down sshd (NB: only do this if you can access the computer locally in order to bring sshd back again) and try running your web server on port 22?
What is it exactly that you do? (curl, browser, etc)
what is it exactly that you see? (and is that immediately, or after a timeout)
What is the error you receive?
I’d use ip, ping and tcpdump on both client and phone to debug further based on the above.
You were right. I had no idea that firewalld was a thing. I stopped that service and now i am able to access the server. Thank you for responding!
Final solution was: sudo firewall-cmd --add-port=8000/tcp --permanent
Note: only use --permanent if it is necessary for this rule to persist between system reboots
