Samsung A56 keeps disconnecting from 5Ghz

Installing and Using OpenWrt
1

I have an ASUS RT-AX53U router with OpenWrt 24.10.5 r29087-d9c5716d1d / LuCI openwrt-24.10 branch 25.340.26705~d88390b on it.

This is a MediaTek MT7621 ver:1 eco:3 soc.

The issue is that whatever I do my Samsnung A56 (and also my Tab A9+) keeps disassociating on 5Ghz and move to 2.4 Ghz.

I’ve been playing with wireless settings but to no avail.
Went to 40 Mhz, used VHT, made sure I am not using a DFS channel.
And I am not excessively far from the AP.

Also there are no overlapping AP’s (so no AP in the channels I am using)
My signal strength at the phone at the moment of writing is about -75 dBm, but I have seen disconnections when I was much closer to the AP.
With speedtest I am still getting a througput of about 50 Mbps; much better than I get on 11g so I would like to keep using 5 Ghz

Any idea what I can do to fix this and keep my phone connected to 5 Ghz?

The 5Ghz section of /etc/config/wireless:

config wifi-device 'radio1'
option type 'mac80211'
option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1'
option channel '40'
option band '5g'
option htmode 'VHT40'
option cell_density '0'
option country 'US'
option txpower '23'
option airtime_mode '0'

config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'xxxxxxxxxxxxxxxxx'
option encryption 'sae-mixed'
option key 'xxxxxxxxxxxxxxxx’
option ocv '0'
option max_inactivity '86400'
option disassoc_low_ack '0'
option skip_inactivity_poll '1'
option max_listen_interval '65535'
option ieee80211k '0'
option ieee80211v '0'

The log says:

Fri Dec 26 13:01:22 2025 daemon.info hostapd: phy1-ap0: STA a6:98:67:93:59:52 IEEE 802.11: associated (aid 4)
Fri Dec 26 13:01:23 2025 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED a6:98:67:93:59:52 auth_alg=sae
Fri Dec 26 13:01:23 2025 daemon.info hostapd: phy1-ap0: STA a6:98:67:93:59:52 WPA: pairwise key handshake completed (RSN)
Fri Dec 26 13:01:23 2025 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED a6:98:67:93:59:52
Fri Dec 26 13:01:23 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.123.191 a6:98:67:93:59:52
Fri Dec 26 13:01:23 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.123.191 a6:98:67:93:59:52 Galaxy-A56-5G
Fri Dec 26 13:01:23 2025 daemon.warn odhcpd[1735]: No default route present, setting ra_lifetime to 0!
Fri Dec 26 13:01:35 2025 daemon.info hostapd: phy0-ap0: STA a6:98:67:93:59:52 IEEE 802.11: associated (aid 1)
Fri Dec 26 13:01:35 2025 daemon.notice hostapd: phy1-ap0: Prune association for a6:98:67:93:59:52
Fri Dec 26 13:01:35 2025 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED a6:98:67:93:59:52
Fri Dec 26 13:01:45 2025 daemon.info hostapd: phy0-ap0: STA a6:98:67:93:59:52 IEEE 802.11: deauthenticated due to local deauth request
Fri Dec 26 13:02:06 2025 daemon.info hostapd: phy1-ap0: STA a6:98:67:93:59:52 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Fri Dec 26 13:02:13 2025 daemon.info hostapd: phy1-ap0: STA a6:98:67:93:59:52 IEEE 802.11: associated (aid 4)
Fri Dec 26 13:02:13 2025 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED a6:98:67:93:59:52 auth_alg=sae
Fri Dec 26 13:02:13 2025 daemon.info hostapd: phy1-ap0: STA a6:98:67:93:59:52 WPA: pairwise key handshake completed (RSN)
Fri Dec 26 13:02:13 2025 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED a6:98:67:93:59:52
Fri Dec 26 13:02:13 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.123.191 a6:98:67:93:59:52
Fri Dec 26 13:02:13 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.123.191 a6:98:67:93:59:52 Galaxy-A56-5G
Fri Dec 26 13:02:14 2025 daemon.warn odhcpd[1735]: No default route present, setting ra_lifetime to 0!
Fri Dec 26 13:02:35 2025 daemon.info hostapd: phy0-ap0: STA a6:98:67:93:59:52 IEEE 802.11: associated (aid 1)
Fri Dec 26 13:02:35 2025 daemon.notice hostapd: phy1-ap0: Prune association for a6:98:67:93:59:52
Fri Dec 26 13:02:35 2025 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED a6:98:67:93:59:52
Fri Dec 26 13:02:37 2025 daemon.notice hostapd: phy0-ap0: AP-STA-CONNECTED a6:98:67:93:59:52 auth_alg=sae
Fri Dec 26 13:02:37 2025 daemon.info hostapd: phy0-ap0: STA a6:98:67:93:59:52 WPA: pairwise key handshake completed (RSN)
Fri Dec 26 13:02:37 2025 daemon.notice hostapd: phy0-ap0: EAPOL-4WAY-HS-COMPLETED a6:98:67:93:59:52
Fri Dec 26 13:03:05 2025 daemon.info hostapd: phy1-ap0: STA a6:98:67:93:59:52 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
1 Like
2

Don't use same name and password on both networks or don't configure 2.4 network on clients ?

Btw, sae-mixed isn't a good pick for encryption.

Which SSID a client use, is their decision, after all.

3

Yeah I considered using a different name/password but I do like a handover to 2.4 when 5 gets out of range (e.g. when going to the garden)

What do you suggest for encryption? I suspect sae-mixed is the default, and in Luci it says “strong security”. Why is it no good choice?

4

First effort would be to reset the device. Dozen parameters look like AI generated, not a normal wifi operation.
Samsung logs wifi connection history

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button (red circle; this works best in the 'Markdown' composer view in the blue oval):

Screenshot 2025-10-20 at 8.14.14 PM

Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
2 Likes
5

Default is unencrypted, use WPA2 or WPA3.

It's however unrelated to your issue.

6

Yeah, while trying to fix things I did use suggestions from chatgpt and claude.

Notably these sections from wifi-iface:
option max_inactivity '0'
option disassoc_low_ack '0'
option skip_inactivity_poll '1'
option ieee80211k '0'
option ieee80211v '0'

and this line from wifi-device

option airtime_mode '0'

I haven’t found how to get the logs at the samsung side.

I’ll try the reset. will take a bit of time though as I need to reconfigure a few things.

7

Ok, reset the device to get rid of clippy damage.

Set both bands with same AP-

Same name
Same country
Same crypto(wpa2+aes or wpa3)
Same pasword
Same network
Auto channel (ch36 which you call ch40 may be rated lower than 2.4ghz because every teapot-iot out there defaults to it)

--

Find "samsung intelligent wifi " version and tap it 10x and wifi diag menu appears.

2 Likes
8

Thanks.

I did the reset, networks have the same name and password.
I did not use auto channel but pinned to 36. There is only one other 5Ghz AP visible here on channel 52 so no conflict, and I want to avoid the DFS channels. Not sure if I am affected by it, but I am in the descent path of a nearby airport, so better safe than sorry.

The initial results seem to be OK.
I’ll keep an eye on it and report back if I find something.

Weird thing is that I did not make any changes last few months (apart from upgrading to .5 but that was already after I found the issue.

Anyway, thanks a lot for your replies!

9

DFS channels are perfectly fine to use, in the very worst case it will use 2.4GHz for a minute while next DFS survey settles.

You can add

option background_radar '1'

to 5ghz radio section. Chances are high it enables permanent radio survey like OpenWrtOne , ie just wait 10min from boot, restart 5ghz wifi and confirm it appers on other channel instantly.

10

I know they are good to use, but as there is no neighbouring AP on lower channels I feel it is better to use those. Especially since my neighbour is on ch 52

11

Some more findings: it seems after the reset still some clients move to 2.4 (but not my A56).
Issue is also that it is not too much of a problem that they go to 2.4 but they do not seem to go bac to 5.

Oh, and I remember one other recent change: I started to use NordVPN (from some clients not from the AP)

12

You can install usteer (and enable via /etc/config/usteer or luci-app-usteer) to get pushes towards upper band.

1 Like
13

It seems my A56 does not have problems any more. However now I am getting the Prune association on my Tab A9+.

The log says:
Fri Dec 26 13:57:11 2025 daemon.info hostapd: phy1-ap0: STA 16:83:c7:8f:d8:1d IEEE 802.11: authenticated
Fri Dec 26 13:57:11 2025 daemon.info hostapd: phy1-ap0: STA 16:83:c7:8f:d8:1d IEEE 802.11: associated (aid 5)
Fri Dec 26 13:57:11 2025 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED 16:83:c7:8f:d8:1d auth_alg=open
Fri Dec 26 13:57:11 2025 daemon.info hostapd: phy1-ap0: STA 16:83:c7:8f:d8:1d WPA: pairwise key handshake completed (RSN)
Fri Dec 26 13:57:11 2025 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED 16:83:c7:8f:d8:1d
Fri Dec 26 13:57:11 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.123.162 16:83:c7:8f:d8:1d
Fri Dec 26 13:57:11 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.123.162 16:83:c7:8f:d8:1d Galaxy-Tab-A9
Fri Dec 26 13:57:12 2025 daemon.warn odhcpd[1910]: No default route present, setting ra_lifetime to 0!
Fri Dec 26 13:57:17 2025 daemon.info hostapd: phy0-ap0: STA f0:b6:1e:7b:e6:89 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Fri Dec 26 13:57:22 2025 daemon.info hostapd: phy0-ap0: STA f0:b6:1e:7b:e6:89 IEEE 802.11: authenticated
Fri Dec 26 13:57:22 2025 daemon.info hostapd: phy0-ap0: STA f0:b6:1e:7b:e6:89 IEEE 802.11: associated (aid 5)
Fri Dec 26 13:57:22 2025 daemon.notice hostapd: phy1-ap0: Prune association for f0:b6:1e:7b:e6:89
Fri Dec 26 13:57:22 2025 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED f0:b6:1e:7b:e6:89
Fri Dec 26 13:57:22 2025 daemon.notice hostapd: phy0-ap0: AP-STA-CONNECTED f0:b6:1e:7b:e6:89 auth_alg=open
Fri Dec 26 13:57:22 2025 daemon.info hostapd: phy0-ap0: STA f0:b6:1e:7b:e6:89 WPA: pairwise key handshake completed (RSN)
Fri Dec 26 13:57:22 2025 daemon.notice hostapd: phy0-ap0: EAPOL-4WAY-HS-COMPLETED f0:b6:1e:7b:e6:89
Fri Dec 26 13:57:24 2025 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 192.168.123.126 f0:b6:1e:7b:e6:89
Fri Dec 26 13:57:24 2025 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.123.126 f0:b6:1e:7b:e6:89
Fri Dec 26 13:57:24 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.123.126 f0:b6:1e:7b:e6:89
Fri Dec 26 13:57:24 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.123.126 f0:b6:1e:7b:e6:89 laptop
Fri Dec 26 13:57:52 2025 daemon.info hostapd: phy1-ap0: STA f0:b6:1e:7b:e6:89 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Fri Dec 26 13:57:59 2025 daemon.info hostapd: phy1-ap0: STA f0:b6:1e:7b:e6:89 IEEE 802.11: authenticated
Fri Dec 26 13:57:59 2025 daemon.info hostapd: phy1-ap0: STA f0:b6:1e:7b:e6:89 IEEE 802.11: associated (aid 3)
Fri Dec 26 13:57:59 2025 daemon.notice hostapd: phy0-ap0: Prune association for f0:b6:1e:7b:e6:89
Fri Dec 26 13:57:59 2025 daemon.notice hostapd: phy0-ap0: AP-STA-DISCONNECTED f0:b6:1e:7b:e6:89
Fri Dec 26 13:58:01 2025 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED f0:b6:1e:7b:e6:89 auth_alg=open
Fri Dec 26 13:58:01 2025 daemon.info hostapd: phy1-ap0: STA f0:b6:1e:7b:e6:89 WPA: pairwise key handshake completed (RSN)
Fri Dec 26 13:58:01 2025 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED f0:b6:1e:7b:e6:89
Fri Dec 26 13:58:03 2025 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 192.168.123.126 f0:b6:1e:7b:e6:89
Fri Dec 26 13:58:03 2025 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.123.126 f0:b6:1e:7b:e6:89
Fri Dec 26 13:58:03 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.123.126 f0:b6:1e:7b:e6:89
Fri Dec 26 13:58:03 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.123.126 f0:b6:1e:7b:e6:89 laptop
Fri Dec 26 13:58:29 2025 daemon.info hostapd: phy0-ap0: STA f0:b6:1e:7b:e6:89 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Fri Dec 26 13:59:13 2025 daemon.warn odhcpd[1910]: No default route present, setting ra_lifetime to 0!
Fri Dec 26 13:59:58 2025 daemon.info hostapd: phy0-ap0: STA 16:83:c7:8f:d8:1d IEEE 802.11: authenticated
Fri Dec 26 13:59:58 2025 daemon.info hostapd: phy0-ap0: STA 16:83:c7:8f:d8:1d IEEE 802.11: associated (aid 5)
Fri Dec 26 13:59:58 2025 daemon.notice hostapd: phy1-ap0: Prune association for 16:83:c7:8f:d8:1d
Fri Dec 26 13:59:58 2025 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED 16:83:c7:8f:d8:1d
Fri Dec 26 14:00:00 2025 daemon.notice hostapd: phy0-ap0: AP-STA-CONNECTED 16:83:c7:8f:d8:1d auth_alg=open
Fri Dec 26 14:00:00 2025 daemon.info hostapd: phy0-ap0: STA 16:83:c7:8f:d8:1d WPA: pairwise key handshake completed (RSN)

Here are the files as requested by @brada4

root@OpenWrt:~# ubus call system board
{
	"kernel": "6.6.119",
	"hostname": "OpenWrt",
	"system": "MediaTek MT7621 ver:1 eco:3",
	"model": "ASUS RT-AX53U",
	"board_name": "asus,rt-ax53u",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "24.10.5",
		"revision": "r29087-d9c5716d1d",
		"target": "ramips/mt7621",
		"description": "OpenWrt 24.10.5 r29087-d9c5716d1d",
		"builddate": "1766005702"
	}
}

network:

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd98:df0a:ab0b::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.123.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan'
	option device 'wan'
	option proto 'dhcp'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'

wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
	option band '2g'
	option channel '11'
	option htmode 'HE20'
	option cell_density '0'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid '***********'
	option encryption 'sae-mixed'
	option key '*******************'
	option ocv '0'

config wifi-device 'radio1'
	option type 'mac80211'
	option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1'
	option band '5g'
	option channel '36'
	option htmode 'HE80'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid '************'
	option encryption 'sae-mixed'
	option key '**************'
	option ocv '0'

SSID and key are removed, they are the same for both interfaces

dhcp

config dnsmasq
	option domainneeded '1'
	option boguspriv '1'
	option filterwin2k '0'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option nonegcache '0'
	option cachesize '1000'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option nonwildcard '1'
	option localservice '1'
	option ednspacket_max '1232'
	option filter_aaaa '0'
	option filter_a '0'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'
	option piofolder '/tmp/odhcpd-piofolder'

firewall (with the example sections removed)

config defaults
	option syn_flood	1
	option input		REJECT
	option output		ACCEPT
	option forward		REJECT
# Uncomment this line to disable ipv6 rules
#	option disable_ipv6	1

config zone
	option name		lan
	list   network		'lan'
	option input		ACCEPT
	option output		ACCEPT
	option forward		ACCEPT

config zone
	option name		wan
	list   network		'wan'
	list   network		'wan6'
	option input		REJECT
	option output		ACCEPT
	option forward		REJECT
	option masq		1
	option mtu_fix		1

config forwarding
	option src		lan
	option dest		wan

# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
	option name		Allow-DHCP-Renew
	option src		wan
	option proto		udp
	option dest_port	68
	option target		ACCEPT
	option family		ipv4

# Allow IPv4 ping
config rule
	option name		Allow-Ping
	option src		wan
	option proto		icmp
	option icmp_type	echo-request
	option family		ipv4
	option target		ACCEPT

config rule
	option name		Allow-IGMP
	option src		wan
	option proto		igmp
	option family		ipv4
	option target		ACCEPT

# Allow DHCPv6 replies
# see https://github.com/openwrt/openwrt/issues/5066
config rule
	option name		Allow-DHCPv6
	option src		wan
	option proto		udp
	option dest_port	546
	option family		ipv6
	option target		ACCEPT

config rule
	option name		Allow-MLD
	option src		wan
	option proto		icmp
	option src_ip		fe80::/10
	list icmp_type		'130/0'
	list icmp_type		'131/0'
	list icmp_type		'132/0'
	list icmp_type		'143/0'
	option family		ipv6
	option target		ACCEPT

# Allow essential incoming IPv6 ICMP traffic
config rule
	option name		Allow-ICMPv6-Input
	option src		wan
	option proto	icmp
	list icmp_type		echo-request
	list icmp_type		echo-reply
	list icmp_type		destination-unreachable
	list icmp_type		packet-too-big
	list icmp_type		time-exceeded
	list icmp_type		bad-header
	list icmp_type		unknown-header-type
	list icmp_type		router-solicitation
	list icmp_type		neighbour-solicitation
	list icmp_type		router-advertisement
	list icmp_type		neighbour-advertisement
	option limit		1000/sec
	option family		ipv6
	option target		ACCEPT

# Allow essential forwarded IPv6 ICMP traffic
config rule
	option name		Allow-ICMPv6-Forward
	option src		wan
	option dest		*
	option proto		icmp
	list icmp_type		echo-request
	list icmp_type		echo-reply
	list icmp_type		destination-unreachable
	list icmp_type		packet-too-big
	list icmp_type		time-exceeded
	list icmp_type		bad-header
	list icmp_type		unknown-header-type
	option limit		1000/sec
	option family		ipv6
	option target		ACCEPT

config rule
	option name		Allow-IPSec-ESP
	option src		wan
	option dest		lan
	option proto		esp
	option target		ACCEPT

config rule
	option name		Allow-ISAKMP
	option src		wan
	option dest		lan
	option dest_port	500
	option proto		udp
	option target		ACCEPT

(oh and I considered usteer before but didn’t look into it as I feared it would add complexity)

14

And this is a screenshot from the tablet (I didn’t find a way to save the data to a file)

image
image1074×397 56 KB

as can be seen it connects at 14:57 and roams 2min 46 sec later

15

And? It is a client-side decision. Should I repeat to move off ch36? Again?

16

But why? I live in a small village. There is only one other ap visible and that one is in ch 52 (58) so 36 is non overlapping.

And it is the ap that kicks the client. See the prune message in the log

17

Ask Samsung ?

Client might have decided to migrate over to 2.4, old connection got deleted (pruned).

18

Faraway APs show as noise, enough of that from small village in quarter mile, not changing from dominant providers default ch36

19

Sorry I still don’t get it. I see prune messages in the log.

It is my understanding that the AP kicks the client, and that is what I am trying to avoid.

I also tried changing channels. As my neighbour is using 52-66 I moved to 100, being the next available channel in Luci.
That gave me something very odd. See this screenshot

image
image947×496 74.5 KB

The selection box says ch 100, 5500 Mhz but the status says ch 100 (6.450 Ghz).
The latter is quite odd especially considering the AX53U does not support 6 Ghz

What is even more odd is that I could select this. My phone and tablet did not see band 3 but after digging into the AX53U it does not support that band either. So why can I even check this.

Anyway, I’m moving back to ch 36 as my neighbour is coming in at about -80 dBm on ch52-66.

20

Set the country code? Ch100 is not allowed in default "location"