TX2 WiFi freezes/pauses/lags every 5-10 seconds

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hi,

We’re using TX2 in our legged robot. (- YouTube).

We create a secure WiFI AP (using create_ap/hostapd), and our Android tablet app connects to the robot by jumping on that WiFi network and sending it UDP packets.

We also SSH into the TX2 over the WiFi AP. Same thing; periodic pauses.

Every 5 to 10 seconds, the data transfer stops for a few seconds, and then resumes. The SSH terminal freezes (stops echoing characters), and then the characters appear.

Same with controlling the robot with the tablet - it’s smooth, and then after 5 or 10 seconds, the robot stops moving for a few seconds, and then resumes.

The SSH performance is great over ethernet connection to the TX2. The problem occurs only over WiFi.

I’ve tried disabling power_save:

iw dev wlan0 set power_save off

which doesn’t solve the issue. Even running the power_save off command every few seconds doesn’t fix it.

We use two Molex antennas: https://www.digikey.com/product-detail/en/molex/1461530300/WM11935-ND/5449071 It seems like it’s a driver/software issue though.

Any ideas?

Thanks,
Tom

2

WiFi AP is created by:

# Install DHCP server
apt-get install dnsmasq
apt-get install create_ap

# Put TX2 Broadcom WiFi chip into AP mode
echo 2 > /sys/module/bcmdhd/parameters/op_mode
echo options bcmdhd op_mode=2 >> /etc/modprobe.d/bcmdhd.conf

# Disable NetworkManager
echo "unmanaged-devices=interface-name:wlan0;interface-name:ap0;interface-name:eth0" >> /etc/NetworkManager/NetworkManager.conf

# Power save OFF
iw dev wlan0 set power_save off

# Create WiFi AP
create_ap --no-virt -g 192.168.168.105 -m bridge wlan0 eth0 ${SSID} ${PASS}
4

It sounds the signal strength is not good. Do you have antenna connected?

Also, could we just use the easiest way to enable the AP? Just install the jetpack and use the ubuntu desktop to enable the wifi manually first.

5

It doesn’t seem like signal strength to me, as it’s not poor throughput, it’s a very periodic stall for a few seconds, every 10 seconds or so. It doesn’t improve at all when I’m 1 foot away from the robot.

It seems like something is freezing, stalling, or turning off/down power periodically.

I can change the antennas to confirm (involves hour+ operation disassembling robot) to rule this out. If there’s any software diagnostics I can run, that would be best to try first.

I also don’t have HDMI/keyboard/mouse plugged into the TX2 for desktop use - everything is done via SSH. (It’s not a desktop computer - it’s a robot brain).

6

You may also try a Wifi analyzer and look for other devices using same band.
I’ve also faced a similar case of periodic deconnections, and it turned out that some temperature sensors were using same band for radio (not sure, but I think it was conflicting with wifi channel 9). Just changing the channel to another one far from this one solved it.

7

Thanks, I’ll try changing the band that the WiFi AP uses.

8

Using channel 6… didn’t help. It’s also hard to tell because the results vary a lot each ping test of 60 pings:

Channel 6:

53 packets transmitted, 52 packets received, 1.9% packet loss   <-- one packet lost
round-trip min/avg/max/stddev = 14.226/169.273/404.630/91.155 ms

60 packets transmitted, 46 packets received, 23.3% packet loss
round-trip min/avg/max/stddev = 1.385/1276.399/6951.918/2103.698 ms

60 packets transmitted, 55 packets received, 8.3% packet loss
round-trip min/avg/max/stddev = 11.983/309.970/5241.834/872.696 ms

Channel 1:

61 packets transmitted, 56 packets received, 8.2% packet loss. <--- packet loss
round-trip min/avg/max/stddev = 5.114/133.124/335.944/83.803 ms

60 packets transmitted, 60 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.339/59.345/287.008/89.958 ms. <-- not too bad, 287ms

60 packets transmitted, 59 packets received, 1.7% packet loss
round-trip min/avg/max/stddev = 15.863/301.149/3727.433/597.637 ms  <-- bad, 3.7 seconds

60 packets transmitted, 52 packets received, 13.3% packet loss <<-- packet loss
round-trip min/avg/max/stddev = 8.228/485.934/5262.748/1007.623 ms

60 packets transmitted, 57 packets received, 5.0% packet loss  <<-- packet loss
round-trip min/avg/max/stddev = 1.478/132.831/269.075/70.714 ms

60 packets transmitted, 60 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.688/115.835/340.875/101.009 ms <<-- not too bad, 340ms

Channel 11:

And this is what I was talking about with periodic pauses:

ping 192.168.168.105 -c 60
PING 192.168.168.105 (192.168.168.105): 56 data bytes
64 bytes from 192.168.168.105: icmp_seq=0 ttl=64 time=203.224 ms
64 bytes from 192.168.168.105: icmp_seq=1 ttl=64 time=188.624 ms
64 bytes from 192.168.168.105: icmp_seq=2 ttl=64 time=299.016 ms
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
64 bytes from 192.168.168.105: icmp_seq=3 ttl=64 time=5156.376 ms
64 bytes from 192.168.168.105: icmp_seq=4 ttl=64 time=4152.653 ms
64 bytes from 192.168.168.105: icmp_seq=5 ttl=64 time=3151.438 ms
64 bytes from 192.168.168.105: icmp_seq=8 ttl=64 time=147.782 ms
64 bytes from 192.168.168.105: icmp_seq=9 ttl=64 time=165.256 ms
64 bytes from 192.168.168.105: icmp_seq=10 ttl=64 time=99.426 ms
64 bytes from 192.168.168.105: icmp_seq=11 ttl=64 time=764.729 ms
64 bytes from 192.168.168.105: icmp_seq=12 ttl=64 time=310.219 ms
64 bytes from 192.168.168.105: icmp_seq=13 ttl=64 time=453.765 ms
64 bytes from 192.168.168.105: icmp_seq=14 ttl=64 time=277.642 ms
64 bytes from 192.168.168.105: icmp_seq=15 ttl=64 time=299.491 ms
64 bytes from 192.168.168.105: icmp_seq=16 ttl=64 time=45.484 ms
64 bytes from 192.168.168.105: icmp_seq=17 ttl=64 time=247.752 ms
64 bytes from 192.168.168.105: icmp_seq=18 ttl=64 time=246.159 ms
64 bytes from 192.168.168.105: icmp_seq=19 ttl=64 time=93.926 ms
64 bytes from 192.168.168.105: icmp_seq=20 ttl=64 time=100.403 ms
64 bytes from 192.168.168.105: icmp_seq=21 ttl=64 time=112.373 ms
64 bytes from 192.168.168.105: icmp_seq=22 ttl=64 time=479.611 ms
64 bytes from 192.168.168.105: icmp_seq=23 ttl=64 time=175.159 ms
64 bytes from 192.168.168.105: icmp_seq=24 ttl=64 time=30.025 ms
64 bytes from 192.168.168.105: icmp_seq=25 ttl=64 time=272.225 ms
64 bytes from 192.168.168.105: icmp_seq=26 ttl=64 time=293.397 ms
64 bytes from 192.168.168.105: icmp_seq=27 ttl=64 time=369.767 ms
64 bytes from 192.168.168.105: icmp_seq=28 ttl=64 time=10.374 ms
64 bytes from 192.168.168.105: icmp_seq=29 ttl=64 time=184.023 ms
64 bytes from 192.168.168.105: icmp_seq=30 ttl=64 time=310.912 ms
64 bytes from 192.168.168.105: icmp_seq=31 ttl=64 time=239.077 ms
64 bytes from 192.168.168.105: icmp_seq=32 ttl=64 time=422.871 ms
Request timeout for icmp_seq 36
Request timeout for icmp_seq 37
Request timeout for icmp_seq 38
64 bytes from 192.168.168.105: icmp_seq=33 ttl=64 time=6417.177 ms
64 bytes from 192.168.168.105: icmp_seq=34 ttl=64 time=5412.687 ms
64 bytes from 192.168.168.105: icmp_seq=35 ttl=64 time=4411.614 ms
64 bytes from 192.168.168.105: icmp_seq=39 ttl=64 time=401.843 ms
64 bytes from 192.168.168.105: icmp_seq=40 ttl=64 time=103.805 ms
64 bytes from 192.168.168.105: icmp_seq=41 ttl=64 time=260.156 ms
64 bytes from 192.168.168.105: icmp_seq=42 ttl=64 time=247.093 ms
64 bytes from 192.168.168.105: icmp_seq=43 ttl=64 time=14.979 ms
64 bytes from 192.168.168.105: icmp_seq=44 ttl=64 time=15.465 ms
64 bytes from 192.168.168.105: icmp_seq=45 ttl=64 time=214.493 ms
Request timeout for icmp_seq 49
Request timeout for icmp_seq 50
Request timeout for icmp_seq 51
64 bytes from 192.168.168.105: icmp_seq=46 ttl=64 time=6279.045 ms
64 bytes from 192.168.168.105: icmp_seq=47 ttl=64 time=5276.228 ms
64 bytes from 192.168.168.105: icmp_seq=48 ttl=64 time=4275.952 ms
64 bytes from 192.168.168.105: icmp_seq=52 ttl=64 time=259.298 ms
64 bytes from 192.168.168.105: icmp_seq=53 ttl=64 time=10.651 ms
64 bytes from 192.168.168.105: icmp_seq=54 ttl=64 time=97.770 ms
64 bytes from 192.168.168.105: icmp_seq=55 ttl=64 time=266.215 ms
64 bytes from 192.168.168.105: icmp_seq=56 ttl=64 time=44.076 ms
64 bytes from 192.168.168.105: icmp_seq=57 ttl=64 time=78.168 ms
64 bytes from 192.168.168.105: icmp_seq=58 ttl=64 time=198.132 ms
64 bytes from 192.168.168.105: icmp_seq=59 ttl=64 time=71.645 ms

--- 192.168.168.105 ping statistics ---
60 packets transmitted, 52 packets received, 13.3% packet loss
round-trip min/avg/max/stddev = 10.374/1031.917/6417.177/1843.846 ms

Ethernet hard-wire is PRETTY GOOD:

60 packets transmitted, 60 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.421/0.635/1.406/0.215 ms  <--1.4 millisecond slowest packet
9

Does the TX2 support 5Ghz WiFi? It says it does in the TX2 Wireless Compliance Guide:

Table 6. Jetson TX2 World Wide Safe Channel Map

Channel Number Frequency (MHz) n40/ac40
38 5190 A
46 5230 A
54 5270 DFS - P
62 5310 DFS - P
Channel Number Frequency (MHz) ac80
42 5210 A
58 5290 DFS - P
Legend:

A = Active
P = Passive
DFS = Dynamic frequency selection|

Channel Number Frequency (MHz) 11b/g/n20
1 2412 A
2 2417 A
3 2422 A
4 2427 A
5 2432 A
6 2437 A
7 2442 A
8 2447 A
9 2452 A
10 2457 A
11 2462 A
12 2467 A
13 2472 A
Channel Number Frequency (MHz) 11a/n20/ac20
36 5180 A
40 5200 A
44 5220 A
48 5240 A
52 5260 DFS - P
56 5280 DFS - P
60 5300 DFS - P
64 5320 DFS - P
Channel Number Frequency (MHz) n40/ac40
38 5190 A
46 5230 A
54 5270 DFS - P
62 5310 DFS - P
Channel Number Frequency (MHz) ac80
42 5210 A
58 5290 DFS - P

It looks like the Broadcom WiFi chip it uses does, but the TX2 doesn’t seem to support it:

iwlist wlan0 channel
wlan0     14 channels in total; available frequencies :
          Channel 01 : 2.412 GHz
          Channel 02 : 2.417 GHz
          Channel 03 : 2.422 GHz
          Channel 04 : 2.427 GHz
          Channel 05 : 2.432 GHz
          Channel 06 : 2.437 GHz
          Channel 07 : 2.442 GHz
          Channel 08 : 2.447 GHz
          Channel 09 : 2.452 GHz
          Channel 10 : 2.457 GHz
          Channel 11 : 2.462 GHz
          Channel 12 : 2.467 GHz
          Channel 13 : 2.472 GHz
          Channel 14 : 2.484 GHz
10

I’m running JetPack 4.3:

cat /etc/nv_tegra_release
# R32 (release), REVISION: 3.1, GCID: 18186506, BOARD: t186ref, EABI: aarch64, DATE: Tue Dec 10 07:03:07 UTC 2019

[L4T r32.3.1 == Jetpack 4.3]

I see people have had trouble with WiFi dropping out in previous JetPacks:

Is there a patch available for the bcmdhd driver that will allow 5Ghz and/or solve long data freezes?

If the TX2 doesn’t support 5Ghz WiFi, which USB WiFi dongle works with built-in drivers on TX2 (Linux kernel 4.9-tegra)? (This has some info for old TK1: Jetson/Network Adapters - eLinux.org)

I need one with an external SMA-port antenna, to move away from metal base of robot.
(Quasar Carrier: 2x USB 3.0)

I’ll get this one based on the RTL8812 (AU?) being listed in that TK1 page:

Is there a command to enable 5Ghz mode on the TX2 wlan0?

sudo create_ap -c 36 --no-virt -g 192.168.168.105 -m bridge wlan0 eth0 test testtest
Channel number is greater than 14, assuming 5GHz frequency band
Config dir: /tmp/create_ap.wlan0.conf.KiJsh7UV
PID: 21693
command failed: Input/output error (-5)

ERROR: Your adapter can not transmit to channel 36, frequency band 5GHz.
11

Hi,

I would say please don’t panic. All the issues you found on jetpack3.3(rel-28) should already be resolved on rel-32.

And it is also no need to immediately try other wifi modules. Those info on tk1 is also not sure working on TX2.

As I pointed out in previous comment, just re-flash your board and use the GUI tool to check the 2.4 and 5 channel stability. We are no longer using hostapd for TX2 wifi. So I cannot provide the exact steps to enable it. Just please use the GUI tool which uses the networkmanager and see if you could hit this issue.

12

Thanks for the reply Wayne. Good to hear the TX2 supports 5.2Ghz WiFi.

I have successfully created a 5Ghz WiFi AP using NetworkManager:

     nmcli connection add type wifi ifname wlan0 con-name $SSID autoconnect no ssid $SSID mode ap
     nmcli connection modify $SSID connection.autoconnect yes
     nmcli connection modify $SSID 802-11-wireless.mode ap
     nmcli connection modify $SSID 802-11-wireless.band a 802-11-wireless.channel 36
     nmcli connection modify $SSID 802-11-wireless.powersave disable
     nmcli connection modify $SSID ipv4.method auto
     nmcli connection modify $SSID ipv4.address 192.168.168.105/24
     nmcli connection modify $SSID ipv4.gateway 192.168.168.105
     nmcli connection modify $SSID wifi-sec.key-mgmt wpa-psk
     nmcli connection modify $SSID wifi-sec.psk $PASS

It’s not sending out IP addresses though. Do you know how to enable DHCP server IP address allocation?
(I have netmasq installed). I’ll try to find out how NetworkManager decides which DHCP server to use - its internal one or another. I’ve set ipv4.method to “auto” which I believe tells it to use DHCP.

Getting:

Connection 'Spirit40-003' (e9dc4fe9-305e-42c0-8cc2-26fd77aa8b07) successfully added.
Error: Connection activation failed: IP configuration could not be reserved (no available address, timeout, etc.)


cat /etc/NetworkManager/NetworkManager.conf 
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

[device]
wifi.scan-rand-mac-address=no

[keyfile]

Update: When I change ipv4.method auto to shared, I dishes out IP addresses and my computer gets one when connecting to that WiFi. But the TX2 IP address 192.168.168.105 isn’t reachable by connected clients (i.e. my computer), so we’re not there yet…

13

GREAT SUCCESS!

Changing ipv4.method to shared did the trick, and removing the gateway line makes the 192.168.168.105 TX2 device reachable. And I found that you do need to put the TX broadcom driver into AP mode manually by adding to the config, otherwise the AP won’t actually be broadcast (despite NetworkManager saying that it is active).

Putting this here for future reference for anyone looking to do the (seemingly not) simple task of “creating an AP on TX2”:

     # Put TX2 Broadcom WiFi chip into AP mode
     echo 2 > /sys/module/bcmdhd/parameters/op_mode
     echo options bcmdhd op_mode=2 >> /etc/modprobe.d/bcmdhd.conf

     # Create WiFi Access Point
     SSID=networkname
     PASS=password
     nmcli connection add type wifi ifname wlan0 con-name $SSID autoconnect no ssid $SSID mode ap
     nmcli connection modify $SSID connection.autoconnect yes
     nmcli connection modify $SSID 802-11-wireless.mode ap
     nmcli connection modify $SSID 802-11-wireless.band a 802-11-wireless.channel 40
     nmcli connection modify $SSID 802-11-wireless.powersave disable
     nmcli connection modify $SSID ipv4.method shared
     nmcli connection modify $SSID ipv4.address 192.168.168.105/24
     nmcli connection modify $SSID ipv4.gateway 192.168.168.105
     nmcli connection modify $SSID wifi-sec.key-mgmt wpa-psk
     nmcli connection modify $SSID wifi-sec.psk $PASS

     nmcli connection up $SSID

And ping on 5200Mhz channel 40 is looking great:

ping 192.168.168.105 -c 60
PING 192.168.168.105 (192.168.168.105): 56 data bytes
64 bytes from 192.168.168.105: icmp_seq=0 ttl=64 time=2.508 ms
64 bytes from 192.168.168.105: icmp_seq=1 ttl=64 time=10.872 ms
64 bytes from 192.168.168.105: icmp_seq=2 ttl=64 time=3.469 ms
64 bytes from 192.168.168.105: icmp_seq=3 ttl=64 time=11.032 ms
64 bytes from 192.168.168.105: icmp_seq=4 ttl=64 time=5.989 ms
64 bytes from 192.168.168.105: icmp_seq=5 ttl=64 time=9.579 ms
64 bytes from 192.168.168.105: icmp_seq=6 ttl=64 time=10.892 ms
64 bytes from 192.168.168.105: icmp_seq=7 ttl=64 time=2.369 ms
64 bytes from 192.168.168.105: icmp_seq=8 ttl=64 time=2.848 ms
64 bytes from 192.168.168.105: icmp_seq=9 ttl=64 time=6.102 ms
64 bytes from 192.168.168.105: icmp_seq=10 ttl=64 time=2.462 ms
64 bytes from 192.168.168.105: icmp_seq=11 ttl=64 time=6.314 ms
64 bytes from 192.168.168.105: icmp_seq=12 ttl=64 time=10.434 ms
64 bytes from 192.168.168.105: icmp_seq=13 ttl=64 time=2.466 ms
64 bytes from 192.168.168.105: icmp_seq=14 ttl=64 time=5.162 ms
64 bytes from 192.168.168.105: icmp_seq=15 ttl=64 time=3.533 ms
64 bytes from 192.168.168.105: icmp_seq=16 ttl=64 time=6.678 ms
64 bytes from 192.168.168.105: icmp_seq=17 ttl=64 time=9.785 ms
64 bytes from 192.168.168.105: icmp_seq=18 ttl=64 time=8.578 ms
64 bytes from 192.168.168.105: icmp_seq=19 ttl=64 time=3.477 ms
64 bytes from 192.168.168.105: icmp_seq=20 ttl=64 time=2.568 ms
64 bytes from 192.168.168.105: icmp_seq=21 ttl=64 time=13.563 ms
64 bytes from 192.168.168.105: icmp_seq=22 ttl=64 time=10.208 ms
64 bytes from 192.168.168.105: icmp_seq=23 ttl=64 time=12.290 ms
64 bytes from 192.168.168.105: icmp_seq=24 ttl=64 time=5.452 ms
64 bytes from 192.168.168.105: icmp_seq=25 ttl=64 time=10.061 ms
64 bytes from 192.168.168.105: icmp_seq=26 ttl=64 time=9.332 ms
64 bytes from 192.168.168.105: icmp_seq=27 ttl=64 time=10.744 ms
64 bytes from 192.168.168.105: icmp_seq=28 ttl=64 time=9.150 ms
64 bytes from 192.168.168.105: icmp_seq=29 ttl=64 time=8.448 ms
64 bytes from 192.168.168.105: icmp_seq=30 ttl=64 time=6.806 ms
64 bytes from 192.168.168.105: icmp_seq=31 ttl=64 time=3.666 ms
64 bytes from 192.168.168.105: icmp_seq=32 ttl=64 time=4.283 ms
64 bytes from 192.168.168.105: icmp_seq=33 ttl=64 time=5.096 ms
64 bytes from 192.168.168.105: icmp_seq=34 ttl=64 time=2.937 ms
64 bytes from 192.168.168.105: icmp_seq=35 ttl=64 time=9.385 ms
64 bytes from 192.168.168.105: icmp_seq=36 ttl=64 time=11.335 ms
64 bytes from 192.168.168.105: icmp_seq=37 ttl=64 time=10.626 ms
64 bytes from 192.168.168.105: icmp_seq=38 ttl=64 time=9.489 ms
64 bytes from 192.168.168.105: icmp_seq=39 ttl=64 time=11.073 ms
64 bytes from 192.168.168.105: icmp_seq=40 ttl=64 time=9.608 ms
64 bytes from 192.168.168.105: icmp_seq=41 ttl=64 time=9.991 ms
64 bytes from 192.168.168.105: icmp_seq=42 ttl=64 time=2.114 ms
64 bytes from 192.168.168.105: icmp_seq=43 ttl=64 time=3.041 ms
64 bytes from 192.168.168.105: icmp_seq=44 ttl=64 time=14.063 ms
64 bytes from 192.168.168.105: icmp_seq=45 ttl=64 time=10.898 ms
64 bytes from 192.168.168.105: icmp_seq=46 ttl=64 time=3.770 ms
64 bytes from 192.168.168.105: icmp_seq=47 ttl=64 time=11.978 ms
64 bytes from 192.168.168.105: icmp_seq=48 ttl=64 time=10.348 ms
64 bytes from 192.168.168.105: icmp_seq=49 ttl=64 time=9.650 ms
64 bytes from 192.168.168.105: icmp_seq=50 ttl=64 time=8.859 ms
64 bytes from 192.168.168.105: icmp_seq=51 ttl=64 time=14.637 ms
64 bytes from 192.168.168.105: icmp_seq=52 ttl=64 time=5.332 ms
64 bytes from 192.168.168.105: icmp_seq=53 ttl=64 time=8.735 ms
64 bytes from 192.168.168.105: icmp_seq=54 ttl=64 time=9.586 ms
64 bytes from 192.168.168.105: icmp_seq=55 ttl=64 time=7.248 ms
64 bytes from 192.168.168.105: icmp_seq=56 ttl=64 time=9.311 ms
64 bytes from 192.168.168.105: icmp_seq=57 ttl=64 time=6.479 ms
64 bytes from 192.168.168.105: icmp_seq=58 ttl=64 time=9.706 ms
64 bytes from 192.168.168.105: icmp_seq=59 ttl=64 time=7.900 ms

--- 192.168.168.105 ping statistics ---
60 packets transmitted, 60 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.114/7.739/14.637/3.379 ms
14

Of course the TX2 is inaccessible (host 192.168.168.105 is not reachable from my computer) when the eth0 ethernet interface is up, and that needs to be up for the robot to operate. It’s fine when I do ifdown eth0, then I can reach it and SSH in.

I configured the eth0 interface to have a static 192.168.168.105 IP address, and also the WiFi AP interface to have the same 192.168.168.105 IP address, which sounds problematic, so I changed the WiFi interface to have the same subnet but different address, 192.168.168.101. That didn’t help.

I tried creating a bridge between the two networks, but that didn’t work either.

If I remove the route from the routing table it also starts working, but of course then the ethernet packets getting sent out to the robot don’t go out the ethernet port…

One day, I’ll have a working TX2…

16

Got it. Now the TX2 on the robot works; it hosts a WiFi AP, and I can connect to it and it can send traffic out its eth0 port to the robot.

And the traffic freezing/pausing/dropped packets is gone, the robot continues to respond for 60+ seconds tested.

Turns out, the bridge that create_ap sets up works. The routing table just has 192.168.168.0 traffic going to the bridge, and nothing else. Neither eth0 nor wlan0 have IP addresses or appear in the routing table.

So I’ll forget using NetworkManager for right now, I’ll use create_ap. I had to modify create_ap to ignore detecting support for 5Ghz on TX2 - it refuses to create it otherwise.

I will try re-creating the bridge that create_ap creates using NetworkManager, so we can use that instead, but won’t spend too much more time on it and just go with create_ap if it doesn’t work.

WOOT. Plus I learned a bunch about bridges, routing, and the ip tools.