The server handles commands in order and holds back everything sent
after a lost one, so giving up on a command now ends the connection, as
in the official client. A connection lost without either side saying
goodbye (a timeout, or such a command) is now reported to listeners as
a disconnect ("connection lost").
- A command's acknowledgement is awaited in the background: ensureSent
is often called from the packet handler thread, which must keep
handling while resends go on. A command that fails makes way for the
next one.
- One packet that fails to handle no longer ends the handler thread,
which left everything after it unhandled while ACKs and pings kept the
connection looking alive.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
TS3 derives a packet's key and nonce from its id, so resending a packet
encrypts it under the same pair again. BouncyCastle has since learned to
refuse that on a cipher that has already used the pair ("cannot reuse
nonce for EAX encryption"), which broke resends on the current version
the Android build uses. A fresh cipher per packet keeps them working.
Moves to bcprov-jdk18on 1.86, the maintained line, so every platform runs
the same BouncyCastle.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
TS3DNS resolved SRV records through JNDI's DNS provider, which Android
does not have. The JNDI code moves into its own class that is only
loaded where JNDI exists; elsewhere a server is reached by its address,
as when it publishes no SRV record. TS3DNS.setSrvLookup lets a platform
supply its own resolver.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Resend unacknowledged packets on the official client's schedule (mean RTT
+ 3 sigma + 50 ms over the last 20 samples, x1.4 per resend) and give up
after 18 s, instead of a fixed 1 s x 30.
- Resend INIT1 packets until the server answers; they are never ACKed.
- Answer each server Init1 step once: a duplicated step-3 reply sent a second
clientinitiv with a new alpha, leaving client and server with different
keys (MAC check failures).
- Disconnect without blocking on an ACK the server may never send.
- Fail waitForState promptly when the connection drops, and name the packet
in decrypt errors.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The server does not acknowledge a resent clientek, so losing its first ACK
stalled the handshake: we kept resending clientek and never got to
clientinit. Send clientek without blocking (resends continue in the
background via the new writePacketAsync) and follow with clientinit right
away; the server cannot decrypt clientinit before it has processed
clientek, so the two stay in order.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The server encrypts initivexpand2 (COMMAND 0 and 1) with the handshake
key. If our ACK for one of those fragments is lost, its retransmit arrives
after we switched to the session key, fails with "mac check in EAX
failed", is never acknowledged and blocks the server's command stream
until it drops us. Common on lossy links such as mobile data.
Retry generation 0 packets that fail under the session key with the
handshake key.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Some servers list a client with an empty client_servergroups; parsing it
threw NumberFormatException and aborted iterating the whole client list.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
RemoteCounterFull only knew a 100-packet window. A packet that arrived more
than 100 IDs late - typically a retransmit after a loss in the large burst a
busy server sends on connect - was assumed to belong to the next generation,
as was packet ID 0 right after a wrap. The generation feeds the EAX key, so
those packets failed with "mac check in EAX failed", were never acknowledged
and stalled the command stream.
Place each ID in the generation closest to the newest packet received, and
remember the last 32768 positions for duplicate detection.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Without -voice the server omits client_input_muted/output_muted and
the hardware flags entirely, so a bare clientlist leaves callers
unable to tell "false" from "not reported" and defaults them wrong.
initserver announces the whole virtual server (its name above all), but only
the client and server ids were taken from it and the rest was dropped. The
name is not obtainable elsewhere: servergetvariables answers without it, and
notifyserveredited only fires when someone edits the server.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both were pulled in for a single call each: commons-lang for
ConstructorUtils.invokeConstructor when building a packet handler, and
dnsjava for the _ts3._udp SRV lookup. Together they added over a
megabyte to a shaded jar (and dnsjava drops jnamed/update classes into
the jar root). Plain reflection and JNDI's dns: provider cover both.
Also drop the BouncyCastleProvider registration: every digest here is
requested by a name the SUN provider already answers, so the only thing
it accomplished was keeping the whole JCE provider, the post-quantum
suite and the X.509 stack reachable for a shaded-jar tree-shaker.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Change client.password to client.server_password in LocalTeamspeakClientSocket.java so that password authentication is properly passed at connection time.
- There is now more detailed output for command futures when reconnecting: "client reconnecting" instead of "client disconnected"
- The MusicPlayer example now returns exit code -1 when it is kicked/disconnected prematurely.
You have to trim that last byte off, otherwise your audio will be corrupted. TS3J now does this automatically and stores it in ServerFlag0 for you, as a nullable Byte object. This way you can handle it if you need to. This has also been factored into the output/write stage.
Digging into theory, I believe this ID has something to do with the opening of a new decoder to ensure that the decoder opens cleanly each time. You do NOT have to do anything to your decoder to reset states, etc., from what I can tell. In other words, COMPRESSED being on shouldn't change the behavior of your decoding.
erikbrockoandClaude Opus 5.5
Mario Beck
nodamnway
sump pump
Phyrone
Manevolent