TODO
✔️ Implement the basic firewall functionality
Implement a basic JSON-defined allow-list of IPs. Also add an option to include all LAN IPs, ie 192.168.0.0/16. If
this option is not enabled, individual LAN IPs can be allowlisted like other IPs.
✔️ Implement T2 recognition and throttling
T2 gaming servers appear to be used as mediators for matchmaking, but also as proxy for players that can't connect in a
p2p fashion. For example, if you block a cheater's IP, they will be automatically switched to a T2 tunneled connection,
which you need to block as well if you want to get rid of the cheater. But, T2 gaming servers cannot be fully blocked,
not if you want friends to play with you. Therefore, only allow a limited amount of traffic from them, which should give
your friends a window to connect to your lobby, but keep any stranger attempting full-blown connections out. Recognize
T2 gaming servers by the small size of packets (currently 12 and 18 bytes). This functionality has precedence over
the allow-list; if disabled, the allow-list must block the packet (unless the IP is allowed, that is).
✔️ Implement local crews and built-in session configurations Session configurations such as the allow-list or the T2 throttling, are defined with JSON files kept in the application's folder. Custom configurations (i.e. "crews") should be allowed as well as built-in configurations (i.e. "Solo"). These JSON files should contain the parameters for the firewall, but also meta-parameters such as the update frequency.
✔️ Implement telemetry window
The telemetry window displays the traffic as it's handled by the firewall. Packets coming from the same IP must be
grouped, e.g. "12x packets coming from 123.123.123.123" must show in a single line rather than 12. Figure out how to
group contiguous packets as appropriate.
✔️ Implement remote crews
Except for the fact that the JSON is fetched from a URL rather than from a local file, remote crews should be identical
to local crews. The content of the JSON must be obfuscated.
✔️ Implement status frames
Status frames should give an idea about what the application is doing, and to help solve problems. Things such as
informing the user that the program has attempted to refresh the session configuration from the source, whether that has
been a successful operation, how long before the next attempt, etc.
✔️ Add "wait N seconds before joining the crew" message (related to the previous entry)
This simple functionality should help users avoid the "Player no longer in session" errors, when they try to connect to
their mates before their firewall could be updated with the new IP. Roughly speaking, the firewall requires
"update_frequency" seconds to update for everybody, so the user should wait "update_frequency" seconds before joining an
existing lobby. This message must be implemented by returning the JSON session configuration for the crew together with
some flag indicating that the firewall app should show the message to the user. Such flag must be set only if the
request of the remote crew session configuration came from a different IP than the one previously known. A bell sound
should be played (optionally?) when the message is shown.
✔️ Implement strangers throttling
Allow a minimal amount of packets (mostly matchmaking requests) from strangers. Blocking all packets is still also a
possibility and sometimes a necessity (ie for crews that are frequently under attack), but doing that might cause
unforeseen issues in the long run, so it is better if it's avoided by default. The idea is to block the connection after
the matchmaking process has completed, not prevent it altogether. Like with T2 throttling, this is done with simple
heuristics, e.g. "only allow 30 packets in a 60 seconds window".
⚪ Implement session lock and Dynamic mode
TBD
⚪ Add transfer rate in the telemetry window
Also sort the columns; the packet count would be more useful if it were on the right of the table.
⚪ T2 heartbeats must be throttled together with other T2 packets
Otherwise the game is led to believe that a connection is possible.
⚪ JSON user-settings
A simple JSON registry for miscellaneous user-specific configurations.
⚪ Allow users to customize the T2 servers (depends on "JSON user-settings")
T2 servers are currently recognized by the small packet sizes. However, this is nothing more than a guess, and it might
cause problems in the future. Therefore, it should be allowed to override the T2 server IPs In the user's configuration
file.
⚪ Set and remember refresh rate (depends on "JSON user-settings")
Given how lightweight the app is, this is only going to benefit people that leave GTA running on their laptops
overnight, or people that really care about saving every penny of electric power (I do respect that). On the other hand
though, this should be very easy to implement when the JSON user-configurations "infrastructure" has been put together.
So why not? Naturally this could be implemented without the JSON bit, but having to set the value every time the app is
started is not nice.
⚪ Add notifications, e.g. play bell sound when people join or leave (depends on "JSON user-settings")
TBD
⚪ Custom enable-telemetry setting (depends on "JSON user-settings").
E.g. always enabled, disabled if minimized, always disabled.
⚪ Switch to tkinter-ttk
PySimpleGUI is very bad.
⚪ Crew's lobbies and players
This section is covered in a separate file: TODO-lobbies-and-players.md.
⚪ Access queues
Multiple crew members accessing a lobby at the same time will trigger the T2 packets throttling, which may result in
tunneled connections through crew mates. This must verified. If that is the case, it is obviously not ideal, as tunneled
connections have more latency. A solution to this might be an access queue, where users are allowed in one by one.
⚪ Port the project to Rust
For performance and for the updated WinDivert bindings.
⚪ Update PyDivert
TBD