Jump to content

Norse_Harold

Lobby Moderators
  • Posts

    424
  • Joined

  • Days Won

    9

Posts posted by Norse_Harold

  1. It looks like one Flatpak app related to 0ad was not successfully removed, "com.play0ad.zeroad.Locale". But, that only uses 114 bytes.

    If you think that some of the objects didn't get removed correctly during uninstallation of 0ad flatpak apps, you can try to repair the flatpak repo with this command as root (or with sudo). Based on this bug report, it should clear objects that don't belong there.

    flatpak repair

    As far as what's using 4 GB, note that 1.6 GB of it is likely due to the apps in a default Flatpak system that has Xorg and nothing else. Specifically, org.freedesktop.Platform, freedesktop.Platform.GL.default. Wesnoth uses 475 MB.

    It looks like you have three copies of the freedesktop platform. You also have Lagrange, Intel drivers, ffmpeg and openh264. There is a possibility that all of that adds up to the 3 GB in use in /var/lib/flatpak.

    Here are other ideas for freeing storage space.

    Check for per-user installed flatpak apps with the following command.
     

    (sign in as a user that might have 0ad installed)
    
    flatpak -u list

    Also run apt-get clean as root. That removes archived package installation files.
     

  2. 5 hours ago, rossenburg said:

    So far i'm not sure the ToU promotes creation of multiple accounts unless permitted. Not really sure if it got updated to be allowed. 

    Correct. Follow the rules, people.

    That said, I'm not able to personally enforce the rules about duplicate accounts because I don't have access to the server logs or ban capability. It's up to @Dunedan and @user1.

    I can pass information back and forth though, such as information about potentially unauthorized duplicate accounts, request for authorization of certain duplicate accounts (include the names and reasons for each), and requests to delete certain duplicate accounts (include the names and proof that you own the accounts).

    • Like 1
  3. Here's an independently developed chat extractor that by default displays only those chat messages that the logging player should be able to see. To use it, install python3, and copy 0adextract_chat.py to the logs directory within the 0ad user data directory. Start a Terminal or command prompt, change directory to the 0ad logs directory, and start the program with information about your lobby user name (and rating) by passing a command line argument. Here's a demonstration of how to start the program once you have changed directory to the 0ad logs directory. Replace "Helicity (1377)" with your lobby username and rating. If you have no rating then exclude the parentheses.

    python3 0adextract_chat.py --player-name "Helicity (1377)"

    After the match is finished, you can read all player chat with Helicity's mainlog_extractor.py script or by passing --show-all-chat to 0adextract_chat.py.

    Please don't use this to cheat. There are many good purposes for this software, including reporting player misconduct, making links copyable to clipboard without using autociv, remembering cool or funny moments from past games, and saving songs generated by ChatGPT and pasted by Larsvandijk.

    0adextract_chat.py

    • Like 3
  4. I don't think that the issue is UDP being blocked by the ISP. It's more complex than that.

    It's already known that STUN doesn't work in all cases. It depends on the network configuration of each peer.

    There's software that can be used to test STUN. The Linux package is named something like stun-client. A Windows version is available here. Here's the manpage for it. Alternatively, if your web browser supports WebRTC, there's a website-based STUN test available here.

    Here's the output that I get when I run tests 0, 1 and 2. I don't have CGNAT. Notice that the return value of test 0 is 0x000010, and the return value of tests 1 and 2 is 0x000000.

    STUN client version 0.97
    running test number 0
    Bad length string 15
    problem parsing ServerName
    Bad length string 15
    problem parsing ServerName
    Bad length string 15
    problem parsing ServerName
    Bad length string 15
    problem parsing ServerName
    Primary: Open	
    Return value is 0x000010
    STUN client version 0.97
    running test number 1
    Bad length string 15
    problem parsing ServerName
    
    Return value is 0x000000
    STUN client version 0.97
    running test number 2
    Bad length string 15
    problem parsing ServerName
    
    Return value is 0x000000

    Can someone with CGNAT please post the output of this command?

    stun -v lobby.wildfiregames.com 0 ; stun -v lobby.wildfiregames.com 1 ; stun -v lobby.wildfiregames.com 2
    • Thanks 1
  5. @BeTeSorry I linked to the wrong thread at first. Good job finding the correct one. I've corrected the link in my post as well.

    The reason that it's important to post these reports in the right thread is so that user1 can find them and process them. This Discussion thread is basically the graveyard for already-processed reports. :)

    20 minutes ago, BeTe said:

    (I don't find option to remove the previous message)

    Only admins can delete posts apparently, so nevermind.

    • Like 1
  6. I've been telling people about Carrier-Grade NAT for a while. It seems to disrupt STUN negotiation. It's unfortunate that the users who are least likely to be knowledgeable about networking and troubleshooting are also the most likely to be using Internet connections that have CGNAT. It's increasingly common now, due to IPv4 address exhaustion. It's also another step toward creating consumers out of us instead of content creators and empowered Internet peers.

    How to diagnose whether you have CG-NAT? Login to the administration interface of your modem and check the WAN or Internet IP address. If it's a private IP address (192.168.x.x, 172.16.x.x, 10.x.x.x, or 0.0.0.0) then you likely have Carrier-Grade NAT. Also check your public address with whatismyip.com or similar websites. If the modem's admin interface indicated IP does not match the IP listed by whatismyip.com then you likely have Carrier-Grade NAT.

    If you have Carrier-Grade NAT and you want to request "public IP address service" then this document could help you with explaining to your ISP what you want. There's usually an additional monthly fee for the service.

    I'll add a mention of this to the FAQ.

  7. 13 minutes ago, beau said:

    It's a simple redirect, it hosts no files, it simply redirects to our current domain, play0ad.com (which sends it to stans auto-generated page)

    I appreciate that you have good intentions and are trying to support a non-profit open source organization. So far it doesn't seem like you're making an offer to donate the domain names with no strings attached.

    Realize that simple redirects are still not secure, as they can temporarily redirect to malicious sites or inject JavaScript that then modifies HTTP content served by the legitimate site. This can change the links for downloads to malware-containing install files. A way to prevent this risk is if WFG has ownership and control of the domain names.

    • Like 1
  8. On 20/03/2023 at 7:07 PM, Helicity said:

    I've made a little Python program which extracts the chat history of players from the mainlog.html.

    Thanks for releasing the source code for mainlog_extractor.py. What license do you choose for it? The FSF suggests using Apache License 2.0 for small programs.

    I hope that players will have integrity and not use this to cheat during gameplay. And, I hope that people will use this program for good purposes like reporting in-game verbal abuse by others.

  9. On 22/03/2023 at 5:25 AM, beau said:

    This wouldn't cost the community a dime, 100% covered for and provided for by myself - [AoG]

    So you would transfer the domain ownership to Wildfire Games staff, right? It's important for security to have WFG control the domain if you expect to have downloads of the game hosted there. Otherwise there's a risk that malware is, intentionally or unintentionally, sent to users via the site.

    • Like 1
  10. @PieLamIf sound works reliably with a native package of 0ad then here is a potential hypothesis that would explain the symptoms.

    Snap apparently can have a race condition where not all devices have been enumerated in the sandbox by the time the app is started within the sandbox. Read about it here. (Scroll down to "Too early for operation errors".)

    That means you should pay attention to whether snapd is already running before each test of audio with 0ad within the Snap sandbox. To check whether snapd is running you can use this command in a Terminal window.

    ps -A | grep snapd

    To start snapd before starting 0ad, maybe this command in a Terminal window will accomplish it.

    sudo systemctl start snapd

  11. Maybe the copy on disk is fine, but the copy of the archive in RAM was corrupted due to malfunctioning RAM or CPU. Then after reboot, the archive was reloaded to RAM from disk and happened to be correct.

    Or, maybe there is a problem with the transfer interface of the hard drive such that sometimes a correct copy is retrieved and sometimes an incorrect copy is retrieved. Or, maybe something else entirely is the cause. I'm just listing hypotheses that would explain the symptoms.

  12. 22 hours ago, PieLam said:

    Shouldn't the log files be the ones that are written on start-up (sound not working)? The files below are from the last time I played 0ad (sound workiig).

    In fact, both are useful for diagnosing the problem. We can compare the log files to see what's different when sound works.

    Also, please post the output of the following commands at two different times: when sound isn't working for 0ad and when sound is working. You may need to install a package named like openal-info in the snap. The command to do that might be: sudo snap install openal-info

    snap openal-info

    snap cat /proc/asound/cards

    And, please provide the output of the following commands when sound is working for 0ad. This will tell us the hardware that is available, independent of the Snap sandbox.

    openal-info

    cat /proc/asound/cards

    Also please test sound with whatever version of 0ad is available as a native package for your system. If it works reliably there then that's a clue that the Snap sandbox might be interfering with access to the audio hardware.

    Basically, ask the question, "under what conditions does sound work reliably?" and construct controlled experiments that test various conditions and make observations. Is it due to the hardware that you're using? Try different hardware temporarily. Is it due to the audio backend that you're using? Try using a different audio backend with OpenAL, as explained in the FAQ answer about sound.

    And, did you follow the advice in the FAQ answer about sound? I've updated it a few times over the months. Scroll down to the answer to "No sound, no audio, or 0 A.D. is the only app with sound".

  13. Thanks for copy/pasting the error messages. Can you attach mainlog.html and system_info.txt? What was happening in the game at the time that the error occurred? Can you cause it to happen again? What happens if you reboot your computer and try to cause the problem to happen again? Which mods were you using at the time? How can others reproduce the symptoms?

    Without further information and testing, we can only guess what would cause that. The error message states that the checksum of a part of a Zip archive failed to match the correct checksum. This could be caused by corruption of the data on the storage device. Or, it could be caused by faulty RAM or CPU. Please make a backup of the game data and then reinstall the game. If that doesn't fix it then check for hardware problems. For example, you can check for faulty RAM with memtest86+.

  14. Please follow the lobby Terms of Use, everyone. Duplicate accounts without authorization are not allowed, so any duplicate accounts that anyone has, please disclose them to the lobby moderators and the reason for having them. Also state which account you would like to consider your primary account from now on. We'll review the request for authorization and might actually authorize a duplicate account or two for legitimate purposes.

    G.O.A.T, please stop calling duplicate accounts "smurfing". Smurfing, as far as I know, means more than just using duplicate accounts. It means lying about one's skill. I think that Yekaterina is good about disclosing their skill level when asked, so that games can be balanced.

    weirdJokes, an unfactual acccusation of a crime (for example breach of contract by violating the terms of use, bullying on the Internet , or ddosing people. These are crimes in certain jurisdictions.) is called libel. Please don't do it. If you have witnessed misconduct or a crime then please disclose the evidence to the moderators. Don't make accusations without evidence. That goes for you too, G.O.A.T.

    • Like 1
    • Thanks 1
  15. 1 hour ago, Helicity said:

    Do you think the MTU patch can be implemented into the default game in the next update? @Norse_Harold

    I would advocate for a fix being implemented into the default game in the next update, but I'm not the decider of that. @Stan`what do you prefer?

     

    1. Adjust the default MTU of 0ad to 1392.

    2. Add a feature for users to override the MTU in the configuration and/or command line. (Note that without options 1 or 3, user education would still be necessary in order to actually solve the problem.)

    3. Ask ENet to adjust the default MTU to 1392.

    4. Options 1 and 3. Guard option 1 with a check of the version of ENet or a check of the value of ENET_HOST_DEFAULT_MTU. Undo option 1 when options 3 or 8 are implemented and used widely by the player base.

    5. Add logic to 0ad to adjust the MTU of each connection between two peers to the minimum of those two peers.

    6. Add logic to ENet to adjust the MTU of each connection between two peers to the minimum of those two peers.

    7. Add logic to 0ad to sense a correct MTU.

    8. Add logic to ENet to sense a correct MTU.

     

    Notice that most or all options can be combined. They are listed roughly in ascending order of time required.

    • Like 1
    • Thanks 1
  16. Today we ran some tests with 0ad while I was connected via VPN, and Helicity was connected via school wifi. We first ran a controlled experiment without the MTU adjustment patch applied. As expected, the maximum outgoing packet size was 1400 data bytes, in fragments of 1400 bytes on wire and 28 bytes on wire, and the problem occurred where Helicity was disconnected after adjusting the number of player slolts to 5 or more.

    Then I hosted a game with the patch applied that adjusts the MTU to 1392. Helicity connected, and I varied settings in the gamesetup that would normally have caused him to get disconnected. He remained connected.

    We used cheat codes to create armies of 200 to 400 units and have them fight. It worked well, and Helicity remained connected until we ended the game voluntarily at about 6 minutes. During the test, the maximum outgoing packet size generated by 0ad was 1392 data bytes (1420 bytes on wire), of which there were 133 such packets, and none of which were fragmented.

     

    • Like 2
    • Thanks 1
  17. 3 minutes ago, hyperion said:
    38 minutes ago, Norse_Harold said:

    There is stilil fragmentation of incoming large packets (1400 bytes)

    This sounds a bit like luck that the order was preserved.

    Linux is able to re-order received out-of-order fragmented packets, within reason.

    See the documentation for sysctl variables net.ipv4.ipfrag_time and net.ipv4.ipfrag_max_dist in (Linux kernel source code tarball)/Documentation/networking/ip-sysctl.rst

    7 minutes ago, hyperion said:

    The reason why I'm somewhat skeptical is such a bug should have been found long ago one might think.

    I would have thought so too. What other tests would you recommend in order to be sure one way or the other?

  18. I haven't tested a game with Helicity yet, but as I said with the patch applied to my copy of 0ad, longsentenceasname was able to stay connected for an entire game, despite large packets of at most 1392 bytes sent to him during the game. Therefore, there was not packet loss of the large outgong packets. There is stilil fragmentation of incoming large packets (1400 bytes), and it would be nice to have the ability to prevent that as a host, but those packets aren't being dropped.

    I'm leaning toward it being a bug in ENet or 0ad. I'm surprised that so far I have found no feature in ENet for automatically adjusting the MTU of the link, but maybe that means that the user app is responsible for adjusting the MTU.

    I think that a proper solution would involve looking at the OS's indication of the MTU of the link that's in use, and harmonizing the MTU used by ENet (or 0ad) to that value at first. Then, upon connection, both peers use the minimum MTU of each side of the connection. It may be difficult for the library or app to determine which link is in use, because when a VPN is in use there is more than one default gateway, and multiple routing table rules are in place. Therefore, maybe a system could be added that would allow the user to hint which interface is in use or at least the MTU to use.

  19. On 06/03/2023 at 11:14 AM, hyperion said:

    still waiting for the output of the original ping command from @Helicity to confirm.

    Okay, Helicity did the ping command. Here are the results.

    White redaction: Helicity's user and host name

    Red redaction: Harold's VPN IP address

    Blue redaction: Helicity's IP address

    2000214709_ping-m1392haroldsvpnip.png.a2011b7278cd53a5427c7cd84d3fe670.png

    Then I asked Helicity to test with a packetsize of 1400 bytes:

    1804704268_ping-m1393haroldsvpnip.png.d4c54085d41107debbb8ab2a4139ed1b.png

     

    We also tested a packetsize parameter of 1393, and it resulted in fragmentation needed. So, it seems that the maximum is 1392 bytes.

    By the way, normally my firewall blocks all ping requests and replies. At first, Helicity got no replies regardless of the packetsize chosen, as expected. I added a firewall rule to allow ping requests and replies with only Helicity's IP address, which produced the above output when Helicity ran the tests.

×
×
  • Create New...