Geomate - Geographic Game Server Filter for OpenWrt

/etc/init.d/geomate check_version
Backend versions:
  Update channel: release
  Current version: 1.1.3
  Latest version: 1.1.3
Frontend versions:
  Update channel: release
  Current version: 1.1.3
  Latest version: 1.1.3

As I said, I've already done that. And I've also played the games. It seems there's a desynchronization between the UI and the program.

I was going through the files and found this:

Error: No symbol type information
add rule inet geomate prerouting ip saddr 192.168.1.150 udp sport 49152-65535 dport 3000-28000 update @geomate_Test_dynamic { ip daddr }
                                                                              ^^^^^

My Config:

config global 'global'
	option enabled '1'
	option debug_level '0'
	option strict_mode '0'
	option operational_mode 'dynamic'
	option geolocation_mode 'frequent'

config settings 'settings'
	option interface 'br-lan'

config geo_filter
	option name 'Test'
	list allowed_region 'circle:-23.57405697:-46.63696289:88174'
	option enabled '1'
	option protocol 'udp'
	option src_ip '192.168.1.150'
	option src_port '49152-65535'
	option dest_port '3000-28000'
	option ip_list '/etc/geomate.d/test_servers.txt'

After removing the destination port, it started working again, meaning there was some error in your code related to the destination port.

nft list table inet geomate
table inet geomate {
        set geomate_Test_allowed {
                type ipv4_addr
                flags interval
        }

        set geomate_Test_blocked {
                type ipv4_addr
                flags interval
        }

        set geomate_Test_ui_dynamic {
                type ipv4_addr
                size 65535
                flags dynamic,timeout
                timeout 10s
                elements = { 35.215.205.141 timeout 10s expires 9s900ms }
        }

        set geomate_Test_dynamic {
                type ipv4_addr
                size 65535
                flags dynamic,timeout
                timeout 1h
                elements = { 35.215.205.141 timeout 1h expires 59m59s900ms, 151.101.249.91 timeout 1h expires 58m38s790ms,
                             162.159.200.123 timeout 1h expires 59m21s870ms, 172.217.162.227 timeout 1h expires 57m36s200ms }
        }

        chain forward {
                type filter hook forward priority mangle; policy accept;
                ip saddr 192.168.1.150 udp sport 49152-65535 ip daddr @geomate_Test_allowed counter packets 0 bytes 0 accept
                ip saddr 192.168.1.150 udp sport 49152-65535 ip daddr @geomate_Test_blocked counter packets 0 bytes 0 drop
                counter packets 12283 bytes 1347337 accept
        }

        chain prerouting {
                type filter hook prerouting priority mangle; policy accept;
                ip saddr 192.168.1.150 udp sport 49152-65535 update @geomate_Test_ui_dynamic { ip daddr }
                ip saddr 192.168.1.150 udp sport 49152-65535 update @geomate_Test_dynamic { ip daddr }
        }
}

However, the map still doesn't update and the servers aren't being saved in the test file I created.

What is the output of ubus call system board

{
        "kernel": "5.15.167",
        "hostname": "OpenWrt",
        "system": "MediaTek MT7621 ver:1 eco:3",
        "model": "Ubiquiti EdgeRouter X SFP",
        "board_name": "ubnt,edgerouter-x-sfp",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "23.05.5",
                "revision": "r24106-10cc5fcd00",
                "target": "ramips/mt7621",
                "description": "OpenWrt 23.05.5 r24106-10cc5fcd00"
        }
}

Found the bug:

When both source and destination ports were configured (e.g., sport
49152-65535 and dport 3000-28000), nftables rules failed to apply with
"No symbol type information" error.

nftables requires the protocol to be repeated before dport when sport
is also present in the same rule:

  • before: udp sport 49152-65535 dport 3000-28000
  • Correct: udp sport 49152-65535 udp dport 3000-28000

Made a quick hotfix and the port range should be working now. Please update to the latest version and try again...

Please be patient… your output clearly shows that GeoMate has already collected server IPs:

However, these are only written to the text file after some time and are then geolocated later (depending on the configuration). Only after that do the servers appear on the map.

1 Like

I was about to suggest manual edits of the code to test if this is the cause.

BTW I'm not sure that the fix is complete: does it take into account single port values? Also does dport always require sport?

Certainly you will test here.

Is there no way to do this manually?

I think updating the version shown in the GUI would be a good idea, since it can be misleading, as happened above.

I think the code should handle all cases correctly now:

  • Only dport (no sport): Works

  • Only sport (no dport): Works

  • Both sport + dport: Works

  • Single ports vs ranges: Both work identically

The reason why there is no manual function for this is that, for example, if you were playing a game, manually added IPs to the list, and geolocation is triggered, it could happen that the server you are playing on is located outside your region and you would get kicked out of the game.

I wanted to avoid users running into these kinds of issues and then coming to me with problems that I would have to troubleshoot again.

Just be a bit patient. For testing purposes, if you need a command to simply check whether the collected IPs have already been added to the list, you can use the following command:

echo $(( $(date +%s) - 3601 )) > /etc/geomate.d/runtime/last_geolocate_run

and then wait approx. a minute or so...

1 Like

I tested it here and it worked, however, the time it took to appear on the map was 20 minutes. I don't know if it would be possible to set the maximum value to 5 minutes since many people won't use SSH to check if it's working. And I'd also like to know if it's necessary to stay in the game for 20 minutes?

I don't think that's good because you take control away from the user.

You don’t need to use ssh to verify that it’s working under normal conditions and you don’t have to stay in a game for 20 minutes. Simply joining a game and leaving again should already be enough for the IP address to be collected.

Apart from the fact that software can of course contain bugs and we just found one earlier.... GeoMate is fundamentally designed so that you simply play your games and the server list is built automatically in the background. No need to open/close your games just to collect server ips...

If you start with an empty server list because you’re playing a new game, it simply won’t work that well at first.

But over time, as you play more and more games, the list becomes more complete and you don’t have to worry about what’s in it.

That’s exactly the idea behind it, whether you like it or not. You’re of course free to create a fork and adapt it, making exactly the changes you want.

Also, free to contribute meaningful changes! I'm open to PR's

My bad, I misread the code.

1 Like

Many people don't like it. I'm just giving a tip to improve the user experience; I don't know why you got offended.

The FIltering Now:

table inet geomate {
        set geomate_Test_allowed {
                type ipv4_addr
                flags interval
                elements = { 34.151.195.96, 34.151.214.253,
                             35.199.123.89, 35.215.210.203,
                             35.215.217.136, 35.215.223.209,
                             35.215.228.242 }
        }

        set geomate_Test_blocked {
                type ipv4_addr
                flags interval
                elements = { 8.215.42.250, 8.215.194.42,
                             8.219.40.60, 8.219.41.88,
                             34.0.140.70, 34.0.158.12,
                             34.0.159.93, 34.2.1.174,
                             34.2.3.246, 34.2.5.67,
                             34.40.17.112, 34.51.21.218,
                             34.51.49.16, 34.51.57.76,
                             34.81.22.82, 34.86.31.122,
                             34.88.241.75, 34.89.160.26,
                             34.145.250.50, 34.174.2.240,
                             34.174.44.7, 34.174.96.119,
                             35.198.101.208, 35.206.221.190,
                             35.206.237.203, 35.206.243.41,
                             35.207.109.208, 35.207.129.16,
                             35.207.185.56, 35.212.17.135,
                             35.212.55.231, 35.212.112.107,
                             35.217.37.50, 35.217.39.18,
                             35.217.58.76, 35.221.13.48,
                             35.228.52.236, 35.228.130.201,
                             35.229.179.227, 35.234.38.254,
                             47.84.148.176, 147.139.243.246 }
        }

        set geomate_Test_ui_dynamic {
                type ipv4_addr
                size 65535
                flags dynamic,timeout
                timeout 10s
                elements = { 35.215.223.209 timeout 10s expires 9s520ms }
        }

        set geomate_Test_dynamic {
                type ipv4_addr
                size 65535
                flags dynamic,timeout
                timeout 1h
                elements = { 35.215.223.209 timeout 1h expires 59m59s520ms }
        }

        chain forward {
                type filter hook forward priority mangle; policy accept;
                ip saddr 192.168.1.150 udp sport 49152-65535 udp dport 3000-28000 ip daddr @geomate_Test_allowed counter packets 51494 bytes 4647668 accept
                ip saddr 192.168.1.150 udp sport 49152-65535 udp dport 3000-28000 ip daddr @geomate_Test_blocked counter packets 0 bytes 0 drop
                counter packets 663386 bytes 2538737259 accept
        }

        chain prerouting {
                type filter hook prerouting priority mangle; policy accept;
                ip saddr 192.168.1.150 udp sport 49152-65535 udp dport 3000-28000 update @geomate_Test_ui_dynamic { ip daddr }
                ip saddr 192.168.1.150 udp sport 49152-65535 udp dport 3000-28000 update @geomate_Test_dynamic { ip daddr }
        }
}

What happens to these blocked IP addresses? Do they disappear after a while or not?

After using it for a while, I restarted the router, and when I logged back into Geomate, this appeared.

What you were proposing was to simplify a complex topic by adding more manual controls for the average user?
In practice, that doesn’t improve usability. it just increases complexity and support overhead.

Geomate is built around automation by design. If that approach doesn’t work for you, you’re free not to use it.

Your router isn't exactly a high-performance device, so as the lists grow, GeoMate's performance is likely to degrade.

It looks like the main view is missing after the reboot.

You can check this with:

ls -la /www/luci-static/resources/view/geomate/

Could it be that your storage is full?

df -h /overlay

What do you think?

1 Like

for battlefield i sugger tell me if is wrong

config geo_filter
option name 'BF6'
option enabled '1'
option protocol 'udp'
option src_ip '192.168.1.130'
option dest_port '21000-25000'
option ip_list '/etc/geomate.d/bf6_servers.txt'

Look here:

Well, if you say so, it must be true, right?

root@OpenWrt:~# ls -la /www/luci-static/resources/view/geomate/
drwxr-xr-x    2 root     root           368 Dec 12 21:31 .
drwxr-xr-x    1 root     root           816 Dec 12 21:29 ..
-rw-------    1 root     root          9349 Dec 12 21:31 geofilters.js
-rw-------    1 root     root         28738 Dec 12 21:31 map.html
-rw-------    1 root     root         48211 Dec 12 21:31 view.js

I think everything is here.

No, I have more than 200MB available.

You could answer directly, but I think yes, they are deleted.

Hudra how did you find those ip's that you have on geomate in the cod.txt and bf.txt.
Im trying to find and colect the bc.googleusercontent.com for Arc Raiders.

Well, if the developer of a piece of software reveals his design philosophy/decisions it seems rational and polite to accept these as true, the alternative is assuming that said developer lies...
Note, you can still have a different opinion about what is best, but questioning the truth of the developers statement is not a productive way forward.

Time for the regular reminder: in FOSS nobody owes you an answer or a service, so the most productive way to deal with a forum is IMHO, be grateful for all responses (even counter questions) as these indicate others are addressing your issue, and then politely ignore those responses you deem not helpful/productive.
In this specific case, you could just have run a small experiment to figure this out, no?

4 Likes

in wireshark apparently you can see the port found all list on bf6 port range is not 65535 for playstation but global 21000-25000 but not sure

Simply identify the correct ports used by the game, optionally whitelist important servers (such as matchmaking servers), and then just play. Over time, this will automatically build up a complete IP list.

Unfortunately, I only tried Arc Raiders very briefly (and refunded it because it wasn’t for me), and I wasn’t using GeoMate at the time. So in this specific case, I can’t really help you further.

I’d recommend going through the GeoMate README carefully from start to finish, step by step. After that, you should have a clear understanding of how to identify the required ports for your game and how to set up a geo-filter for a new title.

That’s possible. Every game uses source and destination ports and these can differ depending on the gaming platform.
I generally recommend using whichever port is consistent.

For example, if a game like BF6 uses a destination port range (e.g. 21000–25000), but the source port is fixed, it’s usually better to base the geo-filter on the source port rather than a wide destination range.