Hello Davey,
I haven't gotten a chance to mess with one of these yet due to
availability, but I placed a copy of the binary image for the AP on my
web-server for you. This came from a 4.7.5 install.
https://jonbither.com/unifi/firmware/U7PG2/3.4.7.3284/firmware.bin
According to the bundles fi
May be the completely wrong idea, but what if there was an
OpenWRT-Kernel GIT repository holding the branches and modifications
required for each arch. Would allow easy updates and backports from a
Trunk branch to an LTS one.
On 04/03/2013 12:31 PM, Bruno Wolff III wrote:
On Wed, Apr 03, 2013
On 04/03/2013 01:44 PM, Nick Podolak wrote:
On Wed, Apr 3, 2013 at 12:36 PM, Jonathan Bither mailto:jonbit...@gmail.com>> wrote:
May be the completely wrong idea, but what if there was an
OpenWRT-Kernel GIT repository holding the branches and modifications
required for eac
Adhoc is configured by the 'iw' utility in the mac80211.sh script.
On Tue 07 May 2013 09:10:11 AM EDT, Francisco Cuesta wrote:
Thanks Felix for clarifying my newbie doubts!!
Secondly, could someone point me out where in hostapd code is
distinguished between adhoc mode and ap mode?
Easy: AP mo
On 06/11/2013 03:34 PM, Ben West wrote:
Quoting from the supported hardware list, and likewise from the Attitude
Adjustment announcement made earlier this year:
"Note that with the release of 'Attitude Adjustment (12.09 final)' on
25th April 2013, 'Lower end devices with only 16 MiB RAM will e
Signed-off-by: Jonathan Bither
---
.../linux/generic/files/drivers/net/phy/rtl8366_smi.c | 2 +-
target/linux/generic/patches-3.10/863-gpiommc.patch| 18 +-
.../patches-3.10/864-gpiommc_configfs_locking.patch| 2 +-
target/linux/generic/patches-3.3/863-gpiommc.patch
On 10/24/2013 01:59 PM, Ben West wrote:
Hello,
The wiki page for wireless settings appears to indicate that the "frag"
setting (fragmentation threshold) is only understood by the madwifi driver:
http://wiki.openwrt.org/doc/uci/wireless#madwifi.options1
However, setting this option does seem to
Nico,
I too have been interested in experimenting with TDMA. When I looked a
while ago the most helpful information that I saw was that TDMA support
is apparently included in freebsd. You may want to take a look at how it
is implemented over there.
http://fxr.watson.org/fxr/source/net80211/i
Perhaps you can configure squid in such a way to allow only the login
forms? That way you could setup iptables transparently to squid.
On 08/06/2012 04:26 AM, Nguyễn Hồng Quân wrote:
Doing so means that we have to have something to trigger the re-openess.
This may makes the communication with
This sounds like an awesome idea. This would also allow for all ubiquiti
equipment that has signal leds no?
On 08/08/2012 08:55 AM, Daniel Golle wrote:
ar71xx: uci-defaults/leds for ALL0258N
Signed-off-by: Daniel Golle
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/leds
b/targ
When I rebuilt the other day my ar2315 would not boot due to jffs2 errors. I
haven't checked to see if it was something in my tree, but just thought i'd let
you know. I can rebuilt with a clean true today and watch serial to see if the
issue persists.
On 08/24/2012 01:02 PM, Ben West wrote:
>
I can confirm that this issue effects EnGenius ECB-3500 as well.
On 08/27/2012 09:24 AM, Karl Palsson wrote:
>
> I think this really just means that the Atheros platform needs to be broken
> up into separate boards,
> like ar71xx and other newer platforms. Currently a Atheros targets get
>
On 10/25/2012 09:31 PM, Stefan Helmert wrote:
From Stefan Helmert
It is mostly the same as wr841nd. WLAN and LAN are working. LAN-Led
ist working. WLAN signal strength Leds are not working yet.
I imagine that you can actually get the signal leds operating correctly
if you add the configuratio
greater detail.
https://dev.openwrt.org/browser/trunk/package/rssileds/src/rssileds.c?rev=33163
Am 26.10.2012 15:40, schrieb Jonathan Bither:
I imagine that you can actually get the signal leds operating
correctly if you add the configuration for the package rssileds. When
I get time I wanted to
do you have the boot log of OpenWRT loading
on this device?
Am 26.10.2012 16:06, schrieb Jonathan Bither:
On 10/26/2012 09:49 AM, Stefan Helmert wrote:
I hope this will work. You should know, the leds on ubiquity devices
are connected to the ar7240 main-controller. On TL-WA7510N they are
ver for maximum performance.
Add gpio detection mechanisms to address EnGenius products cleanly.
Any feedback is greatly appreciated.
Thanks,
Jonathan Bither
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/m
Thanks,
I'll setup my git environment again and merge them all into branches
and split the patches.
On 11/09/2012 07:22 AM, John Crispin wrote:
> On 09/11/12 13:16, Karl Palsson wrote:
>> On Fri, Nov 09, 2012 at 06:11:47AM -0500, Jonathan Bither wrote:
>>> Good
I use this feature often. I'll try to test this today and ack it if it
works for me.
On 10/16/2012 05:30 PM, Zenon Mousmoulas wrote:
This is based on the patches submitted by Matthew Bowman:
http://patchwork.openwrt.org/patch/1258/
http://patchwork.openwrt.org/patch/1261/
More recently hostapd
Confirmed operation today.
Acked-by: Jonathan Bither
On 11/13/2012 09:14 AM, Jonathan Bither wrote:
I use this feature often. I'll try to test this today and ack it if it
works for me.
On 10/16/2012 05:30 PM, Zenon Mousmoulas wrote:
This is based on the patches submitted by Matthew B
It causes flash access errors on devices that use a non-standard gpio
line line to control the spi flash chip select.
First resolved in changeset # 16765
Signed-off-by: Jonathan Bither
---
target/linux/atheros/base-files/etc/uci-defaults/leds | 11 ---
target/linux/atheros/config
This also effects attitude adjustment, preventing many devices from booting.
http://pastebin.com/EHCr6iZ9
On 11/20/2012 03:21 PM, Jonathan Bither wrote:
It causes flash access errors on devices that use a non-standard gpio
line line to control the spi flash chip select.
First resolved in
Please disregard. Did not fix the issue. Fixing properly now.
On 11/20/2012 03:21 PM, Jonathan Bither wrote:
It causes flash access errors on devices that use a non-standard gpio
line line to control the spi flash chip select.
First resolved in changeset # 16765
Signed-off-by: Jonathan Bither
v2: explicitly unset CONFIG_LEDS_GPIO
It causes flash access errors on devices that use a non-standard gpio
line line to control the spi flash chip select. Fixes a handful of open
tickets.
First resolved in changeset # 16765
Signed-off-by: Jonathan Bither
---
target/linux/atheros/base
additional patches that fix the intended behavior. Care to
share the model of your device so that I may get one in to work with?
Thanks,
Jonathan Bither
On 11/21/2012 05:02 PM, Karl P wrote:
I'm still against reverting. What's really needed here is support for
different atheros devices
planning on doing more work to clean this up, then sure, go
ahead, but in that case, can it all go in together? Does it have to go
in part now, and part later?
Cheers,
Karl Palsson
On 11/21/2012 10:29 PM, Jonathan Bither wrote:
Karl,
I remember attitude adjustment not booting as well wi
On 12/13/2012 10:05 AM, Johannes Reichhardt wrote:
Hi,
I'm a noob to openwrt and I can't get Automatic Channel Selection to run.
I'm working with this patch.
http://mirror.sit.wisc.edu/pub/linux/kernel/people/mcgrof/patches/hostapd/acs-all-in-one-v7.patch
From reading some mail-lists and on boar
onathan,
Thanx that you'll forward the last state to me :)
Yeah after I sent the mail I found the v8 of the patch. But it's also
not working.
Do you know in which hostapd version the v8 patch worked last?
Cheers
Johannes
From: Jonathan Bither mailto:jonbit...@gmail.com>>
Rep
Hello Nguyen,
Would you be able to provide me with a 'dmesg' prior to starting wifi?
On 12/14/2012 03:46 AM, Nguyễn Hồng Quân wrote:
Hello,
I'm building OpenWrt for Fonera router (FON2100) (Atheros target).
By default, Wifi is off. But when I turn on the Wifi, OpenWrt freezes.
There is
Felix,
Thanks for this, there was actually a discussion about this yesterday
on linux-wireless, and as such I cc'd the included individuals on the
reply (Hope no one minds). I will be testing this on my local branches
today and I will report my findings. Would you be interested in sending
thi
athan,
Here is my dmesg output before I enable wifi
On Fri 14 Dec 2012 09:07:57 PM ICT, Jonathan Bither wrote:
Hello Nguyen,
Would you be able to provide me with a 'dmesg' prior to starting
wifi?
On 12/14/2012 03:46 AM, Nguyễn Hồng Quân wrote:
Hello,
I'm building OpenW
Bastian,
I currently use these settings on all of my devices as well. Perhaps
the simplest way to apply these values without having to modify each
target/sub-target is to put a patch under
'target/linux/generic/patches-*' for the kernel that sets these values
to defaults within the kernel.
Hauke,
I tested this patch today and just wanted to give some feedback. The
patch applies cleanly and installs everything correctly, however it does
not activate the swap on boot up. Executing '/etc/init.d/zram start'
successfully starts. There is also a uci error when starting when the
'zram
On 02/13/2013 06:41 AM, Aleksander Morgado wrote:
I'm trying to prepare an update of udev/libudev to latest upstream. As
you may already know, udev/libudev sources are now within systemd. I'm
not fully sure how to handle this issue; so I'm hoping to get some
advice here. Comments welcome!
On 02/13/2013 09:39 AM, Aleksander Morgado wrote:
I'm trying to prepare an update of udev/libudev to latest upstream. As
you may already know, udev/libudev sources are now within systemd. I'm
not fully sure how to handle this issue; so I'm hoping to get some
advice here. Comments welcome!
W
This patch allows the ar231x ethernet driver to be controlled from the
userspace "ethtool". I have tested this with ar2315 and ar5312.
Hopefully this sends right, it's my first submission :-p
Signed-off-by: Jonathan Bither
Index: target/linux/atheros/patches-2.6.37/221
Attached is a patch for trunk which fixes gpio assignments for EnGenius
devies on the ar231x platform. This patch fixes rebooting as well the
reset button for the following devices:
ECB-3500, EAP-3660, EOA-3630, EOC-2611P, EOC-1650, EOC-5611P
Signed-off-by: Jonathan Bither
On a side note would the unaligned patch in the ar71xx target benefit
the atheros target?
On 01/04/2012 10:58 AM, Markus Stockhausen wrote:
Hello,
attached an extension to the already existing patch that will fix some
more unaligned
accesses on ar71xx devices. First patch location during estab
That's a pretty neat example and idea behind it. Perhaps it would be
beneficial to apply the same concept to the mac80211 stack that once
loaded would expose /dev/iwrandom?
Jonathan,
On 01/12/2012 12:07 PM, g@free.fr wrote:
- Mail original -
De: "Roman Yeryomin"
À: "Florian Fai
Why not add a pre-init hook?
On 01/17/2012 02:02 PM, Pawel Pastuszak wrote:
Ok, but i am looking for it to go into the foreground and i want to lock
the console access till it finished running it then reboot.
Pawel
On Tue, Jan 17, 2012 at 1:52 PM, Luka Perkov mailto:open...@lukaperkov.net>> wr
r that then i think pre-init would solve
my issue.
Pawel
On Tue, Jan 17, 2012 at 2:05 PM, Jonathan Bither mailto:jonbit...@gmail.com>> wrote:
Why not add a pre-init hook?
On 01/17/2012 02:02 PM, Pawel Pastuszak wrote:
Ok, but i am looking for it to go into the foreground an
an you confirm your patch works with EOC-2611P?
>
> Thanks very much in advance for your input.
>
> Hanno
>
> -Original Message-
> From: openwrt-devel-boun...@lists.openwrt.org
> [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Jonathan
> Bith
I have a couple alix's in the office I can play with to try to help.
On 02/10/2012 06:11 PM, Philip Prindeville wrote:
> Sysupgrade currently doesn't allow updating software in place without
> clobbering the existing config (stored on the ext4 overlay filesystem that
> immediately follows the jf
Philip,
I would love to try to help you. Would you be able to catch me up on
what you have tried or the configuration that you are using so I can
have a starting point?
On 02/20/2012 04:09 AM, Philip Prindeville wrote:
Ok, I'll put $500 USD of my own money toward the sysupgrade port to x86 if
Hanno,
Do we happen to have a list of known issues so that we can work on
getting them resolved instead of reverting back to mac80211?
On 02/27/2012 03:15 PM, Hanno Schupp wrote:
I am not a developer, but I can tell you the ath9k is for b/g/n cards,
so that may be the reason. You should use ei
If you wanted immediate relief you could also just select the right
driver for your card ;-). Ath5k is the replacement for Madwifi. By
selecting ath5k in trunk your radios should operate fine.
On 02/27/2012 04:08 PM, Brian Hutchinson wrote:
So if I want immediate relief from this, I should dr
Have you tried submitting this to linux-wireless?
On 03/02/2012 11:52 AM, Yeoh Chun-Yeow wrote:
Hi, all
This is mainly for ath5k.
Regards,
Chun-Yeow
On Sat, Mar 3, 2012 at 12:50 AM, Yeoh Chun-Yeow mailto:yeohchuny...@gmail.com>> wrote:
This patch allows the possibility of having the mesh
With our recent switch to the 3.3 kernel target, some headers were
occidentally omitted.
Signed-off-by: Jonathan Bither
--- a/target/linux/atheros/patches-3.3/100-board.patch
+++ b/target/linux/atheros/patches-3.3/100-board.patch
@@ -2884,10 +2884,13 @@
+#endif
--- /dev/null
+++ b/arch
47 matches
Mail list logo
