Re: Mesh Problem
Follow-up:
I tried it on an Atheros-based AP (Alfa N2Q) and found the same thing
- works for unencrypted mesh, but adding wpad-mesh-mbedtls causes the
mesh to fail completely, and mesh_params cannot be set:
root@OpenWrt:~# iw phy0-mesh0 set mesh_param mesh_gate_announcements=1
command failed: Link has been severed (-67)
I set log_level to 0 and got some interesting errors:
Tue Jun 25 00:40:11 2024 kern.info kernel: [ 2898.625083] br-lan: port
4(phy0-mesh0) entered blocking state
Tue Jun 25 00:40:11 2024 kern.info kernel: [ 2898.631437] br-lan: port
4(phy0-mesh0) entered disabled state
Tue Jun 25 00:40:11 2024 kern.info kernel: [ 2898.637879] device
phy0-mesh0 entered promiscuous mode
Tue Jun 25 00:40:11 2024 kern.info kernel: [ 2898.643613] br-lan: port
4(phy0-mesh0) entered blocking state
Tue Jun 25 00:40:11 2024 kern.info kernel: [ 2898.649659] br-lan: port
4(phy0-mesh0) entered forwarding state
Tue Jun 25 00:40:11 2024 daemon.err wpa_supplicant[1211]: Line 8: too
large mode (value=5 max_value=4)
Tue Jun 25 00:40:11 2024 daemon.err wpa_supplicant[1211]: Line 8:
failed to parse mode '5'.
Tue Jun 25 00:40:11 2024 daemon.err wpa_supplicant[1211]: Line 15:
failed to parse network block.
Tue Jun 25 00:40:11 2024 daemon.err wpa_supplicant[1211]: Failed to
read or parse configuration '/var/run/wpa_supplicant-phy0-mesh0.conf'.
Tue Jun 25 00:40:11 2024 daemon.notice wpa_supplicant[1211]: :
CTRL-EVENT-DSCP-POLICY clear_all
Tue Jun 25 00:40:11 2024 daemon.notice netifd: radio0 (4079): WARNING
(wireless_add_process): executable path /usr/sbin/wpad does not match
process 1212 path (/usr/sbin/wpad (deleted))
Tue Jun 25 00:40:11 2024 kern.info kernel: [ 2899.068199] br-lan: port
4(phy0-mesh0) entered disabled state
Tue Jun 25 00:40:12 2024 daemon.notice wpa_supplicant[1211]: Set new
config for phy phy0
So it definitely looks like a problem with wpa_supplicant.
root@OpenWrt:~# wpa_supplicant -v
wpa_supplicant v2.11-devel
Again, any suggestions appreciated.
-Bill
On Fri, Jun 21, 2024 at 8:42 AM Bill Moffitt wrote:
>
> Trying to set up meshing on Comfast EW-72 v2 - my first time working
> with the Mediatek chipset. I have played around with meshing quite a
> bit on Atheros chips.
>
> The interesting problem is that it seems to work in v23.05.2 and
> v23.05.3 with wpad-basic-mbedtls, but, when I swap it out for
> wpad-mesh (tried both mbedtls and wolfssl), it won't work. When I use
> iw phy0-mesh0 mesh_param dump, I see that mesh_auto_open_plinks=0,
> which explains why it won't connect to the mesh.
>
> However, trying to set it never works:
>
> root@OpenWrt:~# iw phy0-mesh0 set mesh_param mesh_auto_open_plinks=1
> command failed: Resource busy (-16)
>
> Interestingly, when I swap wpad-basic back in, it does work, but it
> appears to connect with encryption.
>
> uci set wireless.mesh.encryption='psk'
> uci set wireless.mesh.key='xx'
> wifi
>
> and the nodes connect. However, if I leave encryption off on one node,
> it STILL CONNECTS, meaning that encryption is failing silently
> (nothing in the logs). It seems like there should be at least a
> message ("Encryption configured for interface mesh but not enabled" or
> something).
>
> I'm not quite sure how to even debug this.
>
> All suggestions gratefully accepted.
>
> -Bill
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Mesh Problem
Trying to set up meshing on Comfast EW-72 v2 - my first time working
with the Mediatek chipset. I have played around with meshing quite a
bit on Atheros chips.
The interesting problem is that it seems to work in v23.05.2 and
v23.05.3 with wpad-basic-mbedtls, but, when I swap it out for
wpad-mesh (tried both mbedtls and wolfssl), it won't work. When I use
iw phy0-mesh0 mesh_param dump, I see that mesh_auto_open_plinks=0,
which explains why it won't connect to the mesh.
However, trying to set it never works:
root@OpenWrt:~# iw phy0-mesh0 set mesh_param mesh_auto_open_plinks=1
command failed: Resource busy (-16)
Interestingly, when I swap wpad-basic back in, it does work, but it
appears to connect with encryption.
uci set wireless.mesh.encryption='psk'
uci set wireless.mesh.key='xx'
wifi
and the nodes connect. However, if I leave encryption off on one node,
it STILL CONNECTS, meaning that encryption is failing silently
(nothing in the logs). It seems like there should be at least a
message ("Encryption configured for interface mesh but not enabled" or
something).
I'm not quite sure how to even debug this.
All suggestions gratefully accepted.
-Bill
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Comfast CF-E110n
Roger- Good idea. I think I may have been running firmware for a different device (E-320N, probably - it appears to have been the base design for several of their products). I was hoping you (or someone) could look at the log and say, "Hey, I know what that is..." Worth a shot... Next step - pull up one of the ones with the old firmware and compare settings with the .dts file (and figure out exactly what they're running). Thanks, Bill On Tue, Oct 24, 2023 at 2:32 PM Roger Pueyo Centelles | Guifi.net wrote: > > Hi, Bill, > > I have a couple of them, but they're in a remote location I can't access > right now. However, on one of them, I recently upgraded from OpenWrt > 22.03.X to 23.05.0 and I did not experience such issues. > > In order to narrow down the issue, you may want to try flashing this > older OpenWrt version (which one was it? CF-E110N is supported since > 19.07...), then upgrade one major release at a time (first 21.02, then > 22.03, until 23.05). When does this issue appear, if it does? > > Best, > > Roger > > El 23/10/23 a les 23:54, Bill Moffitt ha escrit: > > I have been using an older version of OpenWRT on my E110Ns; I loaded up > > the latest release to see if it would fix some "LOST BEACON" problems. > > > > Unfortunately, it didn't even boot (went into a bootloop), so I broke > > out the serial cable, > > busted open the radio, and connected it. Here's what I captured: > > > > > > U-Boot 1.1.4-ge619c187-dirty (Apr 12 2017 - 18:52:08) > > > > ap143 - Honey Bee 2.0 > > > > DRAM: 64 MB > > Flash: 16 MB > > > > dup 1 speed 100 > > Using eth0 device > > ping failed; host 192.168.1.10 is not alive > > Unknown command 'ERROR!' - try 'help' > > Hit any key to stop autoboot: 1 0 > > ## Booting image at 9f02 ... > > Image Name: MIPS OpenWrt Linux-5.15.134 > > Created: 2023-10-09 21:45:35 UTC > > Image Type: MIPS Linux Kernel Image (lzma compressed) > > Data Size:2328775 Bytes = 2.2 MB > > Load Address: 8006 > > Entry Point: 8006 > > Verifying Checksum at 0x9f020040 ...OK > > Uncompressing Kernel Image ... OK > > No initrd > > ## Transferring control to Linux (at address 8006) ... > > ## Giving linux memsize in bytes, 67108864 > > > > Starting kernel ... > > > > [0.00] Linux version 5.15.134 (builder@buildhost) > > (mips-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r23497-6637af95aa) > > 12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 Mon Oct 9 21:45:35 2023 > > [0.00] printk: bootconsole [early0] enabled > > [0.00] CPU0 revision is: 00019374 (MIPS 24Kc) > > [0.00] MIPS: machine is COMFAST CF-E110N v2 > > [0.00] SoC: Qualcomm Atheros QCA9533 ver 2 rev 0 > > [0.00] Initrd not found or empty - disabling initrd > > [0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 > > bytes. > > [0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, > > linesize 32 bytes > > [0.00] Zone ranges: > > [0.00] Normal [mem 0x-0x03ff] > > [0.00] Movable zone start for each node > > [0.00] Early memory node ranges > > [0.00] node 0: [mem 0x-0x03ff] > > [0.00] Initmem setup node 0 [mem > > 0x-0x03ff] > > [0.00] Built 1 zonelists, mobility grouping on. Total pages: 16240 > > [0.00] Kernel command line: console=ttyS0,115200n8 > > rootfstype=squashfs,jffs2 > > [0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 > > bytes, linear) > > [0.00] Inode-cache hash table entries: 4096 (order: 2, 16384 > > bytes, linear) > > [0.00] Writing ErrCtl register= > > [0.00] Readback ErrCtl register= > > [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off > > [0.00] Memory: 55972K/65536K available (6077K kernel code, > > 591K rwdata, 780K rodata, 1184K init, 217K bss, 9564K reserved, 0K > > cma-reserved) > > [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 > > [0.00] NR_IRQS: 51 > > [0.00] CPU clock: 650.000 MHz > > [0.00] clocksource: MIPS: mask: 0x max_cycles: > > 0x, max_idle_ns: 5880801374 ns > > [0.02] sched_clock: 32 bits at 325MHz, resolution 3ns, wraps > > every 6607641598ns > > [0.008370] Calibrating delay loop... 432.53 BogoMIPS (lpj=2162688) > >
Comfast CF-E110n
I have been using an older version of OpenWRT on my E110Ns; I loaded up the latest release to see if it would fix some "LOST BEACON" problems. Unfortunately, it didn't even boot (went into a bootloop), so I broke out the serial cable, busted open the radio, and connected it. Here's what I captured: U-Boot 1.1.4-ge619c187-dirty (Apr 12 2017 - 18:52:08) ap143 - Honey Bee 2.0 DRAM: 64 MB Flash: 16 MB dup 1 speed 100 Using eth0 device ping failed; host 192.168.1.10 is not alive Unknown command 'ERROR!' - try 'help' Hit any key to stop autoboot: 1 0 ## Booting image at 9f02 ... Image Name: MIPS OpenWrt Linux-5.15.134 Created: 2023-10-09 21:45:35 UTC Image Type: MIPS Linux Kernel Image (lzma compressed) Data Size:2328775 Bytes = 2.2 MB Load Address: 8006 Entry Point: 8006 Verifying Checksum at 0x9f020040 ...OK Uncompressing Kernel Image ... OK No initrd ## Transferring control to Linux (at address 8006) ... ## Giving linux memsize in bytes, 67108864 Starting kernel ... [0.00] Linux version 5.15.134 (builder@buildhost) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r23497-6637af95aa) 12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 Mon Oct 9 21:45:35 2023 [0.00] printk: bootconsole [early0] enabled [0.00] CPU0 revision is: 00019374 (MIPS 24Kc) [0.00] MIPS: machine is COMFAST CF-E110N v2 [0.00] SoC: Qualcomm Atheros QCA9533 ver 2 rev 0 [0.00] Initrd not found or empty - disabling initrd [0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. [0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes [0.00] Zone ranges: [0.00] Normal [mem 0x-0x03ff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x03ff] [0.00] Initmem setup node 0 [mem 0x-0x03ff] [0.00] Built 1 zonelists, mobility grouping on. Total pages: 16240 [0.00] Kernel command line: console=ttyS0,115200n8 rootfstype=squashfs,jffs2 [0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes, linear) [0.00] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes, linear) [0.00] Writing ErrCtl register= [0.00] Readback ErrCtl register= [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [0.00] Memory: 55972K/65536K available (6077K kernel code, 591K rwdata, 780K rodata, 1184K init, 217K bss, 9564K reserved, 0K cma-reserved) [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS: 51 [0.00] CPU clock: 650.000 MHz [0.00] clocksource: MIPS: mask: 0x max_cycles: 0x, max_idle_ns: 5880801374 ns [0.02] sched_clock: 32 bits at 325MHz, resolution 3ns, wraps every 6607641598ns [0.008370] Calibrating delay loop... 432.53 BogoMIPS (lpj=2162688) [0.074950] pid_max: default: 32768 minimum: 301 [0.080919] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.088644] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.105660] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.116125] futex hash table entries: 256 (order: -1, 3072 bytes, linear) [0.123566] pinctrl core: initialized pinctrl subsystem [0.131441] NET: Registered PF_NETLINK/PF_ROUTE protocol family [0.138492] thermal_sys: Registered thermal governor 'step_wise' [0.153766] clocksource: Switched to clocksource MIPS [0.167301] NET: Registered PF_INET protocol family [0.172759] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear) [0.181676] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear) [0.190630] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear) [0.198823] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.206939] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.214408] TCP: Hash tables configured (established 1024 bind 1024) [0.221345] UDP hash table entries: 256 (order: 0, 4096 bytes, linear) [0.228344] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear) [0.236302] NET: Registered PF_UNIX/PF_LOCAL protocol family [0.242338] PCI: CLS 0 bytes, default 32 [0.251473] workingset: timestamp_bits=14 max_order=14 bucket_order=0 [0.264981] squashfs: version 4.0 (2009/01/31) Phillip Lougher [0.271158] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. [0.283297] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251) [0.296681] pinctrl-single 1804002c.pinmux: 576 pins, size 72 [0.304425] Serial: 8250/16550 driver, 16 ports,
Boot loop on Comfast E110N
I have been using an older version of OpenWRT on my E110N; I loaded up the latest release to see if it would fix some "LOST BEACON" problems. Unfortunately, it didn't even boot, so I broke out the serial cable, busted open the radio, and connected it. Here's what I captured: U-Boot 1.1.4-ge619c187-dirty (Apr 12 2017 - 18:52:08) ap143 - Honey Bee 2.0 DRAM: 64 MB Flash: 16 MB dup 1 speed 100 Using eth0 device ping failed; host 192.168.1.10 is not alive Unknown command 'ERROR!' - try 'help' Hit any key to stop autoboot: 1 0 ## Booting image at 9f02 ... Image Name: MIPS OpenWrt Linux-5.15.134 Created: 2023-10-09 21:45:35 UTC Image Type: MIPS Linux Kernel Image (lzma compressed) Data Size:2328775 Bytes = 2.2 MB Load Address: 8006 Entry Point: 8006 Verifying Checksum at 0x9f020040 ...OK Uncompressing Kernel Image ... OK No initrd ## Transferring control to Linux (at address 8006) ... ## Giving linux memsize in bytes, 67108864 Starting kernel ... [0.00] Linux version 5.15.134 (builder@buildhost) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r23497-6637af95aa) 12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 Mon Oct 9 21:45:35 2023 [0.00] printk: bootconsole [early0] enabled [0.00] CPU0 revision is: 00019374 (MIPS 24Kc) [0.00] MIPS: machine is COMFAST CF-E110N v2 [0.00] SoC: Qualcomm Atheros QCA9533 ver 2 rev 0 [0.00] Initrd not found or empty - disabling initrd [0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. [0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes [0.00] Zone ranges: [0.00] Normal [mem 0x-0x03ff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x03ff] [0.00] Initmem setup node 0 [mem 0x-0x03ff] [0.00] Built 1 zonelists, mobility grouping on. Total pages: 16240 [0.00] Kernel command line: console=ttyS0,115200n8 rootfstype=squashfs,jffs2 [0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes, linear) [0.00] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes, linear) [0.00] Writing ErrCtl register= [0.00] Readback ErrCtl register= [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [0.00] Memory: 55972K/65536K available (6077K kernel code, 591K rwdata, 780K rodata, 1184K init, 217K bss, 9564K reserved, 0K cma-reserved) [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS: 51 [0.00] CPU clock: 650.000 MHz [0.00] clocksource: MIPS: mask: 0x max_cycles: 0x, max_idle_ns: 5880801374 ns [0.02] sched_clock: 32 bits at 325MHz, resolution 3ns, wraps every 6607641598ns [0.008370] Calibrating delay loop... 432.53 BogoMIPS (lpj=2162688) [0.074950] pid_max: default: 32768 minimum: 301 [0.080919] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.088644] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.105660] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.116125] futex hash table entries: 256 (order: -1, 3072 bytes, linear) [0.123566] pinctrl core: initialized pinctrl subsystem [0.131441] NET: Registered PF_NETLINK/PF_ROUTE protocol family [0.138492] thermal_sys: Registered thermal governor 'step_wise' [0.153766] clocksource: Switched to clocksource MIPS [0.167301] NET: Registered PF_INET protocol family [0.172759] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear) [0.181676] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear) [0.190630] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear) [0.198823] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.206939] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.214408] TCP: Hash tables configured (established 1024 bind 1024) [0.221345] UDP hash table entries: 256 (order: 0, 4096 bytes, linear) [0.228344] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear) [0.236302] NET: Registered PF_UNIX/PF_LOCAL protocol family [0.242338] PCI: CLS 0 bytes, default 32 [0.251473] workingset: timestamp_bits=14 max_order=14 bucket_order=0 [0.264981] squashfs: version 4.0 (2009/01/31) Phillip Lougher [0.271158] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. [0.283297] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251) [0.296681] pinctrl-single 1804002c.pinmux: 576 pins, size 72 [0.304425] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled [
Re: Old hardware...
I have three (3) old Ubiquiti UniFi indoor access points. Still supported in OpenWRT ath79, these are from 2015 or so. They're actually new in the box, purchased for a project that required OpenWRT; when Ubiquiti locked their bootloader they became unattractive and I set them aside. I have checked them and upgraded them to 22.03. They are just 2.4 GHz. 2x2 indoor access points with POE injectors, mounting brackets, etc. If someone can use them for testing, teaching, or some other use, I'd be happy to ship them in the continental US. If you want one or all three, please contact me at bmoff...@ayrstone.com. As a side note, I tried selling them on ebay using "running OpenWRT, not Ubiquiti's firmware" as a differentiation point. I did not even get a bid, even setting the starting price at $20. On Fri, Apr 28, 2023 at 2:19 PM Bill Moffitt wrote: > > I have three (3) old Ubiquiti UniFi indoor access points. Still supported in > OpenWRT ath79, these are from 2015 or so. They're actually new in the box, > purchased for a project that required OpenWRT; when Ubiquiti locked their > bootloader they became unattractive and I set them aside. I have checked them > and upgraded them to 22.03. They are just 2.4 GHz. 2x2 indoor access points > with POE injectors, mounting brackets, etc. > > If someone can use them for testing, teaching, or some other use, I'd be > happy to ship them in the continental US. > > As a side note, I tried selling them on ebay using "running OpenWRT, not > Ubiquiti's firmware" as a differentiation point. I did not even get a bid, > even setting the starting price at $20. > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Problem with arp-scan
Working with 18.06, arp-scan works as expected; e.g. # arp-scan -I br-lan -l Interface: br-lan, datalink type: EN10MB (Ethernet) WARNING: Cannot open MAC/Vendor file /usr/share/arp-scan/ieee-oui.txt: No such file or directory WARNING: Cannot open MAC/Vendor file /usr/share/arp-scan/ieee-iab.txt: No such file or directory WARNING: Cannot open MAC/Vendor file /usr/share/arp-scan/mac-vendor.txt: No such file or directory Starting arp-scan 1.9.5 with 256 hosts (https://github.com/royhills/arp-scan) 172.22.47.1 de:9f:db:05:46:5d (Unknown) 172.22.47.53 00:24:8c:9d:1d:92 (Unknown) 172.22.47.77 0c:ef:af:c4:f5:b5 (Unknown) 172.22.47.111 3c:2a:f4:b8:25:c2 (Unknown) 172.22.47.116 00:02:d1:43:e8:5b (Unknown) 172.22.47.186 00:c0:ca:8d:4d:2c (Unknown) 172.22.47.108 00:40:8c:a5:e8:03 (Unknown) 172.22.47.186 00:c0:ca:8d:4d:2c (Unknown) (DUP: 2) 172.22.47.132 2c:aa:8e:9a:3a:94 (Unknown) 11 packets received by filter, 0 packets dropped by kernel Ending arp-scan 1.9.5: 256 hosts scanned in 1.810 seconds (141.44 hosts/sec). 9 responded But in 19.07.4, I get the following behavior: # arp-scan -I br-lan -l Interface: br-lan, datalink type: EN10MB (Ethernet) WARNING: Cannot open MAC/Vendor file /usr/share/arp-scan/ieee-oui.txt: No such file or directory WARNING: Cannot open MAC/Vendor file /usr/share/arp-scan/ieee-iab.txt: No such file or directory WARNING: Cannot open MAC/Vendor file /usr/share/arp-scan/mac-vendor.txt: No such file or directory Starting arp-scan 1.9.5 with 256 hosts (https://github.com/royhills/arp-scan) 22 packets received by filter, 0 packets dropped by kernel Ending arp-scan 1.9.5: 256 hosts scanned in 1.854 seconds (138.08 hosts/sec). 0 responded Has anyone else seen this behavior? Any ideas what might be causing this? (e.g. misconfiguration of some sort) -- Bill Moffitt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE Project Forum] [Installing and Using LEDE] New Ubiquiti LOCO M2 XW
Fellow developers- I wanted to follow up on this topic, as it pertains to anyone considering using OpenWRT/LEDE on Ubiquiti wireless gear (I can't speak to the EdgeRouter, etc. devices). I have been speaking with one of the executives at Ubiquiti, and he disclosed that they have been feeling pressured by the FCC to deal with the perceived issue of firmware being able to alter the RF characteristics of the hardware, particularly in the 5 GHz. band. He pointed to this note from the FCC as evidence: https://assets.documentcloud.org/documents/2339685/fcc-software-security-requirements.pdf This is an interesting document - I really don't understand what legal standing it has - wasn't this the proposal that set us all to the web last year to try to make the FCC be sensible? In its First Review and Order of July 13 (https://apps.fcc.gov/edocs_public/attachmatch/FCC-17-93A1.pdf) the FCC specifically mention in the footnotes that they are NOT addressing "...provisions to prevent the unauthorized modification of the software and firmware that ensure that and RF device complies with FCC rules that prevent harmful interference..." So it appears, at this point, that the FCC's position is that the replacement of firmware on devices is perfectly legal, but, to have a U-NII (5 GHz) device authorized in the U.S., it must have its firmware locked so it cannot be modified. Whatever the legality is, the folks at Ubiquiti have made the decision to lock the bootloader on all their models so that firmware that is not specifically "signed" by Ubiquiti cannot be flashed on to their products. Models with locked bootloaders are just being introduced now - my last batch of Loco M2 units (note that these are 2.4 GHz. radios) were very odd: on units running AirOS 5.6.12 (as they shipped) I could load LEDE via the Web UI, but I could not load it using tftp. I updated some units to AirOS 6.0.6 and could not load LEDE at all via any method. Even connecting to the serial port did not help - the console stops when the firmware starts booting. The bottom line is this: effective in the very near future, we will not be able to load OpenWRT/LEDE on to Ubiquiti wireless gear, unless I'm missing something here. And we should expect every vendor to follow suit. This represents an interesting problem for getting commercial vendors to adopt and support OpenWRT/LEDE - if Ubiquiti is interpreting the FCC's notes correctly, any company that wants to use OpenWRT/LEDE will have to sign the images so they cannot be modified. This seems to contradict the real value of OpenWRT/LEDE - and how would that even work with opkg, etc?). I wanted to report what I have found to this group and see if anyone has any brilliant ideas. I haven't any at the moment. Thanks, Bill On 08/14/2017 10:46 AM, Adrian Draus wrote: [r43k3n] r43k3n <http://forum.lede-project.org/users/r43k3n> Adrian Draus <http://forum.lede-project.org/users/r43k3n> August 14 Ubiquiti still refuses to release images for complete system recovery for EdgeRouter devices. So when your EdgeOS firmware gets corrupted beyond repair and your out of warranty then the only course of action is to install LEDE. No official restoration procedure for EdgeOS is available. That is not understandable for me since most TP-Link devices and Netgear units too have a way to restore the entire firmware using TFTP. Visit Topic <http://forum.lede-project.org/t/new-ubiquiti-loco-m2-xw/5760/5> or reply to this email to respond. In Reply To [bmoffitt] bmoffitt <http://forum.lede-project.org/users/bmoffitt> Bill Moffitt <http://forum.lede-project.org/users/bmoffitt> August 14 Yes, they are not being very friendly towards us... Visit Topic <http://forum.lede-project.org/t/new-ubiquiti-loco-m2-xw/5760/5> or reply to this email to respond. To unsubscribe from these emails, click here <http://forum.lede-project.org/email/unsubscribe/d77905e615393f4ac90fda533896470e252bc1a7f50554875dac5763ab8e4293>. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Tried to update ticket 20982 on dev.openwrt.org
I have been busy with other things, but I finally got a shipment of brand-new PicoStations (XM, identical to Bullet) here and tried to flash both the trunk builds of OpenWRT and LEDE on them. I'm getting the same error I did some months back: sent DATA
Re: [OpenWrt-Devel] [OpenWrt] #20982: jffs2-error / nanostation M5 xw / r47658
On 05/05/16 19:16, OpenWrt wrote: #20982: jffs2-error / nanostation M5 xw / r47658 + Reporter: bittorf@… | Owner: developers Type: defect | Status: new Priority: normal | Milestone: Component: packages |Version: Trunk Resolution: | Keywords: + Comment (by johnv): Replying to [comment:31 bmoffitt]: > 1.) Recovery (tftp) flash AirOS 5.6.3 onto the radio; then > 2.) Using the fwupdate command in AirOS, flash AirOS 5.5.11 onto the radio; then > 3.) Again using the fwupdate command, flash OpenWRT onto the radio. > > This sequence seems to work on every PicoStation and NanoStation Loco M2 XM I have gotten SO FAR. Oddly, downgrading a radio that came with AirOS 5.6 running on it to AirOS 5.5 DID NOT WORK - it appears that it is necessary to do the recovery (tftp) flash of AirOS 5.6 before you downgrade to 5.5. I honestly cannot explain it, but, so far, this sequence seems the only way to reliably flash OpenWRT onto a PicoStation, Bullet, or NanoStation Loco M2 that comes running AirOS 5.6. Can you confirm the 5.6.X version that was installed on the units when you received them? There is a Fix in the UBNT changelog for 5.6.4: - Fix: After FW downgrade to 5.5.6 device goes to read-only state (TFTP recovery to previous airOS version is required to restore normal operation) So wondering if the ones that you have that you are unable to simply downgrade back to 5.5.11, are prior to 5.6.4 or not. And if so, if you could upgrade to 5.6.4, then downgrade to 5.5.11, and the OpenWRT. Getting messier but still might be easier then tftp. Alas, I don't have any new ones at the moment, and probably won't for a few weeks. And I don't recall what the new ones I was testing came with. -- Ticket URL: <https://dev.openwrt.org/ticket/20982#comment:32> OpenWrt <http://openwrt.org> Opensource Wireless Router Technology -- Bill Moffitt Ayrstone Productivity http://ayrstone.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] downloads.openwrt.org
I wasn't able to download the trunk nightlies. It looks like there's a nice, slick, new web interface, but no builds in some areas (particularly the AR7xx generic platform). Is it just a failed build or a problem in the webpage? -- Bill Moffitt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Cannot flash UBNT Loco M2
I got a new batch of LocoM2 units, and they won't flash using the "recovery" (tftp) method - it says, received ERROR
[OpenWrt-Devel] Chaos Calmer on Ubiquiti (ubnt) Rocket-M2
I just downloaded CC for the Rocket M2 (openwrt-15.05-ar71xx-generic-ubnt-rocket-m-squashfs-factory.bin) and could not get it to work. Specifically, the lights worked, but I could not obtain any response (ping, ssh - I even tried telnet) at 192.168.1.1 from the Ethernet port. I saw Ben West's note and tickets 19885 and 19579, but this did not seem to be intermittent - I never saw any response from the Ethernet port. I did not wireshark it to see if it was sending out any packets (busy). I thought I'd check in and see if anyone else had seen this issue or knew anything about it. -Bill ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] alternatives to TDMA
My understanding is that UBNT has an ASIC in their devices to help with the timing of the TDMA mode. My suspicion is that, without that ASIC, software only TDMA would probably not be precise enough to bring benefit. Does anyone have a better understanding of this? -Bill ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Q: mac80211: defailt distance-settings 0 (Felix Fietkau)
Message: 1 Date: Tue, 07 Oct 2014 12:35:25 +0200 From: Felix Fietkau n...@openwrt.org To: mailinglist openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] Q: mac80211: defailt distance-settings 0 Message-ID: 5433c1ed.5050...@openwrt.org Content-Type: text/plain; charset=windows-1252 On 2014-10-07 08:15, Bastian Bittorf wrote: i seems that '/lib/netifd/wireless/mac80211.sh' sets the default distance to '0' if not defined via uci. what does that mean? dynamic ack or not? because 0 seems to be a valid value: 0 does not imply dynamic ACK, it is simply the minimum value. Enabling dynack by default would be a bad idea. - Felix Felix- Thanks for the clarification; I was under the same impression as Bastian. Which brings up three follow-up questions: 1. How DO you turn dynack on? 2. When was dynack first added to ath9k and to OpenWRT? (I.e. what's the earliest version of OpenWRT in which it can be used?) 3.) Is 0 the right default for distance? Might 100 or 1000 be better values? (I'm using OpenWRT for outdoor WiFi in the U.S. with 600 mw access points, so I may have a slightly warped sense of what's right here...) In my experience, the default seems to work OK out to over 2 km. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ubiquiti Nanostation LOCO M5
Martin- Yes, it does. The LOCO images are only in the trunk, not in 14.07 - only the nanostation xw images are currently in 14.07. Is there any chance we could get the LOCO xw images (which, I suspect, would also be the Bullet/Pico xw images) built for the final 14.07? -Bill On 09/24/2014 10:02 AM, heini66 wrote: you're using 14.07 images? ubiquity releaed new a new hardwaregesign on the m5 that will only work with trunk or 14.07 ... http://wiki.openwrt.org/toh/ubiquiti/nanostationm5 hope this helps. martin 2014-09-24 18:21 GMT+02:00 Bill bmoff...@ayrstone.com mailto:bmoff...@ayrstone.com: I just got 5 LOCO M5 units that won't run OpenWRT. They are datestamped 1422K; when I try to flash them, they give me: received ERROR code=2, msg=Firmware check failed I am using the Bullet M image (openwrt-ar71xx-generic-ubnt-bullet-m-squashfs-factory.bin), flashing with tftp in binary mode. I have one other LOCO M5 with datestamp 1340K that works fine - flashes fine every time. But the new units won't take the firmware at all. I assume UBNT did something in the bootloader that is disabling OpenWRT. Any help will be welcome. I can open one up and attach a serial cable, but I'm not sure what I'd look for or what I'd do about it... Thanks, Bill ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org mailto:openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Bill Moffitt Ayrstone Productivity http://ayrstone.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWRT IPv6 firewall
I'd like to chime in to this thread as someone who has spent a fair bit of time supporting end users (primarily home and small office users) setting up and using consumer grade routers. All these routers today, of course, necessarily come NATted, meaning no ports are open to the Internet. Users are accustomed to being able to connect their computers to the router's network and be shielded from unwanted intrusions from outside by the NAT firewall. I believe the default behavior of an IPv6 consumer-grade router should be the same: all ports blocked. Of course, it seems foolish to have global addressing and then have a router that blocks client devices, but here is my reasoning: 1.) In the IPv6 world, the firewall should rightfully migrate from the router to the device, but that transition won't be simultaneous with the availability of v6. For some transitional time, we'll have legacy devices on the network that are v6-capable but not necessarily v6-safe - and consumer-grade users will probably not realize it. At the least, users won't be accustomed to having their printer visible to the whole world and will need time to understand that they need to have strong passwords on their printers, cameras, thermostats, dog feeders, etc. (or explicitly block them) 2.) I believe that the transition to v6 in the U.S. and Europe is not going to be slow and orderly, but will be sudden and chaotic, driven by emergent demand for some service that arises in a manner that necessitates v6 access. For that reason, I think that maintaining behavior similar to what consumers see today will be critical in user satisfaction. I expect that, over time, users will become accustomed to the end-to-end nature of the v6 Internet and may demand that the firewall be open by default, and I would certainly propose that we have a simple checkbox in LUCI that allows the firewall to be changed from all closed except explicitly open ports to all open in one action. At some point we would probably change the default behavior from all closed to all open. However, for the moment, I would argue that the rightness of following expected behavior is greater than the rightness of delivering the true end-to-end nature of v6. FWIW, -Bill Moffitt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Long-distance links ath9k
On March 26, 2014 11:29:59 AM PDT, Sergey Ryazanov ryazanov@gmail.com wrote: 2014-03-26 9:13 GMT+04:00 Bill Moffitt bmoff...@ayrstone.com: It's clear that SOMETHING is getting time-limited, but I have distance=0 and dissassoc_low_ack=0 on both the AP and the station, and I'm not sure what else I can tweak. Configure distance parameter according to real distance between points. -- BR, Sergey Sorry, should have mentioned that, of course, I tried that, and various variants of that. At 2 miles (~3000 meters) it had a good connection and could consistently measure bandwidth with iperf. Bandwidth was maximized when distance=6000 (as expected) and distance=0 (as expected). At 5 miles, it would not pass traffic with any value of distance. I tried every value than that made any sense (0, 8000, 16000) and some that didn't (3, 50) and the results were the same (nothing). I note that it appeared to be passing authentication data (per the log) but failing to authenticate. I'd be very interested in hearing from anyone who has successfully set up an encrypted 5+ mile link (8+ km) with this kind of a setup (Ath7k, AA). Thanks, Bill___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Long-distance links ath9k
: [ 2590.96] wlan0: associated Jan 1 00:43:11 TestUnit kern.info kernel: [ 2592.00] wlan0: disassociated from 00:15:6d:4c:45:09 (Reason: 7) Jan 1 00:43:12 TestUnit kern.info kernel: [ 2592.02] wlan0: deauthenticating from 00:15:6d:4c:45:09 by local choice (reason=3) Jan 1 00:43:12 TestUnit kern.info kernel: [ 2592.80] wlan0: authenticate with 00:15:6d:4c:45:09 Jan 1 00:43:12 TestUnit kern.info kernel: [ 2592.83] wlan0: send auth to 00:15:6d:4c:45:09 (try 1/3) Jan 1 00:43:12 TestUnit kern.info kernel: [ 2592.84] wlan0: authenticated Jan 1 00:43:12 TestUnit kern.info kernel: [ 2592.86] wlan0: associate with 00:15:6d:4c:45:09 (try 1/3) Jan 1 00:43:12 TestUnit kern.info kernel: [ 2592.91] wlan0: RX AssocResp from 00:15:6d:4c:45:09 (capab=0x411 status=0 aid=1) Jan 1 00:43:12 TestUnit kern.info kernel: [ 2592.92] wlan0: associated It strongly smells like I'm having trouble with hostapd and/or wpa-supplicant, but I'm not sure even where to look for more information at this point. All help gratefully accepted... -- Bill Moffitt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Comprehensive ipv4 and ipv6 unaligned access, patch for ar71xx
Philosophical rant On the subject of being able to turn off V6, I agree with both sides, but with a caveat. On one side, V6 is necessary today in Asia, but, on the other had, it's not at all necessary or even desirable yet in North America and Europe, so I think it is desirable to be able to turn it off. Right now I don't know of a consumer ISP in North America that will GIVE you an IPv6 address, never mind require it, although some business ISPs tout V6 routing. Because of the foot-dragging in rolling out V6, I believe that adoption is not going to be a gradual affair - I believe that, at some point, someone (probably in Asia) is going to invent the Next Big Thing that Everybody HAS to HAVE, (i.e. the next new Google, Facebook, Twitter, Pinterest, Dropbox, whatever) and it will only be accessible via V6. At that point, everyone in North America and Europe will suddenly change from ignoring V6 to HAVING TO HAVE IT RIGHT NOW!!! I believe the ISPs will mostly be blindsided - the few who thought that this might happen will be able to move users to V6 and will be winners in this scenario, while those who didn't plan ahead (or thought they'd be able to move people gradually to v6) will be roasted alive in the court of consumer opinion. It will be a crisis that no one could have predicted. While we consumers in N. America and Europe can still afford to be complacent for a while, I think that we, as OpenWRT developers, need to be very diligent in ensuring OpenWRT plays well on V6 in anticipation of this event, should it come to pass. It may be a nice opportunity for OpenWRT to get some nice publicity by saving the day when the crisis occurs. /Philosophical rant -- Bill Moffitt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Ubiquiti PicoStation 2HP (and perhaps others)
Folks-
As noted earlier, I found myself unable to flash OpenWRT on to new
Ubiquiti PicoStation 2HP radios. After working on it for about a week, I
have found a solution, at least for my own purposes.
I'm not familiar enough with the OpenWRT standards to suggest a specific
patch, but I'll share the hack I'm using on my own (adulterated) version
of the Robin firmware.
As Jo-Philipp Wich pointed out on January 1:
Hi.
Ubiquiti tightened the regulatory enforcement. They now ship with a
regdomain entry in the boarddate which is not recognized by OpenWrt's
HAL, therfore the wifi is rejected.
It can be fixed by changing the byte at offset 0x277 in mtd6 to 0x00 or
any other valid regdomain id.
Possible fixes are difficult. One obvious solution is to make the HAL
recognize Ubnt's new IDs, but that is going to be difficult since its
closed source. The other workaround I can think of is to runtime-patch
the in-memory copy of the radio-data in the board setup code.
~ Jow
Here's how I did it is this; first, I put the following script in /etc/
and called it regdoman-script.sh:
*Code:*
#!/bin/sh
# By Bill Moffitt - this script puts a zero in the 632nd byte of the
appropriate device
#
date /etc/firstbootlog
echo Starting regdomain-script.sh /etc/firstbootlog
partn=`grep boardconfig /proc/mtd |awk '{print $1}' |cut -d: -f1`
byte=$(hexdump -b /dev/$partn |grep 270 |awk '{print $9}')
echo Going to work on partition $partn where regdomain is $byte
if [ $byte == 000 ]; then
echo success /tmp/regdomain_success
exit
fi
if [ $partn -a ! $byte == 000 ]; then
echo Setting up regdomain on partition /dev/$partn
/etc/firstbootlog
dd if=/dev/$partn of=/tmp/mtdfile bs=1 count=631 echo got the
first 631 bytes /etc/firstbootlog
dd if=/dev/zero bs=1 count=1 /tmp/mtdfile echo put in the
zero /etc/firstbootlog
dd if=/dev/$partn bs=1 skip=632 /tmp/mtdfile echo got the rest
of the file /etc/firstbootlog
mtd erase $partn echo erased the partition /etc/firstbootlog
dd if=/tmp/mtdfile of=/dev/$partn 2/etc/firstbootlog echo
Finished flashing partition $partn /etc/firstbootlog
wait
sync echo Sync succeeded /etc/firstbootlog
byte=$(hexdump -b /dev/$partn |grep 270 |awk '{print $9}')
if [ $byte -eq 000 ]; then
echo regdomain is zero /etc/firstbootlog
sync
rm /tmp/mtdfile
date /etc/firstbootlog
echo done with regdomain /etc/firstbootlog
echo success /tmp/regdomain_success
else
echo FAIL writing the file back to /dev/$partn - regdomain
remains $byte
fi
else
echo Could not find partition /etc/firstbootlog
fi
Next, I edited /etc/init.d/rcS. Just before it kicks off the rc.d
scripts, I inserted the following code:
*Code:*
if [ -e /etc/regdomain-script.sh ]; then
logger applying regdomain patch
/etc/regdomain-script.sh
wait
if [ -e /tmp/regdomain_success ]; then
rm /etc/regdomain-script.sh
echo regdomain-script.sh seems to have worked
/etc/firstbootlog
else
echo regdomain-script.sh seems to have failed
/etc/firstbootlog
fi
fi
The upshot of this is that, on the device's first boot, it looks for the
correct /dev/mtd file, checks to see if it has the bogus byte that
Ubiquiti has placed in there, and, if it does, it changes that byte. It
leaves a little log file in /etc/firstbootlog (so you can tell what
happened) and, if the regdomain-script.sh has succeeded, it deletes the
script so it won't execute every time the device starts up.
Please let me know if you have any questions.
Thanks to Jo-Philipp and several others for help in debugging this.
-Bill
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT fails on recent Ubiquiti PicoStation 2HP radios
Hi. Ubiquiti tightened the regulatory enforcement. They now ship with a regdomain entry in the boarddate which is not recognized by OpenWrt's HAL, therfore the wifi is rejected. It can be fixed by changing the byte at offset 0x277 in mtd6 to 0x00 or any other valid regdomain id. Possible fixes are difficult. One obvious solution is to make the HAL recognize Ubnt's new IDs, but that is going to be difficult since its closed source. The other workaround I can think of is to runtime-patch the in-memory copy of the radio-data in the board setup code. ~ Jow Jow- Thank you for your speedy reply. I agree the best short-term workaround is to do a runtime patch of the regdomain, but how, practically, to do it? I'm very open to suggestions - I'm currently dead in the water. -Bill -- Bill Moffitt Ayrstone Productivity http://www.ayrstone.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWRT consultant
I have a lot of OpenWRT work I need to get done (from the platform to application-level) and need someone with some real OpenWRT experience to help out on a part-time basis. There are benefits to the community at large - I hope to improve the support for certain Ubiquiti and/or Engenius products in OpenWRT. If you're qualified and interested (or know someone who might be), please contact me at bmoff...@ayrstone.com. Thanks, Bill -- Bill Moffitt Ayrstone Productivity http://www.ayrstone.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWRT fails on recent Ubiquiti PicoStation 2HP radios
Ubiquiti (ubnt.com) has changed something in the Pico2HP and OpenWRT can no longer start the WiFi radio on it. I have only seen this on recent Pico2HPs with MAC addresses starting with 00:27:22:8A (although my sample is currently small). OpenWRT (10.03.1) will boot and run, but the log (and dmesg) says, wifi%d ath_attach failed: -22 I don't know enough about MadWifi and the HAL to even debug this. Any help will be appreciated! -- Bill Moffitt Ayrstone Productivity http://www.ayrstone.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Proper Ubiquiti AirRouter Hardware, Support
Confirming that the patch seems to work - ports correct, all lights work correctly. -- Bill Moffitt Ayrstone Productivity http://www.ayrstone.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
