#waterfall-github
1 messages · Page 5 of 1
Waterfall version: #445
Paper version: 1.16.5 #762
Issue: When a player is refused by the subserver for some reason( for example, refused by Authme, for using an illegal username),
The subserver's console can display the right message.
[img]https://media.discordapp.net/attachments/295623711485198357/865556245980381214/unknown.png?width=1241&height=77[/img]
but waterfall can't get the right reason for "lost connection". It just displays "could not connect to a default or fallback serve...
The reason for this is that on join bungeecord tries to connects you to the priority list servers from top to bottom. When it recieves a kick, it tries the next server is that list, ifthere is none, you get this message.
The reason for this is that on join bungeecord tries to connects you to the priority list servers from top to bottom. When it recieves a kick, it tries the next server is that list, ifthere is none, you get this message.
but bungeecord should and used to show why player is kicked, why the recent version's can't。
I did not try to defend the behaviour I just explained it
Getting random disconnects, sometimes 5 players would disconnect at the same time with the following error:
UpstreamBridge has disconnected
sometimes
UpstreamBridge - NativeIoException: readAddress(..) failed: Connection reset by peer
[Proxy] Lost connection to server.
I can't point out where the issue is
My current version I am using:
waterfall-1.17-445
plugins
ViaBackwards-4.0.1.jar
ViaVersion-4.0.1.jar
config:
https://mcpaste.io/36b26db850397cc7
I did not have thi...
Connection reset by peer
This means that something external to the proxy closed the connection in an unexpected manner, this is generally out of the proxies control and generally on networking or plugins, etc, you'd need to maybe look for client logs and see if there is anything there
- Add color support to the end command
Did you rebuild the patches? Can’t imagine this not changing indexes
7196e44 Don't spam github actions log with maven progre... - Janmm14
Oh yea wait let me do that and push
Going to make a new PR with the new repo
9137560 Updated Upstream (BungeeCord) (#678) - guacaplushy
Recently PaperSpigot added a host check that doesn't allow hostnames
in ip addresses and if a hostname is present then it kicks the player
with a configure ip forwarding in bungee to connect error message.
By default Bungee doesn't actually include the hostname (as to include
it you need to call getHostName which triggers reverse service lookups
that add the hostname info). However, the only thing a bungee plugin
needs to do is to call addr.getHostName() in PlayerLoginEvent to
trigger ...
7e6af4c Strip hostname from InetSocketAddress (#679) - mibac138
Many thanks for your quick response @electronicboy
Please use the correct name for our projects - Paper, not PaperSpigot.
[PaperMC/Waterfall] New comment on pull request #625: Add CommandEvent to customize command handling
In order to update to 1.17.x, I will close this PR and open a new one!
It would be nice to have a simple system that makes Waterfall show to the client that the network is offline.
You could add a section in the config file where you can enable the feature and customize the message shown (MOTD, number of players, ect.) and how frequently Waterfall should check if any server is online.
Thats not the rôle of Waterfall, you can use a plugin to achieve this kind of behavior.
I know that, but most of the plugins that do this are made for a maintenance mode, which needs to be manually enabled.
This could be an automatic mode that Waterfall enables when it finds no servers online to forward players to.
Please consider incorporating the functionality of https://github.com/PaperMC/Paper/pull/6142 into Waterfall?
Would turn into a quite hacky implementation as Bungeecord/Waterfall are still java 8.
Is there a reason they are still Java 8? For heaven's sake, we're on Java 16 now -- enforced for MC/Spigot/Paper.
I was too busy/ill to deal with the timeline to bump waterfall, bumping the min version is on the todo list it's just getting the timeline in place, warnings out, ensuring that shit won't go sideways as it did last I tried messing with the java version \o/
You should also add something like https://github.com/Janmm14/BungeeCord/commit/b2a4bab5e9757e5cdf6bde5026198a1dd7cc21af then.
Stack trace might display the version of the plugin then as well (not tested).
Yea, that's what I was actually looking into doing with paper itself a while ago, afaik, so long as you get the manifest info in there it should be able to pick it up
How to actually change name of server_version name ? aka Protocol name to set something custom instead WaterFall
the name is not changeable in the config itself, given that it's practically the only credit we have.
Is there no other way to fix this? We have a check in DiamondProtector which ensures that you can join via the hostname, but if you join via the IPv4 in Minecraft, you can be banned directly with Linux IPTables.
By removing this now, this check has been broken.
What was the point of this check?
Bot attacks resolve the IPv4 through the srv record for example and then attack the server. Since they do this automatically most of the time, whole attack websites were directly blocked.
S...
There is no check here, this is just ensuring that only the actual IP of the player is passed through to the backend server to cater for spigots IP host checks.
This has 0 bearing in what host/IP you connected to in the client, it's completely detached from this
You dont understand what I am saying.
I am talking about my Plugin depending on Waterfall.
I use the PlayerHandShake Event therefore I get from InetSocketAdress the getHost()
and from getHost() I check if it contains the Server Hostname if yes -> do nothing else -> blacklist
now as getHost() is removed, you broke my detection.
You're not understanding what I'm saying.
getHost is not removed, the data is filtered when it is written to the handshake which is sent to the backend server, it is not removed from anywhere else, just filtered before it's passed to the server, as if something causes the players IP address to be resolved, it will cause an erroneous disconnect on the backend server.
That hostname has ZERO bearings on what is exposed in the API at all, nor is the host which is filtered relevant at all to...
Weird, because since one of the last few Updates my Check is broken anyways. So there seems to be an Update that has broken my check. My customers started to complain since they updated Waterfall
Hi there is a bug we cant connect to paper 1.8.8 from waterfall but we can connect to paper 1.12.2 or 1.13+ this is was fixed before updating. I didn't test it with Bungeecord. and I checked everything ports, Firewall, spigot.yml bungeecord=true. its working fine with paper 1.12.2 but if u change it 1.12.2 from 1.8.8 you cant connect.
[PaperMC/Waterfall] New comment on issue #683: Players can't connect to Paper 1\.8\.8 from waterfall
What version did you use before Waterfall update?
Waterfall plugins?
Potentially relevant Paper plugins?
Logs of Waterfall and Paper?
[PaperMC/Waterfall] New comment on issue #683: Players can't connect to Paper 1\.8\.8 from waterfall
before updating waterfall wasnt really old just 4 version i think.
Plugins: AdvancedNMotd, BungeeHelpMe, BungeePing, BungeeStaffChat, BungeeWhitelist, Command4Me, DynamicBungeeAuth, LiteBans, LuckPerms-Bungee, NetworkRestarter, PersianFontFixer, protocolize-plugin, ProxyAntiTab, RedirectPlus, SecuredNetwork, SkinsRestorer, SlashServer.
and there is no error in logs waterfall and paper
i tested paper without plugin
[PaperMC/Waterfall] New comment on issue #683: Players can't connect to Paper 1\.8\.8 from waterfall
I was not just asking for errors in the log, the proxy log should show that people connected and what kick message they got as they were unable to join 1.8.8 server.
You are using quite a bunch of plugins on your proxy which are not using the bungeecord api, but dig deep into bungeecord internals.
First, try updating all your proxy plugins. If the issue persists, try removing plugins from your proxy until you can join 1.8.8 servers again and then report it to the faulty plugin's author.
...
[PaperMC/Waterfall] New comment on issue #683: Players can't connect to Paper 1\.8\.8 from waterfall
Closing, this seems more like a support request than an actual issue report, and I'm not going to flood peoples emails trying to get you to provide basic information like logs
Whenever someone joins our fabric server and forge is enabled on waterfall we get this spam:
[10:45:21] [Server thread/INFO]: StormyIceLeopard joined the game
[10:45:21] [Netty Epoll Server IO #2/WARN]: Received invalid channel identifier "legacy:fml|hs" from connection net.minecraft.class_2535@34ec949f
net.minecraft.class_151: Non [a-z0-9/._-] character in path of location: legacy:fml|hs
at net.minecraft.class_2960.(class_2960.java:41) ~[intermediary-server.jar:?]
at n...
This is down to ViaVersion translating legacy plugin channel names to invalid keys
Neither the forge server or the fabric server has ViaVersion.
That error blatantly includes the hallmarks of being passed through via
That error blatantly includes the hallmarks of being passed through via
Unless fabric proxy mod has via version in it, which i highly doubt, then we do not have via version
Our Lobby server has ViaVersion, but we have the Waterfall config.yml setup so when you connect with a specific subdomain you are connected directly to that server (bypassing/skipping lobby). forced_hosts feature
That error blatantly includes the hallmarks of being passed through via
No, this is a bug in upstream BungeeCord. FML|HS is obviously not a valid Minecraft identifier, and legacy:fml|hs even less so.
This is likely the result of (a) a plugin registering the channel in question or (b) connecting to a server running 1.1...
I forgot about that horror, but, generally expected via or some proto hack to be involved here given that there wouldn't be anything tryna send that on a 1.13+ server, nothing on the proxy would send that message on its own
bc server - waterfall -1.17-448
target server - https://github.com/MohistMC - mohist-1.16.5-757



#450
https://github.com/ArclightPowered/lightfall-client
https://github.com/ArclightPowered/lightfall
these waterfall's fork look like support Modern forge
I'm experiencing this aswell, seemingly random timeouts with random players..
we also have players whos alts get disconnected but not the primary account.
Waterfall version: 448
Java version: 11
timeout: 30000
Yes, same problem on me but hapenning very randomly.. Players starts to have 10seconds ping and chunks not loading + chat not responding. Spigot server's tps are 20TPS (server is not lagging).
Hapenning on 16+ players on single server...
Ambient: Docker container running debian (not sure about the version though) and java 16, ryzen 5 3600X, 64 GB ddr4 2300MHz
Every time the ServerSwitchEvent is triggered the method getFrom() returns null. Is there a small delay I have to wait before calling the method or is that a bug?
I'm using the 1.17-R0.1-SNAPSHOT waterfall-api release in my build.gradle.
getFrom should only be null when people join bungeecord
I know, but I'm getting it when switching between server too
Just asking if I understood the issue correctly: Lightfall allows for Modern Forge Support, however it doesn't allow Vanila player to join. Is this how it works?
and I shall forever keep begging them to do so
But it will never happen in MC:Java, even Hypxiel begged them.
Having read through this, I think that there is still the issue that the backend server might not support the mods, how could you combat that?
That's 100% on mod authors to try to ensure that they'll work in an environment without their mods on the server, etc, that's 100% out of our hands
The single player mode became removed from our server jar but it gets enabled by the server's command line options in vanilla mc. We cannot connect to vanilla's single player mode because single player mode uses encryption without auth. I would like to see this feature added because I see a certain use for vanilla's single player mode. I was wondering if we could add support for this into Waterfall?
For some reason,my sub-servers' ip adresses are not statics,so i need to use ddns,which auto changes the ip addresses.And i set the domain as sub-servers' address in config but i still need to restart waterfall to get the new ip address.
Try
waterfall.yml:
use_netty_dns_resolver: true
I tried to disable Scoreboard packets/api and isn't that good, seems that SpigotMC doesn't handle it at all.
I have a problem, which happens randomly, there are days that it does not happen and days that it does.
The problem is that most of the users that are playing get kicked (not all) from the server at the same time with the exception: [username] disconnected with: ReadTimeoutException: null
In the log of the spigot sv they are kicked for the reason: Timed out
What could the error be due to?
I tried to disable Scoreboard packets/api and isn't that good, seems that SpigotMC doesn't handle it at all.
I'm not maintaining this patch, if you want to achieve the same/better behaivour: https://github.com/xxDark/PassThrough
ReadTimeoutException
The proxy didn't recieve any packets from the client within the past 30 seconds, stuff like this is generally networking issues, etc
Try
waterfall.yml:use_netty_dns_resolver: true
It's already true.
To my recollection, this is the default behaviour, it's just too darn easy
for anything which accesses those addresses to break it from what I recall
due to how the data is stored and exposed at runtime
On Mon, 13 Sep 2021, 08:01 HySand, @.***> wrote:
For some reason,my sub-servers' ip adresses are not statics,so i need to
use ddns,which auto changes the ip addresses.And i set the domain as
sub-servers' address in config but i still need to restart waterfall to get
the new ip ...
Upstream has released updates that appears to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
BungeeCord Changes:
c5a90475 #3195: Remove unused translations
3008d7ef #3189: Improve username validation
1823f86d #3190: Improve login protocol state machine
06bf088d #3186: Replace String.format calls in exceptions with simple string c…
9953698a Add GitHub Java 17 build
Hello,
I have a small home server for my kids and their friends and moved from multiverse to waterfall recently.
Almoust every time we connect (from home or outside) we get the error below.
The second or third try you can connect:
[19:04:51 WARN]: [/IP:27717|TheDarthFather] -> UpstreamBridge - read timed out
[19:04:51 INFO]: [TheDarthFather] disconnected with: ReadTimeoutException : null
I am using pterodactyl, with
Bungee:
Build: last build of waterfall and java 16.
Plugi...
Ok, I did more investigations.
It seems the Magic plugin resource pack that is loading at the beggining (as we jump directly to Survival) is causing this.
What settings options do I have (besides not loading that ress pack ) ?
I assume is a setup to force join in hub first !? ..
try increase timeout and server_connect_timeout
I increased tmeout tp 20k .. but I will do more and add server_connect_timeout as well thanks!
Closing ...
[11:17:12 ERROR]: [/45.232.34.234:55492|BarraR3port] -> UpstreamBridge - encountered exception
io.netty.handler.codec.EncoderException: java.lang.IllegalArgumentException: Cannot get ID for packet class net.md_5.bungee.protocol.packet.GameState in phase GAME with direction TO_CLIENT
at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:125) ~[waterfall-1.17-449.jar:git:Waterfall-Bootstrap:1.17-R0.1-SNAPSHOT:306121c:449]
at io.netty.channel.AbstractC...
This PR ports the root detection introduced in PaperMC/Paper#2432 (and re-added in PaperMC/Paper#6593) to Waterfall. The implementation used in PaperMC/Paper#6593 doesn't seem to work on Java 8, so I've used a slightly different check.
Likely problem of the tab plugin you have on bungeecord
You have at least one plugin which does stuff bejond the supported plugin api.
Now the second question, which plugin could be causing this error?
I'm also getting this one too: THe received string lenght is loger than allowed (19>16)
All we can tell you is that you have oversized strings somewhere, as from where? no idea, usernames are the biggest "16 chars" thing I can think of, but, otherwise, no idea
16 chars could also be the limit of 1.8 teams or tablist
Please add RCON to Waterfall like in Paper/Spigot. It is so much more elegant to manage the server espezial in an linux environment where all servers are controled via systemd.
(sry for my bad english, i'm german)
That kind of feature is outside the scope of Bungeecord or Waterfall for that matter.
The effort of maintaining that feature doesn't pay off, not to mention the additional risks it brings to the table; I'm very certain there aren't enough people who would benefit from having this feature.
Also we generally don't accept requests for features which can be very easily added using plugins, that holds true in this case as well, see: https://github.com/orblazer/bungee-rcon
Und jetzt auch noc...
rcon already causes enough issues in other aspects of mc given that it's shoed in and there's no real API to represent the concepts, rcon itself is not something where there is much traction behind, it misses out a lot of stuff to the sense that I'm more waiting on for the day of something sane rather than something which was created far too many years ago, without any form of security, which has been shoehorned many times to the sense that there are multiple variants of rcon because of the f...
I err on this, no idea if others have any other thoughts on this, I mean, it makes sense but I don't want this to become a norm in any form of the sense
Sorry for the delay, health and all, but, I'd be somewhat inclined to ask for this to be separated into separate PRs so that we can actually go through them individually
Thanks for the PR however this has already been handled
If it's any help, I'd happily accept a PR in BungeeGuard that implements this the other way around :)
Yea, that would probs be nicer, just feels a bit "shameful" like this, and I don't wanna set the means for that oddball slippy slope of "shaming" plugins <3
thx for these really detailed answers ... i see it's not a good idea
thank you very much
@electronicboy
They are still individual patches. Should be quite easy to go through them individually.
Upstream has released updates that appears to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
BungeeCord Changes:
6613aaea Add test fix for library classes being visible to non-dependent plugins
53ce6b93 #3200: Fix protocol for 21w40a
d8e29384 #2466: Use switch in "BungeeCord" plugin message handling
5cf869df #3198: Remove terminally deprecated SecurityManager
f26f7d88 Add optional 1.18 (21w40a) snapshot protocol supp...
85c0a35 Updated Upstream (BungeeCord) (#695) - tomcraft
Java 8 doesn't seem to like the NTSystem/UnixSystem classes, so I used the "running a command" method from the start, so this isn't affected by the OpenJDK bug.
Has there been any progress on the implementation of these concepts?
Question here: I can join my entirely paper/ waterfall network with a good 80% of my mods (Biomes O‘Plenty, Security Craft, Optifine, JEI, Reauth, etc.), fully functionall jumping around servers etc.). As soon as I join my network with mods that add extra mechanics to block such as (FuturePack, Create, AstralSorcery) the paper subserver throws a incomplete set of tags error. From my very simple observations it seems more of a server problem not the proxies. Or is there something I am missing?
This is not about joining paper server with mods through proxy , but about joining sponge/forge server with mods tbrough proxy.
I just came across this issue and realized I wasn't completely insane trying to get this whole thing to work. If I had the expertise, I'd help with this, but I know next to nothing about network implementation.
I'm assuming that there really is no workaround other than exposing the Forge server outside of the proxy network like normal then, right? At least, until someone can find a somewhat hacky patch for this and update Waterfall.
I'm assuming that there really is no workaround other than exposing the Forge server outside of the proxy network like normal then, right? At least, until someone can find a somewhat hacky patch for this and update Waterfall.
In our case, we are forced to run our new modded servers outside the proxy and provide a port to connect to on our server listings. I've also seen it where people can use some service records on their DNS to set a certain subdomain to work on a port but this is offt...
Both of those is literally what I ended up doing for our network, so I'm glad that I took the best option available. Thanks for confirming.
When switching server I'm getting disconnected with: IllegalStateException : Adding 1 elements would exceed capacity of 128 @ com.google.common.base.Preconditions:593
Upstream has released updates that appears to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
BungeeCord Changes:
c3fffbc9 #3205: Don't forward tab completions if the root command is a bungee command
I just PR'd a fix to the BungeeCord repo, with a whole rework of that relaying system, and how it should have been implemented in the first place. Hope it will be merged.
I just PR'd a fix to the BungeeCord repo, with a whole rework of that relaying system, and how it should have been implemented in the first place. Hope it will be merged.
Did you test it?
preliminary support for the upcoming 1.18 release
please merge this already :)
please merge this already :)
No, this pr currently support 1.18-pre1.
I will update pr at 1.18 release.
why? there are legit use cases for supporting 1.18 already, such as using vanillacord.
We very rarely commit to following snapshots closely, if this is a need, you are more than welcome to compile it
Hate to say this but md will likely update Bungeecord before so all that is needed is a patch to skip the SNAPSHOT_SUPPORT var.
That said we’d also happily take that
If md5 updates the bungeecode, I will switch this pr to upstream update.
My PR has been merged on the BungeeCord repository. Just need to update upstream here.
Upstream has released updates that appears to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
BungeeCord Changes:
c7b0c3cd #3207: Rework the plugin message relaying system to allow unregisteri…
c0c9b285 Update snapshot support to 1.18-pre1
This PR casn now be closed since this issue was fixed 😃
Hello
When I try to join my modded server I keep getting the ReadTimeoutException : null
I am one version lower than the latest also when I go into the latest it does not allow me to join with a modded client into the hub saying I have too many channels or something, https://mcpaste.io/696ab3f16751702b.
How can I fix this issue?
kind regards
ZeroG Craft Co-Owner
MrWhiteFlamesYT
I get the same error (ReadTimeoutException : null).
Waterfall kicks player after 20-30 min, but with normal client, not modded.
I also have the same problem. Proxy console logs: UpstreamBridge - read timed out
Your issue is unrelated @PFilip08 and @OPYHL
This issue is caused because too many mod communication channels are used by the client. I’ll take a look at this size limit more thoroughly in a bit
Your issue is unrelated @PFilip08 and @OPYHL This issue is caused because too many mod communication channels are used by the client. I’ll take a look at this size limit more thoroughly in a bit
Also it is when I join hub, I get the ReadTimeoutException : null when I join the modded server.
Your issue is unrelated @PFilip08 and @OPYHL This issue is caused because too many mod communication channels are used by the client. I’ll take a look at this size limit more thoroughly in a bit
Ok
Should fix https://github.com/PaperMC/Waterfall/issues/701
I didn't test this. It compiles but that's all the testing I did.
You can find a test-build here https://fivepb.me/drop/waterfall-1.17-453-experimental.jar
Hello, i'd like to know which plugins are causing these:
[18:09:20] [Netty Worker IO Thread #11/WARN]: Event PlayerDisconnectEvent(player=Zeezee12) took 731ms to process!
[18:09:25] [Netty Worker IO Thread #10/WARN]: Event PostLoginEvent(player=Lmfaoz) took 542ms to process!
Perhaps a config option to print stack trace along with these warning messages? or extract namespace from stacktrace and put it somewhere?
I think that with the addition of Velocity and the sort of deprecation of this software, and the inactivity of this PR, it's probably about time I close this. I also don't really have the motivation to want to do any more work on this PR.
If anyone wants to continue from where I've left off, feel free to take the patches I've written, I don't mind what you do with them.
Upstream has released updates that appears to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
BungeeCord Changes:
21b23624 #3159: Account for the (broken) configuration when ip forward is enabled on bungee but not the server
1ace5c0c Trial snapshot SnakeYAML version
Upstream has released updates that appears to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
BungeeCord Changes:
98afd548 Minecraft 1.18-rc3 support
7fc256db Minecraft 1.18-pre8 support
Same change as PaperMC/Paper#4796, but for Waterfall.
151435f Updated Upstream (BungeeCord) (#705) - NoahvdAa
233a2b0 [ci skip] Fix typo in upstream update commit me... - NoahvdAa
As Minecraft 1.18 requires Java 17, I think we should also use Java 17 to build Waterfall.
You may also want to update the version of setup-java and checkout actions to the newest one.
| Name | Newest version |
|---|---|
| setup-java | v2.3.1 |
| checkout | v2.4.0 |
You may also want to update the version of
setup-javaandcheckoutactions to the newest one.Name Newest version
setup-java v2.3.1
checkout v2.4.0
Good idea
You may also want to update the version of
setup-javaandcheckoutactions to the newest one.Name Newest version
setup-java v2.3.1
[chec...
You may also want to update the version of
setup-javaandcheckoutactions to the newest one.
Name Newest version
setup-java v2.3.1
checkout v2.4.0Thx, done
These actions use tags for release management to update @v2 to the latest 2.x version.
Therefore ...
@Janmm14 is correct. Please revert that for the PR to be considered, thanks.
Thank you for pointing this out to me, I reverted the changes.
[PaperMC/Waterfall] New branch created: pr/1\.18
Definitely didn't cd into the Bungee dir first
0fb2c92 Enable 1.18 release protocol. (#708) - kennytv
[08:17:06 WARN] [io.netty.channel.DefaultChannelPipeline]: An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
io.netty.channel.StacklessClosedChannelException: null
at io.netty.channel.AbstractChannel$AbstractUnsafe.write(Object, ChannelPromise)(Unknown Source) ~[waterfall-1.18-462.jar:git:Waterfall-Bootstrap:1.18-R0.1-SNAPSHOT:ab927be:462]
Between Waterfall build 448 and 460 there is an issue introduced where spectator cannot use the spectator hot bar to TP to other players.
Build -448 works whereas 460 does not with the same backends.
I have also tried removing all plugins from Waterfall and the issue persists.
at net.md_5.bungee.api.score.Scoreboard.addObjective(Scoreboard.java:55) ~[Waterfall-1.18-462.jar:git:Waterfall-Bootstrap:1.18-R0.1-SNAPSHOT:ab927be:462]
at net.md_5.bungee.connection.DownstreamBridge.handle(DownstreamBridge.java:182) ~[Waterfall-1.18-462.jar:git:Waterfall-Bootstrap:1.18-R0.1-SNAPSHOT:ab927be:462]
at net.md_5.bungee.protocol.packet.ScoreboardObjective.handle(ScoreboardObjective.java:67) ~[Waterfall-1.18-462.jar:git:Waterfall-Bootstrap:1.18-R0.1-SNAPSHOT:ab927be:462]
at...
Duplicate of the pinned issue, #318
And in the future, please try to format the issue properly.
Given waterfalls deprecation and the fact that windows is such a niche platform here, I'm not feeling inclined to deal with the issues preventing this or spend time specifically on an environment I have little experience with
9844a1a Update Java version in GitHub Actions (#707) - Luccboy
Thanks for the PR, However, adding new commands to the proxy is always this really weird area given how it will blindly interecept commands even if they're defined by the server, for this reason, I'd require that either the name was stupidly unlikely to conflict with something else, or served a substantiative purpose as to why it was added, and I'm not sure that this PR really serves either one
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
BungeeCord Changes:
425ee4e1 #3215: Add time measurement per event listener method
42d8300b #3220: Fix server list info being cached permanently
5eadf31 Updated Upstream (BungeeCord) (#713) - NoahvdAa
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
BungeeCord Changes:
f2aadd60 #3223: Only rewrite spectate packet if no IP forwarding (probably related to PaperMC/Paper#7015)
1ad81504 Update native cipher
b3a0e14 Updated Upstream (BungeeCord) (#716) - NoahvdAa
[PaperMC/Waterfall] branch deleted: update\-log4j
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
BungeeCord Changes:
b4ccdaa5 #2715: Improve BadPacketException message in MinecraftDecoder
3a116569 #3116: Do not fill in LogRecord caller data by default in slf4j wrapper
2479fab6 #3221: Use computeIfAbsent method in EventBus
51eb1ac6 Dependency upgrades
879f37f0 Upgrade to SnakeYAML 1.30 release
Thank you for the PR. As there are a few changes upstream that seem problematic I’m blocking this until I or another paper member have some time to verify it doesn’t break anything, please wait until then, thanks.
Thank you for waiting, there is one small thing that needs to be changed, please see my comment
The patch here somehow reverts the last upstream commit, and while it applies correctly I think this should be addressed here.
This line may not be missing or no exception will ever be thrown when in debug mode
Guys, I've read this and no one has really done anything yet? I ask because somehow it does not seem to me. I have some basic programming skills, but it's really hard to update from FML to FML2? When it turned out that logj4 had a bug, the fix was within a week and this has been going on for almost a year.
Guys, I've read this and no one has really done anything yet? I ask because somehow it does not seem to me. I have some basic programming skills, but it's really hard to update from FML to FML2? When it turned out that logj4 had a bug, the fix was within a week and this has been going on for almost a year.
Your comparing a bug that just required some small changes to fix to a major api change. Its called FML and FML2 for a reason that reason being that next to nothing about the api is th...
Because one allows a hacker to take control of an entire system. The other is a support request.
There is more to proxying than just handling the newer Forge handshake. You also have to deal with the fact that mods are not generally expecting the server to be swapped from underneath them like this. 1.13+ also sync data from server to client differently than previous versions, which may also need special handling.
When it turned out that logj4 had a bug, the fix was within a week and this has been going on for almost a year.
The log4j vulnerability is a critical issue that leaves ...
There is more to proxying than just handling the newer Forge handshake. You also have to deal with the fact that mods are not generally expecting the server to be swapped from underneath them like this. 1.13+ also sync data from server to client differently than previous versions, which may also need special handling.
None of that is meant to discourage an interested developer from working on this, of course.
When it turned out that logj4 had a bug, the fix was within a week...
Due to the fact that this is a whole lot of effort for little return, very few people are interested in working on this
Due to the fact that this is not supported by the forge client in any capacity anymore, this will require client side modifications, which, shrinks the already small pool of people interested in doing this, afaik they're somewhat looking for support in native forge, but, that's not trivial, but, there's already a project which has done this as a mod
There is a huge pool of people that are interested in this working and many of us have written proof of concepts on how it could be accomplished properly along with making the attempts with both Paper staff and Forge staff to get this going.
People have gone as far as to make client side mods and modified Paper/Velocity builds to make this work and that already proves we all know how and have the interest in it being completed but we can't make it mainstream alone.
**What is failing...
This is an open source project of which we are happy to work with people, however, this project is managed by 1 person and I do not have the energy nor the investment into this project as I once did, I know this is doable, me and lex spoke about the general idea years ago of how this would all work.
There is one person on the team who routinely interacts with this project, however, and he was aware of/working on some things to solve this however idk what all has been said/done, I don't hav...
We were not asking for a commitment of time, or development effort we can write these solutions and we already have. The problem is not that at all, it's that all these attempts by people fall on deaf ears and frankly for many it's become extremely frustrating.
We simply do not have the ability to start the conversations or the cooperation that is needed to get the needed changes on both side in. So you see it's not a matter of writing the software it's a social problem.
I've already spoken to lex about this years ago, I'm not really sure what all else I can say to him, we all generally agreed on the general mechanisms I've already discussed to people over this about
We mentioned it to him rather recently in hopes of getting something similar to the reset packet added for 1.13+ the response was not particularly friendly effectively pushing the entire effort required onto the proxy maker side while the proxy maker side does the same.
It's that back and forth that is very damaging to anyone trying to put considerable effort into getting this issue solved, community solutions are devised but there is a holding pattern where fingers are pointed as to if a...
Thing with a reset packet is that the entire connection state needs to be shot back down to more or less as close to a new connection as possible, hence why our general slim discussion was more just about a reconnect packet (akin to the transfer packet people have asked mojang for years), but, more being nuanced in that, ideally, you'd just send a packet to the client, the client would DC, connect to the new server and pass some token or other back in the connection so that the proxy can dete...
Guys, if I understand correctly, there is a problem with communication. And what to try and contact the creators of Mohist or Magma, they would certainly make some effort to make it work. Has it been tried yet?
mohist/magma have nothing to do with this.
Um, how come? As far as I know, they are developing hybrid servers that run the Forge + Spigot/Paper method
Because the server is 100% irrelevant here
Well, yes, but if I try to connect them and they have mods, it doesn't work, does it?
it doesn't work because waterfall doesn't have support for it. waterfall doesn't have support for it because there's little interest in dealing with support for it when the fundamental reason for support for it is not achievable with the current tech.
The server is 100% irrelevant here at this phase, they have 0 bearing on the issue at all, the foundations for this to work need to be added into forge or vanilla itself, especially if you wanted a much more reliable environment over the hack...
The issue isn't the end server, it's the proxy (to my knowledge) which is why this debate is stemming from Waterfall and not them.
That being said, Mohist and Magma are the last people we'd ever work with for various reasons.
Regardless of the true issue being "communication" or whatever philosophy you wanna bring into here, I don't see any reason to argue in a GitHub issue tracker. We...
Yet another Log4J vulnerability...

Luckily that is limited to "if attacker controls configuration"
@electronicboy Due to the recent log4j exploits i had to switch to the latest official build. Since, our servers were attacked again with the same result. Your fix in #628 doesn't seem to be working or did break at some time in between. The attacker(s) where able to OOM Bungeecord within seconds using only about 40 requests.
20:40:58] [Netty Worker IO Thread #8/ERROR]: [/X.X.X.X:54102] <-> InitialHandler - encountered exception
java.lang.OutOfMemoryError: Cannot reserve 16777216 byte...
@Sneakometer That fix in 628 was intentionally reverted during some minecraft version update, don't remember the reason tho
That was intentional indeed, there are now some packets that can easily exceed that size (up to 16mb) which is already a whole ton too much
Not sure how to fix this again
That was intentional indeed, there are now some packets that can easily exceed that size (up to 16mb) which is already a whole ton too much Not sure how to fix this again
And is this problem happening because the client sends too large packets or because every packet, even if very small, is getting 16mb ram reserved?
The client is telling that the incoming packet size is very high to force netty to allocate the maximum amont of ram. (16mib) but they send the packet very very slowly. This way with a very little amount of client, you can create an oom.
Only the server is sending very large packet (chunk).
But we do not allocate a buffer with the size before the full packet is there in Varint21FrameDecoder.
So until then, the buffer we have is completely handled by netty and that should only grow as more data arrives?
This is seemingly to me akin to the slowloris attacks done against apache, reducing the native buffer size was NOT a fix, in any form shape or capacity was it really a fix, it just did as much of a mitigation here as possible towards junk being allocated in the trunk, which, pre 1.18 was a trivial way to at least mitigate this to some degree
Netty has a buffer pool which allows these native, direct buffers to be pooled rather than the expensive allocations of them across the board, you can...
@electronicboy
Since I moved the timeouthandler after the Varint21FrameDecoder in Bungee to counter slowloris-style attacks, this would mean that the attacker is able to do this in just 30 seconds?
the buffers are fixed size, so all you've gotta do is cause enough of them to be created
the buffers are fixed size, so all you've gotta do is cause enough of them to be created
That really does not sound like thrle right thing to do from netty.
resizing the buffers is stupidly expensive, so it is the right thing to do, the big issue here is that you need to drain them at a decent pace, this is basically IMHO a massive architecture issue across the board
@Sneakometer Did you made changes to the connection throttle configuration?
the buffers are fixed size, so all you've gotta do is cause enough of them to be created
This really does not sound like it could be true.
This would mean that with 512MB there could only be 32 buffers allocated for 32 connections.
it's not supposed to be a buffer per connection, basically; This all gets nuanced on the technicalities of netty
@Sneakometer Did you made changes to the connection throttle configuration?
Not sure what the default is, but it's set to connection_throttle: 8000 on my server.
My setup:
1. Clean server, no plugins or any changes except:
**spigot.yml**
> bungeecord: true
**server.properties**
> ip: 127.0.0.1
> port: 25561
> some minor stuff like rcon, notd, port. etc
2. Pure Waterfall, with only changed:
**config.yml**
> host
> priorities
> servers
3. (as a test) BungeCord, with the same config.yml as Waterfall.
Test #1:
When running the server separately from Waterfall/Paper - everything works fin...
Logs of both server and waterfall instance please. They must include the player joining.
Tab complete is not working for bungee registered commands.. only for bungee plugins commands...
bungee and plugin commands are the exact same in this system, so that makes very little sense; if you actually have a reproducible issue, please create an issue rather than dropping a message on a random commit
I have a similar situation on my server. When the waterfall and sub-server are started, everything works fine for a while, but after a while, the joinmessage and chat have problems one after another. I can't see the chat from sub-server 2 on sub-server 1 (I installed the cross-server chat plugin), and I can't see the global join message on sub-server 1. But on sub-server 2, chat messages from sub-server 1 can be seen. But on sub-server 2, you can only see the join messages of other players bu...
Hi, i have experienced an issue when joining my server. When i try to join my server it just doesn't respond, and i get timed out after some time.
LOG:
[11:31:14 INFO]: [moonmaster324|/:] ServerConnector [lobby] has connected
[11:31:14 INFO]: [moonmaster324|/:] ServerConnector [lobby] has disconnected

Duplicate players appear in waterfall, but not on subservers.
As the title says I have a paper-1.18.1-140 hub server running on waterfall-1.18-473 bungee
I want to run a modded server off the hub server but unfortunately alot of the mods I want to use won't let my client join the papermc hub serve

r
I get this error whenever I try to join
I understand it would fix if I change the hub server to a forge server but I have a surviva...
the mods need to exist on the server when you connect so that all of the info from the server is sent and matches up with what the client expects, there is pretty much nothing we can do here
See #450
Forge above 1.12.2 isn’t supported.
Logs of both server and waterfall instance please. They must include the player joining.
As I wrote, there is nothing on logs, btw here they are:
Waterfall: https://pastebin.com/E19LTSBj
Paper server: https://pastebin.com/088t6ryZ
After successful connection to the server, as a player on a server, I was trying to enter commands, try to send something in chat. Nothing happened. Then, I send "hello?" from the server console. It displayed well. But from the player side - there is ...
**ck me, guys!
The damn AuthMeBungee was in the waterfall plugins folder.
So, I've deleted that not configured plugin, and all works fine.
I feel so dumb now.
Anyway, @sgdc3 is there a way you could somehow maybe enable the logs for the AuthMeBungee plugin in the Waterfall console?
@VladOliinyk AuthMeBungee cancels any chat message/command from any unlogged player, you probably misconfigured AuthMe or AuthMeBungee. Make sure that both plugins are installed in your network (AuthMe in your lobbies, AuthMeBungee in the proxies). Make sure that the "bungeecord" option is enabled in your spigot.yml files!
@VladOliinyk AuthMeBungee cancels any chat message/command from any unlogged player, you probably misconfigured AuthMe or AuthMeBungee. Make sure that both plugins are installed in your network (AuthMe in your lobbies, AuthMeBungee in the proxies). Make sure that the "bungeecord" option is enabled in your spigot.yml files! 😃
@sgdc3 Thanks for the detailed response! Sure! My problem was that I just completely forgot that the AuthMeBungee.jar plugin file was in the plugins folder. So I eve...
The command's code in question
@Override
public void execute(CommandSender sender, String[] args) {
if (!sender.hasPermission("command.uuid")) {
sender.sendMessage("No permission");
return;
}
if (args.length == 1) {
ProxiedPlayer target = ProxyServer.getPlayer(args[0]);
if (target == null) {
sender.sendMessage("Target not found");
return;
}
TextComponent message = ("§7UUID: §b" + target.getUniqueId().toString());
message.setCli...
Definitely not the full error log. And I am not sure how the code could ever compile without errors.
Update: I found the issue.
The plugin is using another Plugin (as seen in the full log) for data.
In my bungee.yml I put depend instead of depends which made the plugin load before the class was present.
But that above is still a really weird stacktrace. Should there not be a message like a "unkown value in bungee.yml depend" or a NullPointerException since the dependency is missing?
@Whitescan Please consult the log file next time. Many server panels add a rate limit of lines per second they display.
bungee doesn't check for unknown values in those files and doing so now would be a change of behavior which I don't feel is justified
3f86a42 Add ServerConnectRequest#sendFeedback - electronicboy
acff2e0 Pass through server request feedback to retry c... - electronicboy
[PaperMC/Waterfall] branch deleted: ServerConnectRequest\-sendFeedback
[PaperMC/Waterfall] branch deleted: pr/omegalul
[08:17:06 WARN] [io.netty.channel.DefaultChannelPipeline]: An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception. io.netty.channel.StacklessClosedChannelException: null at io.netty.channel.AbstractChannel$AbstractUnsafe.write(Object, ChannelPromise)(Unknown Source) ~[waterfall-1.18-462.jar:git:Waterfall-Bootstrap:1.18-R0.1-SNAPSHOT:ab927be:462]
Well, it's doing the work rigth it's c...
disable_entity_metadata_rewrite
disable_tab_list_rewrite
What enabling these option really do? I couldn't find exact information is it safe etc.
这是来自QQ邮箱的假期自动回复邮件。
您好,我最近正在休假中,无法亲自回复您的邮件。我将在假期结束后,尽快给您回复。
Bungeecord rewrites all entity metadata and tab list packets, those options allow you to disable that feature
The feature itself is safe and is based upon the way the modern client works, it has some caveats, but is generally safer in terms of how it treats the client and improves performance of the proxy itself
there have been some plugin compat issues, but many of those have been fixed over the years
Bungeecord rewrites all entity metadata and tab list packets, those options allow you to disable that feature
The feature itself is safe and is based upon the way the modern client works, it has some caveats, but is generally safer in terms of how it treats the client and improves performance of the proxy itself there have been some plugin compat issues, but many of those have been fixed over the years
Isn't it better to keep it enabled by default?
disabling that stuff by default would be a behavioral change, I have considered it over the years but have been wary as there has been a break or two over the years
caveats
What are these? I want to have the fastest and the smoothest server, will it help in any way?
that's of a technical nature and this is not the place for discussions
that's of a technical nature and this is not the place for discussions
I'm sure this issue will be helpful in the future for anyone who will be interested in better explanations of these options.
that's of a technical nature and this is not the place for discussions
But is it possible that I observe worse smoothness after enabling it?
This is not the place for back and forth discussions, I and many others don't need our emails being flooded with such back and forths
disabling metadata rewriting may impact switching worlds and cause the process to take longer as it resets a good chunk of stuff on the client, but otherwise it's gonna reduce the amount of work that the proxy does
As far as im concerned, paper team is not recommending using packet-limiter in paper.yml when is running under a proxy.
My suggestion would be adding a packet-limiter built directly in Waterfall as i can not really find a packet limiter plugin for a proxy.
use viaversion packet limiter then, its per player
use viaversion packet limiter then, its per player
Installing viaversion in bungee just for the packet limiter? You cant just disable other featueres and leave only packet limiter
I mean install on paper, not on waterfall.
I mean install on paper, not on waterfall.
Paper team doesnt recommend using packet-limiter in the spigot when you have a proxy... Thats why im suggesting to add a packet limiter in the waterfall
I do not get the reason of the paper team then. bungee/waterfall usually doesn't do much with the packets, so limiting them on the proxy does not create huge advantages in my eyes.
No idea who said that
Hey, i have a plugin that initializes a RestAPI with Spark. I can access that rest api if i use BungeeCord, but not when using Waterfall. The connection just timed out. In Waterfall Console is nothing showing up, no error or exception. it just blocks incoming traffic (as it seems)
i have tested it with default generated bungeecord and waterfall config.
- Java 16
- Build 480
- Linux Ubuntu 20.04.3 LTS
waterfall doesn't have any logic which would explicitly do that, timing out would generally imply an environment aspect, i.e. routing, but, god knows
idk why its happening to waterfall, but it does somehow. if i use the exact same environment but with waterfall, its not working as it does when using bungeecord
We'd need more info or something, reliable replication, etc, etc; there's nothing for us to work from here
replication is simple:
- initialize a Spark Rest Server with a GET hello-world listener and try to access it from the browser
Example Code:
Spark.port(15000);
Spark.get("/sendplayertoserver", (request, response) -> {
return "received, its working";
});
Spark.awaitInitialization();
"com.sparkjava:spark-core:2.9.3"
Okay, i have found the bug. It was my fault. The listener was blocked async, because i tried to acces the proxy.log.0 file, which does exist in bungeecord but not in waterfall
Netty will change default to what we had, so apparantly this change does not affect the maximum size of buffers.
I do not recall seing any resizing logic for the buffers, afaik the idea is that they're fixed size to prevent constant rescaling, most apps using netty are designed to deal with processing the queue effectively so that backpressure doesn't occur, etc
ah, so, we set the capacity of the buffers, the thing has logic to allocate less by default looking at it, but, maybe tries to always reserve the capacity? Thus, too many buffers = hitting the limit
ofc, caveat here is that the entire system relies upon those buffers being drained effectively, this is basically an architectural issue
Error:
Could not connect to a default or fallback server. Incorrectly configured address/port/firewall? ConnectTimeoutException : connection timed out: n1.luxxy.tech/178.128.174.71:5189
Config:
server_connect_timeout: 5000
listeners:
- bind_local_address: true
force_default_server: false
forced_hosts:
pvp.md-5.net: pvp
host: 0.0.0.0:5673
max_players: 1
motd: '&1Another Bungee server'
ping_passthrough: false
priorities:
- lobby
proxy_protocol...
Kicked whilst connecting to survival: Unknown data in login hostname, did you forget to enable BungeeCord in spigot.yml?
spigot.yml:
settings:
debug: false
bungeecord: true
I have a InitialHandler - bad packet ID, are mods in use!? No more bytes reading varint error. It slowes down my router to a restart of it, I'm getting a lot of it. What causes it & is there a way to completly stop this?
Waterfall is doing what its designed to do. You can probably use a plugin that provides a log filter or a plugin that changes how new connections are handled. Otherwise this isn’t a Waterfall issue.
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
BungeeCord Changes:
34d416a4 #3261: Remove unused AttributeKeys
410f64bc #3268: Correct plugin message size check
978e68fc #3265: Print all thrown exception
a17d8f8a #3264: Negative packet ids are also outside of range
c40d7af Updated Upstream (BungeeCord) (#731) - tomcraft
BungeeCord-Patches/0064-Waterfall-shows-to-everyone-ip-behind-backend-server.patch
这是来自QQ邮箱的假期自动回复邮件。
您好,我最近正在休假中,无法亲自回复您的邮件。我将在假期结束后,尽快给您回复。
Waterfall shows to everyone ip behind backend servers if there are not online
i'm setting to show to ip only admin.
- upstreams changes would be pulled in an upstream merge, not manually applying changes like that
- waterfall already prevents such info being leaked, bungee is opening it up to be displayed to admins, or a shorter message (at the cost of hiding it from server owners too)
No it doesnt as there is already a patch for this. I'm not a core team member but I realy think the change from upstream is uggly and should use a permission instead of checking groups this way.
Also this is not the proper way to update upstream.
I took a look in waterfall dependencies and I found that protobuf-java is running on 3.11.4 version, which was released in 2019.

Because of that outdated version, some issues like that happens everywhere.
I realize this is due to transitive dependencies, but I haven't seen any of them. I mean, we could "strictly" an...
Velocity PR: https://github.com/PaperMC/Velocity/pull/690
Forge PR pending.
You will be kicked from the bungeecord server if you try to join a server with /server.
The lobby is on version 1.8.8
The bungee cord has the latest version
And the server I want to connect to is on the 1.12.2
I sent the log where the error is
Reproduce without plugins, something caused an invalid tab completion response to be generated
What could be the reason? I have installed the following plugins:

as I said, something is generating an invalid tab response packet to be sent to the client, there is no viable path for this to occur in the proxy itself that I can see
is there any chance that above PR is getting included into waterfall aswell?
overflow in packet detected! A string had more data than allowed. For more information, launch Waterfall with -Dwaterfall.packet-decode-logging=true
This message came on the 1.12.2 server.
the paper and forge teams seek a solution that works with all major proxies, which includes bungee, so waterfall would get it automatically if bungee chooses to go with the proposal.
My server is on a Mac M1 computer.
When I run my fabric server, it is normal. Output: MCDR.log
The fabric server is on MCDR.
When I started the Waterfall server, it is also normal. Output: Waterfall.log
However, when I joined the server (I use MultiMC 5), Waterfall server says:
[19:55:32 INFO]: [/127.0.0.1:49757] InitialHandler has connected
[19:...
I'm often getting kicked after connecting to the server with server_went_down message, but there are no errors on spigot or bungee.
You'd need to work out why the connection disappeared, there is nothing here to suggest that this is a waterfall issue, and this is not the place for support
You'd need to work out why the connection disappeared, there is nothing here to suggest that this is a waterfall issue, and this is not the place for support
Kick reason is from proxy, so how to analyze it?
'it's the only way'
'There is always further stuff we can do'
@electronicboy
Please don't bump/mention on issues for useless commentary
Kick reason is from the proxy because the server lost connection and thus, the proxy no longer having somewhere to connect you to, kicked you from the proxy
There is often logs when this stuff happens, but, not always, you'll have to try to deduce what caused it
Kick reason is from the proxy because the server lost connection and thus, the proxy no longer having somewhere to connect you to, kicked you from the proxy
There is often logs when this stuff happens, but, not always, you'll have to try to deduce what caused it
I only have 'disconnected' as reason in the logs, no errors or anything.
Please don't bump/mention on issues for useless commentary
I think it's worth mentioning that closing the idea too fast can be expensive.
I fail to understand what point you're trying to make here, you are more than welcome to make sane reasonable suggestions, playing cat and mouse with bungees dated networking stack is not a high priority especially when there are many options which can deal with specific issues much better
Kick reason is from the proxy because the server lost connection and thus, the proxy no longer having somewhere to connect you to, kicked you from the proxy
There is often logs when this stuff happens, but, not always, you'll have to try to deduce what caused it
I have the error:
java.lang.IllegalArgumentException: Objective sbUsername already exists in this scoreboard
Full error:
java.lang.IllegalArgumentException: Objective sbUsername already exists in this scoreboard
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:220) ~[FlameCord.jar:git:Waterfall-Bootstrap:1.18-R0.1-SNAPSHOT:8e37934:unknown]
at net.md_5.bungee.api.score.Scoreboard.addObjective(Scoreboard.java:55) ~[FlameCord.jar:git:Waterfall-Bootstrap:1.18-R0.1-SNAPSHOT:8e37934:unknown]
at net.md_5.bungee.connection.DownstreamBridge.handle(DownstreamBridge.java:189) ~[F...
#318
What's the fix?
There is no fix atm, don't have duplicate team names across servers, basically
There is no fix atm, don't have duplicate team names across servers, basically
Isn't it creating memory leak for clients?
There is no fix atm, don't have duplicate team names across servers, basically
Also shouldn't it just be overriden, as you can't do much with scoreboards from another server?
It's not creating a leak, there is generally a race condition within the logic due to how server switches occur which makes it much harder to solve than just "overriding", please read the linked issue
It's not creating a leak, there is generally a race condition within the logic due to how server switches occur which makes it much harder to solve than just "overriding", please read the linked issue
1st server didn't have any scoreboards, should it happen in that way?
@electronicboy no way that this would happen again, something is more messed up than that.
This is not the place for a back and forth discussion, no need to spam peoples emails; You clearly have something using scoreboards, and the name doesn't look unique, so, likely some plugin on both is causing duplicate names across server instances
This is not the place for a back and forth discussion, no need to spam peoples emails; You clearly have something using scoreboards, and the name doesn't look unique, so, likely some plugin on both is causing duplicate names across server instances
Shouldn't it clear scoreboard objectives when switching the server?
So If I create objective with name I can't use it anymore on any server during the same proxy connection?
Yes.
Well that's a litte bit problematic, right? 🚀
Yes.
Doesn't your "yes" mean that vanilla scoreboards will cause this problem once you enter the same server for the 2nd time in your proxy session?
Yes, you can't have duplicate team names across servers without it breaking, this is a long standing bungeecord issue, hence the already opened issue for this; resolving this however is a PITA because aspects of this fall into the API, of which any fix for this is potentially going to introduce race conditions or inconsistencies with the API
This is the version promised by the API for bungeecord, I may look at updating the MySQL driver but this is not really an issue, relocate and shading your own dependencies is generally the best path here
I have both restricted and forced_hosts enabled. I use LuckPerms to assign the permission. I use resticted (bungeecord config) as a whitelist replacement. However I noticed when I use forced_host e.g. s1.domain.net : server1
it is not checked if i have the permission for it but i am redirected to the server if possible instead of landing in the lobby.
This is 100% intended behavior for bungeecord
Almost everytime after closing Waterfall, when I'm pressing arrows on the keyboard to run it again, I have this instead of previous commands:
^[OA^[OA^[OB^[OA^[OB^[OD
I have to kill the screen and create it again.
Not a Waterfall issue. The terminal Interfaxe you’re using has an info (terminfo) mapping that’s causing this. You will be able to fix this issue by googling for these scancode characters.
Keep in mind that this functionality, which includes the DEL key is part of the extended terminal features, so you’ll have a harder time if you’re using something like Windows builtin CMD or Powershell to access it.
As far as im concerned, paper team is not recommending using packet-limiter in paper.yml when is running under a proxy. My suggestion would be adding a packet limiter built-in directly in Waterfall as i can not really find a packet limiter plugin for a proxy.
I don't know if this is the best option, for x reason you can send more packets and get kicked out.
Not a Waterfall issue. The terminal Interfaxe you’re using has an info (terminfo) mapping that’s causing this. You will be able to fix this issue by googling for these scancode characters. Keep in mind that this functionality, which includes the DEL key is part of the extended terminal features, so you’ll have a harder time if you’re using something like Windows builtin CMD or Powershell to access it.
But it doesn't happen all the time, I use linux btw.
When there is a problem after waterfall completely shut down it cannot be a problem of waterfall.
Maybe waterfall was not completely shut down when you tried?
When there is a problem after waterfall completely shut down it cannot be a problem of waterfall. Maybe waterfall was not completely shut down when you tried?
Depends if 'end' is closing waterfall.
When there is a problem after waterfall completely shut down it cannot be a problem of waterfall. Maybe waterfall was not completely shut down when you tried?
Depends if 'end' is closing waterfall.
Did you see "Thank you and goodbye" in console before your attempts of arrow key usage fails?
When there is a problem after waterfall completely shut down it cannot be a problem of waterfall. Maybe waterfall was not completely shut down when you tried?
Depends if 'end' is closing waterfall.
Did you see "Thank you and goodbye" in console before your attempts of arrow key usage fails?
Yes I see that.


0+0+17+0=18?? These player number not right
version: waterfall-1.18-483
But after I restarted all servers...

I don't know why
But after I restarted all servers...
It could be just an normal delayed thingy, like he just leaved or smth like that. Nothing as a bug.
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
BungeeCord Changes:
eccdf87f Minecraft 1.19 support
It builds now! Haven't done any testing yet though...
Sorry for the messy commits, should be fixed now
958ae29 Updated Upstream (BungeeCord) (#741) - NoahvdAa
It compiles, but running it instantly gives an error. I tried with Java 8 and Java 17, same error. This is the entire output.
> java -jar Waterfall.jar
Exception in thread "main" java.util.MissingResourceException: Can't find bundle for base name messages, locale en
at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1581)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396)
at java.util.ResourceBundle.getBundle(Reso...
I just tested this commit https://github.com/PaperMC/Waterfall/commit/958ae29cab8832d1093f4fa9292b345cd12d9a4b
It builds, but the proxy server does not start.
These are the commands I used to clone and build Waterfall:
git clone https://github.com/PaperMC/Waterfall/
cd Waterfall
./waterfall b
It builds fine. I copied the Waterfall-Proxy/bootstrap/target/Waterfall.jar in a new folder, then running it gives the following error:
> java -jar Waterfall.jar
Exception in...
[PaperMC/Waterfall] New comment on issue #742: Waterfall does not start anymore on the current build
Thanks, working on a fix!
Fixes #742. The server now actually starts, which I probably should've checked... 😅
Commit https://github.com/PaperMC/Waterfall/commit/9b0080a3ced33d7328837f6f564483ce8208d8e7
This is what shows up on the proxy's log when a 1.19 client tries to join:
[19:45:46 INFO]: [/127.0.0.1:63051] InitialHandler has connected
[19:45:46 WARN]: [/127.0.0.1:63051] InitialHandler - corrupted frame: A packet could not be decoded because it was too large. For more information, launch Waterfall with -Dwaterfall.packet-decode-logging=true
>
This is the error after enabling ...
9719e25 Temp disable protocol limits for 1.19 - electronicboy
Sorry I actually tested the same setup with BungeeCord and I get a similar error:
[KaiNoMood] <-> ServerConnector [lobby] - encountered exception: net.md_5.bungee.util.QuietException: Unexpected packet received during server login process!
4b00
So I guess this error is not about Waterfall
Latest builds should be working
<img width="1118" alt="image" src="https://user-images.githubusercontent.com/1228900/172454338-0c3aaf9e-94f0-494f-b983-8ad88de3b05f.png">
Yes actually I was testing using a Minecraft 1.18.2 server with ViaVersion (I should have mentioned this, my bad!). While the server can be joined directly with that just fine, it cannot be joined through the proxy. So I guess I will have to redirect this issue to the ViaVersion team!
Thanks for the help!
This was an issue with Waterfall and is fixed in the latest build, it's not a viaversion issue.
Okay thanks for clarifying it! I will test the latest commit again!
While the issue in my original post was fixed, now I get the same error I get on BungeeCord while using ViaVersion!
I can join a spigot 1.19 server using the proxy with a 1.19 client, but I cannot join a 1.8.9 spigot server with ViaVersion 4.3.0 using the proxy. I can join the same 1.8.9 spigot server with ViaVersion 4.3.0 directly, without the proxy. I can also join the same 1.8.9 spigot server with any client between 1.8.9 and 1.18.2 with or without the proxy.
Is this a proxy issue, o...
if the misnomer is between a real 1.19 server and via, that's probably it; All we can tell you is that you got an unexpected packet received by the proxy from the server
I'm getting the same error. Using ViaVersion 4.3.0 with a 1.17.1 PaperMC server and latest Waterfall build available in the website (#488). @KaiKikuchi have you found the solution?
Can confirm, not fixed in latest build with viaversion 4.3.0.
I was told I should possibly open this here as it may be related to Waterfall.
BungeeCord made changes to the internals here which broke the ABI, plugin will need updating
java.lang.NullPointerException: Cannot invoke "net.md_5.bungee.connection.LoginResult.getProperties()" because the return value of "net.md_5.bungee.connection.InitialHandler.access$900(net.md_5.bungee.connection.InitialHandler)" is null
at net.md_5.bungee.connection.InitialHandler$6$1.run(InitialHandler.java:573) ~[Waterfall.ja...
Seems updating bungeecord should fix the issue.
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
BungeeCord Changes:
fc8685a0 #3311: Fix chat handling on older versions
cc4765b4 #3313: Fix offline mode support
I can't test this rn, but, probs better than current state
59dbd08 Updated Upstream (BungeeCord) (#747) - Luccboy
If i execute an bungeecord command, like my own writen /ban command there also execute that command on bukkit.
same like /bungee or something else:
This should be fixed with the newest upstream commit (https://github.com/PaperMC/Waterfall/commit/e4f1e3ff8d1b6ec226c3f1e00e5b0c495d9f9b6a)
Error on waterfall build 493. Happens on both 1.18.2 and 1.19 clients. Presumably this happens as soon as one of the Waterfall plugins send a message to player. Did not happen on pre-1.19 builds.
-> UpstreamBridge - encountered exception
io.netty.handler.codec.EncoderException: java.lang.IllegalArgumentException: Cannot get ID for packet class net.md_5.bungee.protocol.packet.SystemChat in phase GAME with direction TO_CLIENT
at io.netty.handler.codec.MessageToByteEncoder.writ...
I have a bit more context. This error happens when one of my Bungee plugins tries to connect a player to 1.19 experimental server. Interesting part is that this server can be turned off completely, but this error will still appear. So it is something on the Waterfall side.
Having the same issue in build 494.
Me too having same issue whit this build.
Upon testing out the waterfall build of 493 and 490 it seemed that Spectator mode has gotten a collision where in default cases it should be no collision what so ever like noclip.
After testing on a stable server running on 1.18.2 without the latest versions of waterfall spectator mode should work how it was, but after slapping on 1.19 update of the waterfall, when spectator mode just breaks.
After downgrading waterfall to a later versions the issues seemed to be gone.
When I am in the 1.18.2 lobby and I execute the command "/server UpdatedSurvival" to go to 1.19 survival server, it does not work.
Obviously, I have via versions and stuff all set up but it keeps disconnecting me with this error.
`[12.06 11:03:12] [Disconnect] /xxx.xxx.xxx.has disconnected, reason: Internal Exception: io.netty.handler.codec.DecoderException: java.lang.IndexOutOfBoundsException: readerIndex(8) + length(1) exceeds writerIndex(8): PooledUnsafeDirectByteBuf(ridx: 8, widx: 8, c...
We do not provide support for environments running protocol hacks, make sure that you're using the latest version of waterfall (495, at the time of writing)
so.. who does provide support for "environments running protocol hacks"?
Generally the people whose protocol hacks you're using; All we can see is that apparently you got a mangled packet, and bungee doesn't log out such info
i am not even sure what "protocol hacks" I am using lol. do you mean the ProtocolLib plguin? I contacted them already, but they don't know how to solve it, they need "further stack trace" and there is no error other than that one error I sent.
I mean viaversion, plugins on the server sending packets can also cause issues, etc; bungee explicitly cuts off the stack trace, so there's no sane means to get it without attaching a profiler or something
so my only solution is the attach a profiler and do a stack trace then send that to viaversion support and they might have a solution?
That's basically the only means of finding the actual exception and what packet, etc, blew up while being read, without modifying the proxy itself to actually print out that info
let's say, theoretically, i have no clue how to do any of that lol, can you point me towards a resource like a youtube tutorial or something lol
Your player UUID is desynced. Ensure the bungee-online-mode setting in the paper.yml reflects the bungee-online-mode and that forwarding is enabled. If that doesn’t help please turn off tab-list rewriting in the waterfall.yml
The issue has now surfaced because of the player keys. This is a wont/cantfix and is a design-flaw in bungee we cant correct due to how the system works.
As of build 495 the issue persists but now no error is printed neither in client nor in console
players cannot join server with waterfall after upgrade from 1.18 waterfall to 1.19 495
I already wrote it in the discord but I think it's better off here.
I noticed that no skins are displayed in Waterfall #495. No matter which version I connect to, it remains a Steve Skin. Also, you can't see other players. I've tried several variants.
Waterfall 1.19 --> Version 1.18.2 Server = No Skin
Waterfall 1.19 --> Version 1.19 Server = No Skin
Waterfall 1.18. --> Version 1.18.2 Server = has skin
The subservers are always the same and have not been changed
If I log in from bo...
Cannot reproduce, nor are protocol hacks supported; many issues akin to this are down to the tablist rewriting in bungee, and various other issues, you can disable tab list rewriting in waterfall.yml
Hi, i cant start my waterfall server.
I use latest build 496
No plugins, clear server
Every time I try to start the server without config.yml server will start but after the next start/restart the server no longer works.
This error appear:
[14:20:54 ERROR]: Exception in thread "main" java.lang.ClassCastException: class java.lang.String cannot be cast to class java.lang.Integer (java.lang.String and java.lang.Integer are in module java.base of loader 'bootstrap')
[14:20:54 ERROR]: ...
Your query port shouldn't be a string (remove the ').
Thanks a lot!! This is hosting default config
Thanks a lot!! This is hosting default config
Then you should change hosting.
The issue is most likely on ViaVersion side as removing it from proxy and installing it on server resolves the issue
`[19:08:34 ERROR]: [/...:52433|qkback] InitialHandler - encountered exception
io.netty.handler.codec.EncoderException: java.lang.NullPointerException: Cannot read the array length because "properties" is null
at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:125) ~[waterfall-1.19-491.jar:git:Waterfall-Bootstrap:1.19-R0.1-SNAPSHOT:eceb6b9:491]
at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContex...
This gives us nothing to go off, all we can see is that something mangled a packet, generally, reproduce without plugins, etc
i think it is caused by Parties plugin, will report here when i get response from author
Just an FYI: Disabling tab rewrite will break most (If not all) skin plugins
This "feature" has been causing many issues such as breaking spectator more on and off for years, on top of that, I'm not 100% sure what plugins would be doing that would rely on this mechanism?
This "feature" has been causing many issues such as breaking spectator more on and off for years, on top of that, I'm not 100% sure what plugins would be doing that would rely on this mechanism?
Yeah I understand, I'm just explaining for those who may be wondering why their skin plugin is no longer functioning.
As for the mechanism. Bungee skin plugins rely on the ability to overwrite the properties/uuid included in the tab-list. Without the re-write, their modified fields will not b...
PRs welcome for API which will deal with that better than relying on hacking into the current mess, I'm not too aware on what all plugins do around here, and would rather expose API for it vs having to tell people to re-enable a feature which has caused issues for years
Using waterfall 1.19-496 and a CraftBukkit version git-Spigot-3b314f5-e2790ae (spigot-1.15). When connecting to waterfall with a 1.19 client, a player can not write text on signs. The behavior follows this:
- Player places sign
- The write sign mode is engaged
- The write sign mode instantly disengages, leaving an empty sign
Protocol hacks are unsupported
I was messing around for testing the new version (1.19) and after some accurate test(s) I'm here to report that ServerKickEvent isn't started if a connected sub_server crashes (or just runs /stop).
Apparently, the issue is gone if /kick (or /ban) and /restart are being executed.
Another thing I saw after some debugging is that the proxy is using PlayerDisconnectEvent if a sub_server goes down (even in /stop) instead of kicking the player.
The issue is here after 1.19 BungeeCord's updat...
This is the error that shows up when trying to connect to the Mohist server from another server from the Bungeecord network:
"The server you were previously on went down, you have been connected to a fallback server"
(When I connect I use the right mod packs and version of forge)
My main servers are running 1.18.2 this one is 1.12.2. (Using Via Version and Via Backwards)
Works when directly connecting to the Mohist server but not through Bungeecord.
Here is the error on the p...
Mohist is unsupported. Youre also running an outdated version.
Though, it might fix itself if you disable tab-list and entity-meta rewriting in the waterfall.yml.
As above, cancelling Chatevent for 1.19 clients has no effect.
This looks like intentional behavior by upstream
boh, write on paper discord for support
We updated waterfall and viaversion on our network last week to the version 1.19-497 and since then player get randomly this error
disconnected with: Kicked whilst connecting to hub: Your data is still loaded, please rejoin in a moment.
It happens randomly on random player not all, either when the server restart and often when the player disconnect on himself
it happens on our whole network, thats why we think it might be waterfall
We made a binary search of our plugin to see if it ...
"Your data is still loaded" is not a message bungeecord or waterfall create.
This seems to be a problem of a plugin on your hub server.
this issue happens on every server we have on our network randomly, but we still tried to remove our plugin but this error happened anyway
We tried the binary search without success
im not saying waterfall is creating this error, im saying it might be a vanilla error when a data is not saved correctly
If waterfall/papermc doesnt save/load data correctly this error would show right?
it couldnt be linked to our hub because it happens on other server as well
it couldnt be linked to a pl...
If vanilla wouldve contained this message it'd be googleable, but there is no result on google.
Paper source code on github doesn't contain this message.
In general the "please ..." part does not sound like a message mojang, spigot or paper would ever put in.
They'd use different wording and no "please". Also they'd likely wait while unloading & reloading the data instead of kicking.
i dont understand then... without plugin the error is still there..
Im out for the day, tomorrow il restart the whole process in case i missed something, thanks! :)
Maybe you could provide plugin lists and versions of both waterfall and one server where this is happening. Maybe this would be better suited for the Paper forims tho, not sure what paper wants in their issues and what not.
The kick came from the server, not the proxy; We have literally 0 control over what the servers do, nothing has changed with how the proxy works either, only real caveat of bungee, which has been the case for years, is that you'll join the new server before you leave the old one, which can create very fun interesting issues for plugins which don't handle that too well
They did a total mess with this crap 1.19 update, hate it.
Can you reproduce this issue on Bungeecord itself?
If yes please move this to upstream.
The update we did wasn’t any higher quality than the Bungeecord update, simply because Waterfall is based on Bungeecord.
I don’t really see how Waterfall could break that event though
BungeeCord's situation is even worse, the kick isn't working anymore.
On waterfall the issue is partially there, for example in some setups works and on some not, but the issue is there from 1.19 update.
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
BungeeCord Changes:
587fb37b #3192, #3210: Handle null ServerPing#getPlayers upon a legacy ping
d221e529 #3241: Support ping passthrough for legacy pings
e151a6cf #3156: Add kick module
9ced5ce1 #3287: Fix HttpHandler calls done method twice
c8e876bf #3342: Fix sanitized address being not IP but hostname after InetSocketAddres...
Thanks, was doing this locally but then remembered I'd have to go update the CI system, which should be done now...
47c4790 Updated Upstream (BungeeCord) (#762) - tomcraft
Using 1.8-1.12 MC client, joining Waterfall proxy server, you can only tab complete commands that are:
- registered on the proxy server
- that player has permission to execute
Using 1.13+ MC client, joining Waterfall proxy server, you can tab complete ANY command ever registered on proxy server despite any permissions
Please test this because this is serious bug
Cannot reproduce, there are some nuances here, however; post 1.13, the way commands work in the server changed, and now the proxy needs to send all commands that the player can access to the client, this is done by injecting into the command structure packet sent by the server to add such entries
bungeecord, and by extension, waterfall, will add all of the commands which the player apparently has access to, this is 100% reliant on plugins handling command execution access properly, and won...
Hi. I'm one of the owners of a small Minecraft network using Waterfall and SubServers 2. After many "too many file descriptors" errors for the last few months, me and the other owner (cc @ilikestohack) have isolated the issue. There appears to be some sort of socket leak in Waterfall where non-Minecraft packets are accepted (of course) and never properly closed, leaving them in the CLOSE_WAIT state.
We use a tool called Uptime Kuma for status monitoring, which sends very simple TCP pings to ...
Can you do a quick check to see whether bungeecord has the same behaviour?
Can you do a quick check to see whether bungeecord has the same behaviour?
@Janmm14 This issue only occurs for me rarely. If I can force a repro with a netcat or something I will attempt that.
So usually waterfall closes the connections of your tcp pinging without problem?
My idea was since you have it set up and such, that you let the tcp pinging happen like 100 or 1000 times and then check java process after 2 mnutes or so for open tcp connections?
So usually waterfall closes the connections of your tcp pinging without problem?
My idea was since you have it set up and such, that you let the tcp pinging happen like 100 or 1000 times and then check java process after 2 mnutes or so for open tcp connections?
I will attempt this, but it's not something can do quickly. Kuma has a maximum interval of 1 ping every 30 seconds (iirc), or 2 pings a minute/120 an hour/2,880 a day/174 days for 500000 descriptors (almost what we obtain...
I think with those rates, if the number of open files of the test bungeecord after a day should already indicate whether the problem exsits in bungeecord or was introduced in waterfall.
I think with those rates, if the number of open files of a test bungeecord after a day should already indicate whether the problem exists in bungeecord or was introduced in waterfall.
I think just running a Bungee instance and mocking one of those connections (SYN, SYN-ACK, ACK, FIN) will tell me the same information (if I receive FIN-ACK, ACK I know we are all clear in Bungee)
Something mangled a packet, that's all we can see; Reproduce on a vanilla client without plugins, etc
Hi! When i receive a bungeecord message example: /server /gist /staffchat(it's custom plugin) it send in actionbar.

My waterfall version: waterfall-1.19-498
At my network in Lobby and BuildFFA servers like this. The other's are normally work.
Hi! My last issue got closed. But it doesn't have solution.
My last issue:

I have everywhere the latest 4.3.1 viaversion.
Hi! Some of my players get this error. Just a a small percent.

AND some players get this error:
disconnected with: Exception Connecting:QuietException : Unexpected packet received during server login process!
3604018078fad2a60839778bbb3370a5
Connection reset by peer is not fixable, its the other end closing the connection.
And unexpected packet bla is often also not a minecraft client trying to connect
And unexpected packet bla is often also not a minecraft client trying to connect
This error is for same players. Use official minecraft client.
There is nothing useful here for us to go off, generally something on the server sent a mangled packet, check server logs/reproduce without plugins, for support, please use the discord/forums
Clients before 1.19 don't support secure profiles, but since secure profiles is one of the first things checked those outdated clients didn't get a useful message telling them to update.
See also https://github.com/SpigotMC/BungeeCord/pull/3364

