Openwrt Github commit notes, Forum posts, and Documentation, refer to:
"The mtd partitions layout for XM-type devices changed from AirOS v5.5
to AirOS v5.6. Before installing OpenWrt, downgrade first to AirOS
5.5."
reference: https://openwrt.org/toh/ubiquiti/common
While the documentation is a
> > I'm having a bit of heartburn with continuing with these instructions:
> >
> > > Flashing via stock GUI:
> > > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first (see
> > >https://openwrt.org/toh/ubiquiti/powerbeam installation instructions)
> >
> > This issue was resolved
I'm having a bit of heartburn with continuing with these instructions:
> Flashing via stock GUI:
> - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first (see
>https://openwrt.org/toh/ubiquiti/powerbeam installation instructions)
This issue was resolved with:
> Subject: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
> Message-ID: <20210523115946.711907-1-russ...@personaltelco.net>
>
> This patch adds support for the Ubiquiti PowerBeam M (XW), e.g. PBE-M5-400,
> a 802.11n wireless with a feed+dish form factor. This device was previously
>
> > Anyone else seeing this on recently purchased Mikrotik models?
> > Installing openwrt 19.07.03 on a Mikrotik LHG 5 boots, initfs and
> > appears to succeed with sysupgrade. Then the device is in an infinite
> > boot loop. It appears there's no console configured in routerboot to
> > see
Anyone else seeing this on recently purchased Mikrotik models?
Installing openwrt 19.07.03 on a Mikrotik LHG 5 boots, initfs and
appears to succeed with sysupgrade. Then the device is in an infinite
boot loop. It appears there's no console configured in routerboot to
see what it is doing. Any
In 19.07.1 and master, I don't find definitions for a few devices in
02_network.
I'm debugging an issue and did not find a definition for gl-ar150. It
appears a few devices were accidentally removed:
- comfast,cf-e5|\
- glinet,gl-ar150|\
- glinet,gl-ar300m-nand|\
- glinet,gl-ar300m-nor|\
-
> > during support of the Ubiquiti Nanostation Loco XW, we encountered the
> > following
> > blocks in ar71xx which are only present for devices not migrated to ath79
> > yet:
> >
> > static struct mdio_board_info ubnt_loco_m_xw_mdio_info[] = {
> > {
> > [...]
> >
40_run_failsafe_hook",
procd completes as expected. Something seems to be triggering
failsafe mode and blocking procd. If anyone knows what might have
changed or where to fix the root cause, would appreciate any
information to save time. I'll dig a little more...
Joe AE6XE
> >
At http:\\arednmesh.org, we've had several mikrotik devices working,
all with "LHG" motherboards. One of the devices, RB LHG 2nD-XL no
longer boots with upgrade from 18.06.2 to 19.07.0. Other devices with
same "LHG" mother board continue to work fine, e.g. RB LHG 5nD-XL,
LHG 5nDHP.
I'm stuck
On Sat, Dec 7, 2019 at 5:19 AM Hauke Mehrtens wrote:
>
> On 12/6/19 7:02 PM, Ben Greear wrote:
> > On 12/6/19 9:44 AM, Joe Ayers wrote:
> >>>
> >>>
> >>>> Possibly the same symptoms don't exist on 128MB RAM devices.
> >>>
> >
On Sat, Dec 7, 2019 at 5:19 AM Hauke Mehrtens wrote:
>
> On 12/6/19 7:02 PM, Ben Greear wrote:
> > On 12/6/19 9:44 AM, Joe Ayers wrote:
> >>>
> >>>
> >>>> Possibly the same symptoms don't exist on 128MB RAM devices.
> >>>
> >
>
>
> > Possibly the same symptoms don't exist on 128MB RAM devices.
>
> Like there is some if condition, which is doing some nasty things on 64M
> devices? I admit, that I don't have ath10k-ct source code under my pillow, but
> it doesn't make much sense to me.
>
> > Comparable results between
> I'm not able to reproduce it on TP-Link Archer C7 v5.
>
> > Attempting to use the hAP ac lite model RB952Ui-5ac2nD with the 5GHz
> > radio0 802.11ac seems to be unstable and consume available memory.
> > This is only enabling radio0 with no other changes and bringing wifi
> > up/down to
Attempting to use the hAP ac lite model RB952Ui-5ac2nD with the 5GHz
radio0 802.11ac seems to be unstable and consume available memory.
This is only enabling radio0 with no other changes and bringing wifi
up/down to reproduce. Am I doing something silly, or should I submit
a bug?
> > > > On nanostation-m-xw ath79 target in master and 19.07,
> > > > "/sys/devices/pci:00" does not exist. Unable to access vendor
> > > > and device IDs, and no longer reported in "iwinfo info"
> > > >
> > > > This is working on ath79 for 'nanostation-m'. I'm guessing the pcie
> > > >
> > On nanostation-m-xw ath79 target in master and 19.07,
> > "/sys/devices/pci:00" does not exist. Unable to access vendor
> > and device IDs, and no longer reported in "iwinfo info"
> >
> > This is working on ath79 for 'nanostation-m'. I'm guessing the pcie
> > entry in dts needs more
On nanostation-m-xw ath79 target in master and 19.07,
"/sys/devices/pci:00" does not exist. Unable to access vendor
and device IDs, and no longer reported in "iwinfo info"
This is working on ath79 for 'nanostation-m'. I'm guessing the pcie
entry in dts needs more definition on the
> > initialized the ackto to max:
> >
> > A) avoidance of late-ack state
> > B) not require wpa_supplicant -- not in use by our community today
> > C) Suspect some conditions, e.g. low SNR Neighbors, do not trigger
> > "late ack" (consistent, with observation of low SNR Neighbors sticking
> > at
; > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > > > > > > > > > wrote:
> > >
ar 31, 2019 at 12:15 PM Lorenzo Bianconi
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > >
> > On Sun, May 19, 2019 at 12:44:18PM -0700, Jeff Kletsky wrote:
> > I'm in the process of porting the AR750S to the ath79 target with
> > SPI-NAND support now available on Linux 4.19[1].
> >
> > From what I can tell, the AR300M (NAND) target, while it builds,
> > does not provide a
> On Sun, May 19, 2019 at 12:44:18PM -0700, Jeff Kletsky wrote:
> > I'm in the process of porting the AR750S to the ath79 target with
> > SPI-NAND support now available on Linux 4.19[1].
> >
> > From what I can tell, the AR300M (NAND) target, while it builds,
> > does not provide a functional
> I've stumbled across problems with the transmission output power of OpenWrt
> routers quite often.
> E.g. https://bugs.openwrt.org/index.php?do=details_id=1289=4
> which I still have to look into in greater detail.
> OpenWrt's handling of TX power, antenna and PA gains needs to be revised
>
19 at 6:45 AM Lorenzo Bianconi
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > bump.
> > > > > > > > >
> > > > > > >
t; > > >
> > > > > >
> > > > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > >
> > > > > >
> > > > > > bump.
> > > > >
> > > > > Hi Joe,
> > > > >
> > > > > sorry for the delay
> > > > >
> > > > > >
> > > > > > On Mon,
On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
wrote:
>
> >
> > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > wrote:
> > >
> > > >
> > > > bump.
> > >
> > > Hi Joe,
> > >
> > > s
On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
wrote:
>
> >
> > bump.
>
> Hi Joe,
>
> sorry for the delay
>
> >
> > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers wrote:
> >>
> >> Lorenzo, I have tested dynack on a (real distance apart)
Lorenzo, I have tested dynack on a (real distance apart) ~60km link
with some success. This is the code change made:
--- a/drivers/net/wireless/ath/ath9k/dynack.c
+++ b/drivers/net/wireless/ath/ath9k/dynack.c
@@ -20,8 +20,9 @@
#define COMPUTE_TO (5 * HZ)
#define LATEACK_DELAY (10 * HZ)
On Tue, Mar 5, 2019 at 8:31 AM Lorenzo Bianconi
wrote:
>
> > On Tue, Mar 5, 2019 at 1:54 AM Lorenzo Bianconi
> > wrote:
> > >
> > > > On Mon, Mar 4, 2019 at 10:31 AM Lorenzo Bianconi
> > > > wrote:
> > > > >
> > > > > > On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi
> > > > > > wrote:
> > > >
On Tue, Mar 5, 2019 at 1:54 AM Lorenzo Bianconi
wrote:
>
> > On Mon, Mar 4, 2019 at 10:31 AM Lorenzo Bianconi
> > wrote:
> > >
> > > > On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi
> > > > wrote:
> > > > >
> > > > > > Lorenzo,I've pulled out all patches related to extended ham
> > > > >
On Mon, Mar 4, 2019 at 10:31 AM Lorenzo Bianconi
wrote:
>
> > On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi
> > wrote:
> > >
> > > > Lorenzo,I've pulled out all patches related to extended ham radio
> > > > channels and ath9k is same out of openwrt 18.06.2.I replaced
> > > > wpad-mini
On Thu, Feb 28, 2019 at 1:59 AM Koen Vandeputte
wrote:
>
>
> On 27.02.19 08:13, Lorenzo Bianconi wrote:
> >>
> > What I mean is just a p2p link running in AP-STA mode, I guess there is no
> > difference for users. Am I missing something?
> >
The design of the out-of-box firmware for AREDN,
On Tue, Feb 26, 2019 at 2:04 AM Lorenzo Bianconi
wrote:
>
> >
> > On 26.02.19 06:28, Joe Ayers wrote:
> > > On Mon, Feb 25, 2019 at 8:42 AM Koen Vandeputte
> > > wrote:
> > > >
> > > > On 25.02.19 17:33, Joe Ayers wrote:
> > > >
On Mon, Feb 25, 2019 at 8:42 AM Koen Vandeputte
wrote:
>
>
> On 25.02.19 17:33, Joe Ayers wrote:
> > On Mon, Feb 25, 2019 at 1:56 AM Lorenzo Bianconi
> > wrote:
> >>> On 24.02.19 21:32, Joe Ayers wrote:
> >> Hi Joe,
> Hi Joe,
> >>>
On Mon, Feb 25, 2019 at 1:56 AM Lorenzo Bianconi
wrote:
>
> >
> > On 24.02.19 21:32, Joe Ayers wrote:
>
> Hi Joe,
>
> > > First of all, thanks for contributing this fix. I've incorporated
> > > into the http://www.arednmesh.org project, just
First of all, thanks for contributing this fix. I've incorporated
into the http://www.arednmesh.org project, just getting into our
nightly builds now. A comment and a couple questions...
The MAX_DELAY was way too short for our community, had to increase
that significantly. We commonly have
me your Tested-by so I can add
> it?
>
Tested-by: Joe Ayers
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On Thu, Dec 6, 2018 at 7:48 AM Petr Štetiar wrote:
>
> could you please retest it on your M5 and tell me if it's better now? Commit
> history of my wip/nanostation-m-xw branch should look like this now:
>
> 6db71cf WIP: ath79: Add support for Ubiquiti Nanostation M (XW)
> a947035 ath79: ag71xx:
Nanostation M5 XW testing results on ath79
>
> > [0.444718] libphy: Fixed MDIO Bus: probed
> > [0.786402] libphy: ag71xx_mdio: probed
> > [0.793193] switch0: Atheros AR8236 rev. 1 switch registered on
> > mdio-bus.0
> > [1.137115] ag71xx 1900.eth: connected to PHY at
> I've just added few more commits, so the Git history should looks like this:
>
> fb4f264 fixup! WIP: ath79: Add support for Ubiquiti Nanostation M (XW)
> 12a0c28 fixup! WIP: ath79: Add support for Ubiquiti Nanostation M (XW)
> 1c2f603 fixup! ath79: Add support for Ubiquity Bullet M (XW)
>
>> if I haven't overlooked it, the patch does not provide a "factory" Image as
>> in ar71xx, at least according to "Flashing instructions".
> if I parse this correctly, then my answer is, that I simply didn't included
> instructions for flashing of factory image as it wasn't possible at that time,
testing update for Nanostation M5 XW:
indeed this entry is needed in 02_network:
ubnt,nano-m-xw)
ucidef_add_switch "switch0" \
"0@eth0" "5:lan" "1:wan"
;;
On a laptop on the LAN, I observe frames egressing (arp requests) and
TX
> I recall that ar71xx had a hack for freezing Ethernet ports on XW
> boards. This may need to be ported also. I need to dig into the sources
> for details.
This was all due to the unique architecture by Ubiquiti with an
external chip used and not the AR93xx onchip Ethernet. In CC, the
8035
> I recall that ar71xx had a hack for freezing Ethernet ports on XW
> boards. This may need to be ported also. I need to dig into the sources
> for details.
This was all due to the unique architecture by Ubiquiti with an
external chip used and not the AR93xx onchip Ethernet. In CC, the
8035
> > root@AE6XE-NSM5XW-QTH:~# cat /etc/openwrt_version
> > r7258-5eb055306f
>
> I was asking for airOS version, so it should rather be `cat /etc/version`. I
> don't have /etc/openwrt_version in my airOS v6.1.7 system.
>
I was running openwrt 3.18.06.1 prior to tftp'ing this test image. It
> > I have a NanoStation M5 XW (and can get access to a NS M2 XW).I
> > can test. What's the reference to build and test?
>
> thanks for the help with testing, something like this could work:
>
> cd openwrt.git
> git remote add github-ynezz https://github.com/ynezz/openwrt.git
> git fetch
> For example, Nanostation is basically a Bullet with extra ethernet port,
> and
> Rocket is a Bullet with added USB port.
> >>> Ah, thanks for explanation.
> >> You're welcome
> It'd be great if support for all of them could be included in
> ar9342_ubnt_xw.dtsi, and then
> >> For example, Nanostation is basically a Bullet with extra ethernet port,
> >> and
> >> Rocket is a Bullet with added USB port.
> > Ah, thanks for explanation.
> You're welcome
> >
> >> It'd be great if support for all of them could be included in
> >> ar9342_ubnt_xw.dtsi, and then secondary
I better clarify. the polarization planes would be 60deg apart.
The vertical antennas would be physically mounted 120deg apart like a
3 blade airplane propeller.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Ditto on channel width, max rate is cut in half with cutting channel
width in half. How do you have the antennas oriented? If all are in
the same plane or polarization, then attempting to transmit different
data on the antennas will directly compete and interfere with all the
signals on the same
From: Joe Ayers <ae6xe@arrl. <ae...@aredn.org>net>
Fixes 19085 nanostation m5 loco xw loses interface
Signed-off-by: Joe Ayers<ae6xe@a <ae...@aredn.org>rrl.net>
Signed-off-by: Trevor Paskett <k7...@aredn.org>
Signed-off-by: Darryl Quinn<k5...@ared
53 matches
Mail list logo
