Hi,
I installed IPERF on a few nodes. I run the server on one and client on the other. It fails between nodes like the firewall is blocking the default IPERF port.
I am the first to admit I don't know enough about iptables to correct the issue.
Wondering if in future releases, if iperf package can come with the release and perhaps the necessary firewall changes?
Thanks, Russ. WL7AG.
Yep the firewall on the nodes is locked down to only accept traffic on known ports by default. I've ran iperf a few dozen times from my nodes, but recently been running from laptops plugged into the nodes instead.
I'll have to throw this one by the dev group.
I'm not even sure iperf is in our package repo anymore and would have to look (we drastically scaled back the software repo as part of the plans for 3.15.1.0 to better focus on nodes being nodes and for services to be running off node where they do not detract from the nodes resources and are easier to keep online should a node fail)
Thanks.
It's just a bit easier to characterize links between nodes without having to deploy raspberry pi's or other hardware if the node itself can do the job.
Russ. WL7AG
I can hack at it and figure out the iptable changes, but perhaps if you or someone on the dev team is savvy with it, perhaps they can point out the changes I need to make?
I also understand why you would perhaps not want to do that.
Thanks Russ.
The iptables rules in the BBHN/AREDN nodes are by far the most complex I've ever seen. Part of this may be because they seem designed to capture a lot of detailed statistics as a side effect, but I wonder about the necessity.
There is little point in using firewall rules to block access to unused ports as the system already rejects attempts to use them. TCP SYNs are answered with RSTs and UDP packets are answered with ICMP unreachables. Since most network nodes are operated and managed remotely, there is little reason to run a network service that can only be accessed locally. If you have one that you're worried about being a security risk, and you really think you still need it, you might consider adding some application-level security rather than trying to limit access to it with iptables. I've found that can bite you when you suddenly find yourself needing to access the service in a way that is blocked by the rules.
If you use an Internet socket for specialized interprocess communication within the same host or node, and it wouldn't make sense for anything else to connect to it, then just have the application bind to the loopback address (127.0.0.1 or ::1) and it will reject off-node requests without need for an iptables entry. Or use Unix domain sockets; that's what they're for.
I am especially uneasy about iptables rules that block forwarded packets. This seems like a very undesirable feature under emergency conditions when you're trying to use some application protocol for the first time and your user can't figure out why it doesn't work.
I'm sorry, for someone who has been working with TCP/IP for 30 years you should know its standard security to block all ports and open up only the ports needed in most cases incase some software some how becomes installed on a node or some unexpected activity occurs it reduces the chance for a vulnerability to be exposed.
As for the rules being the most complex you have seen, all I can say is they are some of the simpelest rules, and no they are not built for statistics (though the Linux kernel does keep counters on iptable rules) they are specificaly built around a framework for reliable, secure, extendable, automticy generated, framework.
"I am especially uneasy about iptables rules that block forwarded packets. This seems like a very undesirable feature under emergency conditions when you're trying to use some application protocol for the first time and your user can't figure out why it doesn't work."
So you want me to configure the nodes to allow and always forward packets from the Mesh to your private home network? Or how about when your in NAT mode where your suppose to have the "LAN" isolated from the "MESH" you want me to forward packets than too? Do you have any idea how much corruption to the routing this would cause? Are you aware we fixed a flaw that did this last year?
I'm sorry I've heard a lot of complaints from you and no solutions. AREDN is focused on making secure reliable deployments (and a standard of secure is not leaving wide open devices w/o firewalls) This is one point that BBHN doesn't agree with us on their Linksys platform where they leave all ports wide open. Perhaps the BBHN group is a better place for you, they are much more a tinkering group that isn't focused on building long term networks and is more focused on networks that only need to last a short period of time (such as a Field Day logging network which was a presentation at HamCom 2015.) it seems they have closer ideals to yours where making sure devices don't get compromised isn't a priority.
I've been around networks long enough to base my views on my own experiences. I'm well aware that reasonable people differ on matters like security, and that's fine. It's not like any of us have the magical solution, that's obvious just from reading the news. You can take my comments or leave them, your choice.
If you're serious about security, you really don't have an excuse to not know what services you're running. The command "netstat -a -n | grep LISTEN" will tell you what TCP ports are being listened to. You can look at udp ports with a similar command. If the remote address is the unspecified address (0.0.0.0 or ::) then it's open to the network unless blocked by iptables. The network stack will automatically reject all incoming packets to unused ports, returning ICMP messages. Many people drop packets in such a way that these ICMP messages are not returned, but I consider them a courtesy.
Yes, I do want you to always forward packets to my home network! (Assuming I am advertising it in my routing updates, of course.) I'll worry about my own security, thank you. I don't need someone else doing that for me in a way that I can't control -- that's the problem with router firewalls. Because my hosts each perform their own filtering, I don't actually care if anybody gets on my home network. My only real concern is that someone might use my regular Internet connection to do something illegal that would point back to me.
I am starting to agree that I would probably be in better company with the BBHN people, who seem more inclusive and open to experimentation. But I live in San Diego, not Texas, and you guys seem to be the only mesh networking game in town so I'm willing to put all that aside and contribute. As I said, the Internet is the collaborative work of a cast of thousands; it could never have been built by a few priests, no matter how talented, working in isolation. So if you want to succeed you're going to have to be open to ideas that aren't yours -- and certainly not just mine. I've seen many projects much less ambitious than yours fail because the principals didn't know how to do that.
[edited at the request of the author: removed reference to Palomar ARC]
Phil, I'd like to clarify something for you ... You have been exposed to three different groups within the San Diego mesh realm.
There's discussion around mesh networking going on in a wide variety of forums... BBHN has been mentioned, but the NW-Mesh group is also very active; OpenWRT, on which the technology is based, is also an active forum.
So my advice to you is to find the place that's most aligned with what you want to contribute. You know I respect your past accomplishments and I do weigh your advice against my own experiences.
I welcome your ongoing participation in the SDWG. I enjoy the spirited discussion you bring to the table.
Sincerely,
Andre, K6AH
[edit by author: removed comment regarding Palomar ARC]
Andre, thanks for the clarifications.
But I do have a question. You say:
Is there a formal project description, list of requirements, anything like that? I see the word "emergency" here a lot, but it seems to be used mainly in the abstract. The first task in any engineering project is to find out what the user wants, to the extent he actually knows. (Admittedly, with new technology they often don't know they need something until you show it to them. That certainly was the case with the Internet itself.)
But I'm not a public official experienced in managing emergencies, so I'd like to talk to some who are: police chiefs, fire chiefs, small town mayors, city, county and state EOC personnel, etc, and ask a whole bunch of questions like:
That last question is based on my own take that the best role for amateur radio in an emergency is as an immediate gap-filler, taking the place of commercial and other facilities knocked out by a disaster. Once the portable satellite trucks and cell-sites arrive, and certainly after the commercial facilities are restored, the need for amateur radio goes away.
Phil,
As I indicated in my earlier post. That's a personal objective of mine. I'd be happy to discuss off line.
Andre
I'd rather not get into the frey, but as an update, I've modified the table and can do iperf between nodes.
An off the cuff benchmark, 2 nodes > 6 miles away and not really line of sight, I'm getting 2 to 2.5 Mbps between them using channel -2 and 5 MHz.
I'd imagine it would be some UI work and low on the feature list priority but, perhaps modifing the iptables to allow the iperf port from the GUI or come standard as part of the release would be useful. As well as packaged as part of the release.
Russ. WL7AG
Nice speed report
The whole firewall visibility is being discussed and hashed in the backend right now.
No commitment or timeline just yet but it is being discussed, trying to sort out the pieces and best method (add it to the package, get the GUI expanded to do it, both, other, etc)
Request...
The subject of this thread is IPERF.. could we reign it back in to the topic at hand?
I think everyone would appreciate that.
Thanks,
Darryl