Hi,
Well, this was my bad )) I accidentally chose cpu's gpio and realised
that this is a mistake yesterday night.
So I made a patch for atheros driver and it works. A signal level on
different frequencies is more or less equal and seems adequate (about
-30 dbm if a client within a meter
Hi Kirill,
Updated version is in the attachment. I tried it on a real device, but I
can't say that the problem was solved, but something is definitely happens.
which OpenWrt image did you use? I flashed openwrt-15.05-rc1-ar71xx-generic-
ubnt-unifi-outdoor-plus-squashfs-factory.bin and did not
Hi,
It seems that ath9k does not even export its pins to the GPIO
subsystem.
ok, here we go. For the brave ones who know their pci wifi chip is at
0x1000 and don't mind bit banging io registers.
Surely still all usleep() timers wrong and full of unknown side effects.
But tunes the hsr
Hi,
Updated version is in the attachment. I tried it on a real device, but I
can't say that the problem was solved, but something is definitely happens.
related question: After installing OpenWRT on the access point, do you know
whether I can revert using the instructions from:
You can revert back to UniFi via TFTP,
I haven't been able to get the reset button on boot to work for UniFi.
I use UART to pull up the boot-loader. Then use urescue to tftp the
UniFi image back on.
-- Davey
On Fri, May 22, 2015 at 1:41 PM, Stefan Rompf ste...@loplof.de wrote:
Hi,
Updated
Hi,
Updated version is in the attachment. I tried it on a real device, but I
can't say that the problem was solved, but something is definitely happens.
Unfortunately I couldn't find where a bunch of zeros were generated, so
I skipped this part ))) (I tried a version with zeros, but no
Hi Kirill,
Updated version is in the attachment. I tried it on a real device, but I
can't say that the problem was solved, but something is definitely happens.
Unfortunately I couldn't find where a bunch of zeros were generated, so
I skipped this part ))) (I tried a version with zeros, but
Hi Kirill,
On Dienstag, 19. Mai 2015 15:11:31 Kirill Berezin wrote:
I think that they tune an external receiver via some sort of SPI bus (GPIO
pins are 5,6,7,8). Write procedure is quite simple, but I can't still get
how enable works (for sure it sends a disable); it is quite possible that
Hi,
-Trapping ar5416GpioSet with some hand crafted assembly code that traces
calls and logs them somewhere
this works. I've trapped ar5416GpioSet, putting my code into space occupied by
the unused function ar5416GpioCfgInput. ar5416GpioGet is work to do. I can
send the code, but it will
Hello,
I succeed to recover a disable command (I followed tips from the
Stefan's post).
A simple user space configuration utility is in the attachment. Compile
it then run the following before a setup of an interface
./hsr 98
What'll be available : scan shows channels 1 and 11; clients on
Hi Matthias,
Any news here? I know a lot of people who are eager to run OpenWrt on
their UAP Outdoor+ ...
oh well so nearly two months have passed
I must admit no news. I am/was planning to run the code in ARMSim to analyze
what is sent to the filter and from where.
Still want to do
On 03/21/2015 10:16 AM, Stefan Rompf wrote:
Hi Sergey,
You should be a wizard to reveal hw protocol without touching hw :)
I cannot say 'Mischief managed!' by now, but it's slowly making progress ;-)
Unlikely that iwconfig changes something directly, I would bet on the
driver.
Hi Sergey,
You should be a wizard to reveal hw protocol without touching hw :)
I cannot say 'Mischief managed!' by now, but it's slowly making progress ;-)
Unlikely that iwconfig changes something directly, I would bet on the
driver.
Indeed. So far
-The RF filter is controlled by the GPIO
2015-03-21 12:16 GMT+03:00 Stefan Rompf ste...@loplof.de:
-The RF filter is controlled by the GPIO pins on the AR928x wifi chip via some
kind of serial protocol.
-The functions responsible for the filter are ath_hal_hsr_init(), called once
on initialisation, ath_hal_hsr_disable() and
On Dienstag, 17. März 2015 23:24:26 Sergey Ryazanov wrote:
Interesting enough: When stopping all wifi related software on the device
and creating a monitor interface, the RF filter seems to follow
iwconfig channel commands (yes it is the madwifi driver).
How do you realized that RF
2015-03-17 23:15 GMT+03:00 Stefan Rompf ste...@loplof.de:
Possibly, you could see some changes during change. Try check GPIO
pins with oscillograph during channel change.
Unfortunately opening the case is not an option.
You should be a wizard to reveal hw protocol without touching hw :)
Or
Hi Sergey,
If they built SPIoverGPIO or I2CoverGPIO or some other serial bus over
GPIO, then you do not see any changes between channel switches. Or
they could use some non GPIO interface to communicate with external
filter (embedded SPI, I2C or even USB or PCI of SoC).
well, GPIO has been
Hi,
On Mittwoch, 11. März 2015 15:14:21 Shvedov Yury wrote:
Thank you for your answer. We will try to solve this issue with our own
forces.
any progress on this? I have one of these access points available right now
for hacking (as long as I do not brick it). The last hours I made those
Hello Stefan,
2015-03-16 23:36 GMT+03:00 Stefan Rompf ste...@loplof.de:
However, independant of the channel selected the ports are always set to
0x00081405 (or 0x00081404 or 0x00081406 depending on the LED setting):
BZ.v3.2.7# /tmp/io -4 -r 0x18040004
18040004: 00081405
If anyone has
Hello,
It's probably driven by a GPIO on the radio itself. Possibly monitor
/sys/kernel/debug/ieee80211/phy[0-9]/ath9k/regidx and
/sys/kernel/debug/ieee80211/phy[0-9]/ath9k/regval. Perhaps someone
with a datasheet might be able to tell you which register(s) it
*could* be tied to, then take
No, unfortunately, the WLAN problem still exists.
My patch made OpenWrt generate images which can be flashed the usual way
from the stock firmware. In addition, it added support to the OpenWrt
kernel and userspace, so that
- the device is identified correctly in /proc/cpuinfo and /tmp/sysinfo
-
Hi,
does your patch fix this problem:
https://lists.openwrt.org/pipermail/openwrt-devel/2014-September/028103.html
?
As I checked, it doesn't, so what exactly your patch do? Does it only
make the leds to work properly?
Kind regards
Yury Shvedov
On 12/30/2014 06:01 AM, Matthias Schiffer
Thank you for your answer. We will try to solve this issue with our own
forces.
Kind regards
Yury Shvedov
On 03/11/2015 01:46 PM, Matthias Schiffer wrote:
No, unfortunately, the WLAN problem still exists.
My patch made OpenWrt generate images which can be flashed the usual way
from the stock
On 30/12/2014 06:01, Matthias Schiffer wrote:
I had read the mails regarding the issue and I've asked about it
in #openwrt-devel (but didn't get an answer yet). I didn't try
changing the channel though as I'm in a very noisy environment
(WLAN-wise) at the moment, so I can't really do any
Signed-off-by: Matthias Schiffer mschif...@universe-factory.net
---
target/linux/ar71xx/base-files/etc/diag.sh | 3 ++
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 ++
.../ar71xx/base-files/lib/upgrade/platform.sh | 2 +
target/linux/ar71xx/image/Makefile
Does the new kernel / ath9k address the RF Filter on this board? I
came up with an old patch for this board, but whenever I changed the
channel inside OpenWRT the signal would just disappear. The RF Filter
has to be toggled somehow ( I assume it's a GPIO of some sort ). I am
just curious on how it
I had read the mails regarding the issue and I've asked about it in
#openwrt-devel (but didn't get an answer yet). I didn't try changing the
channel though as I'm in a very noisy environment (WLAN-wise) at the
moment, so I can't really do any proper testing.
If it's only a GPIO issue, I could
27 matches
Mail list logo
