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
Signed-off-by: Jonathan Bither jonbit...@gmail.com
---
.../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
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
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
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,
On 04/03/2013 01:44 PM, Nick Podolak wrote:
On Wed, Apr 3, 2013 at 12:36 PM, Jonathan Bither jonbit...@gmail.com
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
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
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.
,
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 OpenWrt for Fonera router
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
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
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 jonbit...@gmail.com mailto:jonbit...@gmail.com
Reply-To: OpenWrt
, 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 with flash
errors,
however I can try to rebuild an older
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 jonbit...@gmail.com
---
target
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, not just
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 jonbit...@gmail.com
---
target/linux/atheros/base-files/etc/uci-defaults/leds | 11 ---
target
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
Confirmed operation today.
Acked-by: Jonathan Bitherjonbit...@gmail.com
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
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
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/mailman/listinfo
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 morning list,
I was writing
On 10/25/2012 09:31 PM, Stefan Helmert wrote:
From Stefan Helmert helst_lis...@aol.de
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
.
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 the same
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
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
the
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:
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.
With our recent switch to the 3.3 kernel target, some headers were
occidentally omitted.
Signed-off-by: Jonathan Bither jonbit...@gmail.com
--- 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
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 yeohchuny...@gmail.com
mailto:yeohchuny...@gmail.com wrote:
This patch allows the
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
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
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
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
Message-
From: openwrt-devel-boun...@lists.openwrt.org
[mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Jonathan
Bither
Sent: Friday, 23 December 2011 9:32 a.m.
To: openwrt-devel@lists.openwrt.org
Subject: [OpenWrt-Devel] [PATCH] Add EnGenius ar231x support
Attached
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 open...@lukaperkov.net
pre-init would solve
my issue.
Pawel
On Tue, Jan 17, 2012 at 2:05 PM, Jonathan Bither jonbit...@gmail.com
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 and i
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
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
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
41 matches
Mail list logo
