Closed ann0see closed 3 years ago
corrados
commented
4 years ago Jamulus shall be a free jam session tool. Nothing is more frustrating if a server is listed in the server list but it is protected by a password. If you have setup a private server, then this is enough protection. Nobody will guess the IP number and the port number you have chosen.
genesisproject2020
commented
4 years ago Suggestion. A server listed has to be open. Adding a private flag and when it's set on a server the server will be not listed.
ann0see
commented
4 years ago I totally agree that public servers shouldn't have a password. But especially for private servers some kind of protection would be good (since a portscan is easy). Maybe I'm a bit paranoid but I don't like the idea of somebody being able to connect to my private server and possibly interupt or disturb a jam session.
corrados
commented
4 years ago I use the software since 14 years now. I regularily use private server for some rehearsals. I had never the case that some stranger entered that private server.
gilgongo
commented
4 years ago Adding a private flag and when it's set on a server the server will be not listed.
Interesting, because it implies you wouldn't need to set up a private server (with port forwarding etc.) as you do today. On the other hand I don't think it would work with a 150 server limit to each Central Server. They'd probably just all fill up.
genesisproject2020
commented
4 years ago Adding a private flag and when it's set on a server the server will be not listed.
Interesting, because it implies you wouldn't need to set up a private server (with port forwarding etc.) as you do today. On the other hand I don't think it would work with a 150 server limit to each Central Server. They'd probably just all fill up.
Could be a list that doesnt update that often and then a bigger list that will not show up in the client at all.
WolfganP
commented
4 years ago If it's a private server, why listing and hiding it? I don't see any purpose on it if the intent is being non discoverable. Just host it without registering into a central server.
Regarding the port scan, I don't see what adding a password will add in terms of security of the session: if it's not an authorized user that received the IP:port via a side channel (sharing via mail or IM group), most likely s/he also received the password as well. if it's a matter of portscan, Jamulus is UDP based so it will react as any other stateless server on the machine (game, voip, conference, ...). You may change the server port to a non standard one, and that will mitigate the risk if anyone is purposefully targeting Jamulus default port 22124.
gilgongo
commented
4 years ago If it's a private server, why listing and hiding it? I don't see any purpose on it if the intent is being non discoverable. Just host it without registering into a central server.
Because then you don't have to mess with port forwarding and stuff. Just fire up your server and off you go (Of course, this would mean you'd need to know what to tell your friends to put in their connection window in order to connect to you, and that there wouldn't be more than 150 servers of any type (public or private) on that Central Server).
WolfganP
commented
4 years ago If it's a private server, why listing and hiding it? I don't see any purpose on it if the intent is being non discoverable. Just host it without registering into a central server.
Because then you don't have to mess with port forwarding and stuff. Just fire up your server and off you go (Of course, this would mean you'd need to know what to tell your friends to put in their connection window in order to connect to you, and that there wouldn't be more than 150 servers of any type (public or private) on that Central Server).
So you propose to use the registration procedure as a trigger for the port forward of your router?
gilgongo
commented
4 years ago So you propose to use the registration procedure as a trigger for the port forward of your router?
Well that's how it works today :-) When you register a public server today, it's public and anyone can connect to you without you needing to port forward (this is part of the point of having a Central Server system). The idea @genesisproject2020 had simply implies you'd have the ability to prevent it showing in the list.
But all this is academic. I don't think we can have (or need) "private public servers" like this.
(BTW totally off topic, but I do get the impression some people think you have to port forward to run a public server. It doesn't do any harm of course, but it's completely unnecessary).
sthenos
commented
4 years ago I think a lot of people get confused between port forward and opening a port on their firewall. The two things are mutually exclusive.
gilgongo
commented
4 years ago @sthenos Interesting. I've not noticed any talk about that on the forums I don't think.
If somebody simply opened UDP 22124 on their firewall so that all machines on their LAN were exposed to that, instead of port forwarding 22124, it would appear to be the same as port forwarding, is that right? I didn't realise routers made them mutually exclusive.
BTW the other day I added this to the Server Types docs on the wiki: "Note: It is not necessary to port-forward or otherwise configure your router to run a public server."
WolfganP
commented
4 years ago As there's no registration process/announcement while running a private server, a compromise solution may be for the (local) private server to send a dummy msg to the (remote) central server (no action on central server other than discard the msg, or just update anonymous stats on private servers), and use that initial outbound packet to trigger a port forwarding (that the router/firewall will close once the private server is shutdown and the firewall timeout acts), and avoid any permanent port forwarding/opening that way. What do you guys think?
ann0see
commented
4 years ago Just found this sourceforge thread about a (probably not well working) jamulus fork
https://sourceforge.net/p/llcon/discussion/533517/thread/a17b6db848/
We could talk to them and maybe use the password protection code. EDIT: Bad idea: they seem to do password verification on client side.
I‘d nevertheless suggest to add a commandline flag to the central server which disallows protected servers to connect. The client should show a lock icon or something similar to flag protected servers. I‘d be happy to code something but unfortunately don’t really know QT or C++. I do know PHP and can work it out probably but need some guidance/description of the connection progress/...
The registration progress or connection to a central server to overcome the need of port forwarding in my opinion should not be connected to this feature. The protected private servers would mainly be for educators.
corrados
commented
4 years ago The servers listed in the official Jamulus server lists are free to use for everyone. There will be no password protection.
If you require a private session, you have multiple alternatives with Jamulus:
gilgongo
commented
4 years ago @ann0see You may be interested in contacting the person on this thread regarding the idea of creating a private central server, He seems to also have a pre-configured client for students to download:
https://sourceforge.net/p/llcon/discussion/server/thread/02fc5e8ec6/#05ad/7a16/4f98/c942/2f33/564c
ann0see
commented
4 years ago corrados and gilgongo. Thanks for all the input. As I understand corrados, he doesn't like the idea of password protection since he'd like to have an open (default) central server list without password protected servers. I totally agree to that. If I protected my server with a password, I wouldn't publish the IP anywhere either.
corrados
commented
3 years ago someone creates a Jamulus Central Server which IP/URL is only known to your band so you can register your server there (any volunteers for providing such a server for people which do not have the possiblity to create a private Jamulus server but need some private session?)
FYI (see also this Facebook post), I have created a Central Server List which can be used to register "semi-private" servers:
jamulusprivate.fischvolk.de
Feel free to use this Central server if you like. It is not shown as a default server list in the official Jamulus client.
gilgongo
commented
3 years ago Related to this, someone on the forums posted a link to a site that allows you to create (free) temporary private Jamulus servers in several cities around the world. I've lost the link to it now but it looked quite interesting. Can anyone find it?
Not tried it myself.
Zaidcrowe
commented
3 years ago Might have been us? https://melomax.live
There is also https://koord.live
On Sun, Dec 20, 2020 at 11:52 AM Jonathan notifications@github.com wrote:
Related to this, someone on the forums posted a link to a site that allows you to create (free) temporary private Jamulus servers in several cities around the world. I've lost the link to it now but it looked quite interesting. Can anyone find it?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/corrados/jamulus/issues/299#issuecomment-748597616, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXXXG2Y445VU5G7HJL5K3LSVXQPPANCNFSM4NMMCKJA .
ann0see
commented
3 years ago I have created a Central Server List which can be used to register "semi-private" servers.
Thanks!
That‘s great news. So you‘d setup a server register it with jamulusprivate, let all your members connect and then go private?
corrados
commented
3 years ago So you‘d setup a server register it with jamulusprivate, let all your members connect and then go private?
That would be one option. Another option would be to let the server registered at that list all the time. Since only Jamulus users who know the URL can see the list, the probability that strangers will enter your session is very low. And usually people who register their servers to that list and use that list will respect the privacy of the others since they also want some privacy.
drummer1154
commented
3 years ago We tried to use this yesterday to no avail.
While it appears possible to register the local Jamulus server (WIN8.1 PC) with jamulusprivate.fischvolk.de (by just entering this URL into Jamulus Server - Options - Custom Central Server Address => "Registered" will appear right hand to the "Genre" dropdown list, even if the displayed Genre != Custom and also "Make My Server Public" is unchecked), it does not appear in the Client (iMac on the same LAN; Settings - Custom Central Server Address = jamulusprivate.fischvolk.de; click Connect and select List = Custom => shows only "PrivateServerlist" and when I double click this, the Client is NOT connected to my Server but to "PrivateServerlist" - obviously this is NOT a list but a server). My two other bandmates' remote clients did not even display anything in the "Custom" list.
Most likely I completely misunderstood how this is supposed to work.
Out goal was to set up a private server on a site connected via DS-Lite which gets only a public IPv6 address assigned (see https://github.com/corrados/jamulus/issues/756#issuecomment-737903152). The idea was to register this private server with any central server (which appears to work because "Registered" is displayed) and then to select it from the other clients - but the server does not appear in the list of the other clients.
gilgongo
commented
3 years ago Jamulus does not support IPv6.
drummer1154
commented
3 years ago Sure - I know - but Volker has written elsewhere that he was able to set up a private server on a DS-Lite location and make it visible from outside ... I thought the idea was, as soon as an IPv4 connection to the Internet is made (i.e. the registration with the central server) then the Carrier Grade NAT would also establish a path back. I think the client would also not work on DS-Lite if this would not work ...
Does anyone know if there is a IPv6 based VPN (other than WireGuard which will need the FritzBox OS to be replaced which we cannot do with an ISP provided CPE) which tunnels IPv4?
Still I do not understand how jamulusprivate is supposed to work ...
TPennick
commented
3 years ago Hi All, Coming to this topic late as I've just set up a private server. To return to the original question for this issue, my use case is that I'd like to work with various distinct groups of musicians on my server, but keep these groups to specific time slots. Once I've given them all the IP address of my server, then any of them will be able to drop in at any time. Not a major issue, but possibly confusing and embarrassing. I'd like to be able to issue a password which I could include in an invitation to a particular time-slot.
ann0see
commented
3 years ago I'm afraid this will not happen since Volker dislikes this feature:
Jamulus shall be a free jam session tool. Nothing is more frustrating if a server is listed in the server list but it is protected by a password. If you have setup a private server, then this is enough protection. Nobody will guess the IP number and the port number you have chosen.
I don't 100% agree on his view but understand his concerns. Since I use Jamulus with an educational background, i've hacked something together: https://github.com/ann0see/jamulus/tree/eduTools My fork (on the eduTools) branch supports a "waiting room" feature. It's not secure and not user friendly since you have to send chat commands, but at least it's something. The main changes begin here: https://github.com/ann0see/jamulus/blob/247ed37f0f6f750bf15b95a4982a59841590cf3f/src/server.cpp#L1487
paulsijben
commented
3 years ago As we will be seeing more and more private servers (and increasingly at people's homes). I would very much welcome the ability to support a password. Just to make sure that your session (rehearsal or concert) is uninterrupted
gene96817
commented
3 years ago Is there a reason this concept is not generalized to protect a jam session? Consider: 1- my chorus has a server. When we do not have a rehearsal, we want to allow the community to use the server. 2- I have a server installed at a school. When the students are not using the server, we want to allow the community to use the server. (The school allows classrooms to be used by the community. The virtual rehearsal room should be similarly available.) 3- In #1 and #2 above, a community or church choir, could reserve some rehearsal time.
Sometimes we want to allow visitors, some times we want the rehearsal to be private (meaning interrupted or free from distractions).
If only "private" servers are protected as implied in the other comments, my examples would require three or more servers to be created and each ensemble will have to have admin skills. It would be much better for one chorus with the technical skills to support the community (4+ choruses?).
mcfnord
commented
3 years ago Private means free from distractions, but it also means inaccessible by outsiders. Your chorus or students could each click Solo for every other member of the chorus/class. Then they will be free from audio distractions from any other visitors. This does not protect participants from being heard by visitors. But this core skill needs to be practiced by established groups to maintain a distraction-free environment. If a server could one-time-push Solo settings to participants, that would assure their session is free from audio distractions. They may see sliders, and slider panels might even be visually burdened by visitor signals, but the protection you seek is attainable. I do wish a server operator could mass-set a Solo group, even if participants change this setting later.
ann0see
commented
3 years ago For me private means that only the people of a group can only hear and see the members of this group. If other people are using the server but can't interact with the group, this would be fine too.
gene96817
commented
3 years ago I forgot that the solo feature can isolate the group. Then the only remaining scenario is when the ensemble is preparing for a performance/competition where they/we want the set to be a surprise.
gilgongo
commented
3 years ago @gene96817 You may also be interested to know that you can switch severs between public and private on the fly. Note also that if people are in the server when you switch between modes, they will stay connected. If "undesirable" people are connected when you wish to move between states, then you can disconnect them by using the -d option.
If you are running a Linux server it would be pretty easy to script this behaviour on a cron job in fact, so enabling a public/private server "schedule" if you wanted.
gene96817
commented
3 years ago Thanks for the info. However, I don't want to be available to support every session. I also don't want musicians in my chorus or guest to have Linux access to control the server. It is my opinion that the Jamulus server should be controlled through the UI and not by being a system admin.
gilgongo
commented
3 years ago I don't want to be available to support every session.
If you adopted the "schedule" idea with a cron job, then the server would automatically go from private to public and back again at intervals without you.
controlled through the UI.
Well, that can be done too of course. Run a windowing system on the server and set up a password-protected VNC login (with the server process's userid so nothing else on the server can be changed). I've not actually done that myself, but I believe others have. So you can have an icon on your desktop called "Server admin" :-) Or run Windows on the server and do it that way?
In general though, the answer to your question "Is there a reason this concept is not generalized to protect a jam session?" is that if it can be done with other tools/methods then (right now at least) it's probably better to prioritise work on other things.
That's not to say this might not change, but doing what you need would require a very large amount of work on some fundamental aspects of Jamulus I believe.
gilgongo
commented
3 years ago Moving to a discussion now as we need to keep the Issues for actionable specs.
Would it be possible to add some kind of protection to private servers so that not everybody who knows the IP can join?
Adding a password for private servers would enable real private sessions and increase overall security and privacy. Maybe it's not easy to implement with udp or would add some overhead? Maybe a ip unblock after somebody has input the correct server password would be an option?