Approaches for empty client connected to Servers on Any Genre 1

[ann0see]

Quite a few Any Genre 1 Servers have an empty client connected without visible use. This has been observed for multiple days and is somewhat worrying. Investigations by @dtinth have shown that this might not even be a Jamulus client.
Although it doesn’t seem to cause any visible harm, it doesn’t seem right to leave it like that. We should try to get to know more about the reasons and implications of this.
If anyone knows more or has any any quick fix approaches besides Server side IP blocking, please write here.

[pljones]

Had it been a Jamulus client, the lowest impact might have been firewall rules on the Directories - no impact on the code. If it's not using the protocol, though, that wouldn't help. However, it seems to have used the server list at some point (else it wouldn't have the servers and, particularly, those "permanent" servers).

[dtinth]

One can fetch a list of servers from https://explorer.jamulus.io/ as well.

[pljones]

One can fetch a list of servers from https://explorer.jamulus.io/ as well.

So two people, Volker and Tony, need to make a firewall change. Much easier than expecting hundreds of people - many who don't bother usually - to upgrade their server.

[dtinth]

I think we can reject non-well-formed Opus packets.

Here is a sample of a packet that was sent to my server (41 bytes):

0000   4c 48 db c6 dd f6 67 0c 10 19 00 00 00 18 00 01   LH....g.........
0010   02 00 10 00 04 00 00 00 01 ca 0c 95 af 6c 82 33   .............l.3
0020   05 09 9e 76 ef 5a 95 dc 2f                        ...v.Z../

In contrast, here’s a valid Opus packet that was sent when connecting (330 bytes):

0000   04 60 69 56 f3 e7 4f b4 72 30 7b 3a 52 68 7d 1e   .`iV..O.r0{:Rh}.
0010   5c b8 c8 fd d7 32 47 0a 88 c8 14 77 7e ac a0 a0   \....2G....w~...
0020   56 f0 5f f1 87 10 4b 00 66 c7 cd be a9 52 a0 4d   V._...K.f....R.M
0030   21 a4 e0 48 37 c8 d3 48 46 d5 22 38 00 00 00 00   !..H7..HF."8....
0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0060   00 00 0c c3 cf 33 f3 3c c1 88 b7 a5 a1 55 ab ab   .....3.<.....U..
0070   2e 5f 7c 26 f6 d4 e5 82 bd 75 89 61 18 ec 74 89   ._|&.....u.a..t.
0080   54 09 71 75 40 03 0f 3f fb 48 9d 75 34 dd 74 00   T.qu@..?.H.u4.t.
0090   7b ed db 65 91 86 92 43 cf 00 01 04 63 13 4f ff   {..e...C....c.O.
00a0   18 da d8 43 7b 04 76 8d 76 d2 a5 70 74 28 9d c8   ...C{.v.v..pt(..
00b0   48 e3 1a 99 f5 8e c3 9a be 63 b7 5e 01 f6 44 3f   H........c.^..D?
00c0   a0 56 e6 b3 b4 6a fa 98 a4 b4 bc 51 c1 a3 5a 94   .V...j.....Q..Z.
00d0   f7 c2 ce a6 12 7e aa d6 40 9a 7e f6 18 b7 98 5a   .....~..@.~....Z
00e0   57 29 ac fa 03 e3 e3 e1 ad 70 50 00 00 00 07 ca   W).......pP.....
00f0   8c d1 ca 19 8f c9 26 ac 03 c5 2f 2e d7 7c 46 30   ......&.../..|F0
0100   3f ed f1 a9 1f 22 5b c1 6d 55 d8 75 6f f7 95 ba   ?...."[.mU.uo...
0110   05 e4 f7 a7 c5 76 70 aa 64 af 56 79 9f 9c 0c 6e   .....vp.d.Vy...n
0120   ab 61 aa 5a df 77 4a 0e ef e3 cc 30 d2 6f 31 14   .a.Z.wJ....0.o1.
0130   96 55 c7 a5 4f 73 58 06 ed f3 c6 ec a4 87 50 9f   .U..OsX.......P.
0140   76 29 f7 97 da a6 d6 99 21 4b                     v)......!K

After a while Jamulus negotiates the support for sequence numbers, the data that got sent is 2 bytes larger (332 bytes):

0000   04 79 89 69 8c b8 ea 4b e1 58 6a 15 cf fc 96 72   .y.i...K.Xj....r
0010   c0 10 c7 95 88 73 18 a6 80 12 cf 16 3c c3 18 94   .....s......<...
0020   41 3c 07 60 05 a7 14 98 1d d2 69 91 c2 f4 52 22   A<.`......i...R"
0030   1c a3 53 9a 9a 4d 1b f8 11 ca 01 33 b5 16 f3 5c   ..S..M.....3...\
0040   67 29 a1 c0 00 00 00 07 73 18 7b 40 f7 08 5e a5   g)......s.{@..^.
0050   26 c9 1b ec 80 e9 72 7d 1a 0e 6a bf 36 8a 70 96   &.....r}..j.6.p.
0060   ef d4 61 b3 0d 4d 1d 5d 79 54 d7 36 57 95 82 4a   ..a..M.]yT.6W..J
0070   04 67 a3 9d b6 d8 79 69 0c ee 93 91 9f 37 c4 30   .g....yi.....7.0
0080   4d 1a d0 dc f3 c2 69 3f 5c 2c d5 49 82 f4 39 40   M.....i?\,.I..9@
0090   69 64 85 aa 59 e5 e1 a1 03 35 21 73 cd e1 ef 17   id..Y....5!s....
00a0   6c 9f a3 7d cf 76 04 7c e3 98 10 8a 7a 55 8f 97   l..}.v.|....zU..
00b0   39 41 b7 31 72 cc dd 28 38 c0 24 5b c8 18 d9 6c   9A.1r..(8.$[...l
00c0   e2 05 7c 4d 04 ac 13 88 dc 6d 10 58 4d b4 e0 ff   ..|M.....m.XM...
00d0   a4 7e 52 45 08 9f 50 2b 3f c3 f3 14 39 04 b4 d2   .~RE..P+?...9...
00e0   c5 16 16 11 33 a7 a0 b4 b5 00 00 00 00 cb c0 7f   ....3...........
00f0   ef 71 01 c9 eb 26 c3 2d 6d 0d cd f2 56 38 95 a3   .q...&.-m...V8..
0100   47 ef 48 0d bf 87 6e e8 00 45 2e 15 47 e1 61 b2   G.H...n..E..G.a.
0110   5a c6 ca 52 ff 21 52 e8 37 96 ee d2 d4 3e 35 8e   Z..R.!R.7....>5.
0120   b2 0f 75 25 d0 17 67 a3 71 0f 2f e1 23 3b b5 24   ..u%..g.q./.#;.$
0130   03 4a 91 c8 26 3f 0d ef cf 36 3f 8f b0 58 d4 67   .J..&?...6?..X.g
0140   ab 69 36 ed ec 9d 3c 93 db 30 bb 77               .i6...<..0.w

We have a list of allowed sizes here:

jamulus/src/client.h

Lines 86 to 103 in 1f18d6c

	// calculation to get from the number of bytes to the code rate in bps:
	// rate [pbs] = Fs / L * N * 8, where
	// Fs: sampling rate (SYSTEM_SAMPLE_RATE_HZ)
	// L: number of samples per packet (SYSTEM_FRAME_SIZE_SAMPLES)
	// N: number of bytes per packet (values below)
	#define OPUS_NUM_BYTES_MONO_LOW_QUALITY 12
	#define OPUS_NUM_BYTES_MONO_NORMAL_QUALITY 22
	#define OPUS_NUM_BYTES_MONO_HIGH_QUALITY 36
	#define OPUS_NUM_BYTES_MONO_LOW_QUALITY_DBLE_FRAMESIZE 25
	#define OPUS_NUM_BYTES_MONO_NORMAL_QUALITY_DBLE_FRAMESIZE 45
	#define OPUS_NUM_BYTES_MONO_HIGH_QUALITY_DBLE_FRAMESIZE 82
	#define OPUS_NUM_BYTES_STEREO_LOW_QUALITY 24
	#define OPUS_NUM_BYTES_STEREO_NORMAL_QUALITY 35
	#define OPUS_NUM_BYTES_STEREO_HIGH_QUALITY 73
	#define OPUS_NUM_BYTES_STEREO_LOW_QUALITY_DBLE_FRAMESIZE 47
	#define OPUS_NUM_BYTES_STEREO_NORMAL_QUALITY_DBLE_FRAMESIZE 71
	#define OPUS_NUM_BYTES_STEREO_HIGH_QUALITY_DBLE_FRAMESIZE 165

When Jamulus decodes an audio packet, it must be a multiple of the block size

jamulus/src/buffer.cpp

Lines 138 to 142 in dbd34cd

	// check that the input size is a multiple of the block size
	if ( ( iInSize % ( iBlockSize + iNumBytesSeqNum ) ) != 0 )
	{
	return false;
	}

So a valid Jamulus audio packets should be a multiply of one of these numbers: [12, 13, 22, 23, 24, 25, 26, 35, 36, 37, 45, 46, 47, 48, 71, 72, 73, 74, 82, 83, 165, 166].

From above example:

Example	UDP data length	Multiply of	Valid?
Empty client	41	None	❌
My Jamulus client, before sequence number negotiation	330	165	✅
My Jamulus client, after sequence number negotiation	332	166	✅

[softins]

Note also that the high quality frame size increased at some point in the 3.5.x series. So it would also be necessary to permit the old size.

Only just seen this discussion. Will look in more detail shortly.

[ann0see]

https://hpd.gasmi.net/

classifies the 41 byte packet as this: LLC I, DSAP NULL LSAP Individual, SSAP NULL LSAP Response

[ann0see]

I think it might make sense to look at what your server sends to the IP in question (if nobody is connected).

[pljones]

The problem with code changes on the server is we have servers still running 3.4.2 to consider. We need a solution that will resolve things for them, as well - i.e. for those server operators not upgrading.

[hoffie]

We need a solution that will resolve things for them, as well - i.e. for those server operators not upgrading.

... which is only possible if directory servers and/or Jamulus Explorer is indeed the source of this scanning/behavior. If it isn't, we can't protect such infrastructure except for advising to update.

[pljones]

We'd need a very good reason to drop support for earlier versions, much as I might like to. I don't think, yet, that this is such a reason...

[hoffie]

Is there any evidence that "Any genre 1" is the common denominator? Could that effect happen by accident? Maybe because several servers share a common IP range (haven't checked, just guessing)?

IMO it's quite unlikely that someone uses Jamulus-specific methods (directory servers, Explorer web scraping) only to access those addresses later in a non-Jamulus way ("not a real client, just garbage"). I think it's much more likely that this is some kind of UDP scanning which happens to disturb Jamulus servers in the observed way.

[QJKX]

@dtinth does it automatically reconnect, and is there anything distinctive in the early connection traffic?

[pljones]

I haven’t verified if this method will work, but what if the server send REQ_NETW_TRANSPORT_PROPS first, and wait for client to respond with NETW_TRANSPORT_PROPS before assigning it a channel ID?

Needs updating every server, so won't help a lot on Any Genre 1, unless there's a cull.

The data changes every 2 seconds, but length stays at 41.

"... Interesting ..." as if it's meaningful... ;)

@dtinth does it automatically reconnect, and is there anything distinctive in the early connection traffic?

UDP is inherently connectionless. The client is sending no data other than the non-audio packet that's tricking the server into thinking it's got a connection. The server tracks that source IP and port number. Whilst it's constant "it's the same connection" -- but it's not a connection, really. That's the same as for a real client.

[pljones]

I'm assuming --discononquit does nothing useful, too...

[pljones]

And searching https://www.rfc-editor.org/rfc/rfc6716 for "41" left me as baffled as I expected.

[softins]

It does appear to be specific to Any Genre 1. Browsing in Explorer, with "Hide empty servers" ticked, shows a lot of servers with this dubious client connection in Any Genre 1, but none in any of the other directories. I would expect random scanning to show up on servers in other directories too. Within Any Genre 1, not all of the servers have this client connected. So either it is using a static list that it fetched once, or it is choosing a subset of the list.

[softins]

A server older than 3.5.6 includes the IP address of each client in the list it returns when asked. Very old versions of Jamulus Explorer would display that IP address, but I removed that when privacy concerns were raised. That was also the reason why servers from 3.5.6 onwards do not even include that information in the list.

I've just run up a test version of Explorer to restore the ability to display client IPs, and I can see there are several older servers telling me the same IP of this dubious connection. It is in the range 93.95.250.x, in the Netherlands, owned by Ivengi Benelux aka eurofiber.com.

Maybe it would be worth filing an enquiry with [email protected]?

[softins]

I've just looked in the web server logs on explorer for that IP, and I can see that it used Jamulus Explorer to look at the WorldJam list for a few minutes on the afternoon of 19 October. I'll post a general enquiry on the WorldJam group.

[ann0see]

Maybe it would be worth filing an enquiry with [email protected]?

One of the affected people should contact them.
@softins does it still contact explorer.jamulus.io now and then?

[softins]

See my comments on Discord. Since it affects many servers and has come to the attention of the developer team, we can be justified in contacting them ourselves.

The IP in question contacted explorer once around the time it started, but when I checked yesterday, that was the only occasion.

[ann0see]

Thanks. I read that a few mins ago. Probably it's good to send it then.

[JaminShanti]

Is it, https://jamulus.live/ ?

[rdica]

No.

[ghost]

I read #2941 about about a client that simultaneously connects to an excessive number of servers. Maybe the Directory Server can refuse to cooperate with a client that does this, thus limiting the connections.

[ann0see]

I doubt that this helps as soon as the client knows the IP of all servers. We even suspect the client could have used explorer.jamulus.io or something comparable

[ghost]

Doesn't the Directory server do port pinging to keep the firewall open? If this is the case, the directory server can cause related firewall rules to be foiled.

[ann0see]

Not sure, I think it could also just be the first connection. We can contact Volker, but I don't think he can do much.

[ann0see]

Just as update: The team received a message from Eurofiber saying that their customer has been contacted.

[hoffie]

FYI There is still active communication with Eurofiber. Eurofiber's customer tried to shut down the problematic traffic multiple times, but wasn't successful so far. As far as I understand, their investigations are still ongoing.

[mcfnord]

I notice some servers "naturally" purge the stuck connection, while others don't. Or maybe the rogue client doesn't disconnect in those cases. The long-lived zombie connections don't seem to favor older server versions. Does a sequence of events or operator actions cause these stuck connections to naturally disappear?

[pljones]

Has anyone been counting how many of them there are and whether the quantity is decreasing over time? They only appeared on the "permanent" (bold) servers initially. It looks like they don't appear on one of those servers if it gets restarted... I see no 3.9.1 on Any Genre 1 with the "problem" client, mostly 3.8.2 or before.

[softins]

My theory is that a list of servers in Any Genre 1 was fetched by someone/something around 19 Oct, and that the traffic in question started to be sent to some or all of the servers in the fetched list. Servers that were not currently registered (or had a different IP address) at the time the list was fetched do not therefore receive the traffic.

We would expect that if and when the traffic stops, the blank client entries would automatically disappear after the client timeout of 30 seconds.

On a couple of occasions recently, @dtinth has confirmed using tcpdump that the traffic in question is still being received by his server MusicJammingSG, so there is no suggestion that the client entries are stuck with no traffic.

[mcfnord]

I hadn't thought about ongoing transmissions. Right now there aren't any problem clients! I think I've seen problem clients on 3.9.1 before, but am not sure.

[pljones]

Yeah! Looks lilke it's been stopped one way or another. Thanks to everyone who's been helping make this happen.

[ann0see]

Just a thought. When did we introduce bIsIdentified? Maybe new servers aren't vulnerable to this.

[ghost]

I figured the silence on this matter was because someone was working on it; I guess nobody cares.
Maybe it's a WhiteHat, or maybe it's a BlackHat, or maybe it's an unfortunate soul from the Netherlands. This is funny.

[pljones]

You've been working on it then and have a patch to contribute? Great!

[ghost]

I'll try to answer my aforementioned questions, maybe with a patch.

[ann0see]

We are in contact with the hosting provider. Thanks to @softins who wrote an E-Mail, the Hoster is aware and they said they were investigating and fixing the issue. Even after multiple E-Mails from both sides, the issue couldn't be fully resolved yet unfortunately. I'll read up what the last state is.

[ann0see]

...Previous discussion explaining behaviour and Eurofiber response that they are in contact with the owner...
Eurofiber said that their customer "resolved" the problem and want confirmation from our end.

Softins (excerpt from mail):

Thank you for your email. Unfortunately, the traffic is still present.

You can see the effect at https://explorer.jamulus.io. It is targeting about 20 or so Jamulus servers in the “Any Genre 1” directory, which show a client connection with no identifying data. I have just contacted the operator of the ### server, and just a few minutes ago he confirmed using tcpdump that the traffic was still present, and that the client display was not just an anomaly
...

Eurofiber:

Yesterday and today i’ve looked at https://explorer.jamulus.io, yesterday there wasn’t any data available in Any Genre 1 on the London Linode server.
Today there is data again, but I don’t see the IP on there. Can you check again if you see any problems, and in case I overlooked the IP can you please explain how I can see the traffic?

Softins:

There is an ongoing issue with the Linode London back-end for Explorer. You can observe the same data from other back-ends by selecting London (AWS) or San Francisco, and then choosing Any Genre 1.

The back-end then queries the directory server for Any Genre 1 to obtain a list of the Jamulus servers registered to that directory. It then queries each registered server for its details and client list. It collates all this information into a JSON dataset and returns it to the front-end for display. You can check "Hide empty servers" to display only those with client connections, which is useful for this particular investigation.

The servers targeted with this strange data each show a client connection with blanks for Name, Instrument, Skill, City and Country. Just above is displayed the IP address and Port number of that Jamulus server, and these will be the destination IP and Port of the traffic. If and when the data eventually stops, these blank client entries should disappear within about 30 seconds, if "Auto-refresh" is checked in Explorer.

The Explorer is not able to display the IP address of the connected clients, as this was discontinued a couple of years ago to satisfy privacy concerns.

But independent investigation has confirmed the source IP of the traffic, which in all cases is ###, which has a PTR record in DNS resolving to ###.###.net. However, there is no corresponding forward A record for square.ivengi.net; just a CNAME pointing to ###.net.

What seems to be proving unduly difficult is identifying the originator at ### of this traffic emanating from ###. It surely shouldn't be that hard!

[JaminShanti]

I would appreciate some solution. Category 1 has been useless for about 2 months. I've started to use https://jamulus.live/ exclusively.

[dcorson-ticino-com]

Yes! finally no more empty clients.
Thanks to all who boxed this through.

[JaminShanti]

Glad it got fixed. Disappointing it took so long. I think it affected usage.

[mcfnord]

What if it happens again? What if this is used maliciously? Can we defend against such an attack?

[mcfnord]

It's still something I want people to do successfully.

[pljones]

You'll be asking Microsoft to take responsibility for the content of every document created in Word... ;)

[ann0see]

We should still learn from it. There's no way/should not be a way to interact with servers not in our control, but we can at least make the life of sysadmins easier and focus more on security. ACM by @Rob-NY is a good example.

[mcfnord]

Recently some servers I operate were targeted with waves from three or four kinds of useless or malicious connections. These attacks came from a far-reaching supply of unique IP addresses, and I suspect something like Tor was used. I wrote simple code that detects and blocks some attack profiles in real time. Others could use my centralized detection service for their defense, and I see the case for providing this as a built-in option. But I think the only robust defense is centralized, and centralized detection and defense looks quite different from server-based ACM. People are going to deploy and forget servers, and ideally, I'd like all servers to have the option of a centralized detection and defense service that is responsive to global attack patterns. Wide-scale attacks are rare events but are a fairly existential threat to our public sphere. We might not even think much about dramatic little accidental network events when we know the technology exists for debilitating, stealthy attacks on public servers globally.

[softins]

Recently some servers I operate were targeted with waves from three or four kinds of useless or malicious connections.

This is probably worth reposting as the start of a completely new discussion. I'd be interested in the specifics of what happened and what you did to detect and mitigate.

I see three parts to this, which could each be considered separately:

1. Detecting and identifying the offending traffic
2. Collating the information centrally
3. Using the collated data to limit or block such traffic in some way

[JaminShanti]

There's a tendency to overreach after a DDOS attack. Fix the one bug. Don't allow non Jamulus clients to sent udp steams. And disable blank names. That last one is an easy fix that would have stopped it day 1.

[pljones]

And blocked valid Jamulus users.

[QJKX]

There's a tendency to overreach after a DDOS attack.
A very valid point.

I'm not convinced this was a DDOS attack - I think it could be a combination of a misconfigured network device the jamulus protocol being naive, and some other mystery UDP protocol being naive. Occam's Razor.

The "targeting" could have come from a real jamulus client probing servers through a misconfigured network device that had a mix of NAT and forwarding rules, or even was rewriting packets to have the wrong from address. Instead of the Jamulus client getting the replies from server probes they could have been sent to something else that started a nonsense UDP conversation with the jamulus servers.

Don't allow non Jamulus clients to sent udp steams. And disable blank names. That last one is an easy fix that would have stopped it day 1.

I wouldn't assume those are necessarily "an easy fix". The problems come from protocol design errors, which in turn means a fix probably isn't trivial.
@dtinth 's idea of rejecting invalid Opus packets is a low impact improvement.

(I don't want my view (protocol design errors) to be interpreted as critical of the original development - Jamulus it is the way it is because it's been developed incrementally and deserves enormous credit for actually working and having provided a lot of pleasure to a lot of people.)

[pljones]

@dtinth 's idea of rejecting invalid Opus packets is a low impact improvement.

Agreed. "Until I have a valid audio packet, I have no connection" sounds reasonable.

Remember, the goal of Jamulus is focussed on getting audio packets from client to server, mixed and back. All the other stuff shouldn't be needed (including anything about "my name is"). The only places currently "audio is blocked" in Jamulus are "server" licence (which is actually handled by the client) and self-muting ("nothing" sent from the client) - both of which work in much the same way, simply bypassing the server for the client in question (valid opus silence sent, server mix received, client mixes local audio). And that's because the client has been written that way. It could ignore the server "display and agree the license" flag. (If I remember the flows correctly without checking...)

[softins]

I'm not convinced this was a DDOS attack - I think it could be a combination of a misconfigured network device the jamulus protocol being naive, and some other mystery UDP protocol being naive. Occam's Razor.

The "targeting" could have come from a real jamulus client probing servers through a misconfigured network device that had a mix of NAT and forwarding rules, or even was rewriting packets to have the wrong from address. Instead of the Jamulus client getting the replies from server probes they could have been sent to something else that started a nonsense UDP conversation with the jamulus servers.

I don't think it was accidental, but we may never know what it was, nor who was responsible, but it must have been someone who knew about Jamulus. Here is what was observed:

1. All the traffic in question came from the same IP address. This was determined by comparing the source address observed by @dtinth on his server with the client address displayed in a modified version of Jamulus Explorer when querying the older servers that had been targeted (after 3.5.6, this information was no longer available).
2. Examining the web server log on the Jamulus Explorer server (which I run) showed requests to Jamulus Explorer from the same IP address as above, at around the same time the traffic started (19 Oct). This tells me that a person familiar with Jamulus was involved somehow.
3. All the targeted servers were in Any Genre 1. This suggests that a list was fetched in some way (although I didn't observe a fetch of Any Genre 1 via Explorer at that time).
4. New servers registering in Any Genre 1 did not appear to get targeted at all. This suggests the list of target servers was only fetched once.

Even if we enhance Jamulus to ignore such traffic (which may well be worth doing), that will not prevent the myriad of older servers from such traffic in the future.

I would dearly love, without recriminations, to understand who did this, how and why, but I doubt we will ever find out unless the person in question volunteers to make themselves known.

[ann0see]

@dtinth @DavidSavinkoff @pljones could we agree to drop invalid packages as a part time fix or are there any other valid options to ensure that new servers have at least some protection?
I do not think that blocking an empty name is the way to go.

[pljones]

It'll need investigating. I thought a "connection" (UDP being connectionless, this is the Jamulus Server definition of "connection") already required valid audio to be flowing. I hadn't realised (if this is actually the case) it "only" required repeated UDP packets from a "known source".

The change would want making in the common (between client and server) network code, I think, before where an incoming packet is queued either on the audio queue or processed as Connection-oriented Message... There's a problem with this, though.

An Opus audio packet has an two byte header -- if this is zero, then we know it's audio. EVERY other packet is treated as a Protocol Message... The issue is we cannot know whether we'll get Opus audio before the first (valid) protocol request or after and the network layer itself doesn't know the protocol messages, so it has to accept all packets...

What we can do is prevent clients that have not sent valid Opus packets being listed by the server (perhaps we need two lists -- "all" remote IP/ports being seen (for the Server GUI and JSONRPC, both indicating if the client is "playing") and "all playing clients", which is what would appear in the Connect window).

So it needs looking further into, at least.

[dtinth]

I have another suggestion for a fix.

Problems with checking for valid audio packet is that we need to know 2 things in order to successfully decode a packet: (1) which decoder to use and (2) whether sequence numbers are used. These information is sent out-of-band and not in Opus audio packet, so we need to know their NETW_TRANSPORT_PROPS before we can succesfully decode an audio packet. We can also brute-force all combinations but efficiency is in question.

So here’s a new proposal:

Upon server receiving a packet from an unknown source, put them in a waiting room (do not assign a channel ID yet, dropping all audio packets in the meantime) and send it PROTMESSID_REQ_NETW_TRANSPORT_PROPS. It turns out that a Jamulus client can respond to that message before it has a channel ID assigned. Once an acknowledgement (or a reply, or a well-formed reply) is received, move them from waiting room to jamming room (where all messages are processed as usual).

[pljones]

The solution needs to be backwards-compatible as far as possible. What version of the client first supported PROTMESSID_REQ_NETW_TRANSPORT_PROPS?

[dtinth]

v3.2.0, released in 2011.

[pljones]

OK, I think we're safe then 😃.

[mcfnord]

@softins , Do you think servers.php will need to handle PROTMESSID_REQ_NETW_TRANSPORT_PROPS ?