Halow Client can't communicate with other devices on the halow ap

[Kenbsherman]

I’ve been trying to get a proof of concept up to test some webrtc streaming from an halow client to another machine connected to the halow access point. My halowlink configuration is “Wi-Fi HaLow devices will get an IP on this device’s local network and use 2.4 GHz Wi-Fi for an uplink”

My halow client is a rasperry pi 5 that build usng these instructions Build Thread: HaLow for Raspberry Pi OS - #7 by akshatd

My halo client does get a connection:

My halow client does get an ip address on the lan:
The other two devices on the lan are a windows laptop and and android phone

I can ping between the windows laptop and android phone, but pings from the windows laptop never reach the halow client.

I do see a morse_spi error in the dmesg log on the halow client / raspberry pi

Here are the specific errors:
[ 8.332027] morse_spi spi0.0: Command 0x0052:0160 error -22
[ 8.332034] morse_spi spi0.0: Command morse_cmd_set_bssid 52:160 failed with rc -22 (0xffffffea)
[ 8.332038] morse_spi spi0.0: morse_cmd_set_bssid: 0c:bf:74:00:47:b0 on vif[0] fail (ret:-22)
[ 8.332583] morse_spi spi0.0: Command 0x003e:0170 error -22
[ 8.332586] morse_spi spi0.0: Command morse_cmd_set_max_away_duration 3e:170 failed with rc -22 (0xffffffea)

Would this error be contributing to my issue?

And the rest of the dmesg log for the morse module.

[ 4.883124] dot11ah: loading out-of-tree module taints kernel.
[ 4.883878] Morse Micro Dot11ah driver registration. Version 0-rel_1_17_9_2026_Apr_20
[ 4.883883] channelization_scheme = 3 (IEEE802.11-REVmf)
[ 4.937608] Bluetooth: hci0: BCM: chip id 107
[ 4.937824] Bluetooth: hci0: BCM: features 0x2f
[ 4.938860] Bluetooth: hci0: BCM4345C0
[ 4.938862] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0000
[ 4.942227] Bluetooth: hci0: BCM4345C0 ‘brcm/BCM4345C0.raspberrypi,5-model-b.hcd’ Patch
[ 5.230419] morse micro driver registration. Version 0-rel_1_17_9_2026_Apr_20
[ 5.230690] morse_spi spi0.0: morse_of_probe: Reading gpio pins configuration from device tree
[ 5.230739] uaccess char driver major number is 509
[ 5.230821] morse_io: Device node ‘/dev/morse_io’ created successfully
[ 5.245829] morse_spi spi0.0: Loaded firmware from morse/mm6108.bin, size 459124, crc32 0x51d355b9
[ 5.251381] morse_spi spi0.0: Loaded BCF from morse/bcf_fgh100mhaamd.bin, size 1251, crc32 0x941b2a82
[ 5.300016] Adding 2097136k swap on /var/swap. Priority:-2 extents:2 across:2228208k SS
[ 5.410682] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 5.410691] Bluetooth: BNEP filters: protocol multicast
[ 5.410698] Bluetooth: BNEP socket layer initialized
[ 5.653824] Bluetooth: hci0: BCM: features 0x2f
[ 5.655195] Bluetooth: hci0: BCM43455 37.4MHz Raspberry Pi 3±0190
[ 5.655200] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0382
[ 5.655535] Bluetooth: hci0: BCM: Using default device address (43:45:c0:00:1f:ac)
[ 5.672503] Bluetooth: MGMT ver 1.23
[ 5.678812] NET: Registered PF_ALG protocol family
[ 5.868126] macb 1f00100000.ethernet eth0: PHY [1f00100000.ethernet-ffffffff:01] driver [Broadcom BCM54213PE] (irq=POLL)
[ 5.868134] macb 1f00100000.ethernet eth0: configuring for phy/rgmii-id link mode
[ 5.874940] macb 1f00100000.ethernet: gem-ptp-timer ptp clock registered.
[ 5.902651] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[ 5.913264] morse_spi spi0.0: Driver loaded with kernel module parameters
[ 5.913271] morse_spi spi0.0: enable_pre_assoc_ps : N
[ 5.913274] morse_spi spi0.0: slow_clock_mode : 0
[ 5.913276] morse_spi spi0.0: enable_1mhz_probes : Y
[ 5.913278] morse_spi spi0.0: enable_sched_scan : Y
[ 5.913280] morse_spi spi0.0: enable_hw_scan : Y
[ 5.913282] morse_spi spi0.0: enable_pv1 : N
[ 5.913283] morse_spi spi0.0: enable_page_slicing : N
[ 5.913285] morse_spi spi0.0: log_modparams_on_boot : Y
[ 5.913287] morse_spi spi0.0: enable_mcast_rate_control : N
[ 5.913288] morse_spi spi0.0: enable_mcast_whitelist : Y
[ 5.913290] morse_spi spi0.0: ocs_type : 1
[ 5.913292] morse_spi spi0.0: enable_wiphy : N
[ 5.913293] morse_spi spi0.0: enable_auto_mpsw : Y
[ 5.913295] morse_spi spi0.0: duty_cycle_probe_retry_threshold : 2500
[ 5.913297] morse_spi spi0.0: duty_cycle_mode : 0
[ 5.913298] morse_spi spi0.0: enable_auto_duty_cycle : Y
[ 5.913300] morse_spi spi0.0: dhcpc_lease_update_script : /morse/scripts/dhcpc_update.sh
[ 5.913302] morse_spi spi0.0: enable_ibss_probe_filtering : Y
[ 5.913304] morse_spi spi0.0: enable_dhcpc_offload : N
[ 5.913305] morse_spi spi0.0: enable_arp_offload : N
[ 5.913307] morse_spi spi0.0: enable_bcn_change_seq_monitor : N
[ 5.913309] morse_spi spi0.0: enable_cac : N
[ 5.913310] morse_spi spi0.0: max_mc_frames : 10
[ 5.913312] morse_spi spi0.0: tx_max_power_mbm : 2200
[ 5.913314] morse_spi spi0.0: enable_twt : Y
[ 5.913315] morse_spi spi0.0: enable_mac80211_connection_monitor : N
[ 5.913317] morse_spi spi0.0: enable_airtime_fairness : N
[ 5.913319] morse_spi spi0.0: max_aggregation_count : 0
[ 5.913320] morse_spi spi0.0: max_rate_tries : 1
[ 5.913322] morse_spi spi0.0: max_rates : 4
[ 5.913323] morse_spi spi0.0: enable_watchdog_reset : N
[ 5.913325] morse_spi spi0.0: watchdog_interval_secs : 30
[ 5.913327] morse_spi spi0.0: enable_watchdog : Y
[ 5.913328] morse_spi spi0.0: country : US
[ 5.913330] morse_spi spi0.0: enable_cts_to_self : N
[ 5.913331] morse_spi spi0.0: enable_rts_8mhz : N
[ 5.913333] morse_spi spi0.0: enable_trav_pilot : Y
[ 5.913335] morse_spi spi0.0: enable_sgi_rc : Y
[ 5.913336] morse_spi spi0.0: enable_mbssid_ie : N
[ 5.913337] morse_spi spi0.0: virtual_sta_max : 0
[ 5.913339] morse_spi spi0.0: thin_lmac : N
[ 5.913341] morse_spi spi0.0: enable_dynamic_ps_offload : Y
[ 5.913342] morse_spi spi0.0: enable_ps : 2
[ 5.913343] morse_spi spi0.0: enable_subbands : 2
[ 5.913345] morse_spi spi0.0: enable_survey : Y
[ 5.913347] morse_spi spi0.0: mcs10_mode : 0
[ 5.913348] morse_spi spi0.0: mcs_mask : 1023
[ 5.913350] morse_spi spi0.0: no_hwcrypt : N
[ 5.913351] morse_spi spi0.0: enable_ext_xtal_init : N
[ 5.913353] morse_spi spi0.0: enable_otp_check : Y
[ 5.913354] morse_spi spi0.0: bcf : bcf_fgh100mhaamd.bin
[ 5.913356] morse_spi spi0.0: serial : default
[ 5.913357] morse_spi spi0.0: debug_mask : 8
[ 5.913359] morse_spi spi0.0: tx_status_lifetime_ms : 15000
[ 5.913360] morse_spi spi0.0: tx_queued_lifetime_ms : 1000
[ 5.913362] morse_spi spi0.0: max_txq_len : 32
[ 5.913363] morse_spi spi0.0: default_cmd_timeout_ms : 600
[ 5.913365] morse_spi spi0.0: reattach_hw : N
[ 5.913366] morse_spi spi0.0: hw_reload_after_stop : 5
[ 5.913368] morse_spi spi0.0: enable_short_bcn_as_dtim_override : -1
[ 5.913370] morse_spi spi0.0: rsn_beacon_mode : 0
[ 5.913372] morse_spi spi0.0: fw_bin_file :
[ 5.913373] morse_spi spi0.0: sdio_reset_time : 400
[ 5.913375] morse_spi spi0.0: macaddr_suffix : 00:00:00
[ 5.913377] morse_spi spi0.0: macaddr_octet : 255
[ 5.913378] morse_spi spi0.0: max_total_vendor_ie_bytes : 514
[ 5.913380] morse_spi spi0.0: hw_scan_prim_deconstruct : 0
[ 5.913382] morse_spi spi0.0: coredump_include : 1
[ 5.913383] morse_spi spi0.0: coredump_method : 1
[ 5.913385] morse_spi spi0.0: enable_coredump : Y
[ 5.913386] morse_spi spi0.0: enable_hw_leds : Y
[ 5.913388] morse_spi spi0.0: spi_use_edge_irq : N
[ 5.913390] morse_spi spi0.0: spi_inter_block_delay_bytes : 0
[ 5.913391] morse_spi spi0.0: spi_clock_speed : 0
[ 5.913393] morse_spi spi0.0: enable_mm_vendor_ie : Y
[ 5.913394] morse_spi spi0.0: fixed_guard : 0
[ 5.913396] morse_spi spi0.0: fixed_ss : 1
[ 5.913397] morse_spi spi0.0: fixed_bw : 2
[ 5.913399] morse_spi spi0.0: fixed_mcs : 4
[ 5.913400] morse_spi spi0.0: enable_fixed_rate : N
[ 8.332027] morse_spi spi0.0: Command 0x0052:0160 error -22
[ 8.332034] morse_spi spi0.0: Command morse_cmd_set_bssid 52:160 failed with rc -22 (0xffffffea)
[ 8.332038] morse_spi spi0.0: morse_cmd_set_bssid: 0c:bf:74:00:47:b0 on vif[0] fail (ret:-22)
[ 8.332583] morse_spi spi0.0: Command 0x003e:0170 error -22
[ 8.332586] morse_spi spi0.0: Command morse_cmd_set_max_away_duration 3e:170 failed with rc -22 (0xffffffea)
[ 8.333098] wlan1: authenticate with 0c:bf:74:00:47:b0 (local address=3c:22:7f:71:df:13)
[ 8.333101] wlan1: send auth to 0c:bf:74:00:47:b0 (try 1/3)
[ 8.382947] wlan1: authenticate with 0c:bf:74:00:47:b0 (local address=3c:22:7f:71:df:13)
[ 8.382952] wlan1: send auth to 0c:bf:74:00:47:b0 (try 1/3)
[ 8.425752] wlan1: authenticated
[ 8.429202] wlan1: associate with 0c:bf:74:00:47:b0 (try 1/3)
[ 8.438846] wlan1: RX AssocResp from 0c:bf:74:00:47:b0 (capab=0x11 status=0 aid=1)
[ 8.443147] wlan1: associated
[ 12.508591] rp1-cfe 1f00110000.csi: Using a link rate of 900 Mbps

[ajudge]

Hi @Kenbsherman

While unexpected, those errors look unrelated. I think you can ignore them for now, though we should probably investigate them later.

My initial guess at what might be going on here is that there is a firewall on the RPi 5 blocking ICMP traffic. I didn’t think this was enabled by default, but to be sure try running sudo ufw disable on the Pi and then ping from Windows again.

The other thought is that this might be attributed to Wi-Fi powersave making ICMP responses really slow, though in saying that, the default configuration of the HaLowLink AP should cause this to effectively not be an issue. To rule it out anyway, on the RPi run `iw dev wlan1 set power_save off.

If neither of those work, we’re into some network debugging.
What do:
sudo iptables -L INPUT -n
ip route
ip addr

show on the Pi?

[Kenbsherman]

Hi @ajudge ,

The firewall wasn’t on but I disabled it anyway and setting power save off. Both commands didn’t result in a ping being returned.

Here’s the results of ip route and ip addr

kbsherman@pi5:~ $ sudo ufw disable
Firewall stopped and disabled on system startup
kbsherman@pi5:~ $ sudo ufw status
Status: inactive

kbsherman@pi5:~ $ sudo iw dev wlan1 set power_save off

kbsherman@pi5:~ $ sudo iptables -L INPUT -n
Chain INPUT (policy ACCEPT)
target prot opt source destination

ip route
default via 192.168.12.1 dev wlan1 proto dhcp src 192.168.12.218 metric 600
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.21 metric 601

ip addr
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.21 metric 601
192.168.12.0/24 dev wlan1 proto kernel scope link src 192.168.12.218 metric 600

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 88:a2:9e:8b:2d:33 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 88:a2:9e:8b:2d:34 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.21/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0
valid_lft 86213sec preferred_lft 86213sec
inet6 fdbc:2754:a1fe:55e5:e1b4:1015:250d:7bf8/64 scope global dynamic noprefixroute
valid_lft 1795sec preferred_lft 1795sec
inet6 fe80::ff48:2f29:20bd:20a1/64 scope link noprefixroute
valid_lft forever preferred_lft forever
4: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 3c:22:7f:71:df:13 brd ff:ff:ff:ff:ff:ff
inet 192.168.12.218/24 brd 192.168.12.255 scope global dynamic noprefixroute wlan1
valid_lft 43010sec preferred_lft 43010sec
inet6 fe80::bcb:841c:312c:b2e5/64 scope link noprefixroute
valid_lft forever preferred_lft forever

[Kenbsherman]

@ajudge As I mentioned in my first post, what I’m trying to POC is Webrtc for streaming video. My use case for using the “get ip on local network” is for portability in the field where no second router is needed.

I may have come on a pattern.
Along with no ping between the two devices, what I typically see when trying to bring up a video stream through a browser on the halow client is a device not found or a timeout. When I look at the logs on my streaming service on the pi, there are no client connections which would confirm a timeout scenario.

I’ve tried using the ip to access the streaming service and the host name and there doesn’t seem to be any discernable difference in response. Every once in a while if I leave the browser open, after minutes I might get a stream initiated.

This morning when testing I’m getting 19.5 mpbs on the halow link. I’m currently running 8 channels and my video bit rate is 2mb. I plan on reducing the channels to either 2 or 1 in for future.

What’s interesting is if I bring the streaming service up 1st on the pi’s wlan0, which is an ip on my local network I get a streaming response almost immediately. I then can bring up the streaming service on wlan1 which is running on the halow link.

This will get me by for testing outdoors with some range for the near term. Any suggestions for diagnosing and resolving would be greatly apprectiated.

[ajudge]

Thanks for your patience with replies here.
I might need to attempt to reproduce this locally to dig further. Things that might help in the meantime:

• Start a pcap trace on the pi (you might need to install tcpdump and run tcpdump -i wlan1 -w halow.pcap)
• Concurrently, start a trace with wireshark on the windows machine, on the interface you’re expecting to be communicating to your HaLow network with
• Run a ping from Windows to the Pi.

[Kenbsherman]

@ajudge

• tcpdump -i wlan1 -w halow.pcap)

halow.pcap (7.5 MB)

wiindows.pcapng (4.8 MB)

Here are the two wireshark files.

What I found yesterday with streaming from wlan0 first then wlan1 turns out to be an intermittant thing.

[ajudge]

Hate to be a pain, but it looks like the HaLow capture is the Pi’s 2.4 interface. I suggested wlan1 as earlier that was your HaLow interface. Maybe they swapped on a reboot?

If you could grab that tcpdump again but on the Pi’s HaLow interface, and run a ping from Windows that would be helpful.

[Kenbsherman]

@ajudge

• tcpdump -i wlan1 -w halow.pcap)

halow.pcap (1.2 KB)

windows(1).pcapng (452.0 KB)

Here’s another set.

[ajudge]

Thanks.

Can you also share the HaLowLink configuration (there should be a button under Help → Support to export a tarball. This will help me try to reproduce.

It almost looks like the HaLow interface on the AP is somehow isolated from other devices on the LAN. This isn’t a default configuration from our wizards.

[Kenbsherman]

mm_sysdump_2026-08-27T10_46_41.tar.gz (292.7 KB)

Here’s the configuration

[Kenbsherman]

@ajudge I’ve gotten back to working on this and my halow client on wlan0 can’t communicate with a client on the 2.4ghz phy0.

I’ve gone back to the Wi-Fi HaLow devices will get an IP on this device’s local network option as that fits my use case.

I’m trying to stream data from http:// address :8889/stream where address is the halow station ip.

I’ve tried to allowing the lan and wan zones to accept inputs, outputs and forwarding in the firewall zones. And also added port forwarding for 8889 and 8189 that webrtc use, and added traffic rules and I still can’t reach my halow station from a browser that is connected to the 2.4ghz halow ap.

Is there a better way to try to enable this?

[james.haggerty]

Inability to communicate from the halow client and a 2.4GHz on a device in this configuration is expected. The 2.4 is only intended for management on the AP, since it’s assumed to be plugged into a router which has a better 2.4GHz antenna (+ other frequencies). What’s your use case?

If you do need to do this, the simple way (rather than messing with routing or forwarding) is to put the 2.4 AP on the same network. To do this:

• go back to the wizard and save configuration to get rid of any firewall hackery you’ve done (you just want it in the default state for “Wi-Fi HaLow devices will get an IP on this device’s local network”)
• go to the Quick Config page, and change the 2.4 AP from the lan network to the wlan network (there should be no ‘wan’ network in use). Note that you will now only be able to access 192.168.12.1 over the LAN port.

Once you’ve done this, if it’s still not working, please do the system dump as before (or in this case, a screenshot of the Quick Config page and the homepage would help).

[Kenbsherman]

I made the changes and haven’t been able to communicate with the halow station either through a ping or from http://192.168.12.218:8889/stream/

laptop is connected to halowlink2 via lan port and halowlink 2 is wired via ethernet to my home network.

mm_sysdump_2026-09-18T12_20_34.tar.gz (294.0 KB)

there was only a wlan option on the 2.4ghz radio

I did a factory reset and then made the requested changes.

[ajudge]

I haven’t had a chance to attempt to reproduce this yet with a Pi 5 myself.

In the first configuration you dumped a while ago it looks like you’re doing something fairly standard (all devices on the OpenWrt LAN network), just connected via different radios which shouldn’t have a problem - I have devices in my home lab doing this (just not a Pi 5). I’m suspecting an issue with the Raspberry Pi configuration so want to rule that out first.

I notice that you have two interfaces connected to different networks on the Pi as well. Given your other devices are also on those networks, I wonder if everything is getting a bit confused, and the Pi is responding on the other interface.
Easy test is to temporarily disable the 2.4GHz radio on the Pi - you might want to plug a console or monitor in if you have no other access, or just be prepared to reboot the Pi. If that works, then we can look at some sysctl settings on the Pi.

---

Same goes for the second configuration you have dumped with the way you are accessing. The LAN port is connected to the same network as the HaLow interface, and you should be able to attach the 2.4 radio to the LAN network (I’m not seeing a wlan option in your configs) to get to the same point you were at before.

[james.haggerty]

Hi @Kenbsherman ,

From your sysdump and screenshot, you haven’t used the wizard yet. Sorry, this is my mistake → I forgot to mention it clearly before.

1. Select “Wi-Fi HaLow devices will get an IP on your existing router's network.” and Save/apply
2. Go to Quick Config page, and move the 2.4 (phy0-ap0) to the wlan network (there should be no WAN network used by any of your devices)

If that’s not working, please do the screenshot/sysdump again.

I’m still a bit confused about why you want this configuration.

[Kenbsherman]

I’m trying to see how well halow will accomidate streaming video from a quad copter where I will not have a secondary network to communicate with, so getting an ip on the halowlink would make things the simplist.

An alternative is to plug the wan ethernet into an adapter where my android phone can be used as the primary network.

[james.haggerty]

Sorry, I misunderstood what was going on, and got confused between the two network configs.

Please ignore what I wrote, and listen to Arien

[ajudge]

Hi @Kenbsherman

I have setup an RPi 5 in a way that I can do some testing here. Unfortunately it isn’t SPI but I think we can safely assume your issues are not related to the bus interface used.

I’ve otherwise tried to replicate your original configuration as closely as I could.

In my configuration, I have setup my HaLowLink2 in the same way the wizard configures “Wi-Fi HaLow devices will get an IP on this device’s local network.”. My HaLowLink2 is connected to my home network via the wan port.

I’ve then used nmtui to connect my RPi 5 HaLow interface to the HaLowLink2, and the on board Wi-Fi interface to my home network Wi-Fi. This gave me the below ip addr output.

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 4a:3f:8e:22:9b:71 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 4a:3f:8e:22:9b:72 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.226/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0
       valid_lft 259193sec preferred_lft 259193sec
    inet6 fd00::8a2c:f931:5e07:c1b8/64 scope global dynamic noprefixroute
       valid_lft 27sec preferred_lft 27sec
    inet6 fe80::3b91:d4a2:7c85:e02f/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
6: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 91:7d:2a:00:5f:c3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.12.119/24 brd 192.168.12.255 scope global dynamic noprefixroute wlan1
       valid_lft 43177sec preferred_lft 43177sec
    inet6 fe80::a614:88fb:2d3e:9c07/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

I’ve then connected my laptop to the HaLowLink2 2.4 interface, and I also have an ethernet connection from my laptop to my home network.

I can ping my RPi 5 HaLow interface from my Windows laptop

>ping 192.168.12.119

Pinging 192.168.12.119 with 32 bytes of data:
Reply from 192.168.12.119: bytes=32 time=26ms TTL=64
Reply from 192.168.12.119: bytes=32 time=27ms TTL=64
Reply from 192.168.12.119: bytes=32 time=29ms TTL=64
Reply from 192.168.12.119: bytes=32 time=10ms TTL=64

Ping statistics for 192.168.12.119:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 100ms, Maximum = 293ms, Average = 233ms

I was also able to connect to an RTSP stream running an ffmpeg test pattern via the 2.4 + HaLow bridged interface

---

Anyway, all this to say I’m not sure what’s going on your end and perhaps we need to continue simplifying your network again. I know it’s tedious but perhaps follow along with my configuration and see if it falls over at the ping stage again.

There is another discrepency that I haven’t been able to control for - my HaLowLink2 is running newer firmware. You should have an update available for it and I would recommend taking that update, but otherwise I can attempt a downgrade when time allows.

Other than the firmware, my next step would be to get myself a SPI interface again and attempt this configuration again with that.

[Kenbsherman]

We have matching configurations

Wi-Fi HaLow devices will get an IP on this device’s local network.

I also have my laptop connected via 2.4ghz and ethernet.

On the pi side, the only difference I see is our wlan0 and wlan1 are flipped meaning the ip for my halo is wlan1. I wouldn’t think that would matter

After connecting my laptop to the 2.4ghz network, a ping did return successfully , then I tried to stream video from the laptops browser (http://192.168.12.218:8889/stream/) and could not connect. What I’d also done is ping my laptop from the pi, so I tried that again and then pinged the pi from my laptop and success there is connectivity.

I was also able to stream

My stream is pretty laggy and the gui is reporting between 26 and 32 mbs on the 960 radio. That’s a secondary issue and will see if there’s some optimization if I can continually obtain a connection. My res is 1280 x 720 with a 20mb bit rate.

So it does appear the pattern is get the PI to talk first via ping and I can ping from the laptop and stream. This seems to be repeatable after serveral connections over the span of a few hours.

Firmware wise, I’m at 2.11.13, is there a newer version than this?
I also saw quite a few Luci-app * packages that were updateable. Should I update those.

[ajudge]

@Kenbsherman

Firmware wise, I’m at 2.11.13, is there a newer version than this?
I also saw quite a few Luci-app * packages that were updateable. Should I update those.

I wouldn’t update the luci packages manually yet. I thought we had released the new firmware version for the HaLowLink2 but it hasn’t gone out yet. There should be one arriving imminently!

@Kenbsherman

So it does appear the pattern is get the PI to talk first via ping and connections can work. Not sure what would cause that.

Three things come to mind for me with this statement. Routing, address resolution, or power save.

• Routing shouldn’t be an issue, as you’re on the same subnet and they do not encapsulate each other.
• Address resolution issues is a possibility, but I don’t want to mess with settings for this yet
• Power-save is the easiest to rule out. On the RPi can you run iw dev wlan1 set power_save off? This should also improve the “lag” you are experiencing.

If that resolves it, we then need to look at why Ping traffic from your AP isn’t being buffered for the RPi.