I just compiled trunk for both a WRT160NL and a DIR825 and the
wireless behavior as sta(psk) is completely different.
DIR825 works flawlessly, with throughput of several MB/s.
WRT160NL works in "chunks", which makes it almost unusable.
64 bytes from 8.8.8.8: seq=30 ttl=53 time=1928.917 ms
64 byte
Luci allows configuring an interface as 80211s. However, there doesn't
seem to be any way to configure the mesh_id. The ssid in "Interface
Configuration" is set as "option ssid" in /etc/config/wireless,
but /lib/wifi/mac80211.sh uses "option mesh_id" to set the mesh_id.
Is this a Luci problem or s
On 1/20/11 12:29 AM, Claudio wrote:
2011/1/20 Philip Prindeville:
Add support for PPPoE, PPPoX, and RFC-1483 bridging/routing over AAL5.
Only thing missing is kmod-crypto-ocf, but that requires
CONFIG_OPENSSL_ENGINE=y (which can't be automatically set from within a
target)
are you sure that cr
I don't think, that having two base-files packages is the right way.
Maintaining is too expensive, just for the same stuff.
I like the idea to modularize functional expressions.
There are some lines of code (specially regEx), which are definitely only
readable by a professional.
If this is encaps
> your are right. the question is:
> original:
> sed -ne 's![^0-9].*$!!p' /proc/uptime
> patch:
> cut -d'.' -f1 /proc/uptime
Both are equally fine with me. The IFS version you sent earlier falls
in my "ugly code" category, OTOH.
> patch-2:
> uptime_in_seconds()
> {
> cut -d'.' -f1 /pro
Selon Bastian Bittorf :
> > for micro images usually busybox is used and awk/sed are available
> > busybox applets. i really doubt that the size increase is in
> > proportion to the rework (including bugfixing) the already working
> > code.
>
> think future: do we ever rely on busybox?
> maybe som
On 20.01.2011 13:40, John Crispin wrote:
>> > without having stomach ache, when base breaks.
> i dont get the "when base breaks" bit
he means in case the modifications (in the 'alternative' base package)
introduce a show stopping bug.
..ede
___
openwrt
Great. I have been waiting for that. How about the USB OTG? When will it
be available and supported in ramips?
-Vincent
On Thu, Jan 20, 2011 at 5:48 PM, John Crispin wrote:
> On 20/01/11 10:44, Daniel Golle wrote:
> > Good to hear that.
> >
> > dwc_otg is making progress as well [1], hopeful
On 2011-01-20 2:01 PM, Bastian Bittorf wrote:
>> > - e.g. trying to abondon ifconfig/route/arp by using ip
>>
>> i doubt that owrt will ever switch to using ip, at least not in
>> its
>> current state.
>
> but it's really a pity, that a _network_ distro uses
> an 25+ years old concept 8-). openwr
I want to debug snmpd service, I have Backfire 10.03 and kernel 2.6.30.10
and gdb 6.8.
but when i attach by gdb to snmpd service, it not find symbols. But, i guess
it should be, because configuration of gcc has 'all' flag.
So, what is the reason ? some options of kernel may be?
Best Regards, Egor
On Thu, Jan 20, 2011 at 12:34, Bastian Bittorf wrote:
>> But how many space is safe if busybox is compiled without sed and
>> awk?
>
> 485.928 bytes original
> 451.976 bytes without sed+awk
I think this is not a strong possibility because a LOT of packages
will depend on sed and awk.
> - e.g. tr
How about this patch?
I updated it, since Image/mkfs/cpiogz is also missing the Image/Build
call.
Thanks,
Maarten
On Mon, 2010-12-06 at 13:24 +0100, Maarten Bezemer wrote:
> All Image/mkfs/... macros call the Image/Build except for
> Image/mkfs/targz.
>
> This patch adds the Image/Build call f
> for micro images usually busybox is used and awk/sed are available
> busybox applets. i really doubt that the size increase is in
> proportion to the rework (including bugfixing) the already working
> code.
think future: do we ever rely on busybox?
maybe some users use e.g. toybox[1] later?
bye
> > - e.g. trying to abondon ifconfig/route/arp by using ip
>
> i doubt that owrt will ever switch to using ip, at least not in
> its
> current state.
but it's really a pity, that a _network_ distro uses
an 25+ years old concept 8-). openwrt can only use
ip, if we change a lot in base-files...
>
Hi
>>> [ ] base-files standard
>>> [ ] base-files mini (no sed/awk, experimental)
>>
>> But how many space is safe if busybox is compiled without sed and
>> awk?
>
> 485.928 bytes original
> 451.976 bytes without sed+awk
that is 5k once lzma compressed it for squashfs so the size argument can
b
> > [ ] base-files standard
> > [ ] base-files mini (no sed/awk, experimental)
>
> But how many space is safe if busybox is compiled without sed and
> awk?
485.928 bytes original
451.976 bytes without sed+awk
but thats not only the point. if we have a selectable
experimental base-files package,
Please note the files
target/linux/adm8668/files/arch/mips/include/asm/mach-adm8668/bsp_sup.h
and target/linux/adm8668/files/arch/mips/include/asm/mach-adm8668/prom.h
are removed completely.
I was unsure if running this patch would just make empty files..
On 1/19/11, Scott Nicholas wrote:
> This
This patch cleans up the include directory, as they were from vendors
2.4 GPL source. Now only what's used is there.
Signed-off-by: Scott Nicholas
Index: target/linux/adm8668/files/arch/mips/include/asm/mach-adm8668/bsp_sup.h
===
--
2011/1/20 Bastian Bittorf :
> I will stop sending patches like this, because i see that
> many people have stomachache with these, but i propose
> for menuconfig a selection like this:
>
> [ ] base-files standard
> [ ] base-files mini (no sed/awk, experimental)
>
But how many space is safe if busy
On Wed, Jan 19, 2011 at 18:17, Mark Vels wrote:
> This patch is not an improvement. It should be rejected.
If it runs faster it is an improvement. You can also say that if it is
larger it is not an improvement, so how many bytes are we talking
about?
The only argument could be: "the speed-up is n
On 20.01.2011 06:50, Scott Nicholas wrote:
> I like Bastian's refactorings using only ash builtins. if ever a micro
> image is needed, sed/awk can go away. yes?
for micro images usually busybox is used and awk/sed are available busybox
applets. i really doubt that the size increase is in proport
Hi all,
I like the readability of this patch, clear function names, good structure !
Lowers the entry threshold of reading the code for me.
The option of an additional sh-only-basefile package sounds like I good
compromise.
As I can see, Bastian opts as a maintainer already ;)
H2o
ps: form the
On Sun, Jan 16, 2011 at 6:00 PM, Stefan Monnier
wrote:
>>> As an outsider, I'd just like to say that I find this new code more
>>> complex for very little benefit.
>
>> really? more lines maybe, but straightforward and not hacky.
>
> I guess it's a question of taste, but to me that current code is
On 20/01/11 10:44, Daniel Golle wrote:
> Good to hear that.
>
> dwc_otg is making progress as well [1], hopefully it's synthezised form
> in PPC 405 EX doesn't differ too much from the one found on octeon and
> ramips stuff. licensing issues have seemingly been resolved and so only
> the SoC glue
Good to hear that.
dwc_otg is making progress as well [1], hopefully it's synthezised form
in PPC 405 EX doesn't differ too much from the one found on octeon and
ramips stuff. licensing issues have seemingly been resolved and so only
the SoC glue is missing now...
Cheers
Daniel
[1]
http://www.p
> if
> you, in 1, 6, 12 months, still forward port all the changes and
> fixes
> done in base-files to base-files-mini ?!
of course i can maintain my "private" branch
personally, but I really think I'am not alone.
If we have it in openwrt-git, everybody can use the code.
If we really recognize, t
>> Yes ! :)
>
> Very detailed plan :P
exactly, there is only the intention, we made no specific plans yet, as
gabor was busy with the ath79 push and i am busy with the lantiq push
>
> The main reason I ask is because the SoC specific parts of rt2x00 are quite
> good already (on rt305x at leas
Am Donnerstag, 20. Januar 2011 schrieb John Crispin:
> On 20/01/11 10:15, Helmut Schaa wrote:
> > Hi,
> >
> > are there any plans yet to merge the ramips stuff into mainline?
> >
> > Thanks,
> > Helmut
> > ___
> > openwrt-devel mailing list
> > openwrt-
On 20/01/11 10:15, Helmut Schaa wrote:
> Hi,
>
> are there any plans yet to merge the ramips stuff into mainline?
>
> Thanks,
> Helmut
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/open
Hi,
are there any plans yet to merge the ramips stuff into mainline?
Thanks,
Helmut
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On 20/01/11 10:06, Bastian Bittorf wrote:
it is always a bad idea to mix up different languages
in one environment.
>>
>> I don't accept this is a valid starting point. I agree that it is
>> useful to limit the number of tools/languages you use, but you
>> should
>> still try and use the
> >> it is always a bad idea to mix up different languages
> >> in one environment.
>
> I don't accept this is a valid starting point. I agree that it is
> useful to limit the number of tools/languages you use, but you
> should
> still try and use the right tool/language for the right job.
your
2011/1/20 Philip Prindeville :
> Add support for PPPoE, PPPoX, and RFC-1483 bridging/routing over AAL5.
>
> Only thing missing is kmod-crypto-ocf, but that requires
> CONFIG_OPENSSL_ENGINE=y (which can't be automatically set from within a
> target)
are you sure that creating a config-default with
my-mkimage previously did not include the fs_mark of deadc0de because
upon formatting of jffs2 partition, U-Boot's CRC validation would not
allow the image to boot. This new MTD map will shrink the
kernel+rootfs+fs_mark image and recalculate the CRC, so that only the
kernel is part of the image val
attach patch base on "Last Changed Rev: 25033",
this patch fixed below error:
/home/xiangfu/workspace/PanGu/openwrt-xburst/staging_dir/toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/lib/gcc/mipsel-openwrt-linux-uclibc/4.3.3/../../../../mipsel-openwrt-linux-uclibc/bin/ld:
warning: libintl.so.8
35 matches
Mail list logo
