LG aircon refusing to connect to WiFi

[Adam_S]

Hi All,

Need some expertise with LG aircon. It suddenly disconnected from my wireless network, and refuses to reconnect (no changes were made). Occasionally it would reconnect and immediately drop off. I tested on a standard home router wireless with no security, it still refused to connect. LG have since replaced the wireless dongle and all the circuit boards. It now connects to a the home router WiFi and a phone hotspot, but still refused to connect to my WiFi. Upon further investigation i can see that it obtains an IP address and the translation table shows that it communicating to DNS 8.8.8.8 as primary (which is correct), but has a secondary of 9.9.9.9 (i have not specified this anywhere), additionally all other devices on the SSID are connecting fine. I have attached the device config and some outputs.

[marce1000]

    - What is the wireless environment you are using ? Is there a controller ? 
       If so , specify the software version and model being used (e.g.)

 M.

[Adam_S]

Hi thanks for the response. They're autonomous access points. That
associate to a 3rd AP via WDS. There is a show run attached that will have
the version number, they are all using the same image.

[marce1000]

  - Have a look at https://community.cisco.com/t5/wireless-mobility-knowledge-base/basic-cisco-ap-debugging-autonomous-ios/ta-p/3108718

 M.

[Rich R]

9.9.9.9 can only be from static config on the LG.  But it is a valid DNS service provided by https://www.quad9.net/
Providing the Google secondary (8.8.4.4) in DHCP will probably overwrite that if you really don't want it to use the quad9 server.

> www.google.com
Server: dns9.quad9.net
Address: 9.9.9.9
Non-authoritative answer:
Name: www.google.com
Addresses: 2a00:1450:4009:81f::2004
142.250.200.4

The LG client is getting an IP address and trying to access the internet so it doesn't look like a wireless problem.
Have you done a packet capture to see what it is actually doing and where it goes wrong?
Also compare that to when it's connected to the home router and see what the difference is.

[Adam_S]

Thanks for the response. ive done packet captures on the home router,
there's a lot of noise on the cisco side. I haven't got round to figuring
out how to filter the wire shark output.

[Adam_S]

I've managed to do a packet capture from the a hotspot and one when it fails from the cisco devices. Seems to be something the cisco router is doing, as i connected the RSP supplied router to the cisco router (by passing the Aps) and the same issue occurred. Wireshark is showing RST and retransmissions.

[Rich R]

It would helpful to know which IP address is the LG in the packet captures and where you think it's going wrong.
What model is the Cisco router and what IOS is it running?
Presumably you're doing NAT on the Cisco router - how is the NAT configured?
TCP MSS adjust can solve a whole lot of problems if it's related to MTU/fragmentation somewhere in the path - start conservative with a value like 1250 (recommend best practice with Cisco WLCs) and test increasing it to see what will work if that helps.

[Adam_S]

Hi,
This is a cisco 3845 running c3845-adventerprisek9-mz.151-4.M.bin. Same issue on c3845-advipservicesk9-mz.124-16.bin. Looks like its where the TCP retransmission reoccur (possibly with the translation???), as they are not present in the successful capture.

The 192.168.40.103 is the capturing device, but im not sure of the actual IP the LG takes it should be on the same subnet 192.168.40.XXX. If i look at the DHCP pool i can see that an address is provided, but it doesnt show up in the capture.

I have not yet had a chance to test the TCP MSS suggestion

below is the NAT config (ive excluded all the other interfaces for simplicity)

Interface IP-Address OK? Method Status Protocol

GigabitEthernet0/1 100.67.29.57 YES DHCP up up -> internet facing
Vlan40 192.168.40.1 YES NVRAM up up

Extended IP access list NAT-ACL
10 permit icmp any any (25819 matches)
20 permit ip 10.0.0.0 0.255.255.255 any (23818 matches)
30 permit ip 172.17.0.0 0.0.0.255 any (235929 matches)
40 permit ip 172.16.0.0 0.0.0.255 any (125742 matches)
50 permit ip 192.168.40.0 0.0.0.255 any (4009 matches)
60 permit tcp any any (60 matches)
70 permit udp any any (2030 matches)
80 permit ip any any

interface Vlan40
ip address 192.168.40.1 255.255.255.0
ip nat inside
ip virtual-reassembly in

ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/1 dhcp

interface GigabitEthernet0/1
ip address dhcp
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
media-type rj45
end

[Adam_S]

Hi,
This is a cisco 3845 running c3845-adventerprisek9-mz.151-4.M.bin. Same
issue on c3845-advipservicesk9-mz.124-16.bin. Looks like its where the TCP
retransmission reoccur (possibly with the translation???), as they are not
present in the successful capture.

The 192.168.40.103 is the capturing device, but im not sure of the actual
IP the LG takes it should be on the same subnet 192.168.40.XXX. If i look
at the DHCP pool i can see that an address is provided, but it doesnt show
up in the capture.

I have not yet had a chance to test the TCP MSS suggestion

below is the NAT config (ive excluded all the other interfaces for
simplicity)

Interface IP-Address OK? Method Status
Protocol

GigabitEthernet0/1 100.67.29.57 YES DHCP up
up -> internet facing
Vlan40 192.168.40.1 YES NVRAM up
up

Extended IP access list NAT-ACL
10 permit icmp any any (25819 matches)
20 permit ip 10.0.0.0 0.255.255.255 any (23818 matches)
30 permit ip 172.17.0.0 0.0.0.255 any (235929 matches)
40 permit ip 172.16.0.0 0.0.0.255 any (125742 matches)
50 permit ip 192.168.40.0 0.0.0.255 any (4009 matches)
60 permit tcp any any (60 matches)
70 permit udp any any (2030 matches)
80 permit ip any any

interface Vlan40
ip address 192.168.40.1 255.255.255.0
ip nat inside
ip virtual-reassembly in

ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/1 dhcp

interface GigabitEthernet0/1
ip address dhcp
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
media-type rj45
end

[Scott Fella]

Can your LG A/C connect to an open SSID on your autonomous setup?

[Adam_S]

Hi,

it doesnt connect to an open SSID on autonomous AP, it has the same result.

[Scott Fella]

You have a tough one there.... a device that doesn't connect to an open SSID, I'm not talking about connecting to the backend server, and the fact that other device connect fine.  The only thing when reading through this is that this device was working fine for a while I assume, and then stopped connecting to the SSID.  There was no changes on your end but was there an update pushed to the LG?  The tech replaced the wireless on the LG and it still does not connect.  The LG wireless card does not like some setting on the SSID, even with an open SSID, you should see devices authenticating to the SSID and then at least see a dhcp request.

In the past when autonomous access points were being migrated to AireOS, devices didn't like a mix of WPA/WPA2/TKIP/AES and in your setting you have WPA wtih AES.  This is why I asked you to test with an open SSID, to elimiate this being an issue.  When you connect to your home router, what are you choosing?  Something like WPA2-Personal, WPA/WPA2-Personal?

[Leo Laohoo]

I have a strange feeling that replacement wireless dongle is either a refurb or someone's configuration is in it.  

Is there a way to factory-reset that dongle?

[Adam_S]

I don't believe there is anyway to factory reset it, but it was connecting
previously when it suddenly dropped out, thats when the tech replaced it.
I've used the app to reset and reconnect it to the home router bypassing
the cisco infrastructure.