anyone here on the starlink beta? How's the bloat? other features?

2021-01-02 Thread Dave Taht
I figure that getting the starlink terminal working at all
was a greater challenge than tackling the bufferbloat issue. I've long
worried of
course, that the mac layer on this thing was going to be very weird,
and since they were working with qca they'd end up burying everything
in the network offload processors, even though at present speeds the
cpu they are using is *loafing*, I'm not as optimistic as jon morton is as to
how easy the port of cake or fq_codel would be to their hardware as it
is variable bandwidth and thus needs bql-like backpressure.

Since there doesn't seem to be a gpl drop yet I don't know a lot more,
however there was a teardown of the hw and jim's posting and a start
at testing on reddit - the dslreports test was flawed in that ping did
not work at all

https://www.reddit.com/r/Starlink/comments/k0dwon/starlink_and_bufferbloat_testing/

rate limiting with sqm works beautifully:

https://www.reddit.com/r/Starlink/comments/jxkef9/ahat_is_your_starlinks_bufferbloat_score/

and the starlink teardown was good:
https://www.reddit.com/r/hardware/comments/kchxl8/starlink_teardown_and_analysis/

So I  think that this hardware actually has fq_codel AND hw rate limiting
in it... and openwrt... But pure either algo is not the right thing
for a starlink up or downlink
which is variable rate.

It would of course be great if somehow we could get loud enough for
musk to tweet back or hire a few of us to help 'em get it right I
had a friend of mine send him a suitably inscribed copy of toke's
"bufferbloat and beyond" via interoffice mail... :) but finding someone
up there more focused on the terminal software itself would be better.
I mean low latency should be their bread and butter and while Im sad
that the early tests are dismal, I am pretty confident that ultimately
they will get it right.

Me, well, I live on a sailboat these days, and would really like
to be using this service. And making it
way better, and adding cool features to the product.
-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

d...@taht.net  CTO, TekLibre, LLC Tel: 1-831-435-0729

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] fq_codel and sch_cake improvements for openwrt

2019-04-01 Thread Dave Taht


I have been busy on other stuff than embedded routing for quite some
time, but I'd like to start folding in some new stuff into openwrt
related to fq_codel starting in the next week or so (I am currently in
prague, heading to berlin next week) - with some new code that looks
quite promising in the out of tree

https://github.com/dtaht/fq_codel_fast
and
https://github.com/dtaht/sch_cake repos.

repos, related to the new SCE concept, that we spoke about also, at
ietf. Some background on that here:

https://lwn.net/SubscriberLink/783673/0e7d178ea322e386/

Anybody got any time to hang with me next week? Is it too late for the freeze?

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] OpenWrt and HOMENET talk at IETF recording

2019-04-01 Thread Dave Taht


Is now up here:

https://www.youtube.com/watch?v=y-7G2ItPwco=5m55

I was unaware of how far behind homenet had fallen on the openwrt
integration front until ted talked to me... and I then "threatened to
help". :P

The outline of all that remains in homenet left to do is in his talk.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] EU feedback on "Upload of software on radio equipment"

2019-03-07 Thread Dave Taht
Eric Luehrsen  writes:

> On 3/4/19 6:35 PM, Hauke Mehrtens wrote:
>> Hi,
>>
>> The European commission asked for feedback on the Radio Equipment
>> Directive (RED) regarding the restrictions on "Upload of software on
>> radio equipment"
>>
>> I posted here a comment in the name of the OpenWrt project:
>> https://ec.europa.eu/info/law/better-regulation/initiatives/ares-2018-6621038/feedback/F240894_en?p_id=380919
>> The deadline for comments was 4. March.
>>
>> Thank you for the help and also the others who posted feedback to the
>> European commission.
>>
>> More details can be found here:
>> https://fsfe.org/activities/radiodirective/
>>
>> Hauke
>
> Historical Reference
>
> US FCC attempted a similar thing a few years ago and it received some
> backlash. They chose to revise the interpretation instructions for
> the rule. Although a regulation (FCC rule) is flexible and less
> worrisome. Bad legislation can hang around for a long time.
>
> FCC NPRM:
> https://docs.fcc.gov/public/attachments/FCC-15-92A1.pdf
> FCC Informal News:
> https://www.fcc.gov/news-events/blog/2015/11/12/clearing-air-wi-fi-software-updates
> FCC Revised Interpretation:
> https://apps.fcc.gov/kdb/GetAttachment.html?id=zXtrctoj6zH7oNEOO6De6g%3D%3D=594280%20D02%20U-NII%20Device%20Security%20v01r03_number=39498
> Credible Response:
> https://ecfsapi.fcc.gov/file/60001333550.pdf

I appreciate y'all citing that ex parte brief of mine to the FCC.  I
have not been paying much attention to what's going on in the EU of
late, and would appreciate a brief on what's happening there now.

I will be at netdevconf and IETF in prague march 16th-31st, and still
have a few spare bunks on the houseboat if anyone going needs a place to
crash. Otherwise, I could make a detour to berlin, afterwards.

>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] build: Activate ASLR PIE by default

2019-02-23 Thread Dave Taht
Hauke Mehrtens  writes:

> On 2/13/19 11:51 PM, Felix Fietkau wrote:
>> On 2019-02-13 23:15, Hauke Mehrtens wrote:
>>> This will build all executable as Position Independent Executables (PIE)
>>> by default. PIE executable can make full use of Address Space Layout
>>> Randomization (ASLR) because all sections can be placed at random
>>> offsets of the executed program. This makes it harder to exploit bugs
>>> in our binaries.
>>>
>>> This will increase the size of executable, libraries are already build
>>> position independent and their size will not change.
>>>
>>> This increases the size of the resulting images by about 3% on MIPS BE.
>>> I tested this with the default configuration for the lantiq xrx200
>>> target.
>>>
>>> The size of the initramfs binaries increased by 2.88%:
>>> Without PIE:
>>> 5.303.716 openwrt-lantiq-xrx200-bt_homehub-v5a-initramfs-kernel.bin
>>> With PIE:
>>> 5.456.339 openwrt-lantiq-xrx200-bt_homehub-v5a-initramfs-kernel.bin
>>>
>>> With PIE activated the executable are getting bigger, here are some
>>> examples from the lantiq mips_24kc target:
>>>
>>> Without PIE:
>>> 112.309 /bin/opkg
>>> 299.061 /bin/busybox
>>> 456.549 /usr/sbin/wpad
>>>
>>> With PIE:
>>> 142.496 /bin/opkg   (26.87% increase)
>>> 388.404 /bin/busybox(29.87% increase)
>>> 580.128 /usr/sbin/wpad  (27.06% increase)
>>>
>>> With PIE activated the sections of the binaries are loaded to
>>> different offsets for each program instance like shown here:
>>>
>>> root@OpenWrt:/# cat /proc/self/maps
>>> 555c4000-55622000 r-xp  00:02 1030   /bin/busybox
>>> 55631000-55632000 r-xp 0005d000 00:02 1030   /bin/busybox
>>> 55632000-55633000 rwxp 0005e000 00:02 1030   /bin/busybox
>>> 55633000-55634000 rwxp  00:00 0
>>> 77ee2000-77f04000 r-xp  00:02 331/lib/libgcc_s.so.1
>>> 77f04000-77f05000 r-xp 00012000 00:02 331/lib/libgcc_s.so.1
>>> 77f05000-77f06000 rwxp 00013000 00:02 331/lib/libgcc_s.so.1
>>> 77f06000-77f9a000 r-xp  00:02 329/lib/libc.so
>>> 77fa9000-77fab000 rwxp 00093000 00:02 329/lib/libc.so
>>> 77fab000-77fad000 rwxp  00:00 0
>>> 7fb26000-7fb47000 rw-p  00:00 0  [stack]
>>> 7fefb000-7fefc000 r-xp  00:00 0
>>> 7ff0a000-7ff0b000 r--p  00:00 0  [vvar]
>>> 7ff0b000-7ff0c000 r-xp  00:00 0  [vdso]
>>> root@OpenWrt:/# cat /proc/self/maps
>>> 5561d000-5567b000 r-xp  00:02 1030   /bin/busybox
>>> 5568a000-5568b000 r-xp 0005d000 00:02 1030   /bin/busybox
>>> 5568b000-5568c000 rwxp 0005e000 00:02 1030   /bin/busybox
>>> 5568c000-5568d000 rwxp  00:00 0
>>> 77e8e000-77eb r-xp  00:02 331/lib/libgcc_s.so.1
>>> 77eb-77eb1000 r-xp 00012000 00:02 331/lib/libgcc_s.so.1
>>> 77eb1000-77eb2000 rwxp 00013000 00:02 331/lib/libgcc_s.so.1
>>> 77eb2000-77f46000 r-xp  00:02 329/lib/libc.so
>>> 77f55000-77f57000 rwxp 00093000 00:02 329/lib/libc.so
>>> 77f57000-77f59000 rwxp  00:00 0
>>> 7fd1c000-7fd3d000 rw-p  00:00 0  [stack]
>>> 7fefb000-7fefc000 r-xp  00:00 0
>>> 7ff6-7ff61000 r--p  00:00 0  [vvar]
>>> 7ff61000-7ff62000 r-xp  00:00 0  [vdso]
>>> root@OpenWrt:/#
>>>
>>> Signed-off-by: Hauke Mehrtens 
>>> ---
>>>
>>> I would like to get some comments if we should activate PIE by default.
>>> The advantage is that it will be harder to exploit OpenWrt, but on the 
>>> other hand the binaries are getting bigger. We could also restrict this 
>>> to some CPU types, but as targets share the binaries it is not really 
>>> possible to do this based on the target.
>>>
>>> I am not sure if this should go into the next release or wait for later.
>>>
>>> This could also break some packages, as it is possible to activate PIE 
>>> by default for some time many bugs are already fixed, but probably not 
>>> all of them.
>> I think this is a lot of extra bloat. Maybe we can add a restricted PIE
>> mode where packages can opt-in individually?
>
> So we should probably make it a chose with 3 options:
> 1. No PIE
> 2. Use PIE for exposed binaries
> 3. Use PIE for all binaries

I hate that we have to make choices like this for space reasons. Option
2 will help but means attackers will try to go after something else.
By exposed, you mean "on the network", I guess? 


>
> Then we need something in addition to the existing PKG_ASLR_PIE we
> already have to deactivate it.
>
> Do we want a generic name like this:
> PKG_CRITICAL
> or something specific to PIE:
> PKG_ASLR_PIE_PREFERED
>
> Hauke
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] netdevconf + ietf airbnb share in prague?

2019-02-11 Thread Dave Taht


I might be going to either or both of these conferences. I am curious
if anyone else is going and would like to split an airbnb?

https://netdevconf.org/0x13/ has quite a lot of interest to openwrt
folk - in my case the wireless workshop, bpf, and l4s talks are of
note. I've got a talk at netdevconf *maybe* on opening up the 240/4
IPv4 address space.

Netdevconf is march 20-22nd, ietf is 23-

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] MIPS stack security and other problems

2019-01-19 Thread Dave Taht
Hauke Mehrtens  writes:

> On 12/18/18 12:46 PM, Hauke Mehrtens wrote:
>> On 12/17/18 1:54 AM, Dave Taht wrote:
>>>
>>> A pretty deep look at home MIPS and arm routers, and a surprising bug in 
>>> Linux/MIPS - by mudge and co:
>>>
>>> https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html
>>>
>>> I have no idea if current openwrt, or what prior releases... are subject to
>>> the problems they outline.
>>
>> In the second paper "Build Safety of Software in 28 Popular Home Router"
>> [0] they checked the "security" of multiple popular devices, by checking
>> if they activate ASLR, Non stack Exec, Relro and stack guards. The best
>> device was the Linksys wrt32x and this is based on OpenWrt with not so
>> many modifications. ;-) Just something like Samba downgrade to 3.0.37.
>> The paper also wonders why the other Linksys devices like the wrt1900ac
>> are much worse, but they probably do not use OpenWrt or a much older
>> version. The GPL source code tar.gz of the Linksys wrt32x, begins with
>> cloning from https://github.com/openwrt/openwrt.git
>>
>>
>> It is also interesting how different this approve to security checking
>> is to what the German BSI published in the "BSI TR-03148: Secure
>> Broadband Router:" [1].
>> You can build a device which scores 100% in the one and 0% in the other,
>> there is no overlap. ;-)
>>
>> Hauke
>>
>>
>> [0]:
>> https://cyber-itl.org/assets/papers/2018/build_safety_of_software_in_28_popular_home_routers.pdf
>> [1]:
>> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf?__blob=publicationFile=2
>
> It looks like they ran checksec from
> http://github.com/slimm609/checksec.sh on the root file system of the
> devices and came up with these results. The numbers for the Linksys
> wrt32x look very similar to current OpenWrt master, even for MIPS
> CPUs.
>
> I attached two outputs of checksec to this mail from the lantiq target
> with a MIP24Kc CPU. One with master and the current default
> configuration and one with master + activated ASLR configuration
> option.
>
> You can generate these yourself like this:
> ../checksec.sh/checksec -d build_dir/target-mips_24kc_musl/root-lantiq/

This might be a useful tool to make more obvious security issues to
future builders of openwrt.

>
> ASLR increases the image size by about 2.8%:
> Without ASLR: 5.386.965 bytes
> With ASLR:5.540.565 bytes

To me this seems worth it on the larger flash sizes.

> This is caused by increased user space binary size, see for example
> busybox binary which is 7% bigger:
> Without ASLR: 425.532 bytes
> With ASLR:457.336 bytes
>
> The fortified function count does not work with fortify-headers, but
> only with glibc. With glibc some function calls are getting replaced
> with calls to *_chk functions which are taking extra arguments, this
> is done by some glibc header magic. For musl libc OpenWrt uses
> fortify-headers which overwrites the original functions and inlined
> some extra security checks into the calling application. The result
> should be similar, so I assume that we have at least in most places
> similar security for the glibc fortified functions.
> I checked this by compiling an test application and checked the
> assembler code, it contained some extra size checks.
>
> It looks like the detection does not work correctly for kernel modules.
>
> Currently RELRO is not activated for the following libraries:
>   root-lantiq/usr/lib/libbz2.so.1.0
>   root-lantiq/usr/lib/libbz2.so.1.0.6
>   root-lantiq/lib/libgcc_s.so.1
> this looks like a bug.
>
> For libgcc_s.so.1 also NX is disabled, which is not good.

Hmm. Does gcc still actually contain executable code in this segment?

> Some binaries do not use a stack canary, I assume that these binaries
> just do not have an array on the stack which could be exploited. The
> compiler adds stack canaries only to functions which the compiler
> thinks need it.
>
> ASLR is deactivated for root-lantiq/sbin/vdsl_cpe_control, because
> this application does not link any more when ASLR is activated, this
> is a bug in the package build system.
>
> Hauke
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] MIPS stack security and other problems

2018-12-19 Thread Dave Taht


Still... "Friends don't let friends run factory firmware".


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] MIPS stack security and other problems

2018-12-18 Thread Dave Taht


Going back to my ancient cerowrt box, the stack space is actively being
relocated on this version, but marked executable...

7f8d4000-7f8f5000 rwxp  00:00 0  [stack]
7fff7000-7fff8000 r-xp  00:00 0  [vdso]

but there doesn't appear to be a vfp area on this ancient version of
openwrt.

... so it it appears to me that the paper is correct - two mips
"bugfixes" arrived at almost exactly the same time. The first, fixed
executable stacks and heaps, which already did ASLR, the second added an
executable vfpu area in a fixed location. Sigh.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] MIPS stack security and other problems

2018-12-18 Thread Dave Taht


Cutting this down a bit

>> Do the common MIPS CPUs support non executable stacks at all?

?

>> cpu_has_rixi is set to 0 for the ath79 SoCs for example, for lantiq some

Should this show up in /proc/cpuinfo? Or where?

>> automatic detection is done, but I haven't checked the result.
> ramips has RIXI enabled by default. This is the result for procd:

>> @Dave: From which device did you get the map and which kernel is used there?

I wanted to note that the exploit of vfpu hard codes a mips little endian return
statement, haven't got around to fiddling with big-endian. 

Since everybody is looking at procd, here's a look at 3 platforms.

* The first map I think I got was from Reboot (17.01.4,
  r3560-79f57e422d), or perhaps it was from the edgerouter X, which I
  talk to further down in this message

To clarify:

On a:

root@lupin-jeff:/proc/1# cat /proc/cpuinfo 
system type : Qualcomm Atheros QCA956X ver 1 rev 0
machine : Ubiquiti UniFi-AC-LITE
processor   : 0
cpu model   : MIPS 74Kc V5.0
BogoMIPS: 385.84
wait instruction: yes
microsecond timers  : yes
tlb_entries : 32
extra interrupt vector  : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 
0x0ffb, 0x0ffb]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented: mips16 dsp dsp2
shadow register sets: 1
kscratch registers  : 0
package : 0
core: 0
VCED exceptions : not available
VCEI exceptions : not available

we get

root@lupin-jeff:/proc/1# cat maps
0040-0040b000 r-xp  1f:04 999/sbin/procd
0041a000-0041b000 r--p a000 1f:04 999/sbin/procd
0041b000-0041c000 rw-p b000 1f:04 999/sbin/procd
0041c000-0041e000 rwxp  00:00 0 
00815000-0083c000 rwxp  00:00 0  [heap]
77d32000-77d54000 r-xp  1f:04 611/lib/libgcc_s.so.1
77d54000-77d55000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1
77d56000-77d67000 r-xp  1f:04 633/lib/libjson_script.so
77d67000-77d68000 r--p 1000 1f:04 633/lib/libjson_script.so
77d68000-77d69000 rw-p 2000 1f:04 633/lib/libjson_script.so
77d6a000-77d7b000 r-xp  1f:04 655/lib/libblobmsg_json.so
77d7b000-77d7c000 r--p 1000 1f:04 655/lib/libblobmsg_json.so
77d7c000-77d7d000 rw-p 2000 1f:04 655/lib/libblobmsg_json.so
77d7e000-77d94000 r-xp  1f:04 300/usr/lib/libjson-c.so.2.0.2
77d94000-77d95000 r--p 6000 1f:04 300/usr/lib/libjson-c.so.2.0.2
77d95000-77d96000 rw-p 7000 1f:04 300/usr/lib/libjson-c.so.2.0.2
77d96000-77da9000 r-xp  1f:04 658/lib/libubus.so
77da9000-77daa000 r--p 3000 1f:04 658/lib/libubus.so
77daa000-77dab000 rw-p 4000 1f:04 658/lib/libubus.so
77dac000-77dc3000 r-xp  1f:04 614/lib/libubox.so
77dc3000-77dc4000 r--p 7000 1f:04 614/lib/libubox.so
77dc4000-77dc5000 rw-p 8000 1f:04 614/lib/libubox.so
77dc6000-77e58000 r-xp  1f:04 653/lib/libc.so
77e65000-77e66000 r--p  00:00 0  [vvar]
77e66000-77e67000 r-xp  00:00 0  [vdso]
77e67000-77e69000 rw-p 00091000 1f:04 653/lib/libc.so
77e69000-77e6b000 rwxp  00:00 0 
7ff12000-7ff33000 rw-p  00:00 0  [stack]

However a specific check for ALSR - watching the dynamic relos go for
"cat", at least, everything except the first two (which is normal), are
being relocated, and there appears to be no vfpu map here.

root@lupin-jeff:/proc/1# cat /proc/self/maps
0040-0044b000 r-xp  1f:04 879/bin/busybox
0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox
7742a000-7744c000 r-xp  1f:04 611/lib/libgcc_s.so.1
7744c000-7744d000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1
7744e000-774e r-xp  1f:04 653/lib/libc.so
774ed000-774ee000 r--p  00:00 0  [vvar]
774ee000-774ef000 r-xp  00:00 0  [vdso]
774ef000-774f1000 rw-p 00091000 1f:04 653/lib/libc.so
774f1000-774f3000 rwxp  00:00 0  # this DOES relocate
7f9ef000-7fa1 rw-p  00:00 0  [stack]

So I think this processor + build are doing the "right thing".

* However, this a wndr3800 with OpenWrt 18.06.1, r7258-5eb055306f

system type : Atheros AR7161 rev 2
machine : NETGEAR WNDR3700/WNDR3800/WNDRMAC
processor   : 0
cpu model   : MIPS 24Kc V7.4
BogoMIPS: 452.19
wait instruction: yes
microsecond timers  : yes
tlb_entries : 16
extra interrupt vector  : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 
0x0ffb, 0x0ffb]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented: mips16
shadow register sets: 1
kscratch 

Re: [OpenWrt-Devel] MIPS stack security and other problems

2018-12-18 Thread Dave Taht
Hauke Mehrtens  writes:

> On 12/17/18 1:54 AM, Dave Taht wrote:
>> 
>> A pretty deep look at home MIPS and arm routers, and a surprising bug in 
>> Linux/MIPS - by mudge and co:
>> 
>> https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html
>> 
>> I have no idea if current openwrt, or what prior releases... are subject to
>> the problems they outline.
>
> In the second paper "Build Safety of Software in 28 Popular Home Router"
> [0] they checked the "security" of multiple popular devices, by checking
> if they activate ASLR, Non stack Exec, Relro and stack guards. The best
> device was the Linksys wrt32x and this is based on OpenWrt with not so
> many modifications. ;-) Just something like Samba downgrade to 3.0.37.
> The paper also wonders why the other Linksys devices like the wrt1900ac
> are much worse, but they probably do not use OpenWrt or a much older
> version. The GPL source code tar.gz of the Linksys wrt32x, begins with
> cloning from https://github.com/openwrt/openwrt.git
>
>
> It is also interesting how different this approve to security checking
> is to what the German BSI published in the "BSI TR-03148: Secure
> Broadband Router:" [1].
> You can build a device which scores 100% in the one and 0% in the other,
> there is no overlap. ;-)

It isn't really something I can put smiley faces about.

How many of the 28 can be reflashed with modern openwrt?

>
> Hauke
>
>
> [0]:
> https://cyber-itl.org/assets/papers/2018/build_safety_of_software_in_28_popular_home_routers.pdf
> [1]:
> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf?__blob=publicationFile=2

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] MIPS stack security and other problems

2018-12-17 Thread Dave Taht
John Crispin  writes:

> On 17/12/2018 23:18, Dave Taht wrote:
>> Rosen Penev  writes:
>>
>>> On Sun, Dec 16, 2018 at 4:54 PM Dave Taht  wrote:
>>>>
>>>> A pretty deep look at home MIPS and arm routers, and a surprising
>>>> bug in Linux/MIPS - by mudge and co:
>>>>
>>>> https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html
>>>>
>>>> I have no idea if current openwrt, or what prior releases... are subject to
>>>> the problems they outline.
>>> As of kernel 4.14.88, I see the same problems.
>> Well, I see that the stack, at least, on kernel 4.4.92 on mips and
>> 4.14 on openwrt 18.06...
>>
>> is mapped rw only, with no execute bit.
>>
>> That doesn't mean the other other flaws discussed in the paper don't
>> exist, but at least current openwrt HEAD is using the right gcc version
>> to turn the right linkage on. Someone here with wy more expertise in
>> the compiler, here, should take a hard look at this and the paper.
>>
>>
>> root@lupin-jeff:~# cat /proc/self/maps
>> 0040-0044b000 r-xp  1f:04 879/bin/busybox
>> 0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox
>> 77182000-771a4000 r-xp  1f:04 611/lib/libgcc_s.so.1
>> 771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1
>> 771a6000-77238000 r-xp  1f:04 653/lib/libc.so
>> 77245000-77246000 r--p  00:00 0  [vvar]
>> 77246000-77247000 r-xp  00:00 0  [vdso]
>> 77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so
>> 77249000-7724b000 rwxp  00:00 0 # is this the heap?
>> 7fe06000-7fe27000 rw-p  00:00 0  [stack]
>>
>>
>>>> ___
>>>> openwrt-devel mailing list
>>>> openwrt-devel@lists.openwrt.org
>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> Dave,
>
> too lazy to read thd pdf, in a nutshell whats the issue and what do we
> need to do do to mitigate it ?

From the paper: (It's the second comment regarding ALSR bypass via a
deterministic segment that concerns me most). They are claiming that the
emulation segment at

7000-8000 rwxp  00:00 0 

is a bad idea, in the paper. Which openwrt has.


"Timeline Key:
(A)
2001: Linux introduces FPU emulation in kernel 2.4.3.4. This puts code on the 
stack and
executes it there requiring the stack be marked as readable, writable, and 
executable.
(B)
2016 July:  a new page was introduced to execute branch delay slot 
instructions. This
was introduced to remove the code being inserted and executed on the program 
stack.
However, this fix introduced a new fixed location segment that can be used to 
bypass
ASLR defenses.
3
(C)
2016 August:  a patch to make the stack and heap non-execute was introduced, if 
a
PT_GNU_STACK was present. However, as noted in the patch none of the toolchains
used to build executables created a PT_GNU_STACK and the stack would remain
executable until this was addressed in compiler toolchains.
4
In summary, Linux MIPS binaries have been easier to exploit by way of classic 
stack overflow
attacks for over a decade, and continue to be so according to our examination 
of toolchain
patches. Additionally, the fix that moved FPU emulation off the stack created a 
separate DEP
and 
​
ASLR exposure.  Even if patches were introduced today for both the kernel and 
the
toolchains, the lag in adoption implies it could be years before Linux MIPS 
devices can be
expected to have basic DEP and ASLR.
"

Their proof of concept for exploiting this on mipsel is:

include 
#include 
#include 
#include 

int main(void) {
// set a pointer to the vfpu emulation page address
void* p = (void *)0x7000;
printf("%p\n", (void*)p);
// construct a function pointer from p
void (*func_ptr)(void) = p;
// 'jr $ra' mips32el instruction bytes
char code[] = {0x08, 0x00, 0xe0, 0x03, 0x00, 0x00, 0x00, 0x00};
// copy the instruction to the vfpu page
memcpy(p, code, 8);
// call the function pointer, this should then directly return back
(*func_ptr)();
// print out the current maps of the process
char cmd[200];
sprintf(cmd, "cat /proc/%d/maps", getpid());
system(cmd);
return 0;
}


>
>     John
>
>
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] MIPS stack security and other problems

2018-12-17 Thread Dave Taht
Rosen Penev  writes:

> On Sun, Dec 16, 2018 at 4:54 PM Dave Taht  wrote:
>>
>>
>> A pretty deep look at home MIPS and arm routers, and a surprising
>> bug in Linux/MIPS - by mudge and co:
>>
>> https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html
>>
>> I have no idea if current openwrt, or what prior releases... are subject to
>> the problems they outline.
> As of kernel 4.14.88, I see the same problems.

Well, I see that the stack, at least, on kernel 4.4.92 on mips and
4.14 on openwrt 18.06...

is mapped rw only, with no execute bit.

That doesn't mean the other other flaws discussed in the paper don't
exist, but at least current openwrt HEAD is using the right gcc version
to turn the right linkage on. Someone here with wy more expertise in
the compiler, here, should take a hard look at this and the paper.


root@lupin-jeff:~# cat /proc/self/maps
0040-0044b000 r-xp  1f:04 879/bin/busybox
0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox
77182000-771a4000 r-xp  1f:04 611/lib/libgcc_s.so.1
771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1
771a6000-77238000 r-xp  1f:04 653/lib/libc.so
77245000-77246000 r--p  00:00 0  [vvar]
77246000-77247000 r-xp  00:00 0  [vdso]
77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so
77249000-7724b000 rwxp  00:00 0 # is this the heap?
7fe06000-7fe27000 rw-p  00:00 0  [stack]


>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] MIPS stack security and other problems

2018-12-16 Thread Dave Taht


A pretty deep look at home MIPS and arm routers, and a surprising bug in 
Linux/MIPS - by mudge and co:

https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html

I have no idea if current openwrt, or what prior releases... are subject to
the problems they outline.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] IPv6 and comcast fails

2018-10-22 Thread Dave Taht
Russell Senior  writes:

> Works for me, on current HEAD*, with ar71xx (netgear wndr3800). Can
> you include your /etc/config/network and any other relevant
> configuration details?
>
> * $ git describe
> reboot-8373-gbc3d47cd12

Good to hear.

Is yours configured as a bridge anywhere? My apu2 (x86) is not.

I can reconfigure a wndr3800 "out of the box" with both head and
stable and try that in a night or two on the network where the
arm is working. (production network can't fiddle)

As per the bug report, I see no responses to my ip6 queries.

Had 24 days of uptime...

apu2:

root@office:~# ifstatus wan6
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"dynamic": false,
"proto": "dhcpv6",
"device": "eth0",
"data": {

}
}

I should see at least *some* ipv6 traffic here?

root@office:~# tcpdump -i eth0 ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:41:55.339916 IP6 fe80::20d:b9ff:fe43:a06c.546 > ff02::1:2.547: dhcp6
solicit
every x seconds...

... that's it.

ip6tables -F as well as -P whatever ACCEPT

Tried both reqprefix 56 and 60.

config interface 'wan6' 
option ifname 'eth0'   
option proto 'dhcpv6'  
option reqprefix '56'   
option dns '2001:558:feed::1 2001:558:feed::2'

...

while I'm here, have you had any success in getting a relay to work?

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] IPv6 and comcast fails

2018-10-22 Thread Dave Taht


We have confirmed fails for mips and x86 for even seeing any
ipv6 traffic on a comcast uplink, thus dhcpv6pd fails.

See:

https://bugs.openwrt.org/index.php?do=details_id=1763


And

https://forum.openwrt.org/t/openwrt-18-06-rc1-doesnt-obtain-ipv6-address/16759/6

It was bisected back a few months in the latter bug report.

However, I DO have ipv6 prefix delegation working on an arm a15
box running the current stable release.

Is there anything we can try to reconfigure (for ipv6 mcast?) to
even see these packets? Clue?


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] the "right" rbtree lib for openwrt?

2018-10-13 Thread Dave Taht
I'm in search of the "right" rbtree library to use to solve this bug in babel

https://github.com/dtaht/babeld/issues/31

I'm leaning towards libdict at the moment, but there are dozens. any
opinions? I wouldn't mind storing the red bit in the pointer,
across 36 different platforms

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Wshaper package dependencies fail with snapshot image-builder

2017-02-07 Thread Dave Taht
wshaper was just retired in favor of sqm-scripts and qos-scripts.

See

https://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die/

for why.


On Tue, Feb 7, 2017 at 1:14 AM, Mangesh Bhamre  wrote:
> Hello OpenWRT team,
>
> I am trying to build ramips/7620 router firmware with wshaper and
> luci-app-wshaper package.  Build fails due to dependency error.
>
> --
>  * satisfy_dependencies_for: Cannot satisfy the following dependencies for
> luci-app-wshaper:
>  * wshaper *
>  * opkg_install_cmd: Cannot install package wshaper.
> Makefile:146: recipe for target 'package_install' failed
> -
>
> Please provide a fix.
>
>
> Regards,
> Mangesh Bhamre
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [LEDE-DEV] [Babel-users] Babeld now has procd support on OpenWRT/LEDE

2017-01-13 Thread Dave Taht
On Fri, Jan 13, 2017 at 8:11 AM, L. D. Pinney <ldpin...@yahoo.com> wrote:
> Go back to playing the guitar and smoking dopethat's what you do best.

I look forward very much to doing more of that... after lede ships.

In the interim, I have two fairly large testbeds setup to test lede -
the ATF patch, the dnsmasq-dnssec code, the bcp38 code, the dhcpv6-pd
code, the new bridging code, and babel integration are all high on my
list, along with sch_cake and the sqm-scripts. I have 5 lede platforms
under test - the archer c7v2, wndr3800, linksys 1200ac, uap-lite, and
picostation, with two more that I plan to add after testing interop
(edgerouter and an apu2). There are also 3 different brands of
cablemodem in the loop. Test clients include a dozen hackerboards
(kernels going back to 3.10), OSX, and Linux.

I'm perpetually testing edge cases and things that seem like they
should work, but don't. While things are vague and confusing (like,
babel-1.8's behavior being confusing in some instances) - and a piece
of a puzzle lands (like not restarting it as much, thus causing less
route retractions and floods) - I do tend to dump partial state about
the rathole I may have been going down.

I've been trying to come up with tests for understanding the true
effects of the multicast-unicast bridging code, for wifi primarily,
and simplifying. At the moment I'm more trying to test 3 layers of
lede dhcp-pd (bridged and routed scenarios) across gear that needs to
interop...

... instead of dealing with how all that feeds into babel source
specific routing - which is a combination of interactions between
netifd, babeld, and multicast/bridging.

>
> STOP CROSS POSTING YOU FSCKin' Clown Boy

If these projects want to write "no cross posting ever" into the
rules, I will gladly comply.

I hope you get your caps-lock key fixed.

I'm going to just filter out all further postings from you into my trash folder.


>
> On Saturday, January 14, 2017 12:06 AM, Dave Taht <dave.t...@gmail.com>
> wrote:
>
>
> On Fri, Jan 13, 2017 at 4:08 AM, L. D. Pinney <ldpin...@yahoo.com> wrote:
>> DAVE :
>>
>> WILL YOU PLEASE STOP YOUR FSCKin' CROSS POSTING ???
>
> I did not start the cross-post in this case.
>
>> This is UNRELATED to the OpenWrt / LEDE DEV mailing list...as the change
>> has
>> been merged.
>
> Interop with routing protocols... and networking in general... does
> exist outside of the openwrt universe. In my case I am deeply
> concerned about what happens against older, deployed versions of
> Linuxes (and other OSes) with the new multicast-unicast bridge
> conversion code in lede. Babel tends to use it, and I am also testing
> (in lede!), as per the below, the dhcpv6-pd code, interop-ing with
> several devices.
>
>> F O
>
> I'm really sorry that you hate cross posting so much. It must be
> terrible to have to elide additional responses or deal with bounce
> messages on every 20th email from me. And it must be wonderful to be
> living in a world where all you have is openwrt/lede devices on the
> network and modern kernels everywhere.
>
>>
>> On Friday, January 13, 2017 5:20 AM, Dave Taht <dave.t...@gmail.com>
>> wrote:
>>
>>
>> On Thu, Jan 12, 2017 at 1:01 PM, Baptiste Jonglez
>> <bapti...@bitsofnetworks.org> wrote:
>>> Hi,
>>>
>>> Here is yet another OpenWRT-related change for babeld: I just merged
>>> procd
>>> support for babeld [2], after more than two years of lingering [1].
>>>
>>> The only user-visible changes should be:
>>>
>>> - babeld now logs to the system log (visible with "logread") instead of a
>>>  file in /var/log.  This is nice for embedded devices, where you don't
>>>  want to write too much to the filesystem.  It is still possible to
>>>  explicitly configure babeld to use a log file;
>>>
>>> - babeld is now restarted automatically whenever it crashes;
>>>
>>> - the usual procd niceties: calling "/etc/init.d/babeld reload" will
>>>  restart babeld only if the configuration has changed.
>>>
>>>
>>> Please test babeld 1.8.0-2 and report any resulting breakage.  I would
>>> like this change (and the other compatibility change) to make it into the
>>> upcoming LEDE release, which is due to happen quite soon.
>>
>> Groovy.
>>
>> lede can dynamically insert/delete routes into tables from netifd
>> babeld can pull routes from "protos" but not tables.
>>
>> I spoke with hedecker (? can't remember his email) about somehow
>> having a field to export routes into kernel protos in the lede network
>> file, he indicated he'd look at it in 

Re: [OpenWrt-Devel] [LEDE-DEV] [Babel-users] Babeld now has procd support on OpenWRT/LEDE

2017-01-13 Thread Dave Taht
On Fri, Jan 13, 2017 at 4:08 AM, L. D. Pinney <ldpin...@yahoo.com> wrote:
> DAVE :
>
> WILL YOU PLEASE STOP YOUR FSCKin' CROSS POSTING ???

I did not start the cross-post in this case.

> This is UNRELATED to the OpenWrt / LEDE DEV mailing list...as the change has
> been merged.

Interop with routing protocols... and networking in general... does
exist outside of the openwrt universe. In my case I am deeply
concerned about what happens against older, deployed versions of
Linuxes (and other OSes) with the new multicast-unicast bridge
conversion code in lede. Babel tends to use it, and I am also testing
(in lede!), as per the below, the dhcpv6-pd code, interop-ing with
several devices.

> F O

I'm really sorry that you hate cross posting so much. It must be
terrible to have to elide additional responses or deal with bounce
messages on every 20th email from me. And it must be wonderful to be
living in a world where all you have is openwrt/lede devices on the
network and modern kernels everywhere.

>
> On Friday, January 13, 2017 5:20 AM, Dave Taht <dave.t...@gmail.com> wrote:
>
>
> On Thu, Jan 12, 2017 at 1:01 PM, Baptiste Jonglez
> <bapti...@bitsofnetworks.org> wrote:
>> Hi,
>>
>> Here is yet another OpenWRT-related change for babeld: I just merged procd
>> support for babeld [2], after more than two years of lingering [1].
>>
>> The only user-visible changes should be:
>>
>> - babeld now logs to the system log (visible with "logread") instead of a
>>  file in /var/log.  This is nice for embedded devices, where you don't
>>  want to write too much to the filesystem.  It is still possible to
>>  explicitly configure babeld to use a log file;
>>
>> - babeld is now restarted automatically whenever it crashes;
>>
>> - the usual procd niceties: calling "/etc/init.d/babeld reload" will
>>  restart babeld only if the configuration has changed.
>>
>>
>> Please test babeld 1.8.0-2 and report any resulting breakage.  I would
>> like this change (and the other compatibility change) to make it into the
>> upcoming LEDE release, which is due to happen quite soon.
>
> Groovy.
>
> lede can dynamically insert/delete routes into tables from netifd
> babeld can pull routes from "protos" but not tables.
>
> I spoke with hedecker (? can't remember his email) about somehow
> having a field to export routes into kernel protos in the lede network
> file, he indicated he'd look at it in a few weeks.
>
> (I wanted to get away from ever having to revise the conf file
> dynamically, but it looks like not this release. Not having to restart
> babeld as per the above is a nice improvement though and I'll get on
> testing it this weekend. At the moment I'm going through some mild
> hell with dhcpv6-pd on comcast and adding "sonic" fiber (with a HE
> ipv6 tunnel. Will hopefully have 4 source specific gateways to play
> with here)
>
> In other other news the "rabeld" backport of the gentler route switch
> change loses kernel routes on the vyatta (3.10 based) OS in the
> edgerouter. :(. That said, haven't tested mainline babeld there yet.
> It seems to work on debian.
>
> For those fiddling with edgerouter's default 1.9.x OS, backports of
> cake, iproute, and rabeld are presently here:
> https://build.lochnair.net/
>
>
>> Baptiste
>>
>> [1] https://github.com/openwrt-routing/packages/pull/55
>> [2] https://github.com/openwrt-routing/packages/pull/250
>
>>
>> ___
>> Babel-users mailing list
>> babel-us...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
>
>
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org
>
> ___
> Lede-dev mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [Babel-users] Babeld now has procd support on OpenWRT/LEDE

2017-01-12 Thread Dave Taht
On Thu, Jan 12, 2017 at 1:01 PM, Baptiste Jonglez
 wrote:
> Hi,
>
> Here is yet another OpenWRT-related change for babeld: I just merged procd
> support for babeld [2], after more than two years of lingering [1].
>
> The only user-visible changes should be:
>
> - babeld now logs to the system log (visible with "logread") instead of a
>   file in /var/log.  This is nice for embedded devices, where you don't
>   want to write too much to the filesystem.  It is still possible to
>   explicitly configure babeld to use a log file;
>
> - babeld is now restarted automatically whenever it crashes;
>
> - the usual procd niceties: calling "/etc/init.d/babeld reload" will
>   restart babeld only if the configuration has changed.
>
>
> Please test babeld 1.8.0-2 and report any resulting breakage.  I would
> like this change (and the other compatibility change) to make it into the
> upcoming LEDE release, which is due to happen quite soon.

Groovy.

lede can dynamically insert/delete routes into tables from netifd
babeld can pull routes from "protos" but not tables.

I spoke with hedecker (? can't remember his email) about somehow
having a field to export routes into kernel protos in the lede network
file, he indicated he'd look at it in a few weeks.

(I wanted to get away from ever having to revise the conf file
dynamically, but it looks like not this release. Not having to restart
babeld as per the above is a nice improvement though and I'll get on
testing it this weekend. At the moment I'm going through some mild
hell with dhcpv6-pd on comcast and adding "sonic" fiber (with a HE
ipv6 tunnel. Will hopefully have 4 source specific gateways to play
with here)

In other other news the "rabeld" backport of the gentler route switch
change loses kernel routes on the vyatta (3.10 based) OS in the
edgerouter. :(. That said, haven't tested mainline babeld there yet.
It seems to work on debian.

For those fiddling with edgerouter's default 1.9.x OS, backports of
cake, iproute, and rabeld are presently here:
https://build.lochnair.net/

> Baptiste
>
> [1] https://github.com/openwrt-routing/packages/pull/55
> [2] https://github.com/openwrt-routing/packages/pull/250
>
> ___
> Babel-users mailing list
> babel-us...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Slow DNSMasq with > 100, 000 entries in additional addresses file

2016-12-31 Thread Dave Taht
On Sat, Dec 31, 2016 at 12:15 AM, TheWerthFam <thewerth...@gmail.com> wrote:
> Quick report -
> So I didn't test pihole per say, but used that method of storing the
> blacklist into the hosts file for dnsmasq to use.  Dnsmasq must use a
> different storage method for its hosts file. I loaded 850439 entries in the
> hosts file and restarted dnsmasq. I uses 1/2 as much memory than if loaded
> as a conf-file like adblock does.  And its super fast and virtually non
> existent cpu usage.  DNS lookups perform just like it should.   Though the
> hosts file is now returning an IP address I specified for the blocked hosts
> - would have been nice to do the nxdomain.  Think this will work for my
> needs, I can put a second IP address on the router and run pixelserv on it
> or something like that.

Good to know. I'm still interested in finding more
"read-only-thus-discardable data" methods for protecting home networks
and routers, this for example:

https://plus.google.com/u/0/107942175615993706558/posts/635rm12isPq?sfc=true

> Cheers
> Derek
>
>
>
> On 12/29/2016 11:11 AM, Dave Taht wrote:
>>
>> On Thu, Dec 29, 2016 at 8:09 AM, TheWerthFam <thewerth...@gmail.com>
>> wrote:
>>>
>>> Right now I'd rather not customize the code.  There are two directions
>>> I'm
>>> going to try first.
>>> Give unbound a try to serve DNS, keeping Dnsmasq for DHCP.  If that
>>> doesn't
>>> work try converting the list to a hosts file pointing to a local pixelsrv
>>> address.  There are some other blog posts that indicate that the hosts
>>> file
>>> can handle a lot more entries.  Like https://github.com/pi-hole/pi-hole
>>> Maybe just run pi-hole on openwrt.
>>
>> Well, I've had a bit of fun feeding large blocklists into cmph. Using
>> the "chd" algorithm, it creates an index file from a 24MB blocklist
>> into a 800K one. (but you still need the original data and a secondary
>> index) I also fiddled a bit with bloom filters, which strike me as
>> appropo. It seems feasible to establish a large dataset of read-only
>> data with a fast index (that can be discarded in low memory
>> situations, rather than swapped out)
>>
>> I'll take a look at pi-hole...
>>
>>> Cheers
>>> Derek
>>>
>>>
>>> On 12/28/2016 02:21 PM, Dave Taht wrote:
>>>>
>>>> On Tue, Dec 27, 2016 at 11:03 PM, TheWerthFam <thewerth...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Thanks for the feedback, I'll look into NFQUEUE.  I'm forcing the use
>>>>> of
>>>>> my
>>>>> dns by iptables.  I'm also using a transparent squid and e2guardian to
>>>>> filter content.  I like the idea of the dns based blacklist to add some
>>>>> filtering capabilities since I don't want to try and filter https types
>>>>> sites.  I know no solution in perfect.
>>>>
>>>> I've been thinking about this, and given the large amount of active
>>>> data in a very small memory space have been thinking that another
>>>> approach would be more fruitful. Convert the giant table into a
>>>> "minimally perfect hash", and mmap it into memory read-only, so it can
>>>> be discarded under memory pressure, unlike ipset, squid, or dnsmasq
>>>> based approaches.
>>>>
>>>>
>>>>> Cheers
>>>>>Derek
>>>>>
>>>>>
>>>>>
>>>>> On 12/27/2016 01:53 PM, philipp_s...@redfish-solutions.com wrote:
>>>>>>>
>>>>>>> On Dec 26, 2016, at 10:32 AM, TheWerthFam <thewerth...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Using the adblock set of scripts to block malware and porn sites. The
>>>>>>> porn sites list is 800,000 entries, about 10x the number of sites
>>>>>>> adblock
>>>>>>> normally uses.  With the full list of malware and porn domains
>>>>>>> loaded,
>>>>>>> dnsmasq takes 115M of memory and normally sits around 50% CPU usage
>>>>>>> with
>>>>>>> moderate browsing usage.  CPU and RAM usage isn't really a problem
>>>>>>> other
>>>>>>> than lookups are slow now. Platform is cc 15.05.1 r49389 on banana pi
>>>>>>> r1.
>>>>>>>
>>>>>>> The adblock script takes the different lists, creates files in
>>>&g

Re: [OpenWrt-Devel] Slow DNSMasq with > 100, 000 entries in additional addresses file

2016-12-29 Thread Dave Taht
On Thu, Dec 29, 2016 at 8:09 AM, TheWerthFam <thewerth...@gmail.com> wrote:
> Right now I'd rather not customize the code.  There are two directions I'm
> going to try first.
> Give unbound a try to serve DNS, keeping Dnsmasq for DHCP.  If that doesn't
> work try converting the list to a hosts file pointing to a local pixelsrv
> address.  There are some other blog posts that indicate that the hosts file
> can handle a lot more entries.  Like https://github.com/pi-hole/pi-hole
> Maybe just run pi-hole on openwrt.

Well, I've had a bit of fun feeding large blocklists into cmph. Using
the "chd" algorithm, it creates an index file from a 24MB blocklist
into a 800K one. (but you still need the original data and a secondary
index) I also fiddled a bit with bloom filters, which strike me as
appropo. It seems feasible to establish a large dataset of read-only
data with a fast index (that can be discarded in low memory
situations, rather than swapped out)

I'll take a look at pi-hole...

> Cheers
>    Derek
>
>
> On 12/28/2016 02:21 PM, Dave Taht wrote:
>>
>> On Tue, Dec 27, 2016 at 11:03 PM, TheWerthFam <thewerth...@gmail.com>
>> wrote:
>>>
>>> Thanks for the feedback, I'll look into NFQUEUE.  I'm forcing the use of
>>> my
>>> dns by iptables.  I'm also using a transparent squid and e2guardian to
>>> filter content.  I like the idea of the dns based blacklist to add some
>>> filtering capabilities since I don't want to try and filter https types
>>> sites.  I know no solution in perfect.
>>
>> I've been thinking about this, and given the large amount of active
>> data in a very small memory space have been thinking that another
>> approach would be more fruitful. Convert the giant table into a
>> "minimally perfect hash", and mmap it into memory read-only, so it can
>> be discarded under memory pressure, unlike ipset, squid, or dnsmasq
>> based approaches.
>>
>>
>>> Cheers
>>>   Derek
>>>
>>>
>>>
>>> On 12/27/2016 01:53 PM, philipp_s...@redfish-solutions.com wrote:
>>>>>
>>>>> On Dec 26, 2016, at 10:32 AM, TheWerthFam <thewerth...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Using the adblock set of scripts to block malware and porn sites. The
>>>>> porn sites list is 800,000 entries, about 10x the number of sites
>>>>> adblock
>>>>> normally uses.  With the full list of malware and porn domains loaded,
>>>>> dnsmasq takes 115M of memory and normally sits around 50% CPU usage
>>>>> with
>>>>> moderate browsing usage.  CPU and RAM usage isn't really a problem
>>>>> other
>>>>> than lookups are slow now. Platform is cc 15.05.1 r49389 on banana pi
>>>>> r1.
>>>>>
>>>>> The adblock script takes the different lists, creates files in
>>>>> /tmp/dnsmasq.d/ entries looking like
>>>>> local=/domainnottogoto.com/   one entry per line.  The goal is to
>>>>> return
>>>>> NXDOMAIN to entries in the lists. Lists are sorted and with unique
>>>>> entries.
>>>>>
>>>>> I've tried increasing the cachesize to 10,000 but that made no change.
>>>>> Tried neg-ttl=3600 with default negative caching enabled with no
>>>>> change.
>>>>>
>>>>> Are there dnsmasq setting that will improve the performance?  or should
>>>>> it be configured differently to achieve this goal?
>>>>> Perhaps unbound would be better suited?
>>>>>
>>>>> Cheers
>>>>>  Derek
>>>>
>>>>
>>>> Not to rain on your parade, but the obvious defeat of this solution
>>>> would
>>>> be to point to an external website which does DNS lookups for you, and
>>>> then
>>>> edit the URL to have an IP address in place of the host name.
>>>>
>>>> I would use netfilter’s NFQUEUE and make a user-space decision based on
>>>> packet-destination (since it seems you’re filtering outbound traffic
>>>> requests).
>>>>
>>>> After all, it’s not the NAME you don’t want to talk to… it’s the HOST
>>>> that
>>>> bears that NAME.
>>>>
>>>> -Philip
>>>>
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
>>
>>
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Slow DNSMasq with > 100, 000 entries in additional addresses file

2016-12-28 Thread Dave Taht
On Tue, Dec 27, 2016 at 11:03 PM, TheWerthFam  wrote:
> Thanks for the feedback, I'll look into NFQUEUE.  I'm forcing the use of my
> dns by iptables.  I'm also using a transparent squid and e2guardian to
> filter content.  I like the idea of the dns based blacklist to add some
> filtering capabilities since I don't want to try and filter https types
> sites.  I know no solution in perfect.

I've been thinking about this, and given the large amount of active
data in a very small memory space have been thinking that another
approach would be more fruitful. Convert the giant table into a
"minimally perfect hash", and mmap it into memory read-only, so it can
be discarded under memory pressure, unlike ipset, squid, or dnsmasq
based approaches.


> Cheers
>  Derek
>
>
>
> On 12/27/2016 01:53 PM, philipp_s...@redfish-solutions.com wrote:
>>>
>>> On Dec 26, 2016, at 10:32 AM, TheWerthFam  wrote:
>>>
>>> Using the adblock set of scripts to block malware and porn sites. The
>>> porn sites list is 800,000 entries, about 10x the number of sites adblock
>>> normally uses.  With the full list of malware and porn domains loaded,
>>> dnsmasq takes 115M of memory and normally sits around 50% CPU usage with
>>> moderate browsing usage.  CPU and RAM usage isn't really a problem other
>>> than lookups are slow now. Platform is cc 15.05.1 r49389 on banana pi r1.
>>>
>>> The adblock script takes the different lists, creates files in
>>> /tmp/dnsmasq.d/ entries looking like
>>> local=/domainnottogoto.com/   one entry per line.  The goal is to return
>>> NXDOMAIN to entries in the lists. Lists are sorted and with unique entries.
>>>
>>> I've tried increasing the cachesize to 10,000 but that made no change.
>>> Tried neg-ttl=3600 with default negative caching enabled with no change.
>>>
>>> Are there dnsmasq setting that will improve the performance?  or should
>>> it be configured differently to achieve this goal?
>>> Perhaps unbound would be better suited?
>>>
>>> Cheers
>>> Derek
>>
>>
>> Not to rain on your parade, but the obvious defeat of this solution would
>> be to point to an external website which does DNS lookups for you, and then
>> edit the URL to have an IP address in place of the host name.
>>
>> I would use netfilter’s NFQUEUE and make a user-space decision based on
>> packet-destination (since it seems you’re filtering outbound traffic
>> requests).
>>
>> After all, it’s not the NAME you don’t want to talk to… it’s the HOST that
>> bears that NAME.
>>
>> -Philip
>>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Talks between OpenWrt and LEDE

2016-12-21 Thread Dave Taht
On Wed, Dec 21, 2016 at 12:29 PM, David Lang  wrote:
> On Wed, 21 Dec 2016, Kathy Giori wrote:
>
>> From a PR perspective, I strongly suggest keeping the term OpenWrt as
>> part of the branding of the project moving forward. It can just be
>> cosmetic (web site, etc.) but the name has so much history, and
>> positive connotation, that you don't want to lose that brand attached
>> to the development moving forward.
>
>
> I agree, I think this is an obvious choice to make. OpenWRT has a lot of
> name recognition, it would be foolish to throw that away.

Just to take the other side for rhetorical purposes, a purpose of a
re-branding exercise is to show a change in the "product" or
organisation behind it. OpenWrt is widely known... as a bleeding edge,
sometimes unstable, somewhat hard to use 3rd party firmware. DD-Wrt
and Tomato get a lot more press for some reason. So do things like
Yocto. If lede were to succeed in meeting its other goals, coherently,
preserving "lede" and moving forward as a separate project does make
sense.

> David Lang
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] BT Home Hub 5 support

2016-11-29 Thread Dave Taht
since broadcom was sold to another company recently is there any sign
we'll see open drivers for the BCM4360 ?

On Tue, Nov 29, 2016 at 5:11 AM, Mauro M.  wrote:
> Hello,
>
> From the OpenWrt wiki page: https://wiki.openwrt.org/toh/bt/homehub_v5a
> I understand that support for BT Home Hub 5 was included in DD trunk.
>
> I pulled the latest trunk source 50013 from git, but the image is not built
> under bin/lantiq as expected.
>
> As deducted from the firmware images available on-line
> (openwrt-lantiq-xrx200-BTHOMEHUBV5A-install-uImage-initramfs) I am using:
> Target System (Lantiq)  --->
> Subtarget (XRX200)  --->
> Target Profile (Default Profile)  --->
>
> There is nothing else other than Default Profile. I was expecting to find a
> specific BTHOMEHUB5 configuration.
>
> I run a grep on the code and I found  the following:
>
> ./target/linux/lantiq/image/Makefile:Image/BuildKernel/Profile/BTHOMEHUBV5A=$(call
> Image/BuildKernel/Template,BTHOMEHUBV5A)
> ./target/linux/lantiq/image/Makefile:Image/Build/Profile/BTHOMEHUBV5A=$(call
> Image/BuildNAND/$(1),$(1),BTHOMEHUBV5A)
> ./target/linux/lantiq/image/Makefile:define LegacyDevice/BTHOMEHUBV5A
> ./target/linux/lantiq/image/Makefile:LEGACY_DEVICES += BTHOMEHUBV5A
> ./target/linux/lantiq/base-files/etc/board.d/01_leds:BTHOMEHUBV5A)
> ./target/linux/lantiq/base-files/etc/board.d/02_network:BTHOMEHUBV5A)
> ./target/linux/lantiq/base-files/etc/hotplug.d/firmware/11-ath10k-caldata:
> BTHOMEHUBV5A)
> ./target/linux/lantiq/dts/BTHOMEHUBV5A.dts:model = "BTHOMEHUBV5A - BT
> Home Hub 5A";
>
> However I am not sure how to activate the build.
> Please could you help?
>
> Thank you in advance,
> Mauro
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [LEDE-DEV] RFC netifd: UCI parameter to sort name servers in resolv.conf.auto

2016-09-05 Thread Dave Taht
One other point about provider order in dnsmasq.

dnsmasq added long ago the facility (particularly for reverse lookups
on ipv6) to bind source addresses to destination dns servers. This
solves a portion of this problem. Stuff coming in from one ipv6
network gets dns lookups out the right network (I don't remember all
the syntax now, I can go look)

Openwrt/lede would need to get away from using resolv.conf to do this
stuff more right, which is ok by me since it isn't up to this job.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] shutting down gb10 soon from the build cluster

2016-07-28 Thread Dave Taht
I can no longer afford to contribute ~$850/month to the openwrt and
lede projects' build clusters, so gb10 will be "going away" as soon as
travis tells me it's migrated off of, or aug 10th, whichever is
sooner.

It is still my hope that some sane way of funding the continuous
integration system and the maintainers of it emerges, as per this old
conversation here:

https://lists.openwrt.org/pipermail/openwrt-devel/2015-December/037781.html

but I've got to cut things back. It appears that the current openwrt
build cluster is sizeable enough for the load, currently, and gb10,
will not be especially missed.

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [OpenWrt] openwrt build system costs: support of or foundation over?

2015-12-08 Thread Dave Taht
ing openwrt better.
how would y'all like to spend it? ".

"We also have one time grants available for X and Y amounts - How have
you been supporting openwrt, how can we thank you?"

> If you and the OpenWrt team could explain the situation
> better, what's hosted where, what the costs are and I understand the
> situation better, I can recommend to prpl leadership that funding be
> considered.

My take on it was about 1.7k/month of google compute got all basic
builds done for everything in under 12 hours each. Arguably more than
one cluster should be used (security/safety/redundancy) and more than
one linux distro used to build it, and if there were ways to get the
build time down, or just test build new stuff faster, great...


> Eric
>
> On Mon, Dec 7, 2015 at 12:51 PM, Dave Taht <dave.t...@gmail.com> wrote:
>>
>> I am still not sure what prpl is for. Nor, what happens to donated
>> funds, if any...
>>
>> I have long wanted some non-profit org to serve as an intermediary
>> between the profit centered corps and the developers. I don't think
>> SPI or prpl is doing this right. Linaro sort of used to...
>>
>> There needs to be some sort of translation between the three parties
>> of real needs. A corp is used to paying X for Y, in particular, not
>> fuzzy donations...
>>
>> As sort of a test case for what I'm trying to explain, there are a few
>> people that contribute towards keeping the Continuous Integration and
>> build system of openwrt up and running, both in terms of hardware, and
>> time.
>>
>> Many have been doing it longer than I have, but for most of the last 4
>> years a lot of the visible hardware came from me (snapon, huchra,
>> gb-XX).
>>
>> For 14 months of that, courtesy of a google cloud grant that expired
>> last year, I was running 6(?) boxes at a cost of about $1750/month, +
>> 2 donated boxes from isc.org - and builds popped out in half a day for
>> everything.  I liked it
>>
>> I had to shut all but one machine off after that grant expired, and
>> isc has (sadly) just shut down their free non-profit hosting service
>> also... huchra is nearly gone, snapon has moved to sweden behind a fw
>> where it can't act as a host...
>>
>> ... and recently I see that the lack of enough machines in the build
>> system was annoying enough to at least one party to start up a new
>> box...
>>
>> ... but - dang it! -  the benefits of CI for openwrt should be
>> *obvious to everyone that uses it*. Especially including some big
>> corps for which the opex of a few thousand dollars a month isn't even
>> noticeable.
>>
>> HP supports debian's build cluster, for example.
>>
>> Now, of late, I've had a devil of a time keeping the lights on. My
>> contribution to the cluster costs me $220/month that I would rather
>> spend on... food, and fixing wifi in general, etc [1]
>>
>> So... I'd like it if there was some org(s) were paying these costs
>> (and for everyone else contributing a box themselves) rather than me.
>> That is a "support of" sort of thing, where control remains in the
>> hands of engineers that care. (In fact, I don't have to care, travis
>> takes care of the problems, I just pay the opex bill)
>>
>> If some org were to "take over" this responsibility, the control slips
>> to that org - gains management - and other BS - and the CI might not
>> get done as well.
>>
>> If some org were to however, take a wishlist of existing costs from
>> existing developers, turn that into a budget, present that to willing
>> commercial orgs, and turn that around to the requesting dev (and
>> publicly), then everyone's lives would be better. X for Y with the
>> help of Z.
>>
>> Mine, and (I think) most of openwrt folk's resistance to
>> "organizations" comes from the top down attempt at exerting control in
>> exchange for money.
>>
>> ...
>>
>> Certainly the build system could get done better! I was very happy
>> seeing benchmarks go by with how much faster they could be done... and
>> doing that right does involve human resources that might want to get
>> paid also... the main reason why gb-10 still exists is because it was
>> weeks of time to get it running in the first place, and easy to
>> replicate, and I'd hate to lose those invested weeks were more grant
>> money to arrive...
>>
>> Now: I have no intention of shutting down gb-10, but I came within
>> hours of having to do so, last month. Got saved by a shuttleworth
>> flash grant...
>>
>&

[OpenWrt-Devel] Fwd: [homenet] Protocol Action: 'Home Networking Control Protocol' to Proposed Standard (draft-ietf-homenet-hncp-10.txt)

2015-12-08 Thread Dave Taht
While I'm dreaming of steadier funding for things I care about,
ietf homenet wg's work is nearly complete.

*most* of the work is already done in openwrt to make all the ietf
homenet proposed standards work, and indeed, be the default in
openwrt. However nobody is funded anymore to take it further, and it
would be nice to see builds taking place and tested automagically - to
finally bring the dream of always interoperable, ipv6 capable cpe and
home routers, plugged in, every which way - a reality.

There are still many details left to make it happen well and be a
truly usable set of interoperable standards - I have a huge list of
things still not encapsulated or negotiated right within the hncp
stack, such as wifi channel selection and uplink bandwidth, and babel
is in need of some love, there are some state machine bugs that need
squashing.

-- Forwarded message --
From: The IESG 
Date: Tue, Dec 8, 2015 at 3:09 PM
Subject: [homenet] Protocol Action: 'Home Networking Control Protocol'
to Proposed Standard (draft-ietf-homenet-hncp-10.txt)
To: IETF-Announce 
Cc: homenet-cha...@ietf.org, m...@townsley.net,
draft-ietf-homenet-h...@ietf.org, The IESG ,
home...@ietf.org, terry.mander...@icann.org, rfc-edi...@rfc-editor.org


The IESG has approved the following document:
- 'Home Networking Control Protocol'
  (draft-ietf-homenet-hncp-10.txt) as Proposed Standard

This document is the product of the Home Networking Working Group.

The IESG contact persons are Brian Haberman and Terry Manderson.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/





Technical Summary

This document describes the Home Networking Control Protocol (HNCP),
an extensible distributed configuration protocol for “unmanaged”
(e.g., functions that are not configured manually or by a central
management server of some kind) home network devices. The intent is to
provide a distributed protocol for flooding of basic configuration
state essential to IP network functionality.

HNCP is described as a profile of and extension to the Distributed
Node Consensus Protocol (DNCP).  HNCP enables discovery of network
topology and borders, automated configuration of addresses (using the
algorithm defined in draft-ietf-homenet-prefix-assignment-08), name
resolution, and service discovery.

Working Group Summary

The earliest roots of HNCP are in draft-acee-ospf-ospfv3-autoconfig-00
(Oct 2011) which was eventually published as Standards Track RFC 7503,
 with the expectation that other documents would define
HOMENET-specific TLVs to be carried inside OSPFv3.

Strong resistance from the WG (as well as open source router software
developers) to this tight coupling between a specific routing protocol
and network configuration led to the split of HNCP as a standalone
protocol first defined in draft-stenberg-homenet-hncp-00.

Later, DNCP (generic aspects of HNCP concerning synchronization of
state among a set of nodes using Trickle[RFC6206]) were split from the
main HNCP document to allow for modularity and potential reuse. After
this final split, the HNCP document describes the HOMENET-specific
TLVs and the DNCP profile used to synchronize them across the home
network.

Document Quality

  Are there existing implementations of the protocol?

The reference “hnetd” implementation is at
https://github.com/sbyx/hnetd/ (project homepage at
http://www.homewrt.org/doku.php).

There is a second (fully independent and interoperable) implementation
available at https://github.com/jech/shncpd developed entirely from
the specification documents without referal to the reference
implementation.

There is a partial third implementation, though not fully independent,
available here: https://github.com/fingon/pysyma


  Have a significant number of vendors indicated their plan to
  implement the specification?


The reference implementation has been a part of routing feed of
OpenWrt since Barrier Breaker (14.07) release in July, 2014.

Google Nest, Comcast Xfinity, D-Link, Freebox, Technicolor, and Cisco
have all expressed interest in implementing and/or shipping HNCP. HNCP
is referenced in version 1.0 of the Thread Specification (Nest,
Samsung, etc.)

“Homenet” running either the early OSPF version and later HNCP (with
DNCP) has been demonstrated publicly at 9 IETF BnB events (every BnB
since BnB began, plus at least one “pre BnB” event), HNCP split off
from OSPF has been demontrated at the last 5 IETF BnB events. In
addition to IETF, Homenet Implementations have been presented at:

3 IPv6 World Congress events in Paris
1 CES Event in Las Vegas
1 Cablelabs Meeting in Denver, Co

Are there any reviewers that merit special mention as having done a
thorough review,  e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course

Re: [OpenWrt-Devel] Fwd: [homenet] Protocol Action: 'Home Networking Control Protocol' to Proposed Standard (draft-ietf-homenet-hncp-10.txt)

2015-12-08 Thread Dave Taht
On Tue, Dec 8, 2015 at 6:48 PM, L. D. Pinney <ldpin...@gmail.com> wrote:
> Why has this been cross posted to the OpenWrt Development List?
>
> I fail to see any relevance to the usual and prevailing use of this list.

Well, I do keep hoping more folk within openwrt actually try the
hnet-full and babel packages.  and unless someone actually pokes at
the list(s), once in a while, nothing happens. hnet includes a pretty
radical set of changes to how firewalling, ip address assignment and
dns are done...

If there is a better list to poke at, let me know. Sorry to be annoying.

> On Tue, Dec 8, 2015 at 10:52 AM, Dave Taht <dave.t...@gmail.com> wrote:
>>
>> While I'm dreaming of steadier funding for things I care about,
>> ietf homenet wg's work is nearly complete.
>>
>> *most* of the work is already done in openwrt to make all the ietf
>> homenet proposed standards work, and indeed, be the default in
>> openwrt. However nobody is funded anymore to take it further, and it
>> would be nice to see builds taking place and tested automagically - to
>> finally bring the dream of always interoperable, ipv6 capable cpe and
>> home routers, plugged in, every which way - a reality.
>>
>> There are still many details left to make it happen well and be a
>> truly usable set of interoperable standards - I have a huge list of
>> things still not encapsulated or negotiated right within the hncp
>> stack, such as wifi channel selection and uplink bandwidth, and babel
>> is in need of some love, there are some state machine bugs that need
>> squashing.
>>
>> -- Forwarded message --
>> From: The IESG <iesg-secret...@ietf.org>
>> Date: Tue, Dec 8, 2015 at 3:09 PM
>> Subject: [homenet] Protocol Action: 'Home Networking Control Protocol'
>> to Proposed Standard (draft-ietf-homenet-hncp-10.txt)
>> To: IETF-Announce <ietf-annou...@ietf.org>
>> Cc: homenet-cha...@ietf.org, m...@townsley.net,
>> draft-ietf-homenet-h...@ietf.org, The IESG <i...@ietf.org>,
>> home...@ietf.org, terry.mander...@icann.org, rfc-edi...@rfc-editor.org
>>
>>
>> The IESG has approved the following document:
>> - 'Home Networking Control Protocol'
>>   (draft-ietf-homenet-hncp-10.txt) as Proposed Standard
>>
>> This document is the product of the Home Networking Working Group.
>>
>> The IESG contact persons are Brian Haberman and Terry Manderson.
>>
>> A URL of this Internet Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/
>>
>>
>>
>>
>>
>> Technical Summary
>>
>> This document describes the Home Networking Control Protocol (HNCP),
>> an extensible distributed configuration protocol for “unmanaged”
>> (e.g., functions that are not configured manually or by a central
>> management server of some kind) home network devices. The intent is to
>> provide a distributed protocol for flooding of basic configuration
>> state essential to IP network functionality.
>>
>> HNCP is described as a profile of and extension to the Distributed
>> Node Consensus Protocol (DNCP).  HNCP enables discovery of network
>> topology and borders, automated configuration of addresses (using the
>> algorithm defined in draft-ietf-homenet-prefix-assignment-08), name
>> resolution, and service discovery.
>>
>> Working Group Summary
>>
>> The earliest roots of HNCP are in draft-acee-ospf-ospfv3-autoconfig-00
>> (Oct 2011) which was eventually published as Standards Track RFC 7503,
>>  with the expectation that other documents would define
>> HOMENET-specific TLVs to be carried inside OSPFv3.
>>
>> Strong resistance from the WG (as well as open source router software
>> developers) to this tight coupling between a specific routing protocol
>> and network configuration led to the split of HNCP as a standalone
>> protocol first defined in draft-stenberg-homenet-hncp-00.
>>
>> Later, DNCP (generic aspects of HNCP concerning synchronization of
>> state among a set of nodes using Trickle[RFC6206]) were split from the
>> main HNCP document to allow for modularity and potential reuse. After
>> this final split, the HNCP document describes the HOMENET-specific
>> TLVs and the DNCP profile used to synchronize them across the home
>> network.
>>
>> Document Quality
>>
>>   Are there existing implementations of the protocol?
>>
>> The reference “hnetd” implementation is at
>> https://github.com/sbyx/hnetd/ (project homepage at
>> http://www.homewrt.org/doku.php).
>>
>> There is a second (fully indepe

[OpenWrt-Devel] openwrt build system costs: support of or foundation over?

2015-12-07 Thread Dave Taht
I am still not sure what prpl is for. Nor, what happens to donated
funds, if any...

I have long wanted some non-profit org to serve as an intermediary
between the profit centered corps and the developers. I don't think
SPI or prpl is doing this right. Linaro sort of used to...

There needs to be some sort of translation between the three parties
of real needs. A corp is used to paying X for Y, in particular, not
fuzzy donations...

As sort of a test case for what I'm trying to explain, there are a few
people that contribute towards keeping the Continuous Integration and
build system of openwrt up and running, both in terms of hardware, and
time.

Many have been doing it longer than I have, but for most of the last 4
years a lot of the visible hardware came from me (snapon, huchra,
gb-XX).

For 14 months of that, courtesy of a google cloud grant that expired
last year, I was running 6(?) boxes at a cost of about $1750/month, +
2 donated boxes from isc.org - and builds popped out in half a day for
everything.  I liked it

I had to shut all but one machine off after that grant expired, and
isc has (sadly) just shut down their free non-profit hosting service
also... huchra is nearly gone, snapon has moved to sweden behind a fw
where it can't act as a host...

... and recently I see that the lack of enough machines in the build
system was annoying enough to at least one party to start up a new
box...

... but - dang it! -  the benefits of CI for openwrt should be
*obvious to everyone that uses it*. Especially including some big
corps for which the opex of a few thousand dollars a month isn't even
noticeable.

HP supports debian's build cluster, for example.

Now, of late, I've had a devil of a time keeping the lights on. My
contribution to the cluster costs me $220/month that I would rather
spend on... food, and fixing wifi in general, etc [1]

So... I'd like it if there was some org(s) were paying these costs
(and for everyone else contributing a box themselves) rather than me.
That is a "support of" sort of thing, where control remains in the
hands of engineers that care. (In fact, I don't have to care, travis
takes care of the problems, I just pay the opex bill)

If some org were to "take over" this responsibility, the control slips
to that org - gains management - and other BS - and the CI might not
get done as well.

If some org were to however, take a wishlist of existing costs from
existing developers, turn that into a budget, present that to willing
commercial orgs, and turn that around to the requesting dev (and
publicly), then everyone's lives would be better. X for Y with the
help of Z.

Mine, and (I think) most of openwrt folk's resistance to
"organizations" comes from the top down attempt at exerting control in
exchange for money.

...

Certainly the build system could get done better! I was very happy
seeing benchmarks go by with how much faster they could be done... and
doing that right does involve human resources that might want to get
paid also... the main reason why gb-10 still exists is because it was
weeks of time to get it running in the first place, and easy to
replicate, and I'd hate to lose those invested weeks were more grant
money to arrive...

Now: I have no intention of shutting down gb-10, but I came within
hours of having to do so, last month. Got saved by a shuttleworth
flash grant...

At the moment I am just sending the personal - not a single !@#!
corporate - donations I get at the below url to keep it running, and
not thinking about it very hard - but I just reached for some spare
cash to buy a new board, and came up empty.

it's the meta problem, of keeping infrastructure beneath the devs, in
general, with a minimal amount of overstructure on top, that's bugging
me today.

thx for listening. ideas?


Dave Täht
Keeping the lights on for open routers
[1] https://www.patreon.com/dtaht?ty=h
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v4] ramips: add support for MQmaker WiTi board

2015-12-03 Thread Dave Taht
Is this the one with the promising 802.11ac chipset?

If so, how do I get a few?

If not, how do I get one? :)

On Thu, Dec 3, 2015 at 12:17 PM, John Crispin  wrote:
> offtopic ... my 2 samples of this board just arrived :) i know what i
> will be testing later on today
>
> On 03/12/2015 12:13, Felix Fietkau wrote:
>> On 2015-12-03 07:20, Sebastian Careba wrote:
>>> The board is based on mt7621AT cpu, and has 16mb nor flash, 256mb of ram, 2 
>>> sata ports, microsd card slot, 1 USB 3.0 port and at least one 2.4 and one 
>>> 5 ghz antenna. This is the 4th submission that fixes the naming scheme for 
>>> Mqmaker WiTi board.
>>> Patch v1 added initial support for MQmaker WiTi board. The device tree is 
>>> based on PBR-M1.
>>> Patch v2 changed the flash chip ID (w25q256 to gd25q128).
>>> Patch v3 fixed the left-out entry for WiTi in 02_network.
>>>
>>> Signed-off-by: Sebastian Careba 
>>> ---
>>>  .../patches-3.18/999-add_gd25q128_support.patch|  13 ++
>>>  .../linux/ramips/base-files/etc/board.d/02_network |   1 +
>>>  target/linux/ramips/base-files/etc/diag.sh |   1 +
>>>  target/linux/ramips/base-files/lib/ramips.sh   |   3 +
>>>  .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
>>>  target/linux/ramips/dts/WITI.dts   | 142 
>>> +
>>>  target/linux/ramips/image/Makefile |   7 +-
>>>  target/linux/ramips/mt7621/profiles/mqmaker.mk |  20 +++
>>>  8 files changed, 187 insertions(+), 1 deletion(-)
>>>  create mode 100644 
>>> target/linux/generic/patches-3.18/999-add_gd25q128_support.patch
>>>  create mode 100644 target/linux/ramips/dts/WITI.dts
>>>  create mode 100644 target/linux/ramips/mt7621/profiles/mqmaker.mk
>>>
>>> diff --git 
>>> a/target/linux/generic/patches-3.18/999-add_gd25q128_support.patch 
>>> b/target/linux/generic/patches-3.18/999-add_gd25q128_support.patch
>>> new file mode 100644
>>> index 000..e9c380b
>>> --- /dev/null
>>> +++ b/target/linux/generic/patches-3.18/999-add_gd25q128_support.patch
>>> @@ -0,0 +1,13 @@
>>> Index: linux-3.18.23/drivers/mtd/devices/m25p80.c
>>> ===
>>> --- linux-3.18.23.orig/drivers/mtd/devices/m25p80.c
>>> +++ linux-3.18.23/drivers/mtd/devices/m25p80.c
>>> @@ -352,7 +352,7 @@ static const struct spi_device_id m25p_i
>>>  {"en25q64"},{"en25qh128"},  {"en25qh256"},
>>>  {"f25l32pa"},
>>>  {"mr25h256"},   {"mr25h10"},
>>> -{"gd25q32"},{"gd25q64"},
>>> +{"gd25q32"},{"gd25q64"},{"gd25q128"},
>>>  {"160s33b"},{"320s33b"},{"640s33b"},
>>>  {"mx25l2005a"}, {"mx25l4005a"}, {"mx25l8005"},  {"mx25l1606e"},
>>>  {"mx25l3205d"}, {"mx25l3255e"}, {"mx25l6405d"}, {"mx25l12805d"},
>> Please drop this patch (see below).
>>
>>> --- /dev/null
>>> +++ b/target/linux/ramips/dts/WITI.dts
>>> @@ -0,0 +1,142 @@
>>> +/dts-v1/;
>>> +
>>> +/include/ "mt7621.dtsi"
>>> +
>>> +/ {
>>> +compatible = "mediatek,mt7621-eval-board", "mediatek,mt7621-soc";
>>> +model = "MQmaker WiTi";
>>> +
>>> +memory@0 {
>>> +device_type = "memory";
>>> +reg = <0x0 0x1000>;
>>> +};
>>> +
>>> +chosen {
>>> +bootargs = "console=ttyS0,57600";
>>> +};
>>> +
>>> +sdhci@1013 {
>>> +status = "okay";
>>> +};
>>> +
>>> +palmbus@1E00 {
>>> +spi@b00 {
>>> +status = "okay";
>>> +
>>> +m25p80@0 {
>>> +#address-cells = <1>;
>>> +#size-cells = <1>;
>>> +compatible = "gd25q128";
>> Please use 'jedec,spi-nor' here, so you don't have to patch in the
>> device id for this chip.
>>
>> - Felix
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] buildbot: gb15 fails to upload due to host keys

2015-11-23 Thread Dave Taht
On Mon, Nov 23, 2015 at 11:07 AM, Zoltan HERPAI  wrote:
> Hannu A Nyman wrote:
>>
>> Well, both gb15 and buildslave2 still fail to upload binaries, and as they
>> are making 9 of the 22 concurrent builds, almost half of the compiled
>> binaries are discarded. Sad.
>>
>> Logs from today:
>>
>> http://buildbot.openwrt.org:8010/builders/x86.kvm_guest/builds/119/steps/shell_11/logs/stdio
>>
>> http://buildbot.openwrt.org:8010/builders/brcm2708/builds/126/steps/shell_11/logs/stdio
>>
>>  Upload Snapshot to Openwrt
>>  Host key verification failed.
>>  rsync: connection unexpectedly closed (0 bytes received so far) [sender]
>>  rsync error: unexplained error (code 255) at io.c(605) [sender=3.0.9]
>
> gb15 is fixed now.

I note that I have long been paying for the google openwrt build
cluster out of my own pocket (after the google grant expired last year
- which was costing 1700/month for 5? 6? servers), but I had cut it
down to just gb10, which is cost me about $250/month.

I am hoping some more grant money arrives (not a lot!) next year.

I was unaware of gb15 (not coming out of my account, thankfully), and
am glad someone else is covering costs on it...

IF there is a need to turn around openwrt builds even quicker, (how
much quicker can it be done?) we can re-scale up my old google cluster
if there is funding for it from somewhere. I can keep the one server
I'm contributing up and running indefinitely. Or... ?

I have always wished we could do a full build in under 3 hours, and
could circulate package changes around in minutes, rather than in a
full build.



>
> Regards,
>
> -w-
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] dan gillmor nails why I just did what I did

2015-10-19 Thread Dave Taht
From:

http://www.slate.com/blogs/future_tense/2015/10/15/trans_pacific_partnership_could_thwart_computer_security_research_and_tinkering.html

"Surely our government isn't insane enough to thwart research designed
to keep us safer in the emerging “Internet of Things.” Yet tell that,
for starters, to the automobile industry, where one of the world's
largest car makers, Volkswagen, cheated on emissions testing by
tweaking its software. This crime against humanity—not an
exaggeration, given the massive contribution this may have made to
accelerating climate change—was discovered by researchers who, by good
luck, discovered that VW's cars had been spewing vastly more
pollutants than the company claimed for years. This almost certainly
would have been uncovered much earlier had the industry not relied on
the Digital Millennium Copyright Act to “protect” its software from
analysis; the DMCA made it illegal to circumvent “digital restrictions
management.” Yet the automakers continue to adamantly oppose any
exception to the DMCA.

This TPP provision, assuming it's in the final document—won't it be
great when our government allows us to actually see it?—is just one of
the many, many terrible “intellectual property” arrangements aimed at
giving corporations greater control over their customers. When
software is part of a product, as it is in so many things today and
almost everything tomorrow, the very concept of ownership becomes an
abstraction for the alleged buyer. And when we risk harsh penalties
for even attempting to repair a device that's defective, whether
that's because of the seller's incompetence or venality, we are in a
totally untenable, and frighteningly insecure, position.

We need to be going in precisely the opposite direction, and a
too-little-noticed proposal this week shows how it might be done. A
group of security experts looked into the absolutely horrifying, and
willful, lack of security in devices most of us use every
day—especially the Wi-Fi routers that let us share one Internet
connection among a variety of devices—and asked the Federal
Communications Commission to intervene.

In a letter to the FCC and a press release explaining their goals,
more than 250 people, including Vint Cerf, one of the Internet's
creators, implored the agency to make these crucial devices more
secure by forcing manufacturers to be more open about how they work.
Among other things, the security experts asked the FCC to require that
device makers a) provide public access to “source code”—the
programming instructions that operate the device—so that it can be
analyzed; b) provide ongoing security updates in timely ways; and c)
be prevented from selling devices that don't comply with those and
other rules designed to ensure security.

The FCC should make this happen yesterday. Then, regulators and
Congress should extend the compelling logic of this proposal to other
devices—notably cars and mobile phones—that are notoriously riddled
with flaws.

Meanwhile, it's vital that Congress not agree to the TPP as it's
currently written. Thankfully, the deal is in trouble. Let's hope the
odd-couple combination of a corporate-dominated Obama administration
and a Republican-controlled Congress doesn't override common sense and
the public good."

Scientists and Engineers have a mandate to obey physical law. Lawyers,
and lobbyists, not so much.

Dave Täht
I just lost several years of my life to making wifi better. And the
FCC wants to mess all that up. https://www.gofundme.com/savewifi
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] how we hope to fix wifi and the internet

2015-10-14 Thread Dave Taht
I think many of those here would be delighted to read about our
proposal to washington dc, and other regulators of wifi in the world.

http://www.businesswire.com/news/home/20151014005564/en/Global-Internet-Experts-Reveal-Plan-Secure-Reliable

I note our main servers got completely slammed, you can
get the letter from this alternate url, instead.

http://fqcodel.bufferbloat.net/~d/fcc_saner_software_practices.pdf

-- 
Dave Täht
Do you want faster, better, wifi? https://www.patreon.com/dtaht
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] Last call for signatures to the FCC on the wifi lockdown issue

2015-10-09 Thread Dave Taht
The CeroWrt project's letter to the FCC on how to better manage the
software on wifi and home routers vs some proposed regulations is now
in last call for signatures. The final draft of our FCC submittal is
here:

https://docs.google.com/document/d/15QhugvMlIOjH7iCxFdqJFhhwT6_nmYT2j8xAscCImX0/edit?usp=sharing

The principal signers (Dave Taht and Vint Cerf), are joined by many
network researchers, open source developers, and dozens of developers
of aftermarket firmware projects like OpenWrt.

Prominent signers currently include:

Jonathan Corbet, David P. Reed, Dan Geer, Jim Gettys, Phil Karn, Felix
Fietkau, Corinna "Elektra" Aichele, Randell Jesup, Eric S. Raymond,
Simon Kelly, Andreas Petlund, Sascha Meinrath, Joe Touch, Dave Farber,
Nick Feamster, Paul Vixie, Bob Frankston, Eric Schultz, Brahm Cohen,
Jeff Osborn, Harald Alvestrand, and James Woodyatt.

If you would like to join our call for substituting sane software
engineering practices over misguided regulations, the window for
adding your signature to the letter closes at 11:59AM ET, today,
Friday, 2015-10-08.

Sign via webform here: http://goo.gl/forms/WCF7kPcFl9

We are at approximately 170 signatures as I write.

For more details on the controversy we are attempting to address, or
to submit your own filing to the FCC see:

https://libreplanet.org/wiki/Save_WiFi
https://www.dearfcc.org/

Sincerely,

Dave Täht
CeroWrt Project Architect
Tel: +46547001161
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] the cerowrt project's letter to the fcc about the wifi lockdown is nearly final

2015-10-05 Thread Dave Taht
see:

https://docs.google.com/document/d/1E1D1vWP9uA97Yj5UuBPZXuQEPHARp-AhRqUOeQB2WPk/edit?usp=sharing

for more details.

We still have a boatload of footnotes (help?) to add back in properly,
and there are no doubt other problems we will catch in the morning.
Comment away!

As we are hard up against deadlines, and I no longer expect
substantial changes, all new offers of signature will be considered
final.

signatures are now being collected via: http://goo.gl/forms/WCF7kPcFl9
- the 70+ that have already committed need to be contacted again to
approve this draft.


-- 
Dave Täht
Do you want faster, better, wifi? https://www.patreon.com/dtaht
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] ar71xx: fix 100/10mbps ethernet link issues on mynet range extender

2015-06-05 Thread Dave Taht
TX delay setting? What else can it do?

My dream has been to find a way to set the tx completion interrupt
to only return with a soft set rate. So if I had a gigE connection
but my uplink was only 10Mbits, it would return the interrupt
after 1.3ms had expired.

this would let me get away entirely from using software rate limiting
with htb, just program a register once with the uplink rate, and
let bql and fq_codel handle the rest.

On Wed, Jun 03, 2015 at 05:20:22PM +0200, Christian Lamparter wrote:
 The mynet range extender hardware is suffering from ethernet
 link loss when booting with a recent openwrt image. This only
 happens on 100mbps links, with 1Gbps speed the link was fine.
 
 The cause of the problem is that the AR8035 PHY (aka F1E)
 requires turning on and off the special TX delay setting
 depending on the speed of the link.
 
 The 10mbps mode only needed the proper pll value, which was
 extracted from the vendor code.
 
 Reported-by: Pascal Paradis
 Signed-off-by: Christian Lamparter chunk...@googlemail.com
 ---
  .../ar71xx/files/arch/mips/ath79/mach-mynet-rext.c | 20 
  ...t-phy-at803x-allow-to-configure-via-pdata.patch | 53 
 --
  2 files changed, 69 insertions(+), 4 deletions(-)
 
 diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c 
 b/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
 index 02d168e..3d48ca8 100644
 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
 +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
 @@ -14,6 +14,7 @@
  #include linux/platform_device.h
  #include linux/ath9k_platform.h
  #include linux/ar8216_platform.h
 +#include linux/platform_data/phy-at803x.h
  
  #include asm/mach-ath79/ar71xx_regs.h
  
 @@ -124,6 +125,21 @@ static struct gpio_keys_button mynet_rext_gpio_keys[] 
 __initdata = {
   },
  };
  
 +static struct at803x_platform_data mynet_rext_at803x_data = {
 + .disable_smarteee = 0,
 + .enable_rgmii_rx_delay = 1,
 + .enable_rgmii_tx_delay = 0,
 + .fixup_rgmii_tx_delay = 1,
 +};
 +
 +static struct mdio_board_info mynet_rext_mdio0_info[] = {
 +{
 +.bus_id = ag71xx-mdio.0,
 +.phy_addr = 4,
 +.platform_data = mynet_rext_at803x_data,
 +},
 +};
 +
  static void mynet_rext_get_mac(const char *name, char *mac)
  {
   u8 *nvram = (u8 *) KSEG1ADDR(MYNET_REXT_NVRAM_ADDR);
 @@ -169,12 +185,16 @@ static void __init mynet_rext_setup(void)
  
   ath79_register_mdio(0, 0x0);
  
 + mdiobus_register_board_info(mynet_rext_mdio0_info,
 + ARRAY_SIZE(mynet_rext_mdio0_info));
 +
   /* LAN */
   mynet_rext_get_mac(et0macaddr=, ath79_eth0_data.mac_addr);
  
   /* GMAC0 is connected to an external PHY on Port 4 */
   ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
   ath79_eth0_data.phy_mask = BIT(4);
 + ath79_eth0_pll_data.pll_10   = 0x1313; /* athrs_mac.c */
   ath79_eth0_pll_data.pll_1000 = 0x0e00; /* athrs_mac.c */
   ath79_eth0_data.mii_bus_dev = ath79_mdio0_device.dev;
   ath79_register_eth(0);
 diff --git 
 a/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
  
 b/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
 index babc695..d046ede 100644
 --- 
 a/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
 +++ 
 b/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
 @@ -32,6 +32,14 @@
   #define AT803X_DEBUG_SYSTEM_MODE_CTRL   0x05
   #define AT803X_DEBUG_RGMII_TX_CLK_DLY   BIT(8)
   
 +@@ -50,6 +60,7 @@ MODULE_LICENSE(GPL);
 + struct at803x_priv {
 + bool phy_reset:1;
 + struct gpio_desc *gpiod_reset;
 ++int prev_speed;
 + };
 + 
 + struct at803x_context {
  @@ -61,6 +71,43 @@ struct at803x_context {
   u16 led_control;
   };
 @@ -120,16 +128,53 @@
   return 0;
   }
   
 +@@ -258,6 +334,8 @@ static int at803x_config_intr(struct phy
 + static void at803x_link_change_notify(struct phy_device *phydev)
 + {
 + struct at803x_priv *priv = phydev-priv;
 ++struct at803x_platform_data *pdata;
 ++pdata = dev_get_platdata(phydev-dev);
 + 
 + /*
 +  * Conduct a hardware reset for AT8030 every time a link loss is
 +@@ -287,6 +365,26 @@ static void at803x_link_change_notify(st
 + } else {
 + priv-phy_reset = false;
 + }
 ++}
 ++if (pdata-fixup_rgmii_tx_delay 
 ++phydev-speed != priv-prev_speed) {
 ++switch (phydev-speed) {
 ++case SPEED_10:
 ++case SPEED_100:
 ++at803x_dbg_reg_set(phydev,
 ++AT803X_DEBUG_SYSTEM_MODE_CTRL,
 ++AT803X_DEBUG_RGMII_TX_CLK_DLY);
 ++break;
 ++case SPEED_1000:
 ++

Re: [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt

2014-10-08 Thread Dave Taht
On Wed, Oct 08, 2014 at 11:10:46PM +0300, Hannu Nyman wrote:
 Dave Taht wrote on Thu Oct 2 03:49:15 CEST 2014:
  So I don't know where to go. Certainly I'd like to see the battle
 hardened sqm scripts (which are more flexible than the C code above)
 get more widely used and in BB.
 
 SQM seems to work ok with the current Chaos Calmer trunk.

Well, for now... I'd expect the delta to break eventually...

 
 I have included your SQM in my trunk WNDR3700/3800 community build (
 https://forum.openwrt.org/viewtopic.php?id=28392 ) and it works ok.
 Arokh has also picked it up for his build (
 https://forum.openwrt.org/viewtopic.php?id=50914 ). So you might get
 more feedback sooner or later, if users of our builds really do try
 it.

Excellent. I'd *really* like to get some testers doing ingress shaping
at above 60-80mbits, which seems to be a brick wall we've hit on
the ar71xx and octeon, on other platforms like the arm and x86.

A tool we use a lot is netperf-wrapper.

 I feel that the best way to get wider testing and real-life usage
 for SQM would be to create a pull request in the new packages feed
 in Github, to get both the SQM itself and the Luci frontend included
 there. Being available in the packages feed would create more
 interest for the package. If it proves to work ok, the devs might
 then import it into the core Openwrt repo (where the old qos-scripts
 is).

I went to sleep pre BBrc1. I woke up, and everything was in github.

It's still not clear to me how I'd build cero from frozen BB sources,
rather than the evolving github packages.

 
 
 Ps. For my own build I made a slight modification to the Luci menu item, as 
 pure SQM does not say much. I changed it to SQM QoS.
 

Yes, SQM by itself doesn't mean enough.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt

2014-10-08 Thread Dave Taht
On Thu, Oct 09, 2014 at 01:01:48AM +0200, Stephan Günther wrote:
 Hi,
 
 On Wed, Oct 8, 2014 at 10:10 PM, Hannu Nyman hannu.ny...@iki.fi wrote:
  Dave Taht wrote on Thu Oct 2 03:49:15 CEST 2014:
  So I don't know where to go. Certainly I'd like to see the battle hardened
  sqm scripts (which are more flexible than the C code above) get more widely
  used and in BB.
 
  SQM seems to work ok with the current Chaos Calmer trunk.
 
 Works for mee too, and performs much better than the old luci-app-qos.
 I would love to see this as part of OpenWrt.

OK. I don't see it feasible to retire qos-scripts as that has less dependencies
than sqm does - sqm needs ip and tc to function.

But I'd certainly like to see it available in the main openwrt repo by default.

And: I'd like the next version to do what sqm does, in pure c,
at line rate OR software rate limited, faster, better,
smaller... 
 
 I did some RRUL test using netperf-wrapper on my ADSL 15/1Mbps PPPoE
 link and it looks good in the graphs. I also have an 6in4 tunnel

I always love it when people post their results and the .json.gz files
for the various netperf-wrapper tests somewhere. It has been good to 
build an ever increasing database of valid tests and valid setups, given
that things like speedtest.net are so lame.

Examples:

http://burntchrome.blogspot.com/2014_05_01_archive.html

http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html

While I'm at it there were a couple manefestos along the way.

This explains exactly where and why wondershaper was flawed:

http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die

And this talks to the need for fq + aqm on *everything*

http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/

(I was unhappy qos-scripts just disabled ecn entirely. ECN is looking
 safely deployable in a fq'd system IMHO).

Last manefesto above does not go into the (slight) remaining need for a few 
levels
of classification, one reason is here:

http://perso.telecom-paristech.fr/~drossi/paper/rossi13tma-b.pdf

It is my hope that by explaining the why of sqm we could 
come up with something better before making it available
at larger scale.

 inside PPPoE and IIRC fq_codel should detect these ipv6 flows. RRUL

fq_codel dissects the headers for ipip, ipv6, gre and another protocol
I forget, correctly, and fq's them correctly. 

However my head explodes as to what happens or which
device should be used when that is further encapsulated.

 looks good at IPv6. Had this running at home for some days now, with
 moderate traffic and no issues so far.

Well loading it up is the only way to tell if you're winning.

 But I was wondering which interface to select luci-app-sqm, as no
 tunnel intefaces are shown here. So i used the ethernet interface
 instead of the PPPoE link. Is this fine? Minutes ago, I did a quick
 test and applied SQM to the PPPoE link by fixing luci-base to return
 also the virtual interfaces in net:get_interfaces(). But i didn't
 notice any difference or my test was too sloppy.

Well, sebastian just made a few SQM changes also in the ceropackages
repo and PPPoe over atm makes my head hurt. See cerowrt-devel
for more list. 

I'm a huge believer in measurements, and netperf-wrapper has been
the closest thing the Internet has ever had to one that accurately
measures latency under load. Recently it was proven to scale all
the way to 40GigE. 

Things like speedtest are increasingly inaccurate above 20mbits,
and doesn't measure induced latency at all...

and netalyzer, being written in java, doesn't get past 20mbits
either.

 
 --
 Stephan
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Barrier Breaker 14.07 Final

2014-10-06 Thread Dave Taht

Congrats everyone!

Here's to a faster, bufferbloat-free and ipv6 enabled
Internet!

On Thu, Oct 02, 2014 at 02:59:08PM +0200, Steven Barth wrote:
 The OpenWrt developers are proud to announce the final release
 of OpenWrt Barrier Breaker.
 
   ___ __
  |   |.-.-.-.|  |  |  |..|  |_
  |   -   ||  _  |  -__| ||  |  |  ||   _||   _|
  |___||   __|_|__|__||||__|  ||
   |__| W I R E L E S S   F R E E D O M
  -
  BARRIER BREAKER (14.07)
  -
   * 1/2 oz Galliano Pour all ingredients into
   * 4 oz cold Coffeean irish coffee mug filled
   * 1 1/2 oz Dark Rum   with crushed ice. Stir.
   * 2 tsp. Creme de Cacao
  -
 
 http://downloads.openwrt.org/barrier_breaker/14.07/
 
 Important changes since RC3
 * various ath9k related fixes
 * a few board related fixes
 * fixes for packages depdending on curl
 * per feed download folders
 
 Important changes since RC2
 * NAT  firewall throughput improvements
 * Security updates for OpenSSL  PolarSSL
 * Minor fixes in DHCP  DHCPv6 handling
 * Configuration support for GRE tunnels
 * Various other fixes
 
 Important changes since RC1
 * fix a long standing ath9k deadlock bug
 * all feeds are now built
 * image builder now works and RC2 contains all board specific images
 * various board/stability fixes
 
 ** Highlights since Attitude Adjustment **
 Default configuration and images
 
 * Linux kernel updated to version 3.10
 * Procd: new preinit, init, hotplug and event system written in C
 * Native IPv6-support
 - RA  DHCPv6+PD client and server
 - Local prefix allocation  source-restricted routes
   (multihoming)
 * Filesystem improvements
 - Added support for sysupgrade on NAND-flash
 - Added support for filesystem snapshot and rollback
 - Rewritten mounting system in C for rootfs and block devices
 * UCI configuration improvements
 - Support for testing configuration and rollback to working
   last working state
 - Unified change trigger system to restart services on-demand
 - Added a data validation layer
 * Networking improvements
 - Netifd now handles setup and configuration reload of
   wireless interfaces
 - Added reworked event support to allow obsoleting network
   hotplug-scripts
 - Added support for dynamic firewall rules and zones
 - Added support for transparent multicast to unicast
   translation for bridges
 - Various other fixes and improvements
 
 Additional highlights selectable in the package feeds or SDK
 * Extended IPv6-support
 - Added DS-Lite support and improved 6to4, 6in4 and 6rd-support
 - Experimental support for Lightweight 4over6, MAP-E and MAP-T
 - Draft-support for self-managing home networks (HNCP)
 * rpcd: new JSONRPC over HTTP-frontend for remote access to ubus
 * mdns: new lightweight mdns daemon (work in progress)
 * Initial support for the musl C standard library
 * Support for QMI-based 3g/4g modems
 * Support for DNSSEC validation
 * Added architecture for package signing and SHA256 hashing
 * ... and many more cool things
 
 Package feed reorganization
 For quite a while already we are not very satisfied with the quality
 of the packages-feed. To address this, we decided to do a fresh start
 on GitHub. The new feed https://github.com/openwrt/packages should be
 used from now on and package maintainers are asked to move their
 packages there. For the final release we will still build the old
 packages feed but it will be necessary to enable it manually in the
 opkg package list to be usable.
 Additionally we would like to give a big thank you to all of our
 package
 maintainers working on our various feeds.
 
 New build servers
 We would like to express our gratitude to Imagination Technology for
 funding the 2 build servers that we used for the release.
 
 Whats next ?
 We aim at releasing Chaos Calmer (CC) before the end of the year. The
 CC release will use 3.14 or a newer LTS kernel as baseline.
 
 
 Have fun!
 The OpenWrt developer team
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] How to properly add an unreachable route?

2014-07-12 Thread Dave Taht
I have been trying to simplify my babel setup. I have
8 /27s out of a single /24 that I would like not
to have to expose to the universe.

I have 172.21.2.0/27, 172.21.2.64/27 etc
on each of the 8 devices I have.

But there is no need to export each /27, as these
are out of a single /24.

The way to do that is to setup /etc/babel.conf to only
let /24s out...

redistribute ip 0.0.0.0/0 le 24 allow
redistribute local deny

(this can also easily be expressed in the /etc/config/babeld
 file)

And at the moment, I add this to /etc/firewall.user
to add the covering route locally. 

ip route add unreachable 172.21.2.0/24 proto static

Boom, I go from exporting 16 routes to 1.

Where I'm stuck is on how to express the above line
inside of uci and luci. Luci demands both a specific
interface name and a numeric destination, if you are
trying this via the route method.

If you try the otherwise promising uci newfangled rule method
by adding something like this to /etc/config/network

config rule
option dest   '172.21.2.0/24'
option action 'unreachable'

You end up bricking the router's network setup.

http://wiki.openwrt.org/doc/uci/network#routing.actions
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt

2014-03-30 Thread Dave Taht
On Sun, Mar 30, 2014 at 02:24:44PM -0400, Weedy wrote:
 On Sat, Mar 29, 2014 at 2:56 PM, Dave Täht dave.t...@bufferbloat.netwrote:
 
  From: Dave Taht dave.t...@bufferbloat.net
 
  This adds support for the bufferbloat project's Smart Queue Management
  (SQM) system, which improves over openwrt's qos-scripts in the following
  ways
 
  + Uses HTB with two models for managing traffic
a simplest one that merely uses fq_codel, and a three tier one that does
some basic and tunable packet prioritization.
 
  + Works with ipv6 and ipv4 correctly (unlike qos-scripts)
  + extensive support for fixing ADSL and PPOe framing problems
  + Partial support for key diffserv markings
  + highly tuned fq_codel implementation especially for low bandwidths
  + Tested heavily on cable modems and on dsl devices
 
  It is a disimprovement in that:
 
  - There are no built-in tricks for doing l7 classification,
  or other forms of packet inspection.
 
  - We haven't explored hfsc all that much, prefering to rely
  on the predictable behavior of htb + fq_codel for everything
 
  - And there is support for a few qdiscs that are not in the linux
  kernel mainline that remain experimental.
  ---
   net/sqm-scripts/Makefile   |   48 +++
   net/sqm-scripts/files/etc/config/sqm   |   11 +
   net/sqm-scripts/files/etc/init.d/sqm   |   23 ++
   net/sqm-scripts/files/usr/lib/sqm/functions.sh |  335
  
   net/sqm-scripts/files/usr/lib/sqm/run.sh   |   67 
   net/sqm-scripts/files/usr/lib/sqm/simple.qos   |  187 +++
   net/sqm-scripts/files/usr/lib/sqm/simple.qos.help  |1 +
   net/sqm-scripts/files/usr/lib/sqm/simplest.qos |   84 +
   .../files/usr/lib/sqm/simplest.qos.help|1 +
   net/sqm-scripts/files/usr/lib/sqm/stop.sh  |   22 ++
   10 files changed, 779 insertions(+)
   create mode 100644 net/sqm-scripts/Makefile
   create mode 100644 net/sqm-scripts/files/etc/config/sqm
   create mode 100755 net/sqm-scripts/files/etc/init.d/sqm
   create mode 100644 net/sqm-scripts/files/usr/lib/sqm/functions.sh
   create mode 100755 net/sqm-scripts/files/usr/lib/sqm/run.sh
   create mode 100755 net/sqm-scripts/files/usr/lib/sqm/simple.qos
   create mode 100644 net/sqm-scripts/files/usr/lib/sqm/simple.qos.help
   create mode 100755 net/sqm-scripts/files/usr/lib/sqm/simplest.qos
   create mode 100644 net/sqm-scripts/files/usr/lib/sqm/simplest.qos.help
   create mode 100755 net/sqm-scripts/files/usr/lib/sqm/stop.sh
 
  diff --git a/net/sqm-scripts/files/etc/config/sqm
  b/net/sqm-scripts/files/etc/config/sqm
  new file mode 100644
  index 000..547d321
  --- /dev/null
  +++ b/net/sqm-scripts/files/etc/config/sqm
  @@ -0,0 +1,11 @@
  +
  +config queue 'ge00'
  +option enabled '0'
  +option interface 'ge00'
  +option download '2'
  +option upload '4000'
  +option qdisc 'fq_codel'
  +option script 'simple.qos'
  +option qdisc_advanced '0'
  +option linklayer 'none'
  +
 
 
 How hard is this to config from the command line/vim?

There are a few more options than this (for DSL compensation, ecn
and advanced configuration), the above would work if you changed
enabled to '1' and the device from ge00 to your wan device. (not
the wan firewall rule, presently. )

It does help to have a sane long term and realistic measurement of your
network using something like the rrul test rather than the oft-gamed speedtest.

http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310

You are right, we should fully document all the variables in this file.
Until recently they were kind of in flux.

 I've never needed or really wanted luci on my box, I just use vim. Going by
 this patch, there is either nothing to config or no examples. I would think
 shipping a roughly equivalent config to what ships in qos-scripts would be
 a good start to get people testing.

/etc/init.d/sqm start,stop etc work as expected.

 IE: highest priority: small ARP, DNS, and SSH packets

The SQM default is local DNS and ntp. fq_codel automagically optimizes
for other sparse flows like arp, ssh, mosh, tcp syn, synack, etc,
no need to do that via classification.

 normal: HTTP, HTTPS

So you want to deprioritize vpn, smtp, rsync, dropbox, http on odd ports,
caching servers, etc, all in favor of the web gods?

we just toss all that into the normal (best effort bin) and let fq_codel
sort it out.

 bulk: everything else.

We do respect the diffserv marking of CS1 (background) and toss it
into the background queue.

 Side note: Will SQM do bandwidth slicing? Or at least handle hostile
 environments better? I say hostile as in roommates or maybe teenage kids.
 Multiple people/devices thinking they are entitled to the entire WAN
 bandwidth at all times.

fq_codel does fair (well, we call it flow) queuing.

https://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel-00

[OpenWrt-Devel] ceropackages feed

2014-03-29 Thread Dave Taht

All the packages I just submitted are currently maintained in the
ceropackages-3.10 repo on github.

https://github.com/dtaht/ceropackages-3.10.git

so you can add that feed to your feeds.conf if you like, and do a

./scripts/feeds update
./scripts/feeds install sqm-scripts luci-app-sqm bcp38

and enable them to be built and give 'em a shot that way, rather
than trying the patches I just submitted.

There are a ton of other packages in that repo of varying 
quality and specificity to CeroWrt, possibly worth
browsing through also.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] getting more randomness by improving MIPS get_cycles()

2013-09-08 Thread Dave Taht
In light of the whole nsa hoo-ra (stuff like this)

https://plus.google.com/u/0/117091380454742934025/posts/SDcoemc9V3J

Ted Tso has pointed out to me that apparently mips' does not have a working 
generic get_cycles() call,  but instead returns 0 in all cases.

e.g: In arch/mips/include/asm/timex.h:

typedef unsigned int cycles_t;

static inline cycles_t get_cycles(void)
{
return 0;
}

Um.

get_cycles() is used in innumerable places in random.c.

This is double plus ungood... I am REALLY hoping I'm merely misreading 
the code...

An example:

(see drivers/char/random.c for how often it is used)

/*
 * Add device- or boot-specific data to the input and nonblocking
 * pools to help initialize them to unique values.
 *
 * None of this adds any entropy, it is meant to avoid the
 * problem of the nonblocking pool having similar initial state
 * across largely identical devices.
 */

void add_device_randomness(const void *buf, unsigned int size)
{
unsigned long time = get_cycles() ^ jiffies;

...

So, what blocks having a working get_cycles in common mips architectures?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] bloatie-bloat-bloat?

2013-09-08 Thread Dave Taht
On Sun, Sep 08, 2013 at 11:37:40AM +0200, Felix Fietkau wrote:
 On 2013-09-08 11:26 AM, Russell Senior wrote:
  
  I have a number of (admittedly) ancient Netgear WGT634U's in the field
  doing duty as free-wifi hotspots.  Recent builds of our standard set
  of tools have become unhappy in the last year or so.  For example,
  here are the RES memory sizes of processes on our workload, comparing
  r37911 (current) with r34240 (circa Nov 18, 2012):
  
  r37911  r34240
  
  RSS  commandRSS  command
  3700 gateway3000 gateway (nocatauth, w/ perl)
  1400 snmpd  1240 snmpd
  1196 openvpn3400 openvpn

Wow. Is that sort of benefit available if I switched to polarssl
for everything (dropbear? webserver?)

  736  olsrd  628  olsrd 
  732  olsrd  572  olsrd 
  664  netifd 268  netifd
  656  procd  76   init   
  104  init  
  108  rcS   
  632  top612  top   
  532  dropbear   540  dropbear  
  496  ash480  ash   
  492  logread168  syslogd   
  488  hostapd392  hostapd   
  456  crond  332  crond 
  448  udhcpc * (used static config, so no udhcpc)
  248  hotplug2  
  420  dropbear   188  dropbear  
  384  logger 172  logger
  164  logger
  380  sh  
  376  dnsmasq440  dnsmasq   
  372  radvd  188  radvd 
  256  radvd  320  radvd 

radvd has been obsoleted by either dnsmasq or the 6relayd stuff.

  364  ntpclient  200  ntpclient 

Not clear to me which ntp you are using...

  280  ubusd  56   ubusd  
  272  sleep   
  224  askfirst
  68   ??
  84   watchdog   
  -   -
  15956   14048 
  
  Today's resident size is almost 2 megabytes larger than a year ago,
  even after a substantial improvement in the openvpn size (I switched
  to polarssl).
  
  Admittedly, the numbers are just a convenience sample (r37911 just
  booted, r34240 has been up for 44 days) and might not be a fair
  comparison in all cases.  But, the direction here seems to be making
  the WGT634U less viable for us.
  
  Are these numbers illuminating at all?
 The increase in individual processes is interesting, but you made one
 mistake here: Adding up the RSS numbers does not yield the total memory
 usage, but a gross overestimation of it.
 Much of the memory use is coming from uClibc and other shared libraries,
 and most of that is shared in RAM as well.
 To fix that counting error, you can enable CONFIG_PROC_PAGE_MONITOR in
 your kernel config. This enables /proc/pid/smaps, which contains a Pss
 value for each mapping. For all shared parts, the memory amount is
 divided by the number of processes sharing it.
 
 - Felix
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 7/8] mac80211: add full diffserv support to wireless

2012-10-01 Thread Dave Taht
On Mon, Oct 01, 2012 at 07:28:11PM +0200, Felix Fietkau wrote:
 On 2012-10-01 6:49 PM, Dave Täht wrote:
  From: Dave Taht dave.t...@bufferbloat.net
  
  This moves all but EF marked traffic out of the VO queue,
  allowing for aggregation of other forms of traffic.
  
  It more aggressively uses the VI queue for interactive-ish
  traffic.
 Please propose this for upstream inclusion on linux-wireless@. I'd like
 to see the feedback there before I consider merging it to OpenWrt.

OK. Honestly I wanted feedback from openwrt first because this patch
originally exposed several problems in the VI queue handling on the ath9k,
and I suspect that other chipsets (like iwl) have hidden problems in VI
queue handling as well.

 
 - Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 5/8] Reduce skb truesize on common qdiscs under load

2012-10-01 Thread Dave Taht
On Mon, Oct 01, 2012 at 10:44:56AM -0700, Sebastian Moeller wrote:
 Hi Felix,
 
 
 On Oct 1, 2012, at 10:26 , Felix Fietkau wrote:
 
  On 2012-10-01 6:49 PM, Dave Täht wrote:
  From: Dave Taht dave.t...@bufferbloat.net
  
  After queue lengths start getting out of hand, try to preserve memory
  by shortening skbs to their truesize on the common pfifo, codel, and
  fq_codel qdiscs.
  
  Arguably (128) should be a configureable param
  I think this is a bad idea, at least on routers. 'Preserving memory'
  here involves copying buffer data, which is really horrible for
  performance. The memory bus is a tough bottleneck when routing at high
  speed…
 
   But the in severe situations the alternative is OOM - watchdog based 
 reboot; under these circumstances limping along and recover later once the 
 memory pressure is over sounds better than rebooting? (At least in cerowrt 
 the OOM reboot cycle could be easily initiated by a simple UDP flood through 
 the router. Now, while this is abusive, it is way better if the router 
 survives this and recovers with out a reboot, IMHO). This change along with a 
 few others Dave made turned cerowrt robust against UDP flooding which I think 
 is the right thing to do. Since this only triggers once memory gets scarce, 
 think of this as a defense mechanism in a situation where performance will 
 suffer anyway...
 
 best
   Sebastian

As I noted, openwrt's workaround of a txqueuelen of 30 on wifi means this 
check will never be hit. It also means that fq_codel can't be applied at
all to the openwrt wifi queues, as 30 is not deep enough to do any good.

(cerowrt is presently using a latency/bandwidth compromise of a shortened
 driver queue and a longer fq_codel based txqueue - and we're painfully 
aware that far more work is needed to make wireless-n stop being so
darn bloated and unresponsive: 

http://www.bufferbloat.net/projects/cerowrt/wiki/Fq_Codel_on_Wireless )

So, it IS possible to run a box with tons of SSIDs easily out of memory
with the larger txqueuelens cero is using, and this patch helped that.

Other devices (such as ethernet and qos'd devices)
have longer queues by default, where this memory saving optimization
*might* help

It would be interesting if more folk would abuse their openwrt routers
heavily using the current (2.6) version of netperf, to fully exercise
the 4 hardware wifi queues, or the multiple qos queues. 

Tests like this showed up a hw queue bug in ath9k (long since
fixed) and appears to mess up iwl (on a laptop) somewhat, and it would
be good to blow up more drivers and devices... in addition to running
older versions of openwrt out of memory.

What I typically do is a bunch of udp flooding and tcp flooding,
along the lines of this, using the netperf 2.6 distro, and exercising
each hw queue thusly. 

# netserver runs here
SERVER1=somewhere
SERVER2=somewhere.else

DUR=120

# on clients connected through the router via
# wifi, etc

(
# Flood BE with tcp in both directions
netperf -l$DIR -H$SERVER1 -tTCP_MAERTS 
netperf -l$DIR -H$SERVER2 -tTCP_MAERTS 
netperf -l$DIR -H$SERVER1 -tTCP_STREAM 
netperf -l$DIR -H$SERVER2 -tTCP_STREAM 
# Beat up on the BK, BE, VO, VI hw queues
netperf -l$DIR -Y CS1,CS1 -H$SERVER2 -tUDP_STREAM 
netperf -l$DIR -Y CS0,CS0 -H$SERVER2 -tUDP_STREAM 
netperf -l$DIR -Y EF,EF -H$SERVER2 -tUDP_STREAM 
netperf -l$DIR -Y CS5,CS5 -H$SERVER2 -tUDP_STREAM 
) 

 
 
  
  - Felix
  
  ___
  openwrt-devel mailing list
  openwrt-devel@lists.openwrt.org
  https://lists.openwrt.org/mailman/listinfo/openwrt-devel
 
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v2] [RFC] Add Kernel 3.4 to AR71xx platform.

2012-09-28 Thread Dave Taht
On Fri, Sep 28, 2012 at 02:29:56PM +0200, Oliver wrote:
 On Friday 28 September 2012 14:30:45 Felix Fietkau wrote:
  3.6 is going to be released soon, I think we should go for that once
  we've taken care of branching for release.
  
  - Felix
 
 +1 to that.

+1 to that too. It seems possible this will be a long-term stable release,
which 3.3 is not.

It would be nice if we could expend effort on making the ar71xx arch more
part of the mainline kernel, too. As best as I recall that was seriously
bottlenecked on device tree support, when last I looked.

 
 Do you by any chance have a kernel repo in which you maintain the OpenWRT 
 patch-set? I realise of course that the buildenv expects quilt-style, but for 
 porting, merging, cherry-picking etc, Git is second to none. I've setup a 
 repo 
 over at GitHub, if anyone else is using Git to maintain kernel patches, a 
 remote URI would be much appreciated!
 
 Regards,
 Oliver
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Linux 3.3.x has been EOLed ; time to move on ?

2012-08-12 Thread Dave Taht
On Wed, Aug 01, 2012 at 08:40:52PM +0200, Hartmut Knaack wrote:
 Hi,
 my impression is, that a kernel version makes it into trunk if it is either a 
 long term kernel, or it brings essential new functions. For 3.3 this was most 
 certainly the introduction of BQL code. Keeping in mind that our main targets 
 are network routers, the bufferbloat issue probably concerns most of the 
 maintainers.

I have been away from my mail for a while.

Van Jacobson gave a great talk about bufferbloat, BQL, codel, and fq_codel
at last week's ietf meeting. Well worth watching. At the end he outlines
the deployment problems in particular.

http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF84_TSVAREAchapter=part_3

Far more interesting than this email! 

While we have made great progress towards addressing bufferbloat in openwrt, it
is only barely addressed in the openwrt QoS system, (it would be nice
if fq_codel ran on all interfaces with BQL support), BQL support only exists
for a few drivers in the openwrt tree...

And fixing wifi with similar techniques is going to take months and
months longer to do, even if we could get the chipset makers focused on
the problem.

http://www.bufferbloat.net/projects/cerowrt/wiki/Fq_Codel_on_Wireless

So the upcoming 3.3 release of openwrt is a start, only, towards fixing
bufferbloat. I'm very happy we made so much progress in a year, with
perhaps another year of effort and we'll have it thoroughly licked in linux
and in openwrt. That leads towards difficult decision-making for declaring
a stable release this year for openwrt.

The current trunk of openwrt is unquestionably better than last years
release, and deserves wider use.

As for the long term support issue for 3.3, it does concern me very
much that 3.3 is already EOL'd.

I would like it if openwrt planned on a stable release on the next go-round
built around a kernel that has long term support (perhaps 3.8?).

I do note that openwrt's 3.3 is not actually 3.3 to a large extent,
it has wireless-next, and the fq_codel implementation
from linux 3.5, and tons and tons of patches for driver and chipset
support that haven't made it up to mainline.

There are 160 generic linux patches, and for the ar71xx architecture
*alone* there are 136 patches, and 95 new driver related files.

It would be good if efforts were expended to merge up the
enormous patch burden into the kernel mainline, so as to make it
easier to move openwrt forward in conjuction with it.

The patch burden is the enormous problem impeding progress forward, and
makes bi-directional patching from the Linux kernel head much harder as
time goes by...

The patch burden and driver collisions in the arm world got
so bad 2 years ago that linaro was formed to fix it. That effort
has largely been successful and it would help a lot to do something similar
here.

It would be my hope that those that build products around openwrt would
recognise this infrastructural problem and step up.

(side note, the bufferbloat.net effort has loaned 4 boxes to the buildbot
 system and it would be very helpful in terms of cycle time if the buildbot
 cluster could be even more dramatically expanded)

IMHO, I think it's worth creating a stable release now, but also working
hard towards being able to create another stable release on a new kernel
base *this year* - which is going to be hard due to these other problems.


 
 Emmanuel Deloget schrieb:
  Hello, 
 
  I understand that a lot of effort has been pushed in making 
  Linux 3.3 the trunk kernel, and I understand that I probably 
  missed long (IRC?) discussions on this very subject, but since 
  3.3.8 is going to be the last supported kernel in the 3.3.x 
  branch it might be a good idea to move on to another, more 
  recent kernel version - and to do it slightly better. Not 
  that anything is really bad, but there were obviously better 
  choices that 3.3 at the time it came up. 
 
 
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH] Codel: avoid a nul rec_inv_sqrt

2012-07-31 Thread Dave Taht
One condition before codel_Newton_step() was not good if
we never left the dropping state for a flow. As a result
rec_inv_sqrt was 0, instead of the ~0 initial value.

codel control law was then set to a very aggressive mode, dropping
many packets before reaching 'target' and recovering from this problem.

Brought over from 3.5-stable
---
 ...one-condition-to-avoid-a-nul-rec_inv_sqrt.patch |   68 
 1 file changed, 68 insertions(+)
 create mode 100644 
target/linux/generic/patches-3.3/049-codel-refine-one-condition-to-avoid-a-nul-rec_inv_sqrt.patch

diff --git 
a/target/linux/generic/patches-3.3/049-codel-refine-one-condition-to-avoid-a-nul-rec_inv_sqrt.patch
 
b/target/linux/generic/patches-3.3/049-codel-refine-one-condition-to-avoid-a-nul-rec_inv_sqrt.patch
new file mode 100644
index 000..210a58c
--- /dev/null
+++ 
b/target/linux/generic/patches-3.3/049-codel-refine-one-condition-to-avoid-a-nul-rec_inv_sqrt.patch
@@ -0,0 +1,68 @@
+From patchwork Mon Jul 30 06:52:21 2012
+Content-Type: text/plain; charset=utf-8
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: codel: refine one condition to avoid a nul rec_inv_sqrt
+Date: Sun, 29 Jul 2012 20:52:21 -
+From: Eric Dumazet eric.duma...@gmail.com
+X-Patchwork-Id: 173968
+Message-Id: 1343631141.2626.13293.camel@edumazet-glaptop
+To: David Miller da...@davemloft.net
+Cc: netdev net...@vger.kernel.org, Anton Mich lp2...@gmail.com
+
+From: Eric Dumazet eduma...@google.com
+
+One condition before codel_Newton_step() was not good if
+we never left the dropping state for a flow. As a result
+rec_inv_sqrt was 0, instead of the ~0 initial value.
+
+codel control law was then set to a very aggressive mode, dropping
+many packets before reaching 'target' and recovering from this problem.
+
+To keep codel_vars_init() as efficient as possible, refine
+the condition to make sure rec_inv_sqrt initial value is correct
+
+Many thanks to Anton Mich for discovering the issue and suggesting
+a fix.
+
+Reported-by: Anton Mich lp2...@gmail.com
+Signed-off-by: Eric Dumazet eduma...@google.com
+
+---
+include/net/codel.h |8 ++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+
+
+--
+To unsubscribe from this list: send the line unsubscribe netdev in
+the body of a message to majord...@vger.kernel.org
+More majordomo info at  http://vger.kernel.org/majordomo-info.html
+
+diff --git a/include/net/codel.h b/include/net/codel.h
+index 550debf..389cf62 100644
+--- a/include/net/codel.h
 b/include/net/codel.h
+@@ -305,6 +305,8 @@ static struct sk_buff *codel_dequeue(struct Qdisc *sch,
+   }
+   }
+   } else if (drop) {
++  u32 delta;
++
+   if (params-ecn  INET_ECN_set_ce(skb)) {
+   stats-ecn_mark++;
+   } else {
+@@ -320,9 +322,11 @@ static struct sk_buff *codel_dequeue(struct Qdisc *sch,
+* assume that the drop rate that controlled the queue on the
+* last cycle is a good starting point to control it now.
+*/
+-  if (codel_time_before(now - vars-drop_next,
++  delta = vars-count - vars-lastcount;
++  if (delta  1 
++  codel_time_before(now - vars-drop_next,
+ 16 * params-interval)) {
+-  vars-count = (vars-count - vars-lastcount) | 1;
++  vars-count = delta;
+   /* we dont care if rec_inv_sqrt approximation
+* is not very precise :
+* Next Newton steps will correct it quadratically.
-- 
1.7.9.5

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH] gpsd: update to 3.7

2012-07-09 Thread Dave Taht
The openwrt specific patches have been merged into gpsd 3.7 and
are no longer needed.
---
 net/gpsd/Makefile |4 ++--
 net/gpsd/patches/001-add-staging-prefix.patch |   10 --
 net/gpsd/patches/002-no_rpath.patch   |   11 ---
 3 files changed, 2 insertions(+), 23 deletions(-)
 delete mode 100644 net/gpsd/patches/001-add-staging-prefix.patch
 delete mode 100644 net/gpsd/patches/002-no_rpath.patch

diff --git a/net/gpsd/Makefile b/net/gpsd/Makefile
index 47dd279..ca4983a 100644
--- a/net/gpsd/Makefile
+++ b/net/gpsd/Makefile
@@ -8,12 +8,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=gpsd
-PKG_VERSION:=3.6
+PKG_VERSION:=3.7
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=http://download-mirror.savannah.gnu.org/releases/gpsd
-PKG_MD5SUM:=064a5ad75593f8c3ea3fe85010647832
+PKG_MD5SUM:=52d9785eaf1a51298bb8900dbde88f98
 
 PKG_BUILD_DEPENDS:=libncurses libusb-1.0
 
diff --git a/net/gpsd/patches/001-add-staging-prefix.patch 
b/net/gpsd/patches/001-add-staging-prefix.patch
deleted file mode 100644
index b88171b..000
--- a/net/gpsd/patches/001-add-staging-prefix.patch
+++ /dev/null
@@ -1,10 +0,0 @@
 a/SConstruct
-+++ b/SConstruct
-@@ -200,6 +200,7 @@ import_env = (
- 'PATH',# Required for ccache and Coverity scan-build
- 'PKG_CONFIG_PATH', # Set .pc file directory in a crossbuild
- 'STAGING_DIR', # Required by the OpenWRT build.
-+'STAGING_PREFIX',  # Required by the OpenWRT build.
- )
- envs = {}
- for var in import_env:
diff --git a/net/gpsd/patches/002-no_rpath.patch 
b/net/gpsd/patches/002-no_rpath.patch
deleted file mode 100644
index 38ba782..000
--- a/net/gpsd/patches/002-no_rpath.patch
+++ /dev/null
@@ -1,11 +0,0 @@
 a/SConstruct
-+++ b/SConstruct
-@@ -269,8 +269,6 @@ def installdir(dir, add_destdir=True):
- 
- # Honor the specified installation prefix in link paths.
- env.Prepend(LIBPATH=[installdir('libdir')])
--if env[shared]:
--env.Prepend(RPATH=[installdir('libdir')])
- 
- # Give deheader a way to set compiler flags
- if 'MORECFLAGS' in os.environ:
-- 
1.7.9.5

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] ubnt rocket gps supported?

2012-06-06 Thread Dave Taht
I am thinking through a prototype deployment of a bunch of outdoor
radios, gps and sensors, with fq_codel, and its successors,
for location, environmental sensing and precision time.

Does the on-board gps on the ubiquity rocket-m gps work in openwrt?
(any details on it so as I can make it work would be helpful)

Are there any other openwrt supported devices with an integral gps supported?

Are there any outdoor radios with a usb port?

(yes, I'm aware I can build or buy a case for something like a
routerstation pro or routerboard, I
 was looking for something more or less like a nanostation M5 with a USB port)

-- 
Dave Täht
SKYPE: davetaht
http://ronsravings.blogspot.com/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] reminder: buildbot slave ready for action

2012-05-22 Thread Dave Taht
Last I'd heard travis was off on a well deserved vacation... as am I.

snapon.lab.bufferbloat.net can also be tossed into the buildbot system.
It's a 6 core box, but only has a single drive.

Does anyone else have a grip on the buildbot system?

On Tue, May 22, 2012 at 6:36 PM, Daniel Golle dgo...@allnet.de wrote:
 i got a box ready to participate in as a buildbot slave.
 it's a brand-new CentOS x86_64 install and I made sure all build-dependencies
 are present.
 please advise me on how it can serve the buildbot, it's waiting :)
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [Codel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)

2012-05-21 Thread Dave Taht
In looking over your test scripts and results, it seems possible you
have gso on.

ethtool -K the_device tso off
ethtool -K the_device gso off
ethtool -K the_device ufo off

Secondly, in the 100Mbit and below case, I have found BQL's estimates
to be persistently on the high side, and have generally found that a
byte queue limit of 3000 or 4500 produces optimal, consistent results.

Usually 1500 causes starvation. YMMV.

On Mon, May 21, 2012 at 10:49 PM, Tobias Diedrich
ranma+open...@tdiedrich.de wrote:
 Rick Jones wrote:
 On 05/20/2012 08:48 PM, Dave Taht wrote:
 Thx for the numbers!
 
 Could you do a TCP_RR while under load from UDP_STREAM?

 If you want to generate pretty pictures while doing so, you can
 probably tweak
 http://www.netperf.org/svn/netperf2/trunk/doc/examples/bloat.sh

 How about this:
 http://tdiedrich.de/~ranma/bufferbloat-rt3050/

 --
 Tobias                                          PGP: http://8ef7ddba.uguu.de



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [Codel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)

2012-05-21 Thread Dave Taht
I would really like people to clearly mark when they are using pfifo_fast,
codel, and fq_codel.

Secondly, I note that for utterly best results it is useful to ALSO have
htb on on ingress to a value only slightly lower than the rate under
test, and fq_codel attached to
the bin(s)

(an example of this is in the deBloat repo on github - both ingress.sh
and simple_qos.sh)

It would be nice if doing ingress was as simple as egress, maybe using some sort
of tbf + fq_codel

Otherwise for some benchmarks... at 100Mbit, you will see TCP_STREAM
behavior holding
the line at ~5ms, and TCP_MAERTS being in excess of 30ms, especially
when pfifo_fast is on the other
side. Or vice versa, depending on where you are running the test.

On Tue, May 22, 2012 at 2:22 AM, Rick Jones rick.jon...@hp.com wrote:
 On 05/21/2012 04:30 PM, Rick Jones wrote:

 I think my original ones had the unfortunate effect of putting lines on
 top of one another. Your's seem to put them pretty far apart (at least
 sometimes). We aught to be able to find some reasonable medium in there
 somewhere. I'm thinking if latency is the metric of greatest interest,
 we want that to have the full y axis, and then the peak bandwidth of the
 STREAM test be about half-way up?


 I've tweaked the bloat.sh script in a couple ways.  First, I changed how I
 compute the scaling factor, to implement what I described above. Second, I
 am using a negative value for the demo interval for the TCP_RR test.  This
 causes netperf to check if it is time to emit a result after each
 transaction rather than after what it thought would be the number of
 transactions in the interval.  In that way the latency line is much more
 robust in the face of a sudden bloating of the path.  The effect on
 transactions per second should be similar to that of enabling histograms.
  An example of a test across my 100 Mbit/s link to a laptop is attached.

 happy benchmarking,

 rick jones

 ___
 Codel mailing list
 co...@lists.bufferbloat.net
 https://lists.bufferbloat.net/listinfo/codel




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)

2012-05-20 Thread Dave Taht
Thx for the numbers!

Could you do a TCP_RR while under load from UDP_STREAM?

On Mon, May 21, 2012 at 1:31 AM, Tobias Diedrich
ranma+open...@tdiedrich.de wrote:
 Tobias Diedrich wrote:
 Dave Taht wrote:
  In looking over the enormous stack of boards and drivers that openwrt
  supports, I see that many of the ethernet drivers don't yet support
  Linux 3.3's Byte Queue Limits, which are discussed here:
 
  http://lwn.net/Articles/454390/
 
  It would be good if more did. They improve network performance in the
  general case enormously, particularly when a link is not connected at
  it's peak wire speed.
 
  *Adding* support for BQL to an ethernet driver is trivial, here's an
  example of how.

 I tried adding BQL to the ramips ethernet driver, however I found
 some interesting behaviour while doing
 root@OpenWrt:~# netperf -l 120 -t UDP_STREAM -H myserver

 It looks like the briding code still needs to implement this as well?

 netperf UDP_STREAM:
 iface  limit_min   inflight  tx mbps  remote mbps  ping ms
 eth0   0           ~15000    95.71    95.71        ~10ms
 eth0   100     ~30   177.98   23.28(*)     ~30ms
 br0    0           ~15000    154.88   33.94(*)     ~120ms
 br0    100     ~30   170.92   25.57(*)     ~30ms

 (*) bwm-ng on the server showed ~100mbps incoming...
 [...]
 Haven't tried codel yet...

 Turns out, it works nicely with codel, even with the bridge:

 netperf:  netperf -l 120 -t UDP_STREAM -H myserver
 fq_codel: tc qdisc add dev eth0 handle 1: root fq_codel target 5ms

 iface  eth0 qdisc  bql  inflight  tx mbps    sys time  ping ms
 eth0   pfifo_fast  no   n/a       182.98(*)  96.43s    ~30ms
 eth0   fq_codel    no   n/a       177.98(*)  96.09s    ~30ms
 eth0   pfifo_fast  yes  ~15000    95.71      42.73s    ~10ms
 eth0   fq_codel    yes  ~15000    95.19      51.52s    ~4ms
 br0    pfifo_fast  yes  ~15000    155.19(*)  94.24s    ~120ms
 br0    fq_codel    yes  ~15000    90.92      65.52s    ~4ms

 (*) 100mbit link after the switch, ifconfig eth0 shows no drops,
    so I'm assuming they are getting dropped by the switch.

 --
 Tobias                                          PGP: http://8ef7ddba.uguu.de



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] Codel explanation in Danish

2012-05-20 Thread Dave Taht
See:

http://www.linuxin.dk/node/19778 for the original text:

Via google translate:

Version 3.4 of Linux has not arrived yet, but 3.5 already appears to
be a very interesting version. There will be a vital improvement to
the handling of buffers in the network. More specifically, it is a new
algorithm that can correct bufferbloat problem. That is a congested
internet to a lesser extent will feel slow for example. ordinary web
browsing or gaming. 3.5 is therefore really one of those releases
where the average user can feel the difference kernel versionen.

A few days ago announced Kathleen Nichols and Van Jacobson their paper
a new algorithm for active queue management (AQM). Besides having
improvements in performance compared to previous algorithms, so the
new is also a huge advantage of not requiring difficult settings for
each use pattern. Previously it required networking expert to analyze
the individual traffic and set the AQM if you needed it. The new is it
just plug and play and AQM can now be used as default.

Shortly after the publication of paperen had scientists from cerowrt /
bufferbloat an implementation ready for linux. It has already been
included in git repoet for network-next, which is expected to be part
of Linux 3.5. The code is also also included in the development
version of openwrt and would also be found in the first release of
cerowrt, expected to come very soon. 


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)

2012-05-10 Thread Dave Taht
In looking over the enormous stack of boards and drivers that openwrt
supports, I see that many of the ethernet drivers don't yet support
Linux 3.3's Byte Queue Limits, which are discussed here:

http://lwn.net/Articles/454390/

It would be good if more did. They improve network performance in the
general case enormously, particularly when a link is not connected at
it's peak wire speed.

*Adding* support for BQL to an ethernet driver is trivial, here's an
example of how.

http://huchra.bufferbloat.net/~cero1/openwrt-bql-patches/0103-BQL-support-added-to-ag71xx-driver.patch

* testing BQL* is also trivial - but will require the device to do.
I've been beat up by memory barrier issues and stuff like that, so it
pays to do the patch and then run serious tests through it, rather
than try it blind.

So, getting more BQL enabled ethernet drivers working would be good.

There is BQL support in many of the mainstream ethernet cards already,
see those for more examples of how to do it.

...

Anyway, as folk are hopefully aware by now, Kathie Nichols and Van
Jacobson have released a new no knobs AQM algorithm which can be
used by default on all interfaces - not just the uplink - in order to
manage bandwidth and latency far better than has ever been done
before.

If you haven't heard about it yet, please see
http://queue.acm.org/detail.cfm?id=2209336 for the paper.

Figure 7 shows the enormous differences in latency and buffering
behavior between drop tail (the current linux default), RED, and
Codel.

There's also been good coverage in lwn, jim gettys blog, arstechnica,
etc. I'd ignore slashdot.

Codel is a brand new algorithm, something truly new under the sun,
which doesn't happen every day. Kathie and Van been working on it for
over a decade and the bufferbloat/cerowrt team for over a year.

We took the wraps off the algorithm a few days ago.
We've made the code freely available under a dual BSD/GPL license.

AQM is not just for routers anymore, either, but it helps a lot there!

Versions of Codel for linux 3.3 and 3.4 (and ns2 and ns3 simulations) are here:

http://www.bufferbloat.net/projects/codel/wiki

Codel will work best on a BQL-enabled ethernet driver.
It will also work on devices with small numbers of ring buffers.

I look forward to hearing of early successes (and failures!) on
various bits of hardware. Certainly while codel + bql works well, htb
and hfsc in combination with various other technologies is not well
tested yet.

Codel is a RED replacement, and will work best when paired up with
QFQ, or the upcoming sfq-enabled version.

However by itself it's pretty darn good, and can be used on all
interfaces of a router, not just the uplink.

Work on characterizing wireless behavior is on-going. (some help on
that would be nice)

There is still a great deal of work ahead for the cerowrt project,
it's my hope that by sharing this stuff as soon as I felt the patches
were baked enough, that all those frustrated by network delays and
bufferbloat on supposedly fast hardware, would jump on it, on their
own hardware.

Our intent from day one was to get Codel into OpenWrt (and indeed, all
OSes) as fast as possible.

Unfortunately I kind of forgot about getting BQL on everything, everywhere, too!


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)

2012-05-10 Thread Dave Taht
On Thu, May 10, 2012 at 9:13 AM, John Crispin j...@phrozen.org wrote:
 On 10/05/12 17:57, Dave Taht wrote:
 In looking over the enormous stack of boards and drivers that openwrt
 supports, I see that many of the ethernet drivers don't yet support
 Linux 3.3's Byte Queue Limits, which are discussed here:

 http://lwn.net/Articles/454390/

 It would be good if more did. They improve network performance in the
 general case enormously, particularly when a link is not connected at
 it's peak wire speed.

 *Adding* support for BQL to an ethernet driver is trivial, here's an
 example of how.

 http://huchra.bufferbloat.net/~cero1/openwrt-bql-patches/0103-BQL-support-added-to-ag71xx-driver.patch

 * testing BQL* is also trivial - but will require the device to do.
 I've been beat up by memory barrier issues and stuff like that, so it
 pays to do the patch and then run serious tests through it, rather
 than try it blind.

 Hi,

 do you run specific tests or just hammer the unit ?

Hammering via any means is good - netperf, iperf, apache benchmarks, etc.

We have been using (and improving) netperf to exercise things like
classification and alternate tcp algorithms. You can get that from
netperf.org's svn, or

There is a version of that already packaged up in the openwrt
compatible ceropackages repository here:

https://github.com/dtaht/ceropackages-3.3

the new (to be 2.6) version of netperf is not backward compatible with
version 2.5, so all sides of the connection need to be running it.

useful tests are TCP_STREAM, TCP_MAERTS, and TCP_RR, run multiple
times simultaneously, for long periods. (memory barriers are hard to
hit). Codel shows up well in a simultaneous TCP_STREAM and TCP_RR test
vs pfifo_fast, too.

Iperf is a simpler substitute.


 john


 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] Add Lua bindings for libgps

2012-05-05 Thread dave taht

On 05/05/2012 01:17 PM, Felix Fietkau wrote:

On 2012-05-05 8:49 PM, Eric S. Raymond wrote:

Felix Fietkaun...@openwrt.org:

I merged scons build support in r31618. I was just about to merge
chrpath too, but it didn't build on my OSX box. When I found out what
chrpath is used for in the build system, I decided to not merge it at all.
If I understand the code that uses it in the gpsd build system
correctly, it seems to be an unnecessary hack that should be patched out
entirely.

It's necessary for dynamic linking.  It replaces the elaborate stuff libtool
does in an autotools-based build.

I really don't think we need it in OpenWrt, so I'm going to patch it
out. chrpath seems to need some ELF related stuff that isn't part of our
host build yet, and I think it is completely pointless to add all of
this for a piece of functionality that we don't need or want in OpenWrt
at all.

Works for me.


After fixing some madness wrt. scons platform detection (I'm beginning
to dislike scons even more than autoconf now)


That would be hard to imagine, but I feel your pain, I do, I do.


, I tried my patched gpsd
package and it seemed to find its libraries just fine.

Awesome.

I note that there was a great deal of churn happening after the 3.5 
release, I don't know if eric considers it 3.5 stable enough or not. 
Notably there was some stuff going by about endianness on the list that 
appeared to be ibm360 related, which I know is not a target platform 
(yet) for openwrt.


Does this mean I can retire the ceropackages version?

I note that the xorp package therein needed scons too.



- Felix


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx

2012-04-30 Thread Dave Taht
On Mon, Apr 30, 2012 at 3:49 AM, David Woodhouse dw...@infradead.org wrote:
 On Sun, 2012-04-22 at 14:48 -0700, Dave Täht wrote:


Thank you very much for the code review!

 +
 +-#define tcp_flag_word(tp) ( ((union tcp_word_hdr *)(tp))-words [3])
 ++#define tcp_flag_word2(tp) ( ((union tcp_word_hdr *)(tp))-words [3])
 ++#define tcp_flag_word(tp) ( __get_unaligned_cpu32union tcp_word_hdr 
 *)(tp))-words [3])))

 Ewww. And didn't you already make that union __packed anyway?

yes, ewww. I'll note that I don't like the define in the general case.
It is used both for assignment (once!) and for access , which is why
it got broken into two macros...


 +diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
 +index 22ef5f9..bf3f773 100644
 +--- a/net/ipv4/tcp.c
  b/net/ipv4/tcp.c
 +@@ -2834,7 +2834,7 @@ found:
 +
 +       p = *head;
 +       th2 = tcp_hdr(p);
 +-      tcp_flag_word(th2) |= flags  (TCP_FLAG_FIN | TCP_FLAG_PSH);
 ++      tcp_flag_word2(th2) = tcp_flag_word(th2) | flags  (TCP_FLAG_FIN | 
 TCP_FLAG_PSH);

 net/ipv4/tcp.c: In function 'tcp_gro_receive':
 net/ipv4/tcp.c:2837:82: warning: suggest parentheses around arithmetic in 
 operand of '|' [-Wparentheses]

 Have you posted these patches to the netdev list? And is the response
 going to be just make sure your network devices are receiving packets
 into sensibly-aligned buffers, and none of this is necessary?

Yes, that would be the answer I expect from the list.

There is no reason to try to push this stuff upstream.

 There's a reason a lot of Ethernet drivers pad the start of their skb by
 2 bytes before receiving the packet...

Tell it to however wired up this chip and shipped it in qty millions.
Actually that message was already received, successor chipsets from
this manufacturer did it up right.

I am somewhat forgiving in that. Compared to some arches I've worked
with the ar71xx is very solid. (for comparison, take the ep9302, where
a working toolchain didn't arrive until 2 years after the chip had
ceased production)

But this problem is a PITA, and as demonstrated, scribbling on these
core portions of the stack improves performance by an enormous amount.

 --
 dwmw2

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx

2012-04-30 Thread Dave Taht
On Mon, Apr 30, 2012 at 7:49 AM, David Woodhouse dw...@infradead.org wrote:
 On Mon, 2012-04-30 at 07:41 -0700, Dave Taht wrote:
 Tell it to however wired up this chip and shipped it in qty millions.
 Actually that message was already received, successor chipsets from
 this manufacturer did it up right.

 So the real problem is that the ar71xx doesn't allow you to DMA to
 addresses which aren't aligned to 4 bytes? Which network devices does
 that restriction apply to? All of them?


 Out of interest, have you done a performance comparison with just
 *moving* the packet when it arrives?

I did not. Felix did.



Fixing this issue has had a long, tortuous history...

this got tried and later backed out...

https://dev.openwrt.org/changeset/20892

- on ar724x, rx buffers can be aligned with an offset of 2, which
keeps the ip header aligned
- alignment offset is only added if the ar8216 workaround is not
active and the phy driver does not advertise its own packet alignment
- ar71xx and ar91xx can not handle rx alignment offsets, however
taking a hit on unaligned exceptions seems to have less overhead than
re-aligning the data for large packets
- use memmove to re-align small packets, if necessary

tested on ar9132, ar7240 and ar7242 based devices without ar8216 headers

Which got backed out here:

https://dev.openwrt.org/ticket/7236

So I'd certainly be willing to attempt realignment in the driver, and
sort of remember that it's like a one-liner to do nowadays...

but it is a 16 bit bus, and packets are dmaed, so getting the cpu
involved on every ethernet transfer strikes me as potentially very
bad.


 If this really is needed to work around hardware limitations, I don't
 see why *some* of it shouldn't be acceptable upstream. A config option
 to add '__packed' to various structures is fairly harmless, for
 example...

The __packed trick, so far as I know, is undefined gcc behavior. But, yea,
perhaps something more PC than this

#define F_ING_HW_ENGINEER_SAVED_A_PIN __packed


 --
 dwmw2



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx

2012-04-30 Thread Dave Taht
On Mon, Apr 30, 2012 at 8:02 AM, Felix Fietkau n...@openwrt.org wrote:
 On 2012-04-30 4:49 PM, David Woodhouse wrote:
 On Mon, 2012-04-30 at 07:41 -0700, Dave Taht wrote:
 Tell it to however wired up this chip and shipped it in qty millions.
 Actually that message was already received, successor chipsets from
 this manufacturer did it up right.

 So the real problem is that the ar71xx doesn't allow you to DMA to
 addresses which aren't aligned to 4 bytes? Which network devices does
 that restriction apply to? All of them?
 AR71xx and AR91xx are affected, AR724x, AR933x, AR934x are unaffected.

I guess a long term issue is this patch needs to apply only to those arches,
somehow. It's silly to be hurtful to the successor arches.


 Out of interest, have you done a performance comparison with just
 *moving* the packet when it arrives?
 I did some tests before I did the first unaligned hack patch, I don't
 have the numbers anymore, but the results were horrible.

I'm still looking for the 'one liner to pass the driver to tell it to realign',
but was that the approach you were trying...


 If this really is needed to work around hardware limitations, I don't
 see why *some* of it shouldn't be acceptable upstream. A config option
 to add '__packed' to various structures is fairly harmless, for
 example...
 Makes sense

 - Felix



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx

2012-04-30 Thread Dave Taht
On Mon, Apr 30, 2012 at 10:26 AM, Felix Fietkau n...@openwrt.org wrote:
 On 2012-04-30 5:08 PM, Dave Taht wrote:
 On Mon, Apr 30, 2012 at 8:02 AM, Felix Fietkau n...@openwrt.org wrote:
 On 2012-04-30 4:49 PM, David Woodhouse wrote:
 On Mon, 2012-04-30 at 07:41 -0700, Dave Taht wrote:
 Tell it to however wired up this chip and shipped it in qty millions.
 Actually that message was already received, successor chipsets from
 this manufacturer did it up right.

 So the real problem is that the ar71xx doesn't allow you to DMA to
 addresses which aren't aligned to 4 bytes? Which network devices does
 that restriction apply to? All of them?
 AR71xx and AR91xx are affected, AR724x, AR933x, AR934x are unaffected.

 I guess a long term issue is this patch needs to apply only to those arches,
 somehow. It's silly to be hurtful to the successor arches.


 Out of interest, have you done a performance comparison with just
 *moving* the packet when it arrives?
 I did some tests before I did the first unaligned hack patch, I don't
 have the numbers anymore, but the results were horrible.

 I'm still looking for the 'one liner to pass the driver to tell it to 
 realign',
 but was that the approach you were trying...
 I did test with such a one liner (or maybe it was a two liner), but I
 didn't keep the patch.
 I think it's quite normal that this approach is so much more expensive
 than adding the unaligned access hacks. The main bottleneck on these
 devices is the memory bus, and for normal traffic passed through the
 device as a router, the CPU does not have to touch much of the payload
 contents at all, since it's only touched by DMA.
 Doing a memmove to re-align the packet contents blows the dcache
 footprint out of proportion and significantly increases the amount of
 unnecessary memory bus traffic.

I agree it would blow up the dcache and be worse than what exists by a lot.

So, out of this conversation:

1) It would be nice to not have this patch take effect on any but the
ar71xx and ar91xx. As these share code in openwrt, doing it with a
compile time define

2) IF there existed another brain damaged ethernet chip on some other
arch, it would be worth coming up with a Kbuild option to enable
defining __packed generically as part of the network stack for those
arches. Something more
pithy than

#define F_ING_HW_ENGINEER_SAVED_PIN

would be needed tho.

#define UNALIGNED_ETHERNET

perhaps.

3) I don't like the tcp_hdr macro in general, but it looks like that
is an obsolete part of the patch anyway, so I'll try ripping it out.

4) get_unaligned_be32 seems like the right thing rather than
get_unaligned_cpu32?

5) I THINK the 'if aligned, do assembly version' for the checksums is
a win, but if item #2 is true, I'm not happy with the casts...

@@ -105,6 +141,9 @@ static inline __sum16 ip_fast_csum(const void
*iph, unsigned int ihl)
unsigned int csum;
int carry;

+   if ((unsigned int) iph  3)
+   return ip_fast_csum_unaligned(iph,ihl);
+


 - Felix



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx

2012-04-24 Thread Dave Taht
Would it be too much to ask for those expending time on this debate,
to expend a little extra time doing some code review and testing this
patch?

Or, like while the flames are being composed, merely sending data through it?

This particular patch improves ipv4 by over 10% especially when used
with the sfq and sfqred qdiscs, fixes encapsulation for ipsec (both
ipv4 and ipv6), and yes, more than doubles ipv6 performance on the
ag71xx.

Although simple in outline, it is pretty invasive into core bits of
the kernel. I wish it wasn't, but the alternatives (have the driver
rebuffer misaligned packets) were far worse for performance, and the
final patch isn't all that big.

I agree with felix's suggestion to not let __packed leak out of the
kernel headers, and will respin the patch for that. I'm dubious that
the check alignment and branch is actually all that useful in the ipv6
checksum code, too, on an arch with a small cache.

And I'm still trying to track down the last causes of traps in the
routing path, and several other ipv6 and ipv4 related bugs. I'm pretty
sure that the traps in the routing path have caused many a tcp reset
for me over the last year, under load.

http://www.bufferbloat.net/projects/cerowrt/issues/371

http://www.bufferbloat.net/projects/cerowrt/issues

http://www.bufferbloat.net/projects/cerowrt/issues/360


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 1/2] __packed can leak from the kernel headers into iptables so define

2012-04-24 Thread Dave Taht
On Tue, Apr 24, 2012 at 7:21 AM, David Woodhouse dw...@infradead.org wrote:
 On Mon, 2012-04-23 at 07:24 +0200, Felix Fietkau wrote:
 Maybe it would make sense to just use the long form
 __attribute__((packed)) instead of __packed in parts that are visible to
 userspace.

 Hm, 'make headers_install' should be performing that substitution
 anyway, shouldn't it?

 I don't quite see why this patch was needed in the first place.


The a) __packed portion or the b) patch to iptables?

a) Although most of the network headers are naturally 'packed', the
compiler by default issues aligned instructions for accessing them. In
the case of the ag71xx stuff dma-ing in from the ethernet device are
misaligned, and the cost on re-aligning them with a memmove (16 bit
bus!) proved to be very high.

https://dev.openwrt.org/changeset/20892/trunk/target/linux/ar71xx/files/drivers/net/ag71xx/ag71xx_main.c

This alignment issue is one of the few flaws of this hardware, and was
fixed in successor chipsets.

Declaring key network headers __packed causes the compiler to issue
unaligned instructions to access the members. The basic ipv4 patch has
been in openwrt for nearly a year now. The remainder of the patch
finds casts to other types and makes sure they are also accessed
unaligned.

b) However __packed leaks out of the main network header file, and was
not defined by iptables to be the define it is in the kernel code.


 --
 dwmw2

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 1/2] __packed can leak from the kernel headers into iptables so define

2012-04-24 Thread Dave Taht
On Tue, Apr 24, 2012 at 7:50 AM, David Woodhouse dw...@infradead.org wrote:
 On Tue, 2012-04-24 at 07:47 -0700, Dave Taht wrote:
 b) However __packed leaks out of the main network header file, and was
 not defined by iptables to be the define it is in the kernel code.

 How? When you run 'make headers_install' to export kernel headers for
 use by userspace, it *sanitizes* them, which includes automatically
 changing any instance of __packed to __attribute__((packed)). See
 scripts/headers_install.pl

 If someone is using headers that they've just copied out of the kernel,
 instead of using 'make headers_install', they deserve all the breakage
 they get.


Hmm. OK. Well, it happened, so perhaps something in openwrt is doing
it wrong, or some pattern of mine while doing a build broke it.

I'll try a clean build later this week, with the iptables patch
removed. Certainly it's cleaner to use __packed everywhere it is used.

As for the former, I don't know enough of the innards of the openwrt
buildsystem to really even know where to look.

 --
 dwmw2

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 1/2] __packed can leak from the kernel headers into iptables so define

2012-04-24 Thread Dave Taht
Also I'd like for there to be some way to not apply this patch on
successor architectures such as the

- on ar724x, rx buffers can be aligned with an offset of 2, which
keeps the ip header aligned
- alignment offset is only added if the ar8216 workaround is not
active and the phy driver does not advertise its own packet alignment

On Tue, Apr 24, 2012 at 7:53 AM, Dave Taht dave.t...@gmail.com wrote:
 On Tue, Apr 24, 2012 at 7:50 AM, David Woodhouse dw...@infradead.org wrote:
 On Tue, 2012-04-24 at 07:47 -0700, Dave Taht wrote:
 b) However __packed leaks out of the main network header file, and was
 not defined by iptables to be the define it is in the kernel code.

 How? When you run 'make headers_install' to export kernel headers for
 use by userspace, it *sanitizes* them, which includes automatically
 changing any instance of __packed to __attribute__((packed)). See
 scripts/headers_install.pl

 If someone is using headers that they've just copied out of the kernel,
 instead of using 'make headers_install', they deserve all the breakage
 they get.


 Hmm. OK. Well, it happened, so perhaps something in openwrt is doing
 it wrong, or some pattern of mine while doing a build broke it.

 I'll try a clean build later this week, with the iptables patch
 removed. Certainly it's cleaner to use __packed everywhere it is used.

 As for the former, I don't know enough of the innards of the openwrt
 buildsystem to really even know where to look.

 --
 dwmw2

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel




 --
 Dave Täht
 SKYPE: davetaht
 US Tel: 1-239-829-5608
 http://www.bufferbloat.net



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Comprehensive ipv4 and ipv6 unaligned access, patch for ar71xx

2012-04-23 Thread Dave Taht
On Mon, Apr 23, 2012 at 11:43 AM, David Woodhouse dw...@infradead.org wrote:
 On Mon, 2012-04-23 at 20:14 +0200, Gert Doering wrote:
 (Now, what I'm not sure whether OpenWRT already has this: to fully
 utilize IPv6 over here, what you need to have is dynamic IPv6 prefix
 support using DHCP-PD.  As in router queries ISP for a prefix, ISP
 assigns 2001:db8:1::/56, router assigns 2001:db8:1:1::/64 to LAN,
 2001:db8:1:2::/64 for WiFi and informs radvd that this is the prefix
 to be used.  AVM's Fritz!Box does this nicely today, but not with
 open source components...)

 It's documented here: http://wiki.openwrt.org/doc/uci/dhcp6c

 I haven't actually tried it; I have to manually configure the range of
 Legacy IP addresses anyway, so it's easy enough to configure the IPv6
 too. But I *will* try it, and make sure it interoperates with my ISP
 correctly.

It has long been a goal of mine to have both cerowrt and openwrt
builds ready for world ipv6 launch day and be able to fully meet this
spec:

http://www.worldipv6launch.org/form/?q=3

I'd like to think I'm close. But truly getting there will require more
folk to want to do it, by that date. Please goferit!

All the machines in the bloatlab are native dual-stack
(see, for example, http://europa.lab.bufferbloat.net/cerowrt/ ), and I
have several running dhcp-pd, sorta. It's my last remaining bug. I
tried dibbler (crashes after 24 hrs), and isc-dhcp (too big, too
complex) and have fallen back to wide. I have reports of it working in
New Zealand.

The biggest problem that I have (in America, at least) is that
comcast's first rollout is only going to be a single /64 delegation,
which breaks cerowrt's multiple interface scheme, but will hopefully
work ok with openwrt. Still, /64 only is crazy and I'm told they
intend to do better by fall.

Certainly other providers are handing out /56s and /60s.

 We should make sure it's enabled by default.

Latest build for me, wide-dhcpv6 is installed but not enabled by default.
After some testing, it will.

 There should be no need for anyone to disable IPv6, except perhaps if
 they mean by that turn off automatic 6to4. If they're stuck in the
 20th century and don't have IPv6 routing, they won't get IPv6. What's to
 disable?

 (And no, I wouldn't advocate 6to4 being enabled by default anyway).

I had it enabled by default during comcast's trials. It worked great,
on their network (and having a /48 was good too). It didn't work very
well elsewhere, so it's in there, but disabled by default.

 I also have HE tunnels and 6rd working.

I'm more of the opinion that ipv6 needs to be made to work, using
every method possible, and if possible, those methods should be able
to co-exist, using policy routing. That proves to be hard.


 --
 dwmw2

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx

2012-04-22 Thread Dave Taht
On Sun, Apr 22, 2012 at 2:48 PM, Dave Täht dave.t...@bufferbloat.net wrote:
 This updates the existing unaligned_access_hacks patch to
 reduce unalignment traps to nearly zero for ipv4 and ipv6,
 in the normal path, in encapsulation, for native apps,
 and in the qdiscs.

While I have tested these patches for several days now,
I have not tested them in the default openwrt 'bridged' environment,
and they could use more testing as well as a better
before/after comparison for ipv4 and ipv6 performance
vs a vs wireless.

Certainly they won big on ipv6...

If you prefer patches free of being mangled by email, see:

http://huchra.bufferbloat.net/~d/for_openwrt/



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] Add Lua bindings for libgps

2012-04-16 Thread Dave Taht
On Mon, Apr 16, 2012 at 2:37 AM, Christian Gagneraud ch...@techworks.ie wrote:
 On 05/04/12 16:19, Dave Taht wrote:

 I note that I have been tracking the latest gpsds closely (with the new
 api)

 A problem is that it requires that scons support be added to the
 mainline openwrt build.

 Got patches for all that, could use some more testing...


 Hi Dave,

 I'm interesting as well to see gpsd updated to the latest stable version,
 would you mind to share your patches? I'll be happy to give them a try!

The newly released gpsd 3.5 is currently living in the ceropackages
repository, and has only been tested on the wndr3700v2 (and not quite
3.5 was tested - 3.5 was released saturday)

It also requires that chkpath and scons support be added to the main openwrt .

(aformentioned scons support is also required for things like xorp)

you can either add the ceropackages repo to your feeds.conf

src-git cero git://github.com/dtaht/ceropackages.git
./scripts/feeds uninstall gpsd
./scripts/feeds install cero gpsd

or extract the latest gpsd package from:
https://github.com/dtaht/ceropackages/tree/master/net

As for the scons and chrpath support, patches are at:

http://huchra.bufferbloat.net/~cero1/for_openwrt/

I'm sure eric would love to see gpsd 2.x retired from openwrt
(and I'd love the lua interface you just did)

(hat off to swalker for packaging this stuff up and eric for taking
 the openwrt related patches into his mainline)




 Chris




 On Thu, Apr 5, 2012 at 3:02 AM, Viktar Palstsiuk
 viktar.palsts...@promwad.com  wrote:

 Signed-off-by: Viktar Palstsiukviktar.palsts...@promwad.com
 ---
  lang/luagps/Makefile                               |   50
 
  .../001-add_compatibility_with_old_gpsd_api.patch  |   62
 
  2 files changed, 112 insertions(+), 0 deletions(-)
  create mode 100644 lang/luagps/Makefile
  create mode 100644
 lang/luagps/patches/001-add_compatibility_with_old_gpsd_api.patch

 diff --git a/lang/luagps/Makefile b/lang/luagps/Makefile
 new file mode 100644
 index 000..268e826
 --- /dev/null
 +++ b/lang/luagps/Makefile
 @@ -0,0 +1,50 @@
 +#
 +# Copyright (C) 2012 OpenWrt.org
 +#
 +# This is free software, licensed under the GNU General Public License
 v2.
 +# See /LICENSE for more information.
 +#
 +
 +include $(TOPDIR)/rules.mk
 +
 +PKG_NAME:=luagps
 +PKG_REV:=2d3dd6b1cc7b87891af19857bfedd2e1845d2e3b
 +PKG_RELEASE:=1
 +
 +PKG_SOURCE:=$(PKG_NAME)-$(PKG_REV).tar.bz2
 +PKG_SOURCE_SUBDIR:=$(PKG_NAME)
 +PKG_SOURCE_PROTO:=git
 +PKG_SOURCE_URL:=git://github.com/jdegges/lua-gps.git
 +PKG_SOURCE_VERSION:=$(PKG_REV)
 +
 +include $(INCLUDE_DIR)/package.mk
 +
 +define Package/luagps
 +  SUBMENU:=Lua
 +  SECTION:=lang
 +  CATEGORY:=Languages
 +  TITLE:=Lua bindings for libgps
 +  URL:=https://github.com/jdegges/lua-gps
 +  DEPENDS:=+lua +gpsd
 +endef
 +
 +define Package/luagps/description
 +  Lua bindings for libgps.
 +endef
 +
 +define Build/Configure
 +endef
 +
 +TARGET_CFLAGS += $(FPIC) -shared -g -W -Wall
 -I$(STAGING_DIR)/usr/include/
 +TARGET_LDFLAGS += -lgps
 +
 +define Build/Compile
 +       $(TARGET_CC) $(TARGET_CFLAGS) $(TARGET_LDFLAGS)
 $(PKG_BUILD_DIR)/lgps.c -o $(PKG_BUILD_DIR)/gps.so
 +endef
 +
 +define Package/luagps/install
 +       $(INSTALL_DIR) $(1)/usr/lib/lua
 +       $(INSTALL_BIN) $(PKG_BUILD_DIR)/gps.so $(1)/usr/lib/lua/
 +endef
 +
 +$(eval $(call BuildPackage,luagps))
 diff --git
 a/lang/luagps/patches/001-add_compatibility_with_old_gpsd_api.patch
 b/lang/luagps/patches/001-add_compatibility_with_old_gpsd_api.patch
 new file mode 100644
 index 000..63a7f3d
 --- /dev/null
 +++ b/lang/luagps/patches/001-add_compatibility_with_old_gpsd_api.patch
 @@ -0,0 +1,62 @@
 +--- a/lgps.c   2012-04-05 11:19:27.0 +0300
  b/lgps.c   2012-04-05 12:28:17.0 +0300
 +@@ -30,7 +30,6 @@
 + static int
 + lgps_open (lua_State *L)
 + {
 +-  int top = lua_gettop (L);
 +   struct gps_data_t *ud = NULL;
 +   const char *server = luaL_checkstring (L, 1);
 +   const char *port = luaL_checkstring (L, 2);
 +@@ -39,8 +38,13 @@
 +   if (NULL == ud)
 +     print_error (out of memory);
 +
 ++#if (GPSD_API_MAJOR_VERSION  4)
 +   if (0 != gps_open (server, port, ud))
 +     print_error (no gpsd running or network error: %d, %s, errno,
 gps_errstr (errno));
 ++#else
 ++  if (0 != gps_open_r (server, port, ud))
 ++    print_error (no gpsd running or network error: %d, %s, errno,
 gps_errstr (errno));
 ++#endif
 +
 +   luaL_getmetatable (L, MT_GPS);
 +   lua_setmetatable (L, -2);
 +@@ -86,9 +90,13 @@
 + lgps_waiting (lua_State *L)
 + {
 +   struct gps_data_t *ud = luaL_checkudata (L, 1, MT_GPS);
 +-  lua_Integer timeout = luaL_checkinteger (L, 2);
 +
 ++#if (GPSD_API_MAJOR_VERSION  4)
 ++  lua_Integer timeout = luaL_checkinteger (L, 2);
 +   lua_pushboolean (L, gps_waiting (ud, timeout));
 ++#else
 ++  lua_pushboolean (L, gps_waiting (ud));
 ++#endif
 +
 +   return 1;
 + }
 +@@ -108,7 +116,12 @@
 +   int count;
 +   int i;
 +
 ++#if (GPSD_API_MAJOR_VERSION

Re: [OpenWrt-Devel] [PATCH] Add Lua bindings for libgps

2012-04-05 Thread Dave Taht
I note that I have been tracking the latest gpsds closely (with the new api)

A problem is that it requires that scons support be added to the
mainline openwrt build.

Got patches for all that, could use some more testing...

On Thu, Apr 5, 2012 at 3:02 AM, Viktar Palstsiuk
viktar.palsts...@promwad.com wrote:
 Signed-off-by: Viktar Palstsiuk viktar.palsts...@promwad.com
 ---
  lang/luagps/Makefile                               |   50 
  .../001-add_compatibility_with_old_gpsd_api.patch  |   62 
 
  2 files changed, 112 insertions(+), 0 deletions(-)
  create mode 100644 lang/luagps/Makefile
  create mode 100644 
 lang/luagps/patches/001-add_compatibility_with_old_gpsd_api.patch

 diff --git a/lang/luagps/Makefile b/lang/luagps/Makefile
 new file mode 100644
 index 000..268e826
 --- /dev/null
 +++ b/lang/luagps/Makefile
 @@ -0,0 +1,50 @@
 +#
 +# Copyright (C) 2012 OpenWrt.org
 +#
 +# This is free software, licensed under the GNU General Public License v2.
 +# See /LICENSE for more information.
 +#
 +
 +include $(TOPDIR)/rules.mk
 +
 +PKG_NAME:=luagps
 +PKG_REV:=2d3dd6b1cc7b87891af19857bfedd2e1845d2e3b
 +PKG_RELEASE:=1
 +
 +PKG_SOURCE:=$(PKG_NAME)-$(PKG_REV).tar.bz2
 +PKG_SOURCE_SUBDIR:=$(PKG_NAME)
 +PKG_SOURCE_PROTO:=git
 +PKG_SOURCE_URL:=git://github.com/jdegges/lua-gps.git
 +PKG_SOURCE_VERSION:=$(PKG_REV)
 +
 +include $(INCLUDE_DIR)/package.mk
 +
 +define Package/luagps
 +  SUBMENU:=Lua
 +  SECTION:=lang
 +  CATEGORY:=Languages
 +  TITLE:=Lua bindings for libgps
 +  URL:=https://github.com/jdegges/lua-gps
 +  DEPENDS:=+lua +gpsd
 +endef
 +
 +define Package/luagps/description
 +  Lua bindings for libgps.
 +endef
 +
 +define Build/Configure
 +endef
 +
 +TARGET_CFLAGS += $(FPIC) -shared -g -W -Wall -I$(STAGING_DIR)/usr/include/
 +TARGET_LDFLAGS += -lgps
 +
 +define Build/Compile
 +       $(TARGET_CC) $(TARGET_CFLAGS) $(TARGET_LDFLAGS) 
 $(PKG_BUILD_DIR)/lgps.c -o $(PKG_BUILD_DIR)/gps.so
 +endef
 +
 +define Package/luagps/install
 +       $(INSTALL_DIR) $(1)/usr/lib/lua
 +       $(INSTALL_BIN) $(PKG_BUILD_DIR)/gps.so $(1)/usr/lib/lua/
 +endef
 +
 +$(eval $(call BuildPackage,luagps))
 diff --git 
 a/lang/luagps/patches/001-add_compatibility_with_old_gpsd_api.patch 
 b/lang/luagps/patches/001-add_compatibility_with_old_gpsd_api.patch
 new file mode 100644
 index 000..63a7f3d
 --- /dev/null
 +++ b/lang/luagps/patches/001-add_compatibility_with_old_gpsd_api.patch
 @@ -0,0 +1,62 @@
 +--- a/lgps.c   2012-04-05 11:19:27.0 +0300
  b/lgps.c   2012-04-05 12:28:17.0 +0300
 +@@ -30,7 +30,6 @@
 + static int
 + lgps_open (lua_State *L)
 + {
 +-  int top = lua_gettop (L);
 +   struct gps_data_t *ud = NULL;
 +   const char *server = luaL_checkstring (L, 1);
 +   const char *port = luaL_checkstring (L, 2);
 +@@ -39,8 +38,13 @@
 +   if (NULL == ud)
 +     print_error (out of memory);
 +
 ++#if (GPSD_API_MAJOR_VERSION  4)
 +   if (0 != gps_open (server, port, ud))
 +     print_error (no gpsd running or network error: %d, %s, errno, 
 gps_errstr (errno));
 ++#else
 ++  if (0 != gps_open_r (server, port, ud))
 ++    print_error (no gpsd running or network error: %d, %s, errno, 
 gps_errstr (errno));
 ++#endif
 +
 +   luaL_getmetatable (L, MT_GPS);
 +   lua_setmetatable (L, -2);
 +@@ -86,9 +90,13 @@
 + lgps_waiting (lua_State *L)
 + {
 +   struct gps_data_t *ud = luaL_checkudata (L, 1, MT_GPS);
 +-  lua_Integer timeout = luaL_checkinteger (L, 2);
 +
 ++#if (GPSD_API_MAJOR_VERSION  4)
 ++  lua_Integer timeout = luaL_checkinteger (L, 2);
 +   lua_pushboolean (L, gps_waiting (ud, timeout));
 ++#else
 ++  lua_pushboolean (L, gps_waiting (ud));
 ++#endif
 +
 +   return 1;
 + }
 +@@ -108,7 +116,12 @@
 +   int count;
 +   int i;
 +
 ++#if (GPSD_API_MAJOR_VERSION  4)
 +   count = gps_read (ud);
 ++#else
 ++  count = gps_poll (ud) + 1;
 ++#endif
 ++
 +   if (count = 0)
 +     print_error (either no data or error reading data);
 +
 +@@ -247,7 +260,9 @@
 +   SET_CONST_INT (WATCH_RARE);
 +   SET_CONST_INT (WATCH_RAW);
 +   SET_CONST_INT (WATCH_SCALED);
 ++#if (GPSD_API_MAJOR_VERSION  4)
 +   SET_CONST_INT (WATCH_TIMING);
 ++#endif
 +   SET_CONST_INT (WATCH_DEVICE);
 +   SET_CONST_INT (WATCH_NEWSTYLE);
 +   SET_CONST_INT (WATCH_OLDSTYLE);
 --
 1.7.9.1

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] openwrt ntp ipv6 servers

2012-04-05 Thread Dave Taht
On Thu, Apr 5, 2012 at 10:20 AM, Gioacchino Mazzurco
gmazzurc...@gmail.com wrote:
 Hi all!


 It seems to me that only 2.openwrt.pool.ntp.org is reacheable trought ipv6

 I think that it is better to add ipv6 support also to the other 3
 servers, is there any particular problem why they are not ipv6 ready ?

 Because for examples in our community network ( ninux pisa ) nodeas have
 only ipv6 and ntp seems keep trying to connect just to
 0.openwrt.pool.ntp.org that obviously is unreacheable

I'm sitting in the offices (isc.org) where ntp.org is located. When
last I looked there were
also some issues with how dns was setup... let me poke into it.
However I have no
control, influence, or insight into what can be done to spread ntp
over ipv6 better.

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] iproute 3.3? (was: iproute2 bump to 3.2.0 and ss now available)

2012-04-02 Thread Dave Taht
iproute-3.3 was released march 19th. I've been using the git version for
months now (on 3.2 and 3.3), but I'd done things like rip out esfq (totally
obsolete), q_wrr (does it even work?), and was puzzled as to why it fiddled
so much with pkt_sched.h...

So I'll gladly produce an openwrt patch for iproute-3.3, but would like
answers to the above questions first...

In my case iproute-3.3 is needed for adaptive red, the enhanced sfq, and
sfqred...

I note the sfq enhancements in 3.3 expose a bug in qos-scripts where
'limit' is packets, but is passed as bytes.

commit 18cb809850fb499ad9bf288696a95f4071f73931
Author: Eric Dumazet eric.duma...@gmail.com
Date:   Wed Jan 4 14:18:38 2012 +

net_sched: sfq: extend limits

SFQ as implemented in Linux is very limited, with at most 127 flows
and limit of 127 packets. [ So if 127 flows are active, we have one
packet per flow ]

This patch brings to SFQ following features to cope with modern needs.

- Ability to specify a smaller per flow limit of inflight packets.
(default value being at 127 packets)

- Ability to have up to 65408 active flows (instead of 127)

- Ability to have head drops instead of tail drops
  (to drop old packets from a flow)

Example of use : No more than 20 packets per flow, max 8000 flows, max
2 packets in SFQ qdisc, hash table of 65536 slots.

tc qdisc add ... sfq \
flows 8000 \
depth 20 \
headdrop \
limit 2 \
divisor 65536

Ram usage :

2 bytes per hash table entry (instead of previous 1 byte/entry)
32 bytes per flow on 64bit arches, instead of 384 for QFQ, so much
better cache hit ratio.




the sfqred support in 3.3, described here:

commit 6987ecf0832d62350ea10432f3f1f7a84c457b81
Author: Eric Dumazet eric.duma...@gmail.com
Date:   Fri Jan 20 12:17:43 2012 +0100

sfq: add optional RED on top of SFQ

Adds an optional Random Early Detection on each SFQ flow queue.

Traditional SFQ limits count of packets, while RED permits to also
control number of bytes per flow, and adds ECN capability as well.

1) We dont handle the idle time management in this RED implementation,
since each 'new flow' begins with a null qavg. We really want to address
backlogged flows.

2) if headdrop is selected, we try to ecn mark first packet instead of
currently enqueued packet. This gives faster feedback for tcp flows
compared to traditional RED [ marking the last packet in queue ]

Example of use :

tc qdisc add dev $DEV parent 1:1 handle 10: est 1sec 4sec sfq \
limit 3000 headdrop flows 512 divisor 16384 \
redflowlimit 10 min 8000 max 6 probability 0.20 ecn

qdisc sfq 10: parent 1:1 limit 3000p quantum 1514b depth 127 headdrop
flows 512/16384 divisor 16384
 ewma 6 min 8000b max 6b probability 0.2 ecn
 prob_mark 0 prob_mark_head 4876 prob_drop 6131
 forced_mark 0 forced_mark_head 0 forced_drop 0
 Sent 1175211782 bytes 777537 pkt (dropped 6131, overlimits 11007
requeues 0)
 rate 99483Kbit 8219pps backlog 689392b 456p requeues 0

In this test, with 64 netperf TCP_STREAM sessions, 50% using ECN enabled
flows, we can see number of packets CE marked is smaller than number of
drops (for non ECN flows)

If same test is run, without RED, we can check backlog is much bigger.

qdisc sfq 10: parent 1:1 limit 3000p quantum 1514b depth 127 headdrop
flows 512/16384 divisor 16384
 Sent 1148683617 bytes 795006 pkt (dropped 0, overlimits 0 requeues 0)
 rate 98429Kbit 8521pps backlog 1221290b 841p requeues 0

Signed-off-by: Eric Dumazet eric.duma...@gmail.com



On Mon, Apr 2, 2012 at 10:02 AM, Florian Fainelli flor...@openwrt.orgwrote:



 Le 02/16/12 14:49, Oliver a écrit :

  This patch bumps iproute2 to the latest available version, fixes the
 package URL to use kernel.org (as things have now been moved back there)
 and also adds ss (socket statistics) to menuconfig.

 Signed-off-by: Oliver Smitholipro@8.c.9.b.0.7.4.0.**1.0.0.2.ip6.arpa


 Applied in r31179, thanks Oliver!
 --
 Florian
 __**_
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.**org openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/**mailman/listinfo/openwrt-develhttps://lists.openwrt.org/mailman/listinfo/openwrt-devel




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] iproute 3.3? (was: iproute2 bump to 3.2.0 and ss now available)

2012-04-02 Thread Dave Taht
On Mon, Apr 2, 2012 at 11:06 AM, Dave Taht dave.t...@gmail.com wrote:

 iproute-3.3 was released march 19th. I've been using the git version for
 months now (on 3.2 and 3.3), but I'd done things like rip out esfq (totally
 obsolete), q_wrr (does it even work?), and was puzzled as to why it fiddled
 so much with pkt_sched.h...


This was my hacked and slashed update from iproute 3.2 to iproute-3.3.

https://github.com/dtaht/Cerowrt-3.3/commit/859f5aa8b033ba66044548db25e5e041bba95ec2

Why is htb getting scribbled on?

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] ath9k_htc ad-hoc bitrate stuck at 1Mbit/s

2012-03-31 Thread Dave Taht
2012/3/31 Nicolás Echániz nicoecha...@codigosur.org

 I'm not sure if this is the right place to report/ask about this matter
 so I'll try to make it short and please ask for any additional
 information that could be important.

 We are building a free network in a small town in Córdoba, Argentina.
 The hardware we are using for the nodes is: TPlink MR-3220 + usb wifi
 dongle WN722N

 So each node has two interfaces, internal + USB.

 The software is OpenWRT (trunk) and batman-adv as dynamic routing protocol.

 We have been using OpenWRT Rev.29660 for a couple of weeks, but after we
 updated to Rev.31077 (to test batman-adv 2012.0.0), the WN722N dongles
 (which use ath9k_htc) are always stuck at 1Mbit/s bitrate. This only
 happens in ad-hoc mode, infrastructure works fine.


I am having total breakage of wifi (on 3.3.) at present, but until last
week I got good rates out of adhoc on the wndr3800s on both 2.4 and 5 ghz.

I'm kind of hoping you're narrowing where it went bad with your commit
range...


 We have tested other dongles: WN7200ND, which use rt2800usb and this
 problem is not present (bitrate is 150Mbit/s as it should be), same
 thing with the internal (ath9k) interfaces in the MR-3220 routers.

 We haven't had the opportunity to trace down the problem to a specific
 revision, but we know it is somewhere between r.29660 and r.31077

 Please let us know what information would be relevant in order to help
 nail this problem and we will report it.


 On a side note, we would like to ask if there's any wifi/usb chipset
 that's known to work well in ad-hoc mode.


There's a atheros based USB stick I've heard good things about (open source
drivers too)

http://linuxwireless.org/en/users/Drivers/Atheros#USB_Drivers

It seems like there has been a movement of late to discard adhoc in favor
of... well I don't know, I see new, shiny meshy stuff, but as one example,
adhoc is now disabled on most android phones.

I'm told it's because adhoc uses more battery, but I tend to think it was
because it's old technology that used to 'just work', and we can't have
that

This community network[0] is the first of many we will be building
 during this year in the area. We are testing the possibilities of cheap
 multi-interface nodes because we are working with a very low income
 population.


That's my own focus too. The architecture I'd settled on was directional
nanostation m5s for the longer haul links, and dual channel boxes for the
more meshy nodes. I predate batman-adv (been meaning to try it) so I'd
settled on babel and AHCP...




 Cheers,
 NicoEchániz


 [0] http://www.lavecindaria.org.ar/article/quintanacamp-2012/

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] linux 3.3 hostapd issue between 30952 - 31118

2012-03-29 Thread Dave Taht
On Tue, Mar 27, 2012 at 9:52 PM, Otto Solares Cabrera so...@guug.orgwrote:

 On Tue, Mar 27, 2012 at 05:03:24PM -0700, Dave Taht wrote:
  however my issue is that hostapd isn't coming up for ap mode.

 Yeah in 3.3 the mon.wlan0 i/f is not being setup but I didn't
 investigate further.


Your confirmation rules out cerowrt's setup (with device renaming, etc), so
that
reduces it to hostapd, nl, wireless-next, or the 3.3 kernel, sometime in
the last 150 commits. sigh.

I confirm there's no mon device being created.

Go looking for a newer hostapd? bisect?

root@OpenWrt:/lib/wifi# wifi start

Configuration file: /var/run/hostapd-phy0.conf
nl80211: Failed to set interface sw00 into AP mode
nl80211 driver initialization failed.
Failed to start hostapd for phy0

Configuration file: /var/run/hostapd-phy1.conf
nl80211: Failed to set interface sw10 into AP mode
nl80211 driver initialization failed.
Failed to start hostapd for phy1


 OTOH is just me or do you note too that the compressed firmware
 image with the 3.3 kernel is like 0.25MB bigger than 3.2?  It
 seems too much kernelbloat* to me :(


firmwarebloat on my side is cracking 10Mbytes, hardly notice a difference...


 *any similarity with bufferbloat is pure coincidence... :)


Well, I was just about to try finalizing the last aqm fixes and boom went
the wifi.

 --
  Otto
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] linux 3.3 hostapd issue between 30952 - 31118

2012-03-29 Thread Dave Taht
On Thu, Mar 29, 2012 at 8:27 PM, Dave Taht dave.t...@gmail.com wrote:



 On Tue, Mar 27, 2012 at 9:52 PM, Otto Solares Cabrera so...@guug.orgwrote:

 On Tue, Mar 27, 2012 at 05:03:24PM -0700, Dave Taht wrote:
  however my issue is that hostapd isn't coming up for ap mode.

 Yeah in 3.3 the mon.wlan0 i/f is not being setup but I didn't
 investigate further.


 Your confirmation rules out cerowrt's setup (with device renaming, etc),
 so that
 reduces it to hostapd, nl, wireless-next, or the 3.3 kernel, sometime in
 the last 150 commits. sigh.

 I confirm there's no mon device being created.

 Go looking for a newer hostapd? bisect?

 root@OpenWrt:/lib/wifi# wifi start

 Configuration file: /var/run/hostapd-phy0.conf
 nl80211: Failed to set interface sw00 into AP mode
 nl80211 driver initialization failed.
 Failed to start hostapd for phy0

 Configuration file: /var/run/hostapd-phy1.conf
 nl80211: Failed to set interface sw10 into AP mode
 nl80211 driver initialization failed.
 Failed to start hostapd for phy1



The only other thing I see going wrong is this:

[17308.449218] gw01: Trigger new scan to find an IBSS to join
[17309.289062] ADDRCONF(NETDEV_CHANGE): gw01: link becomes ready
[17315.261718] gw11: Trigger new scan to find an IBSS to join
[17316.726562] ADDRCONF(NETDEV_CHANGE): gw11: link becomes ready
[17382.464843] ath: Failed to stop TX DMA, queues=0x004!

I just managed to rather quickly build iw-3.4 and am about to go looking at
hostapd...

:me flails:


 --
 Dave Täht
 SKYPE: davetaht
 US Tel: 1-239-829-5608
 http://www.bufferbloat.net




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] linux 3.3 hostapd issue between 30952 - 31118

2012-03-29 Thread Dave Taht
On Thu, Mar 29, 2012 at 8:48 PM, Dave Taht dave.t...@gmail.com wrote:



 On Thu, Mar 29, 2012 at 8:27 PM, Dave Taht dave.t...@gmail.com wrote:



 On Tue, Mar 27, 2012 at 9:52 PM, Otto Solares Cabrera so...@guug.orgwrote:

 On Tue, Mar 27, 2012 at 05:03:24PM -0700, Dave Taht wrote:
  however my issue is that hostapd isn't coming up for ap mode.

 Yeah in 3.3 the mon.wlan0 i/f is not being setup but I didn't
 investigate further.


 Your confirmation rules out cerowrt's setup (with device renaming, etc),
 so that
 reduces it to hostapd, nl, wireless-next, or the 3.3 kernel, sometime in
 the last 150 commits. sigh.

 I confirm there's no mon device being created.

 Go looking for a newer hostapd? bisect?

 root@OpenWrt:/lib/wifi# wifi start

 Configuration file: /var/run/hostapd-phy0.conf
 nl80211: Failed to set interface sw00 into AP mode
 nl80211 driver initialization failed.
 Failed to start hostapd for phy0

 Configuration file: /var/run/hostapd-phy1.conf
 nl80211: Failed to set interface sw10 into AP mode
 nl80211 driver initialization failed.
 Failed to start hostapd for phy1



 The only other thing I see going wrong is this:

 [17308.449218] gw01: Trigger new scan to find an IBSS to join
 [17309.289062] ADDRCONF(NETDEV_CHANGE): gw01: link becomes ready
 [17315.261718] gw11: Trigger new scan to find an IBSS to join
 [17316.726562] ADDRCONF(NETDEV_CHANGE): gw11: link becomes ready
 [17382.464843] ath: Failed to stop TX DMA, queues=0x004!

 I just managed to rather quickly build iw-3.4 and am about to go looking
 at hostapd...

 :me flails:


 --
 Dave Täht
 SKYPE: davetaht
 US Tel: 1-239-829-5608
 http://www.bufferbloat.net




 --
 Dave Täht
 SKYPE: davetaht
 US Tel: 1-239-829-5608
 http://www.bufferbloat.net



Another symptom is that adhoc interfaces are created but do not get ssids
assigned. I can assign them manually, however...

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] [package] iproute2: Add hotplug script to add slave devices to TEQL master

2012-03-28 Thread Dave Taht
On Wed, Mar 28, 2012 at 3:36 PM, David Woodhouse dw...@infradead.orgwrote:

 Resolves https://dev.openwrt.org/ticket/11192

 You can now configure devices to be used as a TEQL slave as follows:
 # uci set network.ppp0.teql=teql0
 # uci set network.ppp1.teql=teql0
 # uci commit


I am pretty intensely curious as to how the debloating stuff is going to
work
with bonded adsl lines.



 I have teql0 configured as a normal device, and this script
 automatically adds the PPP devices when they come up — giving me load
 balancing across both ADSL lines.


Can I convince you to try some new sfq and sfqred stuff for load
optimization
on those lines?

Signed-off-by: David Woodhouse dw...@infradead.org
 ---
  package/iproute2/Makefile  |2 ++
  package/iproute2/files/30-teql |   23 +++
  2 files changed, 25 insertions(+), 0 deletions(-)
  create mode 100644 package/iproute2/files/30-teql

 diff --git a/package/iproute2/Makefile b/package/iproute2/Makefile
 index 38e493a..97614be 100644
 --- a/package/iproute2/Makefile
 +++ b/package/iproute2/Makefile
 @@ -92,6 +92,8 @@ endef
  define Package/tc/install
$(INSTALL_DIR) $(1)/usr/sbin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/tc/tc $(1)/usr/sbin/
 +   $(INSTALL_DIR) $(1)/etc/hotplug.d/iface
 +   $(INSTALL_BIN) ./files/30-teql $(1)/etc/hotplug.d/iface/
  endef

  define Package/genl/install
 diff --git a/package/iproute2/files/30-teql
 b/package/iproute2/files/30-teql
 new file mode 100644
 index 000..231c09f
 --- /dev/null
 +++ b/package/iproute2/files/30-teql
 @@ -0,0 +1,23 @@
 +#!/bin/sh
 +
 +. /etc/functions.sh
 +
 +if [ $ACTION != ifup ]; then
 +   exit
 +fi
 +
 +config_load network
 +
 +config_get teql $INTERFACE teql
 +
 +if [ $teql !=  ]; then
 +logger Adding device $DEVICE to TEQL master $teql
 +insmod sch_teql
 +tc qdisc add dev $DEVICE root $teql
 +
 +# The kernel doesn't let us bring it up until it has at least one
 +# slave. So bring it up now, if it isn't already.
 +if ! cat /sys/class/net/$teql/carrier /dev/null; then
 +ifup $teql 
 +fi
 +fi
 --
 1.7.7.6


 --
 dwmw2

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] hostapd issue maybe between 30952 - 31118

2012-03-27 Thread Dave Taht
after freezing at  30952 for the last two(ish) weeks...

I updated to 31118 this morning and built against my formerly working 3.3
kernel...

I see hostapd, ar71xx, ath9k, 3.3, etc all had updates over this period.

Despite replacing my mac80211.sh with the new one and trying a more
open-wrt-y build...

I see earlier advice today about reverting a bridging related commit, which
I will try.
(as everything is routed in cerowrt, not bridged)...

however my issue is that hostapd isn't coming up for ap mode.

I can get adhoc interfaces to come up, but they don't get a ssid.

ifup sw00
Configuration file: /var/run/hostapd-phy0.conf
nl80211: Failed to set interface sw00 into AP mode
nl80211 driver initialization failed.
Failed to start hostapd for phy0

cat hostapd-phy0.conf

ctrl_interface=/var/run/hostapd-phy0
driver=nl80211
wmm_ac_bk_cwmin=4
wmm_ac_bk_cwmax=10
wmm_ac_bk_aifs=7
wmm_ac_bk_txop_limit=0
wmm_ac_bk_acm=0
wmm_ac_be_aifs=3
wmm_ac_be_cwmin=4
wmm_ac_be_cwmax=10
wmm_ac_be_txop_limit=0
wmm_ac_be_acm=0
wmm_ac_vi_aifs=2
wmm_ac_vi_cwmin=3
wmm_ac_vi_cwmax=4
wmm_ac_vi_txop_limit=94
wmm_ac_vi_acm=0
wmm_ac_vo_aifs=2
wmm_ac_vo_cwmin=2
wmm_ac_vo_cwmax=3
wmm_ac_vo_txop_limit=47
wmm_ac_vo_acm=0
tx_queue_data3_aifs=7
tx_queue_data3_cwmin=15
tx_queue_data3_cwmax=1023
tx_queue_data3_burst=0
tx_queue_data2_aifs=3
tx_queue_data2_cwmin=15
tx_queue_data2_cwmax=63
tx_queue_data2_burst=0
tx_queue_data1_aifs=1
tx_queue_data1_cwmin=7
tx_queue_data1_cwmax=15
tx_queue_data1_burst=3.0
tx_queue_data0_aifs=1
tx_queue_data0_cwmin=3
tx_queue_data0_cwmax=7
tx_queue_data0_burst=1.5
hw_mode=g
channel=11

country_code=US


logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2

ieee80211n=1
ht_capab=[HT20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40]
ieee80211d=1
preamble=0

interface=sw00
ctrl_interface=/var/run/hostapd-phy0
auth_algs=1
wpa=0
ssid=OpenWrt
wmm_enabled=1
bssid=e0:46:9a:34:30:d2
ignore_broadcast_ssid=0




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 1/1] dnsmasq: add mx record support

2012-03-20 Thread Dave Taht
While you are poking around in here, I note that the latest dnsmasq
version and the upcoming one has some nice new features.

From the changelog for 2.6.1 (WIP)

Add ra-names DHCPv6 keyword which adds  records
for dual-stack hosts which get IPv6 addresses via SLAAC.

Add --dhcp-duid to allow DUID-EN uids to be used.

Add --host-record.

Add --dhcp-client-update option.

In the recently shipped 2.6.0

Support DHCPv6. Support is there for the sort of things
the existing v4 server does, including tags, options,
static addresses and relay support. Missing is prefix
delegation, which is probably not required in the dnsmasq
niche, and an easy way to accept prefix delegations from
an upstream DHCPv6 server, which is. Future plans include
support for DHCPv6 router option and MAC address option
(to make selecting clients by MAC address work like IPv4).
These will be added as the standards mature.
This code has been tested, but this is the first release,
so don't bet the farm on it just yet.

Add --dhcp-client-update option.

 Support IPv6 router advertisements. This is a
simple-minded implementation, aimed at providing the
vestigial RA needed to go alongside IPv6. Is picks up


On Tue, Mar 20, 2012 at 8:55 PM, Philip Prindeville
philipp_s...@redfish-solutions.com wrote:
 Adding the following syntax support:

 config mxhost
        option domain mydomain.com
        option relay svr10.ironport.com
        option pref 50

 and this will generate an MX record for mydomain.com pointing at the relay 
 with a given preference.

 Signed-off-by: Philip Prindeville phil...@redfish-solutions.com

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] RFC: update oprofile to 0.9.7

2012-02-18 Thread Dave Taht
While the toolchain churn was going on I took the opportunity to
update oprofile.

I didn't understand why x86 had been renamed so I didn't update
that part of the patch. Tested somewhat on ag71xx, could
use more testing on other arches

regrettably as this contains a line longer than 998 characters I can't
send it via email (why does this happen to me?)

http://huchra.bufferbloat.net/~cero1/for_openwrt/0001-update-oprofile-to-0.9.7.patch

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] 2012.02 Linaro 4.6

2012-02-12 Thread Dave Taht
On Sun, Feb 12, 2012 at 7:09 PM, Otto Solares Cabrera so...@guug.org wrote:
 On Sat, Feb 11, 2012 at 01:34:58PM -0500, jonsm...@gmail.com wrote:
 Updating to Linaro 4.6 2012.02 has fixed those code generation bugs I
 was hitting.  2012.02 can also compile openssl for ARMv5 again (some
 Cortex changes had broken it).

 JFYI 2012.02 works fine for me on all my targets, thanks.
 --
  Otto

Does this imply that the toolchain will be changing at some point,
soon? (otto, does your targets include ar71xx?)

I have a long standing bug with QFQ that I perversely hope is
toolchain related but aside from that...

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] cerowrt's openwrt patches, bql, sfqred backport, bql for ag71xx, etc

2012-02-09 Thread Dave Taht
While I'm planning on rebasing cerowrt soon, perhaps some of these
patches would be of
use in the openwrt mainline or by those with an experimental bent.

http://huchra.bufferbloat.net/~cero1/openwrt-bql-patches/

They include an update of iproute2 to 3.1.0,
iptables 1.4.12.1,
obsoleting ESFQ entirely,
adding support for QFQ, DRR, and CHOKE
an update to iproute2 HEAD (which has
support for all the new 3.3 aqm code)
A backport of BQL 3.3 support to 3.2
backport of the new SFQRED aqm code to kernel 3.2...
BQL support added to the ag71xx ethernet driver

scons cross-building support (needed for the latest gpsd which
is available in the cerowrt repo, and perhaps xorp one day)
(swalker is the original author of this patch)

And so on. I kind of regard all this as rather bleeding edge
but most of it has been rather thoroughly tested
at this point.

Of these I would ask juhosg to queue up the ag71xx BQL
patch for 3.3's release. That driver also provides a decent
example of how to add bql support to other out
of tree ethernet drivers. BQL (byte queue limits)
are a goodness...

if there is anything in here that can actually make it
through trac or patchwork and get used, cool,
let me know what submittal process works best these days.



[TXT]   0001-update-iproute2-to-3.1.0.patch 09-Feb-2012 17:54   1.4K
[TXT]   0002-update-iptables-to-1.4.12.1.patch  09-Feb-2012 17:54   16K 
[TXT]   0003-Add-support-for-QFQ-CBQ-DRR-SFB-CHOKE-packet-schedul.patch 
09-Feb-2012
17:54   1.2K
[TXT]   0083-Obsolete-esfq-patch.patch  09-Feb-2012 17:54   22K 
[TXT]   0084-Update-iproute2-to-git-3.3-head-obsolete-esfq.patch
09-Feb-2012
17:54   9.2K
[TXT]   0102-Add-scons-support-to-openwrt.patch 09-Feb-2012 17:54   1.9K
[TXT]   0103-BQL-support-added-to-ag71xx-driver.patch   09-Feb-2012 17:54   
3.2K
[TXT]   0135-IPv6-PIMSM2-support.patch  09-Feb-2012 17:54   805 
[TXT]   0136-3.2.3-kernel-configuration-with-BQL-and-alternate-TC.patch 
09-Feb-2012
17:54   2.9K
[TXT]   0137-3.2.3-support-in-build.patch   09-Feb-2012 17:54   705 
[TXT]   0138-Add-scons-support-in-build.patch   09-Feb-2012 17:54   1.0K
[TXT]   0139-BQL-backport-to-3.2.3.patch09-Feb-2012 17:54   243K
[TXT]   0140-Enable-low-latency-by-default.patch

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] ar71xx TCP/IPsec unaligned instructions

2012-01-29 Thread Dave Taht
2012/1/4 Markus Stockhausen markus.stockhau...@collogia.de:
 Hello,

 attached an extension to the already existing patch that will fix some more
 unaligned
 accesses on ar71xx devices. First patch location during establishing of tcp
 recv operations.
 The second one is only relevant for IPsec tunnels. In my setup this results
 in the following
 numbers:

 - Without patch:

 Normal transmission of 400MB between router and client ~ 140k mem faults
 Encrpyted transmission of 200MB between router and client ~ 600k mem faults

 With patch:

 Normal transmission of 400MB between router and client ~ No more mem faults
 Encrpyted transmission of 200MB between router and client ~ 480k mem faults


I am planning to play with this patch this week, and update to 3.2.2.

I am curious if you tracked down the causes of the other 480k mem faults?

 Signed-off-by: markus dot stockhausen at collogia dot de

 Best regards.

 Markus

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!

2012-01-25 Thread Dave Taht
On Wed, Jan 25, 2012 at 3:46 AM, Philip Prindeville
philipp_s...@redfish-solutions.com wrote:
 On 1/24/12 6:06 AM, Jonathan McCrohan wrote:
 I also see svn as part of the problem. I think a move towards the
 linux-kernel development model would be a great benefit.

 Using git would allow users to make many small fixes in their own tree
 and send single a pull request for fixes to x,y and z to a member of the
 patch review team for ACK or NAK who can then commit to master.
 Hopefully this will result in fewer stray patches.

 The original user will then show up in git blame and will make tracing
 errors far easier. Currently, unless you have commit rights, everything
 comes from one of the few core developers and you have to manually look
 up the changeset to figure out who is responsible for it.

 For those of us that submit fixes that then languish for months before being 
 committed, wouldn't that mean having to constantly rebase them?

Certainly, I do not want to fork this conversation further, and I would
hope that if the time between submittal and application can be brought down
that this ongoing problem will be reduced. It IS a pita however, and
like many I'm willing to volunteer to help, and I've seen a few suggestions
(like using git pulls from temporary repos to preserve ownership) go by
that look like further improvements on the process.

However, I would also like to find ways to deal with my other comment
on this thread:

A second, large problem (in my mind), is that I would like to find a
process for getting stuff upstream into the mainline kernel.

Returning to handling the patch backlog:

One way to perhaps help this is for the overall schedule to be more
widely publicised and to work on more of a time based manner.
In my case I've been trying to adhere to the kernel release schedule
+ .1 + X, where .1 is the first followup to the 'stable' kernel release,
where X is the delta that it seems to take between a release and
patches appearing.

The ar71xx 3.1 process had 3? 4? patch sets go by that never made it into
openwrt proper (and I rebased each time), and the 3.2 patch set landed
a few days ago without (as best as I recall)
public review. I'm delighted that it appears to work, but confess to having
been a bit surprised. (I have been out of the loop for several weeks however)

Would adding a 'Tested-by' email, to patch sets going by, be a helpful addition?
It seems that also finding a way to track coverage sanely would be good
addition, like:

Tested-by: dave.t...@gmail.com
Coverage: ag71xx

Or on a proposed patch from a developer unable to fully test:

Coverage-needed: mips, arm, x86

 -Philip

 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!

2012-01-24 Thread Dave Taht
On Mon, Jan 23, 2012 at 8:33 PM, Felix Fietkau n...@openwrt.org wrote:
 As you've probably noticed, we've had issues keeping up with the
 workload of incoming patches.
 There is quite a bit of work involved in taking care of incoming
 patches, not just review. Patches need to be compile tested, ideally
 also runtime tested, and checked for dependency issues. Most of the
 time, this work is left up to the limited number of people that have SVN
 access. People often complain that it's hard to get involved, because it
 takes a long time to get SVN access, and the rules for that may not
 always be clear.

 In my opinion, the main issue is not that we don't give out SVN access
 fast enough, it's that people consider SVN access necessary for
 contributing in the first place. If we change the way patches are
 accepted to no longer depend on that, it becomes much easier for people
 to start.

 To be able to do that properly, it is important that patches still get
 reviewed and tested, but we can decentralize this work to split it up
 among a bigger group.

 One way to do this would be to have a group of people - with or without
 SVN access - maintaining a git tree with proposed changes to /trunk or
 /packages. This tree should be frequently rebased to latest SVN.
 This allows any developer with SVN access to spend a few minutes a day
 looking over the tree, giving it a quick sanity check, and then flushing
 all changes into SVN.
 With proper care by the tree maintainers, author attribution and review
 annotations can be easily put into the commit messages to ensure that
 they are preserved during the commit to SVN.

 With such a tree, the typical lifetime of a patch could look somewhat
 like this:

 - User proposes a patch on the list.
 - Core developer does a superficial review on patchwork, assigns it to
 the patch team, possibly with comments on what to test or look out for
 - Somebody from the patch team picks up the patch, tests it, ACKs it.
 - Patch gets added to the proposed-changes tree.
 - A developer with SVN access flushes the proposed-changes tree into SVN.

 One nice thing about this workflow is that aside from a few scripts to
 simplify dealing with constantly rebased git trees, we have all the
 tools we need to implement this.

 Does this proposal make sense? Do we have any volunteers that are
 willing to organize and take care of maintaining the tree and compile
 testing and reviewing the incoming changes?

If there is a process like that in place I'll gladly participate on the arches
I am working on, notably the ag71xx, and perhaps one day guruplug and
x86 and kvm. I do try to test things thoroughly - sometimes too thoroughly,
I have something of a backlog.

My principal critique of this workflow is that I tend to view svn as part
of the problem to a large extent. If I do a patch in my own (git) tree
to test with, I invariably have to rebase that tree when it comes down
from svn.

as I am frequently offline, not being able to do a 'svn log' is the
second deal-killer for me, for svn usage.

I can see what you propose as being an incremental improvement
on what currently exists, and can live with it, however.

A second, large problem (in my mind), is that I would like to find a
process for getting stuff upstream into the mainline kernel. The
latest patch set for the 71xx is something like 84 files and 120+
patches, and most of that is stuff that is unchanged for the past year.

Most of what I worked on last quarter got developed in the net-next
git tree,  and backported and then tested on cerowrt.


 - Felix
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH V2] ar71xx: support for kernel 3.1

2012-01-22 Thread Dave Taht
On Wed, Jan 18, 2012 at 10:24 AM, Florian Fainelli flor...@openwrt.org wrote:
 Hello,


 On 01/18/12 08:47, Dave Taht wrote:

 On Wed, Jan 18, 2012 at 4:42 AM, Otto Solares Cabreraso...@guug.org
  wrote:

 On Thu, Dec 08, 2011 at 11:57:46PM +0100, Hartmut Knaack wrote:

 juhosg was working quite hard to get us out of sync, with decent support
 of nbd ;-) It took me a while, but we're finally back on the track. Minimum
 kernel version is probably still 3.1.1. Successfully tested with kernel
 3.1.4 on a WR1043ND. Kernel version in the Makefile still needs to be
 adjusted manually. Any comments appreciated. Enjoy.


 Hi Harmut, do you have something for 3.2? I don't want to duplicate
 efforts :=)


 Personally I feel that skipping 3.2 entirely and going to 3.3 is the
 right course,
 as that has byte queue limits, a fixed implementation of RED, aRED,
 multiple improvements to SFQ that make it scale up much better, and
 behave better in the general case, and a new combination of SFQ and
 RED that looks very promising.


 Well sure these are interesting features to pull from an updated kernel
 version, but it is not a reason for skipping 3.2 entirely, especially if we
 feel like making this the base kernel version for releasing Attitude
 Adjustement at some point.

Well, it's quite a long list (do a git log net/sched to see just the packet
scheduling related fixes)
and I wouldn't call the RED fixe(s) a 'feature', as red is part of openwrt's
current qos system and has been broken for ~3 years.

The SFQ  head of line fix is a nice improvement on SFQ, too. As
are the the additional abilities and extensions added in the 3.3 series.

disregarding BQL for the nonce, these were helpful.
they are mostly trivial to backport.

d47a0ac7b66883987275598d6039f902f4410ca9
225d9b89c937633dfeec502741a174fe0bab5b9f
1ee5fa1e9970a16036e37c7b9d5ce81c778252fc
ea6a5d3b97b768561db6358f15e4c84ced0f4f7e

Tons more, but I understand that you have your own
schedules to keep.

http://linuxplumbersconf.org/2011/ocw/proposals/171


 --
 Florian



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH V2] ar71xx: support for kernel 3.1

2012-01-17 Thread Dave Taht
On Wed, Jan 18, 2012 at 4:42 AM, Otto Solares Cabrera so...@guug.org wrote:
 On Thu, Dec 08, 2011 at 11:57:46PM +0100, Hartmut Knaack wrote:
 juhosg was working quite hard to get us out of sync, with decent support of 
 nbd ;-) It took me a while, but we're finally back on the track. Minimum 
 kernel version is probably still 3.1.1. Successfully tested with kernel 
 3.1.4 on a WR1043ND. Kernel version in the Makefile still needs to be 
 adjusted manually. Any comments appreciated. Enjoy.

 Hi Harmut, do you have something for 3.2? I don't want to duplicate
 efforts :=)

Personally I feel that skipping 3.2 entirely and going to 3.3 is the
right course,
as that has byte queue limits, a fixed implementation of RED, aRED,
multiple improvements to SFQ that make it scale up much better, and
behave better in the general case, and a new combination of SFQ and
RED that looks very promising.


 --
  Otto
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] pthread configure test failing

2012-01-13 Thread Dave Taht
On Fri, Jan 13, 2012 at 8:54 PM, Jo-Philipp Wich x...@subsignal.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi,

 just seen your message on the Lua list - be aware that OpenWrt Lua is
 heavily patched, so maybe try again with some of the Lua patches removed
 and see if the issue persists.

I was not aware openwrt lua was heavily patched. I am curious as to
what it will take to move forward to lua 5.2?


 ~ Jow
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk8QjAUACgkQdputYINPTPMkUwCeMtrdxMAQwVGBEIyxAVCjl/qH
 TPAAn3y5b7r5yBQOZ2LfgQXzD9poQbQp
 =EzpX
 -END PGP SIGNATURE-
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] ar71xx: local mac support on the wndr3700?

2012-01-06 Thread Dave Taht
On Thu, Jan 5, 2012 at 10:09 PM, Gabor Juhos juh...@openwrt.org wrote:
 Please remove the ar71xx_eth{0,1}_data.* initialization. Those values are
 configured automatically for AR7240 since r29103.

I have been carrying this patch (of yours?) forward for a while,
in order to get routable ethernet interfaces on the wndr3700 and
wndr3800. Am I doing it in the right place?

One thing I've noticed on my recent builds (3.1.6) is that hostapd
eats cpu when the wireless is not in use, and the wired interface
is being loaded up. (top shows a hostapd eating up to 40% of
cpu while I'm doing a big transfer over the two ethernet interfaces
- and my transfer rates have dropped since I last did benchmarking)

I've been doing debugging on other quarters, but perhaps
this is significant, or another problem... The mac address DOES
show up as changed, but maybe the driver or hostapd is confused?

[PATCH 4/4] Add local mac support to wndr3700 so as to be able to
route not bridge

The wndr3700 at least has no eth0 mac address and usually leverages
the first wireless device's mac when in a bridged scenario. If,
however, you want to route, and not bridge the interfaces, you
need a unique mac address for it.

This patch sets the local bit on the mac address pulled from the
wireless chip and uses the resulting address for eth0.
---
 .../ar71xx/files/arch/mips/ar71xx/mach-wndr3700.c  |   15 +--
 1 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/target/linux/ar71xx/files/arch/mips/ar71xx/mach-wndr3700.c
b/target/linux/ar71xx/files/arch/mips/ar71xx/mach-wndr3700.c
index cfd0ba9..c708b97 100644
--- a/target/linux/ar71xx/files/arch/mips/ar71xx/mach-wndr3700.c
+++ b/target/linux/ar71xx/files/arch/mips/ar71xx/mach-wndr3700.c
@@ -111,12 +111,23 @@ static struct platform_device wndr3700_rtl8366s_device = {
}
 };

+/*
+ * The eth0 and wmac0 interfaces share the same MAC address which
+ * can lead to problems if operated unbridged. Set the locally
+ * administered bit on the eth0 MAC to make it unique.
+ */
+
+static void __init wndr3700_init_local_mac(unsigned char *mac_base)
+{
+   ar71xx_init_mac(ar71xx_eth0_data.mac_addr, mac_base, 0);
+   ar71xx_eth0_data.mac_addr[0] |= 0x02;
+}
+
 static void __init wndr3700_setup(void)
 {
u8 *art = (u8 *) KSEG1ADDR(0x1fff);

-   ar71xx_init_mac(ar71xx_eth0_data.mac_addr,
-   art + WNDR3700_ETH0_MAC_OFFSET, 0);
+   wndr3700_init_local_mac(art + WNDR3700_ETH0_MAC_OFFSET);
ar71xx_eth0_pll_data.pll_1000 = 0x;
ar71xx_eth0_data.mii_bus_dev = wndr3700_rtl8366s_device.dev;
ar71xx_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
-- 
1.7.1


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] ar71xx: support for kernel 3.1

2011-12-07 Thread Dave Taht
On Tue, Dec 6, 2011 at 7:13 AM, dingo outbackdi...@gmail.com wrote:
 On Mon, 2011-12-05 at 10:57 +0100, Hartmut Knaack wrote:
 Dave Taht schrieb:
  I applied these patch series, and either I goofed (possible), or subsequent
  updates to the various trees since the time it came out and the time
  I started trying it, broke it again.
 
  It fails on linux 3.0.9, 3.1.3, 3.1.4 with errors applying stuff to various
  mtd partitions. A typical error (3.0.9)
 
  Applying patch platform/416-mtd_api_tl_mr3x20.patch
  patching file arch/mips/ar71xx/mach-tl-mr3x20.c
  Hunk #1 FAILED at 34.
  Hunk #2 FAILED at 61.
  2 out of 2 hunks FAILED -- rejects in file 
  arch/mips/ar71xx/mach-tl-mr3x20.c
  Patch platform/416-mtd_api_tl_mr3x20.patch does not apply (enforce with -f)
  make[4]: *** 
  [/home/cero1/src/cerowrt/build_dir/linux-ar71xx_generic/linux-3.0.9/.quilt_checked]
  Error 1
  make[4]: Leaving directory `/home/cero1/src/cerowrt/target/linux/ar71xx'
  make[3]: *** [compile] Error 2
  make[3]: Leaving directory `/home/cero1/src/cerowrt/target/linux'
  make[2]: *** [target/linux/compile] Error 2
  make[2]: Leaving directory `/home/cero1/src/cerowrt'
  make[1]: *** 
  [/home/cero1/src/cerowrt/staging_dir/target-mips_r2_uClibc-0.9.32/stamp/.target_compile]
  Error 2
  make[1]: Leaving directory `/home/cero1/src/cerowrt'
  make: *** [world] Error 2
 juhosg made some changes during the last week, relating mtd code in ar71xx. 
 I guess, this is the reason for the above problems, but I still need to 
 check on this as soon as I find some time.

 It did work on r29337 dated like 2011-11-26 22:52:17 EST
 uname -a
 Linux XX 3.1.2 #1 Sat Nov 26 23:11:33 EST 2011 mips GNU/Linux

Well, ordinarily, I'd have the brain cells to fix this patch set. I don't, I'm
too busy working on BQL and AQM stuff. I would appreciate it if someone
else could.


 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] ar71xx: Reclaim unused space in WNDR3700 image

2011-12-04 Thread Dave Taht
On Mon, Dec 5, 2011 at 5:15 AM, Mark Mentovai m...@moxienet.com wrote:
 Jonathan McCrohan wrote:
 Would you mind having another look at this patch as a priority, as it
 causes images larger than 8MB to FTBFS.

 While this obviously is not a problem for the WNDR3700, it is a problem
 for the WNDR3700v2 and WNDR3800, both of which have 16MB of flash.

 Attached is a build log.

 Of course. It's failing while attempting to build a WNDR3700 (v1)
 image, because there's no way to produce an image for WNDR3700 this
 large. It'd never fit in its flash. I believe it's correct to produce
 an error in this case. What you'd evidently like to do is produce
 WNDR3700v2 and WNDR3800 images, but not WNDR3700 (v1). The build
 system doesn't currently allow for this, because it produces the three
 images simultaneously. What you can do is locally remove this line
 from target/linux/ar71xx/image/Makefile:

Would there be a way to set, globally, something that would disable
building images for sub 8MB flash units in the ar71xx series? That
way I could build for more than the wndr3700v2 and 3800 series (
the wzr, for example).


        $(call 
 Image/Build/Template/$(fs_64k)/$(1),Netgear,wndr3700,$(wndr3700_cmdline),$(wndr3700_mtdlayout),3700,WNDR3700,
 NA,)
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] ar71xx: support for kernel 3.1

2011-12-04 Thread Dave Taht
I applied these patch series, and either I goofed (possible), or subsequent
updates to the various trees since the time it came out and the time
I started trying it, broke it again.

It fails on linux 3.0.9, 3.1.3, 3.1.4 with errors applying stuff to various
mtd partitions. A typical error (3.0.9)

Applying patch platform/416-mtd_api_tl_mr3x20.patch
patching file arch/mips/ar71xx/mach-tl-mr3x20.c
Hunk #1 FAILED at 34.
Hunk #2 FAILED at 61.
2 out of 2 hunks FAILED -- rejects in file arch/mips/ar71xx/mach-tl-mr3x20.c
Patch platform/416-mtd_api_tl_mr3x20.patch does not apply (enforce with -f)
make[4]: *** 
[/home/cero1/src/cerowrt/build_dir/linux-ar71xx_generic/linux-3.0.9/.quilt_checked]
Error 1
make[4]: Leaving directory `/home/cero1/src/cerowrt/target/linux/ar71xx'
make[3]: *** [compile] Error 2
make[3]: Leaving directory `/home/cero1/src/cerowrt/target/linux'
make[2]: *** [target/linux/compile] Error 2
make[2]: Leaving directory `/home/cero1/src/cerowrt'
make[1]: *** 
[/home/cero1/src/cerowrt/staging_dir/target-mips_r2_uClibc-0.9.32/stamp/.target_compile]
Error 2
make[1]: Leaving directory `/home/cero1/src/cerowrt'
make: *** [world] Error 2




On Sun, Nov 27, 2011 at 7:36 PM, Dave Taht dave.t...@gmail.com wrote:
 On Sun, Nov 27, 2011 at 6:17 PM, Outback Dingo outbackdi...@gmail.com wrote:
 On Sun, Nov 27, 2011 at 11:52 AM, Otto Solares Cabrera so...@guug.org 
 wrote:
 On Sat, Nov 26, 2011 at 10:37:33PM -0500, Outback Dingo wrote:
 On Sat, Nov 26, 2011 at 10:13 PM, Hartmut Knaack knaac...@gmx.de wrote:
  This patch brings support for kernel version 3.1 to the ar71xx platform. 
  It is based on Otto Estuardo Solares Cabreras linux-3.0 patches, with 
  some changes to keep up with recent filename changes in the kernel. 
  Minimum kernel version seems to be 3.1.1, otherwise one of the generic 
  patches will fail. Successfully tested with kernel 3.1.2 on a WR1043ND. 
  Kernel version in the Makefile still needs to be adjusted manually.

 ill get onto testing these also

 It works for me on the wrt160nl with Linux-3.1.3. Thx Hartmut!

 Also working on WNDR3700v2 and a variety of Ubiquiti gear nice
 Thanks both of you.

 My thanks as well, although I haven't had time to do a build yet. IF
 anyone is interested in
 byte queue limits, the patches I was attempting to backport to 3.1
 before taking off for the holiday,
 including a modified ag71xx driver, are at:

 http://huchra.bufferbloat.net/~cero1/bql/

 Regettably they didn't quite compile before I left for holiday, and
 I'm going to have to rebase cerowrt and rebuild, (I'm still grateful!)
 and I figure (hope!) one of you folk will beat me to getting BQL working
 before I get  back to the office tuesday.

 A plug:

 Byte queue limits hold great promise for beating bufferbloat, and getting
 tc's shapers and schedulers to work properly again, at least
 on ethernet.

 Byte Queue limits, by holding down the amount of outstanding data that
 the device driver
 has in it, all the QoS and shaping tools that we know and love finally
 get a chance to work again. You can retain high hw tx queue rings - so, as
 an example, you could have a 6k byte queue limit and 4 large packets
 in the buffer,
 or 93 ack packets in the buffer - and this let you manage the bandwidth via
 tools higher in the stack, as either take about the same amount of
 time to transmit,
 without compromising line level performance...

 The current situation is: we often have hw tx rings of 64 or higher,
 which translates out to
 96k in flight, meaning that (as already demonstrated) with this patch working,
 you can improve network responsiveness by a factor of at least ten, perhaps as
 much as 100. (TCP's response to buffering is quadratic, not linear,
 but there are other
 variables, so... factor 10 sounds good, doesn't it?)

 From Tom Herbert's announcement (there was much feedback on netdev, I
 would expect
 another revision to come by)


 Changes from last version:
  - Rebase to 3.2
  - Added CONFIG_BQL and CONFIG_DQL
  - Added some cache alignment in struct dql, to split read only, writeable
   elements, and split those elements written on transmit from those
   written at transmit completion (suggested by Eric).
  - Split out adding xps_queue_release as its own patch.
  - Some minor performance changes, use likely and unlikely for some
   conditionals.
  - Cleaned up some show functions for bql (pointed out by Ben).
  - Change netdev_tx_completed_queue to do check xoff, check
   availability, and then check xoff again.  This to prevent potential
   race conditions with netdev_sent_queue (as Ben pointed out).
  - Did some more testing trying to evaluate overhead of BQL in the
   transmit path.  I see about 1-3% degradation in CPU utilization
   and maximum pps when BQL is enabled.  Any ideas to beat this
   down as much as possible would be appreciated!
  - Added high versus low priority traffic test to results below.

 

 This patch series implements byte queue limits (bql) for NIC

Re: [OpenWrt-Devel] [PATCH] ar71xx: Reclaim unused space in WNDR3700 image

2011-11-29 Thread Dave Taht
On Tue, Nov 29, 2011 at 7:44 PM, Mark Mentovai m...@moxienet.com wrote:
 Jonathan Bennett wrote:
 This patch seems like a really good idea for the ar71xx family. What
 sorts of problems are preventing this from being implemented? As small
 as it sounds, an extra 192k would be really useful on quite a few
 routers.

 I don't know of any actual problems with the patch. When I originally
 proposed the patch on this list, Dave Taht was concerned that it might
 not leave enough headroom to field-update the kernel with a larger one
 (https://lists.openwrt.org/pipermail/openwrt-devel/2011-August/012026.html),


I withdraw my objections.

 although my position is that this is what the configuration-preserving
 sysupgrade feature is for
 (https://lists.openwrt.org/pipermail/openwrt-devel/2011-August/012033.html).

 although I would like the field update feature to
become ever more robust.


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] ar71xx support in mainline kernel?

2011-11-25 Thread Dave Taht
I am curious as to if anyone was working on getting the ar71xx arch and
drivers upstream?

It appears that the ath79 arch was intended to be the same thing, but has
nearly no users in the upstream kernel aside from two boards, and was last
worked on back in april...

the ar71xx patches in openwrt supports 43 boards at present and a
great deal of additional (and possibly duplicated) functionality.

http://nbd.name/gitweb.cgi?p=openwrt.git;a=tree;f=target/linux/ar71xx/files/arch/mips/ar71xx;h=878ba990e3b04c98e5e244011a82177e465f405a;hb=HEAD

So I'm curious as to what were the show-stoppers aside from the name change
and the huge backlog of boards and specialized devices?

(I see that the usb drivers are different, and I have no idea if the ag71xx
 ethernet driver is actually in there in some form under some name)

(msg somewhat triggered by seeing the drivers/net directory getting
re-organized in linux 3.2 and trying to hack in BQL on top of the
existing patchset)

-- 
Dave Täht
SKYPE: davetaht
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] correct fair traffic sharing support in qos-scripts

2011-10-20 Thread Dave Taht
On Thu, Oct 20, 2011 at 11:55 AM, Weedy weedy2...@gmail.com wrote:

 On 08/10/11 10:41 AM, Dave Taht wrote:
  I am getting towards being able to test both this and ipv6 support in
  the qos-scripts6 packages in the ceropackages repo on github, but
  various problems elsewhere (kernel.org http://kernel.org being out of
  service notably) were stopping me. Perhaps next week.
 
  On Fri, Oct 7, 2011 at 2:53 PM, Weedy weedy2...@gmail.com
  mailto:weedy2...@gmail.com wrote:
 
  On 25/09/11 01:21 PM, Dave Taht wrote:
   I am pleased to see this basic improvement to qos-scripts. I will
 be
   testing this patch soon in the cerowrt-1.0rc7 series if it doesn't
 get
   committed to openwrt head soon.
 
  Any luck?

 Yo


It's very near the top of my list. Regrettably at the top of my list are 2
talks and linuxcon. I made a start at fixing qos-scripts for ipv6 but still
lacks the above patch, in the ceropackages repo...

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


  1   2   >