Wall Connector network connections to AWS servers

[Ostrichsak]

Why isn't it? I would think wall connectors is part of "& charging infrastructure". It certainly shouldn't go under any of the specific car models, so this does seem like the correct category for wall connector discussions. I don't see anywhere else it would fit better.

I'm not the OP but I think they were referring to me specifically since my issue wasn't related to "Supercharging or Charging Infrastructure" which it is not. This issue is since it's the Gen 3 HPWC specifically and comms would be part of that solution.

 

[ATechGuy]

Why isn't it? I would think wall connectors is part of "& charging infrastructure". It certainly shouldn't go under any of the specific car models, so this does seem like the correct category for wall connector discussions. I don't see anywhere else it would fit better.

Rocky,

The wall connectors ARE relevant, but the car's WiFi isn't relevant to infrastructure...

 

[ATechGuy]

Latest firmware across all of my UniFi gear and I did pull back the transmit power on the AP side upon installation years back. I appreciate the suggestion to try in other subforums. Like I said, I've all but given up on my issue at this point (it seems Tesla has too... lol) Especially since I know that a new(er) car may likely solve this issue. We'll likely be replacing the 2017 Model S P100D w/a Plaid sooner than later once I find the right deal so this issue has become far less pressing for me personally.

I was more following along with your situation just in case whatever you found out with the outbound/inbound comms from the HPWC came into play w/my situation as well. Doubtful but if I learn something along the way a bonus. Again, I wasn't trying to derail the thread so much as let you know that others were following your journey even if we weren't actively posting.

If you haven't already, I'd suggest posting over in the Unifi user forum too. There's quite a few things similar to this (non-Tesla mostly but traffic-related) being discussed as well as outstanding issues on the UniFi side of things. Beyond that, I'm afraid I'm not of much help other than to offer some encouragement on your troubleshooting.

BTW, my home s/u is also fully UniFi managed as well. Here's an unsolicited picture of my rack as it currently sits (until I get a bug to change something again):

View attachment 1022211

I really need to expand to a 48pt PoE switch but can't bring myself to shell out the 2x price tag for the new one with the purdier lights.

Nice rack!

 

[ATechGuy]

This is my last reply for the day. Anyone with an open ticket with Ubiquiti on this may want to see this dump. This time, I used each of the three IPs that are found in the CNAME to make sure I could capture it all.

16:03:21.720392 IP 70.16.74.83.65059 > 54.148.15.24.443: Flags [Start], seq 2769957917, win 14000, options [mss 1400], length 0
16:03:21.811445 IP 54.148.15.24.443 > 70.16.74.83.65059: Flags [Start.], seq 1229533962, ack 2769957918, win 62377, options [mss 1460], length 0
16:03:21.815302 IP 70.16.74.83.65059 > 54.148.15.24.443: Flags [.], ack 1, win 14000, length 0
16:03:21.817803 IP 70.16.74.83.65059 > 54.148.15.24.443: Flags [P.], seq 1:300, ack 1, win 14000, length 299
16:03:21.908175 IP 54.148.15.24.443 > 70.16.74.83.65059: Flags [.], ack 300, win 61978, length 0
16:03:21.909361 IP 54.148.15.24.443 > 70.16.74.83.65059: Flags [P.], seq 1:2801, ack 300, win 61978, length 2800
16:03:21.910392 IP 54.148.15.24.443 > 70.16.74.83.65059: Flags [P.], seq 2801:3446, ack 300, win 61978, length 645
16:03:21.916641 IP 70.16.74.83.65059 > 54.148.15.24.443: Flags [.], ack 2801, win 11200, length 0
16:03:21.933468 IP 70.16.74.83.65059 > 54.148.15.24.443: Flags [.], ack 3446, win 12578, length 0
16:03:24.307820 IP 70.16.74.83.65059 > 54.148.15.24.443: Flags [P.], seq 300:1233, ack 3446, win 14000, length 933
16:04:15.391818 IP 54.148.15.24.443 > 70.16.74.83.65059: Flags [.], ack 8988, win 56000, length 0
16:04:16.407725 IP 70.16.74.83.65059 > 54.148.15.24.443: Flags [P.], seq 8953:8988, ack 18139, win 13969, length 35
16:04:16.498064 IP 54.148.15.24.443 > 70.16.74.83.65059: Flags [.], ack 8988, win 56000, length 0
16:05:05.251058 IP 54.148.15.24.443 > 70.16.74.83.65059: Flags [P.], seq 18139:18170, ack 8988, win 56000, length 31
16:05:05.707843 IP 54.148.15.24.443 > 70.16.74.83.65059: Flags [P.], seq 18139:18170, ack 8988, win 56000, length 31
16:05:06.635979 IP 54.148.15.24.443 > 70.16.74.83.65059: Flags [P.], seq 18139:18170, ack 8988, win 56000, length 31
16:05:08.497099 IP 54.148.15.24.443 > 70.16.74.83.65059: Flags [P.], seq 18139:18170, ack 8988, win 56000, length 31
16:05:12.335760 IP 54.148.15.24.443 > 70.16.74.83.65059: Flags [P.], seq 18139:18170, ack 8988, win 56000, length 31
16:05:19.759938 IP 54.148.15.24.443 > 70.16.74.83.65059: Flags [P.], seq 18139:18170, ack 8988, win 56000, length 31
16:05:34.603838 IP 54.148.15.24.443 > 70.16.74.83.65059: Flags [P.], seq 18139:18170, ack 8988, win 56000, length 31
16:06:05.068000 IP 54.148.15.24.443 > 70.16.74.83.65059: Flags [P.], seq 18139:18170, ack 8988, win 56000, length 31
16:06:15.349415 IP 54.148.15.24.443 > 70.16.74.83.65059: Flags [FP.], seq 18170:18263, ack 8988, win 56000, length 93

The bolded lines are the ones Ubiquiti needs to explain. Maybe they will blame this on the TWC, but the USG and every other firewall I have kicking around doesn't seem to show this sequence. For the tcpdump-challenged, note that the first bolded line is a simple ACK packet, acknowledging packet # 8988. This could be a tcpdump buffering situation, (usually won't matter with TCP anyway) as the bolded line is acknowledging a packet it has yet to receive. The following line is the packet (from the TWC) that was just acknowledged. On that same (second bolded line) the TWC is also acknowledging the fourth bolded line packet. The actual FIRST packet from AWS for sequence 18139:18170 appears to have been lost.

The crazy thing is the TWC acks the 18139 sequence, but never sends the ack for 18170. My best guess on this is because the TWC believes it either hasn't received the 18170 packet, or that it feels it has already acknowledged it.

Those four bolded lines ARE the USG-Lite problem.

As for any other tests, yes, I did try scaling back MSS but it doesn't seem to have any effect on the outgoing packets AT ALL. I have not tried a DMZ. Not sure how to on Unifi and with only one LAN port, I can't imagine how it might get configured other than with VLANs. I also tried creating a pre-emptive firewall rule for 35.161.98.75, but I should probably try it again and build an IP group of those three IPs and apply the same "PASS THE PACKET, Damnit!" rule. Maybe I'll try that after I run some errands.

Then, the AWS server acknowledged the same packet, again. However, at that point, the UXG is massively confused and no longer will forward the packet with sequence 18139:18170

 

[Ostrichsak]

Nice rack!

Thanks. In most other settings that would be considered offensive.

 

[brkaus]

@ATechGuy post to the community.ui.com forum and tag UI-Glenn

 

[brkaus]

Not sure who is who on the two forums, but this thread has a suggestion from UI

https://community.ui.com/questions/Tesla-Wall-Charger-Issues-with-UGX-Lite/4bc1ad06-f327-4713-b3ac-00f51e4b0eb1

 

[ATechGuy]

Oh, @brkaus, I've been all through the UI forums looking for this, but...

NAT IS SERIOUSLY BROKEN on the UXG-Lite.

Turns out Conntrack is at fault and the UXG-Lite sets the parameter:

net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 30

It's a typo. The USG has the value of 300.

If you want to verify the fix, first log into the UXG-Lite (or go for debug console from the controller) and enter:

sysctl -w net.netfilter.nf_conntrack_tcp_timeout_unacknowledged=300

Then bounce the TWC (I just tell the Unifi controller to reconnect the TWC) and voila. A working TWC & UXG-Lite.

If you want the permanent fix, you'll need to edit the \etc\sysctl.d\99_uex_custom.conf file and right near the top you'll find the line with the value being set to 30. Just add a 0 to make it 300 and it will be permanent over reboots.

Turns out a LOT of other NAT issues are being found and supposedly "Unifi is working on it", but honestly, I have my doubts. It's been over two months since the 3.1.16 firmware and even the EA didn't have the fix.

It's not my fix, but it was found in: https://community.ui.com/questions/...-lobbies/97da5c0b-85d1-47f4-a61b-89a02520b84f

I just edited the typos and file names to help everyone here.

And FWIW, some UI users report enabling Smart Queues solves the problem as well, but clearly, you don't want to use them if your ISP bandwidth is greater than the suggested range. Smart Queues forces the ordering and handling of unacknowledged packets so that's why it's rumored to fix this situation.

I hope you had a good day,
-Ken

 

[brkaus]

Thanks @ATechGuy

UI did suggest that same change on the thread I linked. Hopefully they will get their act together with the new device.

 

[dirty_park]

That link on the forum with the command was suggested from a ticket and post I opened with them. The recommended fix of increasing the timeout does seem to be working by running: sysctl -w net.netfilter.nf_conntrack_tcp_timeout_unacknowledged=300

 

[ATechGuy]

That link on the forum with the command was suggested from a ticket and post I opened with them. The recommended fix of increasing the timeout does seem to be working by running: sysctl -w net.netfilter.nf_conntrack_tcp_timeout_unacknowledged=300

Sadly, this morning, my app is once again showing offline. What about you, @dirty_park?

 

[ATechGuy]

The timeout change did not solve the issue. It kept it online for longer than the 5-10 minutes but had disconnected overnight. I CAN verify that enabling Smart Queues HAS solved the issue, but it's knocking down my internet speeds significantly.

 

[ATechGuy]

Sheesh. Even Smart Queues hasn't solved the problem, but now I no longer see the "Offline" display but "Check Internet Connection" instead. This has only happened since I enabled Smart Queues. And, once again, I can verify that not only is the Wall Connector Online and connected (well) to my wireless network, it also believes it can access the internet.

One step forward, one step back.

 

[ATechGuy]

Smart queues does seem to have solved the issue with respect to the TWC being offline. I had earlier been experimenting with the MSS value and either the AWS server or the TWC did not appreciate shorter values. WIth them set back to 1460, the Smart Queues setting has kept the TWC online for over two days now.

 

[dirty_park]

I have mine set to the default of 30 not 300 like the fix and it’s been online for 4 days…. Not sure what’s going on, it seems to random.

 

[CSFTN]

Count me in as well, same problem, Unifi Dream Machine SE, current OS "Network 8.0.28". I'm not skilled enough to do any dumps, so I doubt I can contribute much to this conversation. But if someone can find a fix, I would be thankful.

Meanwhile I was also having problems with my Trane touchscreen T stat, and to a lesser extent my Carrier touch T stat. I think I fixed them by allowing http connections in the firewall for these specific devices ...

 

[brkaus]

@CSFTN Do you have rules that block all traffic setup? Or the basic default rules.

 

[ATechGuy]

Oh, @brkaus, I've been all through the UI forums looking for this, but...

NAT IS SERIOUSLY BROKEN on the UXG-Lite.

Turns out Conntrack is at fault and the UXG-Lite sets the parameter:

net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 30

It's a typo. The USG has the value of 300.

If you want to verify the fix, first log into the UXG-Lite (or go for debug console from the controller) and enter:

sysctl -w net.netfilter.nf_conntrack_tcp_timeout_unacknowledged=300

Then bounce the TWC (I just tell the Unifi controller to reconnect the TWC) and voila. A working TWC & UXG-Lite.

If you want the permanent fix, you'll need to edit the \etc\sysctl.d\99_uex_custom.conf file and right near the top you'll find the line with the value being set to 30. Just add a 0 to make it 300 and it will be permanent over reboots.

Turns out a LOT of other NAT issues are being found and supposedly "Unifi is working on it", but honestly, I have my doubts. It's been over two months since the 3.1.16 firmware and even the EA didn't have the fix.

It's not my fix, but it was found in: https://community.ui.com/questions/...-lobbies/97da5c0b-85d1-47f4-a61b-89a02520b84f

I just edited the typos and file names to help everyone here.

And FWIW, some UI users report enabling Smart Queues solves the problem as well, but clearly, you don't want to use them if your ISP bandwidth is greater than the suggested range. Smart Queues forces the ordering and handling of unacknowledged packets so that's why it's rumored to fix this situation.

I hope you had a good day,
-Ken

One thing I've found with the UXG-Lite is that the uex_custom.conf file is overwritten by the 99_uxglite_custom.conf file. So, really, that's the file you want to edit instead. That said, even with the changes set to conntrack, I'm afraid I'm not seeing an improvement. Anyone who is, please let everyone know!

 

[CSFTN]

@CSFTN Do you have rules that block all traffic setup? Or the basic default rules.

Basic; I used Unifi's default settings for an IoT network

 

[milsonian]

Anyone who is, please let everyone know!

The config update to 300 instead of 30 for nf_conntrack_tcp_timeout_unacknowledged=300 worked for me, for both my wall connectors - and a few others on the threads: https://community.ui.com/questions/...s/7b5835a1-cab4-4fc3-8bc6-02fb368a0b6c?page=3
They say the persistent fix will be in 4.x UXG firmware.

I'm not running any additional firewall rules or anything, just that change (though I certainly had tried about EVERYTHING prior to it), and I also had moved an AP basically right next to them in the garage.