Re: [LEDE-DEV] [PATCH RFC 2/2] ramips: dts: add precompiler macro for VLAN defaults
Hi Florian,
On Wed, Feb 22, 2017 at 03:54:23PM -0800, Florian Fainelli wrote:
>
>
> On 02/22/2017 08:21 AM, Daniel Golle wrote:
> > Add new dt-bindings precompiler include to replace numerical default
> > VLAN assignments with more meaningful descriptive values, such that
> > 0x3f -> VLAN_CONFIG_L
> > 0x2f -> VLAN_CONFIG_W
> > 0x3e -> VLAN_CONFIG_W
> >
> > In that we we get the best of both worlds: the usability of having
> > strings and all the freedom and simplicity of having just an 8-bit
> > field.
>
> Why not bite the bullet and just migrate to the new DSA binding which
> allows you to describe all switch ports more exhaustively. That does not
> mean you need to implement a DSA switch register driver, but that does
> not mean you can't use use the same binding to describe your HW.
I agree, however, I'd rather take small iterative steps instead of
adding quite a lot of extra complexity, most of which is unneeded for
the way OpenWrt/LEDE currently works. Plus I don't know what's written
on all devices' Ethernet ports and which ports are actually physically
connected. Sidenote: John has added support for labeling individual
ports on rt305x a long time ago and the only board which is using that
is the FONERA2 which was the board he was using back then...
Thus, when implementing the DSA-like switch port description, we'd have
to keep the legacy mediatek,portmap attribute anyway and then migrate
board by board and apparently there is no ground to expect high
interest from users to help with that.
Apart from that, the mediatek,portmap is very similar to what people
find in MTK/Ralink's SDK menuconfig which makes it easy for people to
migrate from there to vanilla OpenWrt/LEDE.
The idea of my patch/rfc series is to unify the mediatek,portmap
attribute such that it'd be the same semantics for rt305x and mt76xx.
This will already allow to add more information than the current
implementation on mt76xx which basically just allows for two different
setups ("w" or "w").
Migrating the existing board-support to use a numeric attribute plus
precompiler macros is a matter of using sed and can easily be done all
at once.
I'm also planning to implement mediatek,disablemap for mt76xx in the
same way it works on rt305x.
Cheers
Daniel
>
> See, e.g:
>
> https://patchwork.kernel.org/patch/9493039/
> --
> Florian
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Is there a Image for TP-Link TL-WA854RE (WiFi Range Extender) ?
On 22.02.2017 18:37, Dennis Schneck wrote:
Thanks, the image work on my TP-Link TL-WA854RE v1
ok.
if you want to use newer or self-compiled firmwares on that device you
can use/flash the 850v1-Image. (same hardware)
with sysupgrade you might once need option "-F" to force it, and after
that the device will "think" that it is a 850v1.
as already mentioned: take care of your firmware network settings
when/before flashing!
is it possible that you contact the lede project to integrade you modifcations
that i included in the next version ?
contact is difficult, devil is in the detail :-o see my text below ("for
standard new-device-support")
thanks
Gesendet: Mittwoch, 22. Februar 2017 um 01:43 Uhr
Von: Ufo
An: Lede-dev@lists.infradead.org
Betreff: Re: [LEDE-DEV] Is there a Image for TP-Link TL-WA854RE (WiFi Range
Extender) ?
On Sat, Feb 18, 2017 at 06:32:53PM +0100, Dennis Schneck wrote:
Hello,
is there a Image for TP-Link TL-WA854RE ?
Am 18.02.17 um 19:40 schrieb Daniel Golle:
As a hack or temporary work-around, this is easy to achieve though.
854v1:
http://gadow.freifunk.net:8004/srv2/lede/tplink854/lede-wa854re-v1-squashfs-factory.bin
854v2:
http://gadow.freifunk.net:8004/srv2/lede/tplink854/lede-wa854re-v2-squashfs-factory.bin[http://gadow.freifunk.net:8004/srv2/lede/tplink854/lede-wa854re-v2-squashfs-factory.bin][http://gadow.freifunk.net:8004/srv2/lede/tplink854/lede-wa854re-v2-squashfs-factory.bin[http://gadow.freifunk.net:8004/srv2/lede/tplink854/lede-wa854re-v2-squashfs-factory.bin]]
Am 18.02.17 um 19:40 schrieb Daniel Golle:
Due to the lack of an Ethernet port the device is currently very hard
to support properly.
but its not too hard for our cases: freifunk communities..
you literally know that we are using the imagebuilder (via webui
"meshkit") for building pre-configured (blame ipv4) openwrt/lede images
for our devices. so devices are being flashed, and coming up with
enabled free wifi and mesh-protocols (olsr + 2x batman-adv).
see my 854v1 firmware version, its done with that!
btw: the "libremesh" firmware also comes up with that (even there is not
so much ipv4 this firmware is ipv6-autoconfig-style, so you can flash
many devices with same firmware instantly). also for freifunk "gluon"
firmware there is a "skip config"-mode, same behaviour..
so, i think there is no need for major changes for these ethernet-less
devices. openwrt/lede have to support these devices, such as other devices.
users and usergroups may now take care of the ethernet-less
restrictions. some of them are well-prepared and have to take really no
adjustments :-)
Alberto wrote:
With the settings written by that script you only need to enable the
wifi and everything will work.
yes, so i did it for my mentioned 854v2 firmware. i was using piotr's
newest (thanks for 850v2!) stuff, modifying the hardware-ids
see
https://github.com/lede-project/source/compare/master...FreifunkUFO:master[https://github.com/lede-project/source/compare/master...FreifunkUFO:master][https://github.com/lede-project/source/compare/master...FreifunkUFO:master[https://github.com/lede-project/source/compare/master...FreifunkUFO:master]]
mathias committed:
wifi disabled by default but you can enable it with the wps button.
that sounds nice!
Piotr wrote:
I don't think there is any
good/secure enough approach which everybody would
agree to implement by default in LEDE
at least we could make a configuration for that:
on "make menuconfig" i found "preconfigure image" to change at least
IPv4 adress. there could be a flag "enable wifi". (some minutes
programming later there also could be settings for SSID and wpa2 key).
so enabling wifi would be easier for all people who are compiling the
firmware ( and who dont want to use the imagebuilder :-o )
Piotr wrote:
Wi-Fi inside failsafe mode would be the only way.
above 854 firmwares are preconfigured with enabled wifi. reset-button
works. so if network contact is lost due to new, wrong network settings
you may press reset and will get that preconfigured, wifi-enabled device
as before :-)
for standard new-device-support:
n3ph and me are struggling, if we should devide support for v1 and v2
version of tplink-854 and who could commit that properly.
at the moment we have these changes for development, but never tested
yet: ethernet is disabled (why only for v2?), wifi is enabled (has to be
deleted further)
https://github.com/lede-project/source/compare/master...freifunk-leipzig:master[https://github.com/lede-project/source/compare/master...freifunk-leipzig:master][https://github.com/lede-project/source/compare/master...freifunk-leipzig:master[https://github.com/lede-project/source/compare/master...freifunk-leipzig:master]]
for the future: as you might read at openwrt wiki or tplink site: 850
will appear as v3 or v4 eventually.. and there is a nice-looking new
device tplink-855.
---
Freifunk Leipzig
http://leipzig.freifunk.net[http://leipzig.freifunk.net][http://leipzig.frei
Re: [LEDE-DEV] multi-function buttons
Hello, 2017-02-20 9:11 GMT+01:00 Mathias Kresin : > 19.02.2017 14:31, Piotr Dymacz: > > This is more like offtopic, but there is another one problem with > > similar devices. Lets forget now about "Wi-Fi enabled or not enabled > > by default" issue and assume we have a device which: > > - doesn't have Ethernet interface > > - serial access is not possible or very difficult to get > > - has _only one button_, configured as rfkill (because there must be > > some way to enable Wi-Fi after the flash) > > - is or could be supported in LEDE > > > > What will happen if the user breaks wireless configuration (it > > happens, I know it from experience) in this kind of device? Maybe, > > just by an accident, (s)he configured channel "17" instead of "7", > > saved changes, restarted Wi-Fi and... ended up with a nice > > paperweight. > > > > In this kind of situation, the "rfkill" button is useless (wireless > > configuration is broken, Wi-Fi can't be started). Failsafe mode can be > > enabled but is not accessible. AFAIK, there is no way to perform > > "firstboot"/"factory reset" in this situation. > > > > Of course, this is more like an extreme case (no Ethernet, no serial > > access, only one button), but IMHO it shows that if we want to support > > devices without Ethernet interface, we should make failsafe mode > > working for them. > > Hey Pepe, > > let me start a new thread regarding this issues. > > After I pushed > https://git.lede-project.org/bcfbeae79f799cf1087d692e4869589eb20d2080 we had > a discussion in IRC because what I've done in the commit wasn't that > correct. > > I've changed the linux,code of the buttons to RF_KILL/0xf7 to have this > enable WLAN functionality. But the with that change the send keycode doesn't > match any longer what is printed in the case. Means, a WPS button should > send the KEY_WPS_BUTTON keycode, a Wifi button should send KEY_WLAN, a Wifi > on/off button should send KEY_RFKILL and so on. I agree and I think we should keep this as a general rule: if the button/switch has a known _single_ function (e.g. it's printed on the device enclosure or we know how it works inside the vendor firmware) we should assign the same key code in LEDE. But, as in the message subject, what should we do with multi-function buttons regarding the key code (there is no way to use more than one key code in kernel)? Who should decide what key code will send button marked as "reset/wps", "wps/reset" or "wifi/reset" (in fact, these are existing examples)? Can we maybe agree about some general rule here too? Like, we prefer "reset" key code over "wps" and/or "rfkill" etc.? Or maybe we should leave this decision for the person who adds device support in code? > Jonas came up with the idea of interpreting the "wps" button press as > "rfkill" in userspace instead of changing the meaning of the buttons in the > dts file(s). John and Felix joined the discussion and we agreed that having > something configurable in userspace for interpreting the keycodes would be a > good idea. It can be extended to have timer based interpretations as well > (10sec press do A, 20sec press do B and so on). [...] I really like the idea of having something configurable. Personally I prefer to have it in system config as for LEDs and actually, that kind of "configurable user space code" was for long time already in the repository and got dropped not that long time ago [1]. I'm not convinced here only about static role assignments, like interpreting "wps" button press as "rfkill". What if the device has both buttons, what if it doesn't have the "reset" button? I'm worried that this could bring a lot of additional code needed to configure all of this in advance (board.d/uci-defaults). I was thinking about a slightly different and hopefully more universal approach: 1. Keep default functions for known buttons (same as now in /etc/rc.button/*). 2. Allow configuration from userspace, with support for timer based handlers. 3. Include "wildcard button" support with two interpretation set by default. For last point, we could define some general, timer based handlers for _any_ button (wildcard), e.g. (take below values only as examples): - 15-29s: rfkill - 30-...s: factory reset IMHO, above two functions are the most important from user perspective (there might be more of them). With this approach, we are solving two issues at once: 1. Wi-Fi can be enabled with any button (no need to change original key code) in devices with only Wi-Fi interface and at least one button. 2. Default settings can be restored with any button (also useful for devices with only Wi-Fi interface and broken wireless configuration/useless "rfkill" button). What I'm not sure about here is should this "wildcard buttons" functions be also configurable (and thus, could be also disabled/removed) by the user or should we for example keep them as last steps, after checking all configured timer based functions for "released" action. I see h
Re: [LEDE-DEV] Mikrotik sysupgrade install not working on sxt lite2.
On 2017-02-21 00:29, Alen Opacic wrote: > On sxt lite 2 (older version with 128mb nand flash) using > lede-17.01.0-rc2-r3131-42f3c1f-ar71xx-mikrotik-vmlinux-initramfs.elf image, > than sysupgrade to > lede-17.01.0-rc2-r3131-42f3c1f-ar71xx-mikrotik-nand- > large-squashfs-sysupgrade.bin. > After reboot sxt is in a boot loop state, boots allways from network boot > (tftp). This can be called a regresion since this sxt works fine with CC > and wget2nand. > > How can i help debug this ishue. > > Ps: if someone can help maybe we can get sxtg2hnd > (not lite version) to work with > openwrt. This one as far as i know newer worked with openwrt/lede. Please post a boot log from the initramfs image running on that device. Thanks, - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Compile error on Raspberri Pi 3
Hi, Ik compiled lede for raspberri pi 2 and it compiled. When i try to compile it for raspberri pi 3, it get the following compile error: What can i do to fix this ? Perry CHK include/generated/asm-offsets.h UPD include/generated/asm-offsets.h CALLscripts/checksyscalls.sh HOSTCC scripts/dtc/dtc-parser.tab.o HOSTCC scripts/kallsyms HOSTCC scripts/pnmtologo HOSTLD scripts/mod/modpost HOSTCC scripts/conmakehash HOSTLD scripts/dtc/dtc HOSTCC scripts/sortextable LDS arch/arm64/kernel/vdso/vdso.lds VDSOA arch/arm64/kernel/vdso/gettimeofday.o cc1: fatal error: symtab.h: No such file or directory compilation terminated. scripts/Makefile.build:405: recipe for target 'arch/arm64/kernel/vdso/vdso.lds' failed make[7]: *** [arch/arm64/kernel/vdso/vdso.lds] Error 1 make[7]: *** Waiting for unfinished jobs arch/arm64/Makefile:141: recipe for target 'vdso_prepare' failed make[6]: *** [vdso_prepare] Error 2 make[6]: *** Waiting for unfinished jobs ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kmodloader: don't store aliases info in struct module
On Thu, 2017-02-23 at 11:25 +0800, Yousong Zhou wrote: > This also fixes FS#544 as the allocation causing possible address alignment > issue should now disappear > > Size comparison on x86_64 system > > function old new delta > alloc_module 398 245-153 > > -- > (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-153) Total: -153 > bytes > > Signed-off-by: Yousong Zhou > --- > Ted, please test it on your board to see if it can fix your issue. > > The patch was only run-tested on armvirt cortex-a15 machine. > > I actually thought about patching calloc_a to make sizeof_long-aligned > allocation as the comment in libubox/utils.h says the func should "allocate a > block of memory big enough to hold multiple aligned objects." > > But that's too corase a solution for a fundamental lib and can waste runtime > memory. Maybe we should reword that comment and provide a few helper macros > like SHORT_ALIGN, INT_ALIGN, LONG_ALIGN? > I was also thinking of making calloc_a() function as one would expect for a data structure with embedded pointers and data. It serves as an memory efficient method for handling multiple (atomic) allocations and makes the task of freeing the object more straightforward. However, its current implementation ALWAYS creates packed objects which is fine for a lot of architectures, but not all. The alignment necessary is for pointers only since that is what it is allocating. There must be some platform/architecture specific system macros which can be used here. That said, your patch is a much better workaround for the issue at hand than was mine. I am concerned however, about the possibility of other problems lurking in code using calloc_a() which haven't been discovered yet and would like to advocate changing calloc_a() as a permanent fix. The memory and performance impact would be minimal compared to using multiple allocations for the same thing. /ted ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] QCA Dakota support
Hi Christian, do you plan to integrate the IPQ40XX support for Asus, ZyXEL and AVM from https://github.com/chunkeey/LEDE-IPQ40XX/commits/staging in the next days? I can provide support for Compex WPJ428 afterwards. Best, Christian Am 2017-02-17 19:22, schrieb John Crispin: On 17/02/2017 17:06, Matthew McClintock wrote: Cool, still personally missing a Dakota board myself. Maybe I'll get one soon. -M i used your v4.7-rc for-next tree as basis for the 4.9 support ;) John ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kmodloader: don't store aliases info in struct module
On 2017-02-23 04:25, Yousong Zhou wrote: > This also fixes FS#544 as the allocation causing possible address alignment > issue should now disappear > > Size comparison on x86_64 system > > function old new delta > alloc_module 398 245-153 > > -- > (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-153) Total: > -153 bytes > > Signed-off-by: Yousong Zhou > --- > Ted, please test it on your board to see if it can fix your issue. > > The patch was only run-tested on armvirt cortex-a15 machine. > > I actually thought about patching calloc_a to make sizeof_long-aligned > allocation as the comment in libubox/utils.h says the func should "allocate a > block of memory big enough to hold multiple aligned objects." > > But that's too corase a solution for a fundamental lib and can waste runtime > memory. Maybe we should reword that comment and provide a few helper macros > like SHORT_ALIGN, INT_ALIGN, LONG_ALIGN? I think aligning to 4 bytes by default in calloc_a might be a good idea. For cases where it's important to not waste any bytes, we could have an unaligned variant of it. - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] automated signed firmware upgrades / hide a secret in image
Eric Schultz wrote: > prpl member IntrinsicID has physically unclonable function technology > which allows a key to be generated at bootup based upon the physical > characteristics of the device. It's the same key generated everytime > but it isn't actually stored in flash. Their technology requires a paid And, is it the same for every device? This sounds like fake security to me. reading the web site, it seems to be based upon pulling IDs from DIMMs. Maybe I don't understand the goal here. >> There are "automated" signatures (e.g. from builbot) and manual ones, >> from humans. For protecting ourselfes from bad admins, there should be >> a "secret thing" which is baked into the firmware and only seeable >> during runtime: this way we can prevent, that a lazy admin "signs" a >> sha256 sum, without really has flashed the image and can make sure >> that it really runs. >> >> Now the question: a secret can be e.g. # ls -la /etc | md5sum >> >> This is naive, and a dumb admin can e.g. unsquashfs the image for >> getting the data. are there better methods? any ideas? >> >> bye, bastian >> >> ___ Lede-dev mailing list >> Lede-dev@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/lede-dev > ___ Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Compile error on Raspberri Pi 3
Hello, That's weird because neither the buildbot nor my local setup are failing. Could you try again with a clean checkout of LEDE? Which distro are you using? Regards, Álvaro. El 23/02/2017 a las 13:35, Perry Couprie escribió: > Hi, > > Ik compiled lede for raspberri pi 2 and it compiled. > > When i try to compile it for raspberri pi 3, it get the following compile > error: > > What can i do to fix this ? > > Perry > > CHK include/generated/asm-offsets.h > UPD include/generated/asm-offsets.h > CALLscripts/checksyscalls.sh > HOSTCC scripts/dtc/dtc-parser.tab.o > HOSTCC scripts/kallsyms > HOSTCC scripts/pnmtologo > HOSTLD scripts/mod/modpost > HOSTCC scripts/conmakehash > HOSTLD scripts/dtc/dtc > HOSTCC scripts/sortextable > LDS arch/arm64/kernel/vdso/vdso.lds > VDSOA arch/arm64/kernel/vdso/gettimeofday.o > cc1: fatal error: symtab.h: No such file or directory > compilation terminated. > scripts/Makefile.build:405: recipe for target > 'arch/arm64/kernel/vdso/vdso.lds' failed > make[7]: *** [arch/arm64/kernel/vdso/vdso.lds] Error 1 > make[7]: *** Waiting for unfinished jobs > arch/arm64/Makefile:141: recipe for target 'vdso_prepare' failed > make[6]: *** [vdso_prepare] Error 2 > make[6]: *** Waiting for unfinished jobs > > > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Using kdump... persistent logs, etc.
Thanks for that. > On Feb 22, 2017, at 11:44 PM, Syrone Wong wrote: > > According to LEDE's source code: > > config KERNEL_CRASHLOG > bool "Crash logging" > depends on !(arm || powerpc || sparc || TARGET_uml || i386 || x86_64) > default y > > https://github.com/lede-project/source/blob/master/config/Config-kernel.in > > It is enabled by default on some targets and will be available at > `/sys/kernel/debug/crashlog` on next boot after crash. > > The implementation detail can be found here: > https://github.com/lede-project/source/blob/master/target/linux/generic/patches-4.9/930-crashlog.patch > > > Best Regards, > Syrone Wong > > > On Thu, Feb 23, 2017 at 10:05 AM, Philip Prindeville > wrote: >> Hi, >> >> Has anyone managed to use kdump with OpenWRT/LEDE? >> >> I have a box which periodically panics, and since /var is a link to /tmp/ >> there are no persistent logs. Which reminds me: is it safe to configure a >> third partition on my CF card, format it as ext3, and mount that as /var/log >> in /etc/fstab? >> >> And how would I modify the build process if I wanted to add additional >> partitions? >> >> Thanks, >> >> -Philip >> ___ >> openwrt-devel mailing list >> openwrt-de...@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Mikrotik sysupgrade install not working on sxt lite2.
Sxt LIte2(sxt2ndr2) boot log: [0.00] Linux version 4.4.49 (buildbot@builds) (gcc version 5.4.0 (LEDE GCC 5.4.0 r3511-04c4b6f) ) #0 Mon Feb 20 09:21:42 2017 [0.00] bootconsole [early0] enabled [0.00] CPU0 revision is: 0001974c (MIPS 74Kc) [0.00] SoC: Atheros AR9344 rev 3 [0.00] Determined physical RAM map: [0.00] memory: 0400 @ (usable) [0.00] User-defined physical RAM map: [0.00] memory: 0400 @ (usable) [0.00] Initrd not found or empty - disabling initrd [0.00] No valid device tree found, continuing without [0.00] Zone ranges: [0.00] Normal [mem 0x-0x03ff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x03ff] [0.00] Initmem setup node 0 [mem 0x-0x03ff] [0.00] On node 0 totalpages: 16384 [0.00] free_area_init_node: node 0, pgdat 804904d0, node_mem_map 8100 [0.00] Normal zone: 128 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 16384 pages, LIFO batch:3 [0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. [0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 [0.00] Kernel command line: parts=1 boot_part_size=4194304 gpio=228923 HZ=3 mem=64M kmac=4C:5E:0C:DD:A5:54 board=sxt5n boot=0 mlc=7 rootfstype=squashfs noinitrd [0.00] PID hash table entries: 256 (order: -2, 1024 bytes) [0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Writing ErrCtl register= [0.00] Readback ErrCtl register= [0.00] Memory: 57856K/65536K available (3408K kernel code, 179K rwdata, 840K rodata, 2028K init, 204K bss, 7680K reserved, 0K cma-reserved) [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS:51 [0.00] Clocks: CPU:600.000MHz, DDR:400.000MHz, AHB:400.000MHz, Ref:25.000MHz [0.00] clocksource: MIPS: mask: 0x max_cycles: 0x, max_idle_ns: 6370868154 ns [0.09] sched_clock: 32 bits at 300MHz, resolution 3ns, wraps every 7158278654ns [0.008859] Calibrating delay loop... 299.82 BogoMIPS (lpj=1499136) [0.081948] pid_max: default: 32768 minimum: 301 [0.087320] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.094840] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.105794] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.118345] NET: Registered protocol family 16 [0.125038] MIPS: machine is Mikrotik RouterBOARD SXT Lite5 [0.363076] clocksource: Switched to clocksource MIPS [0.370196] NET: Registered protocol family 2 [0.376159] TCP established hash table entries: 1024 (order: 0, 4096 bytes) [0.384143] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) [0.391366] TCP: Hash tables configured (established 1024 bind 1024) [0.398691] UDP hash table entries: 256 (order: 0, 4096 bytes) [0.405370] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [0.412832] NET: Registered protocol family 1 [0.417871] PCI: CLS 0 bytes, default 32 [2.689687] futex hash table entries: 256 (order: -1, 3072 bytes) [2.696780] Crashlog allocated RAM at address 0x3f0 [2.718540] squashfs: version 4.0 (2009/01/31) Phillip Lougher [2.725241] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. [2.798025] io scheduler noop registered [2.802493] io scheduler deadline registered (default) [2.808701] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled [2.818749] console [ttyS0] disabled [2.842979] serial8250.0: ttyS0 at MMIO 0x1802 (irq = 11, base_baud = 1562500) is a 16550A [2.852789] console [ttyS0] enabled [2.936349] bootconsole [early0] disabled [3.038841] nand: device found, Manufacturer ID: 0x98, Chip ID: 0xf1 [3.115086] nand: Toshiba NAND 128MiB 3,3V 8-bit [3.170445] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [3.261370] Scanning device for bad blocks [3.416114] Bad eraseblock 768 at 0x0600 [3.506563] Creating 3 MTD partitions on "ar934x-nfc": [3.568229] 0x-0x0004 : "booter" [3.629341] 0x0004-0x0040 : "kernel" [3.690716] 0x0040-0x0800 : "ubi" [3.840290] libphy: ag71xx_mdio: probed [4.474837] ag71xx-mdio.1: Found an AR934X built-in
Re: [LEDE-DEV] [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.
On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev wrote: > The sender domain has a DMARC Reject/Quarantine policy which disallows > sending mailing list messages using the original "From" header. > > To mitigate this problem, the original message has been wrapped > automatically by the mailing list software. You don't need this and I think you were already instructed on other ML not to do so. Just include proper From: as the first e-mail of your e-mail body. Actually git format-patch can even do that for you. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] utils/busybox: prevent weak root passwords
On 17 February 2017 at 11:42, danrl wrote: > We are trying to make passwords on LEDE a tiny bit more secure by refusing > weak or short (read: less than 6 characters) passwords. > > Please see related discussion over here, where the inconsistencies were > discovered: > https://github.com/openwrt/luci/pull/878 > > Here is what the patch changes in user experience: > > Router running an image NOT including the proposed patch: > > root@rtr:~# passwd > Changing password for root > New password: > Bad password: too short > Retype password: > passwd: password for root changed by root > > The password minimum length is not enforced for the root user, also weak > passwords are accepted for the root user despite showing a warning. Just to add my personal opinion: I also don't like this ideas. I've plenty of routers just for testing LEDE I don't need any/complex passwords on. If this is really important feature for you, maybe try sending busybox patch for an option adding such restriction also for a root user. Then we could have our option enabling that busybox option. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.
On Thu, 2017-02-23 at 21:35 +0100, Rafał Miłecki wrote: > On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev > wrote: > > > > The sender domain has a DMARC Reject/Quarantine policy which disallows > > sending mailing list messages using the original "From" header. > > > > To mitigate this problem, the original message has been wrapped > > automatically by the mailing list software. > You don't need this and I think you were already instructed on other > ML not to do so. > > Just include proper From: as the first e-mail of your e-mail body. > Actually git format-patch can even do that for you. He didn't do that bit. That's the stupid list configuration. Anthony's problem was that he was posting from a mail domain with stupid settings. The list's stupidity is a reaction to that. Personally, I think we're better off just *rejecting* posts from people with such broken domains. But I only provide the hosting; I'm not actively playing BoFH and enforcing my opinions on the list config... smime.p7s Description: S/MIME cryptographic signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.
On 23 February 2017 at 21:48, David Woodhouse wrote: > On Thu, 2017-02-23 at 21:35 +0100, Rafał Miłecki wrote: >> On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev >> wrote: >> > >> > The sender domain has a DMARC Reject/Quarantine policy which disallows >> > sending mailing list messages using the original "From" header. >> > >> > To mitigate this problem, the original message has been wrapped >> > automatically by the mailing list software. >> You don't need this and I think you were already instructed on other >> ML not to do so. >> >> Just include proper From: as the first e-mail of your e-mail body. >> Actually git format-patch can even do that for you. > > He didn't do that bit. That's the stupid list configuration. Anthony's > problem was that he was posting from a mail domain with stupid > settings. The list's stupidity is a reaction to that. > > Personally, I think we're better off just *rejecting* posts from people > with such broken domains. But I only provide the hosting; I'm not > actively playing BoFH and enforcing my opinions on the list config... Thanks for the explanation! -- Rafał ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] libubox: Fix calloc_a() to return mem aligned pointers
The current implementation of calloc_a() returns packed pointers for the extra
arguments. These packed, unaligned, pointers are OK for a lot of architectures,
but not all. This patch will aligned the pointers returned in a manner congruent
with malloc(). I do not believe the extra padding overhead is all the burdensome
considering the overhead of separate malloc/calloc/free call to accomplish the
same thing.
Signed-off-by: Ted Hess
---
utils.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/utils.c b/utils.c
index 5d9d5aa..314f716 100644
--- a/utils.c
+++ b/utils.c
@@ -27,6 +27,9 @@
_addr; \
_addr = va_arg(_arg, void **), _len = _addr ? va_arg(_arg,
size_t) : 0)
+#define C_PTR_ALIGN(2*sizeof(size_t))
+#define C_PTR_MASK (-C_PTR_ALIGN)
+
void *__calloc_a(size_t len, ...)
{
va_list ap, ap1;
@@ -40,7 +43,7 @@ void *__calloc_a(size_t len, ...)
va_copy(ap1, ap);
foreach_arg(ap1, cur_addr, cur_len, &ret, len)
- alloc_len += cur_len;
+ alloc_len += (cur_len + C_PTR_ALIGN - 1 ) & C_PTR_MASK;
va_end(ap1);
ptr = calloc(1, alloc_len);
@@ -49,7 +52,7 @@ void *__calloc_a(size_t len, ...)
alloc_len = 0;
foreach_arg(ap, cur_addr, cur_len, &ret, len) {
*cur_addr = &ptr[alloc_len];
- alloc_len += cur_len;
+ alloc_len += (cur_len + C_PTR_ALIGN - 1) & C_PTR_MASK;
}
va_end(ap);
--
2.7.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH netifd] system-linux: add VXLAN support
VXLAN shares many attributes with the tunnel devices, so it is implemented
as a new tunnel type. The 'remote' attribute can be used for an unicast
peer or a multicast group.
The IANA-assigned port 4789 is used by default, instead of the non-standard
port Linux defaults to.
Signed-off-by: Matthias Schiffer
---
I've also added a matching proto package in my staging tree. Seems to work
fine and I could probably just push this myself, but I prefer to get a
least a little review as I'm not really familar with the netifd code.
system-linux.c | 153 -
system.c | 3 ++
system.h | 3 ++
3 files changed, 158 insertions(+), 1 deletion(-)
diff --git a/system-linux.c b/system-linux.c
index f4d6c25..fa698cf 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -4,6 +4,7 @@
* Copyright (C) 2013 Jo-Philipp Wich
* Copyright (C) 2013 Steven Barth
* Copyright (C) 2014 Gioacchino Mazzurco
+ * Copyright (C) 2017 Matthias Schiffer
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2
@@ -25,6 +26,7 @@
#include
#include
+#include
#include
#include
@@ -2540,6 +2542,148 @@ failure:
}
#endif
+#ifdef IFLA_VXLAN_MAX
+static int system_add_vxlan(const char *name, const unsigned int link, struct
blob_attr **tb, bool v6)
+{
+ struct nl_msg *msg;
+ struct nlattr *linkinfo, *data;
+ struct ifinfomsg iim = { .ifi_family = AF_UNSPEC, };
+ struct blob_attr *cur;
+ int ret = 0;
+
+ msg = nlmsg_alloc_simple(RTM_NEWLINK, NLM_F_REQUEST | NLM_F_CREATE |
NLM_F_EXCL);
+
+ if (!msg)
+ return -1;
+
+ nlmsg_append(msg, &iim, sizeof(iim), 0);
+
+ nla_put_string(msg, IFLA_IFNAME, name);
+
+ if ((cur = tb[TUNNEL_ATTR_MACADDR])) {
+ struct ether_addr *ea = ether_aton(blobmsg_get_string(cur));
+ if (!ea) {
+ ret = -EINVAL;
+ goto failure;
+ }
+
+ nla_put(msg, IFLA_ADDRESS, ETH_ALEN, ea);
+ }
+
+ if ((cur = tb[TUNNEL_ATTR_MTU])) {
+ uint32_t mtu = blobmsg_get_u32(cur);
+ nla_put_u32(msg, IFLA_MTU, mtu);
+ }
+
+ if (!(linkinfo = nla_nest_start(msg, IFLA_LINKINFO))) {
+ ret = -ENOMEM;
+ goto failure;
+ }
+
+ nla_put_string(msg, IFLA_INFO_KIND, "vxlan");
+
+ if (!(data = nla_nest_start(msg, IFLA_INFO_DATA))) {
+ ret = -ENOMEM;
+ goto failure;
+ }
+
+ if (link)
+ nla_put_u32(msg, IFLA_VXLAN_LINK, link);
+
+ if ((cur = tb[TUNNEL_ATTR_ID])) {
+ uint32_t id = blobmsg_get_u32(cur);
+ if (id >= (1u << 24) - 1) {
+ ret = -EINVAL;
+ goto failure;
+ }
+
+ nla_put_u32(msg, IFLA_VXLAN_ID, id);
+ }
+
+ if (v6) {
+ struct in6_addr in6buf;
+ if ((cur = tb[TUNNEL_ATTR_LOCAL])) {
+ if (inet_pton(AF_INET6, blobmsg_data(cur), &in6buf) <
1) {
+ ret = -EINVAL;
+ goto failure;
+ }
+ nla_put(msg, IFLA_VXLAN_LOCAL6, sizeof(in6buf),
&in6buf);
+ }
+
+ if ((cur = tb[TUNNEL_ATTR_REMOTE])) {
+ if (inet_pton(AF_INET6, blobmsg_data(cur), &in6buf) <
1) {
+ ret = -EINVAL;
+ goto failure;
+ }
+ nla_put(msg, IFLA_VXLAN_GROUP6, sizeof(in6buf),
&in6buf);
+ }
+ } else {
+ struct in_addr inbuf;
+
+ if ((cur = tb[TUNNEL_ATTR_LOCAL])) {
+ if (inet_pton(AF_INET, blobmsg_data(cur), &inbuf) < 1) {
+ ret = -EINVAL;
+ goto failure;
+ }
+ nla_put(msg, IFLA_VXLAN_LOCAL, sizeof(inbuf), &inbuf);
+ }
+
+ if ((cur = tb[TUNNEL_ATTR_REMOTE])) {
+ if (inet_pton(AF_INET, blobmsg_data(cur), &inbuf) < 1) {
+ ret = -EINVAL;
+ goto failure;
+ }
+ nla_put(msg, IFLA_VXLAN_GROUP, sizeof(inbuf), &inbuf);
+ }
+ }
+
+ uint32_t port = 4789;
+ if ((cur = tb[TUNNEL_ATTR_PORT])) {
+ port = blobmsg_get_u32(cur);
+ if (port < 1 || port > 65535) {
+ ret = -EINVAL;
+ goto failure;
+ }
+ }
+ nla_put_u16(msg, IFLA_VXLAN_PORT, htons(port));
+
+ if ((cur = tb[TUNNEL_ATTR_TOS])) {
+ char *str = blobmsg_get_string(cur);
+
[LEDE-DEV] [PATCH] [17.01] Kernel: bump to 4.4.51
Updates the 17.01 kernel to .51.
Compile-tested on:
* ar71xx
* ramips/mt7621
* x86/64
Run-tested on:
* ar71xx
* ramips/mt7621
Signed-off-by: Stijn Segers
---
include/kernel-version.mk | 4 ++--
.../901-Revert-bcma-switch-GPIO-portions-to-use-GPIOLIB_IRQC.patch| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/kernel-version.mk b/include/kernel-version.mk
index 21418b85bb..d88260f956 100644
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -3,10 +3,10 @@
LINUX_RELEASE?=1
LINUX_VERSION-3.18 = .43
-LINUX_VERSION-4.4 = .50
+LINUX_VERSION-4.4 = .51
LINUX_KERNEL_HASH-3.18.43 =
1236e8123a6ce537d5029232560966feed054ae31776fe8481dd7d18cdd5492c
-LINUX_KERNEL_HASH-4.4.50 =
e4944ca5bb0bdf63a7e97dc7fbdd38bcc820d8b3b57c4a3a7b3bf9c8a48216b7
+LINUX_KERNEL_HASH-4.4.51 =
ee51ad1c588608871ad25002fa6ae9623096f03b21f71530e6a2a2764be4b911
ifdef KERNEL_PATCHVER
LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER)))
diff --git
a/target/linux/brcm47xx/patches-4.4/901-Revert-bcma-switch-GPIO-portions-to-use-GPIOLIB_IRQC.patch
b/target/linux/brcm47xx/patches-4.4/901-Revert-bcma-switch-GPIO-portions-to-use-GPIOLIB_IRQC.patch
index 7c2c54e338..4968c1bbac 100644
---
a/target/linux/brcm47xx/patches-4.4/901-Revert-bcma-switch-GPIO-portions-to-use-GPIOLIB_IRQC.patch
+++
b/target/linux/brcm47xx/patches-4.4/901-Revert-bcma-switch-GPIO-portions-to-use-GPIOLIB_IRQC.patch
@@ -223,7 +223,7 @@ Signed-off-by: Rafał Miłecki
}
--- a/include/linux/bcma/bcma_driver_chipcommon.h
+++ b/include/linux/bcma/bcma_driver_chipcommon.h
-@@ -649,6 +649,7 @@ struct bcma_drv_cc {
+@@ -646,6 +646,7 @@ struct bcma_drv_cc {
spinlock_t gpio_lock;
#ifdef CONFIG_BCMA_DRIVER_GPIO
struct gpio_chip gpio;
--
2.11.0
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] [17.01] Kernel: bump to 4.4.51
On 23 February 2017 at 22:35, Stijn Segers wrote: > Updates the 17.01 kernel to .51. > > Compile-tested on: > * ar71xx > * ramips/mt7621 > * x86/64 > > Run-tested on: > * ar71xx > * ramips/mt7621 > > Signed-off-by: Stijn Segers Why not the common way? Update kernel in master & cherry-pick to lede-17.01 branch? What makes this 17.01 specific? ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [wiki]Table of packages is officially live!
On Mon, Feb 20, 2017 at 06:52:15PM +, Alberto Bursi wrote: > The wiki feature showing what packages are in LEDE (and some information > about them) is now complete! Hooray! :) > > https://lede-project.org/packages/start Great, thanks Alberto! Here are a few questions and comments: - what is the difference between /packages/$pkg and /packages/pkgdata/$pkg? e.g. https://lede-project.org/packages/tinc vs. https://lede-project.org/packages/pkgdata/tinc It seems that the first one is supposed to be created manually? - what would you think of moving the "category" column more to the right in the tables, for instance after "source code"? This way, the first two columns are "name" and "version", which are for me the most important information. - the description field is often quite large (look for instance at the "network---vpn" category), so the table looks ugly. I'm not sure how to fix this though, maybe show just the beginning of the text, and show the rest in a popup when hovering/clicking on the field? - still with the description: it seems that line breaks are removed. On the other hand, word-wrapped text is ugly in HTML. What do you think of removing single line breaks, but treating two consecutive line breaks as a or even a new block? - your script does not seem to handle multiple maintainers? (e.g. net/wireguard) - just a cosmetic note: why not use "/" instead of "---" to separate between category and submenu? Thanks again, other than these minor points it's a great tool :) Baptiste signature.asc Description: PGP signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.
On 23 February 2017 at 23:01, Anthony Sepa wrote: > Is there anything I can do to fix it? I can switch to my gmail account? I > was using my yahoo out of habit. I was posting using git send-mail, is that > causing the problem? Should I change to just using email? Well, using GMail will for sure let you post patches easily. Please note you don't need to change your e-mail used in git commits. Also using git send-email is perfectly fine. This is what I use for my git configuration: git config --global sendemail.smtpserver smtp.gmail.com git config --global sendemail.smtpserverport 587 git config --global sendemail.smtpencryption tls git config --global sendemail.smtpuser f...@gmail.com This allows you easily send patches using git send-email --no-chain-reply-to \ --from "Foo " \ --to "Bar " \ 0001-x.patch ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Broken emails and SPF (Was: [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.)
On Thu, Feb 23, 2017 at 09:48:10PM +0100, David Woodhouse wrote: > On Thu, 2017-02-23 at 21:35 +0100, Rafał Miłecki wrote: > > On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev > > wrote: > > > > > > The sender domain has a DMARC Reject/Quarantine policy which disallows > > > sending mailing list messages using the original "From" header. > > > > > > To mitigate this problem, the original message has been wrapped > > > automatically by the mailing list software. > > You don't need this and I think you were already instructed on other > > ML not to do so. > > > > Just include proper From: as the first e-mail of your e-mail body. > > Actually git format-patch can even do that for you. > > He didn't do that bit. That's the stupid list configuration. Anthony's > problem was that he was posting from a mail domain with stupid > settings. The list's stupidity is a reaction to that. > > Personally, I think we're better off just *rejecting* posts from people > with such broken domains. Well, it may be stupid, but not really "broken", because it's done intentionally by Yahoo: $ dig +short yahoo.ca TXT "v=spf1 redirect=_spf.mail.yahoo.com" $ dig +short _spf.mail.yahoo.com TXT "v=spf1 ptr:yahoo.com ptr:yahoo.net ?all" $ dig +short _dmarc.yahoo.ca TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_...@yahoo.com;"; Long story short, Yahoo uses SPF to only allow yahoo mail servers to send emails with a "From:" field in a @yahoo.whatever domain. Google does the same thing for gmail, but they are just more permissive (for now?). See also https://www.ietf.org/mail-archive/web/ietf/current/msg87153.html David, you could configure the mailing list to avoid the annoying wrapping of the original message, and just change the From field. This may be less confusing (but maybe this already got discussed elsewhere?) Baptiste signature.asc Description: PGP signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] libubox: Fix calloc_a() to return mem aligned pointers
On 24 February 2017 at 05:20, Ted Hess wrote:
> The current implementation of calloc_a() returns packed pointers for the extra
> arguments. These packed, unaligned, pointers are OK for a lot of
> architectures,
> but not all. This patch will aligned the pointers returned in a manner
> congruent
> with malloc(). I do not believe the extra padding overhead is all the
> burdensome
> considering the overhead of separate malloc/calloc/free call to accomplish the
> same thing.
>
>
> Signed-off-by: Ted Hess
> ---
> utils.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/utils.c b/utils.c
> index 5d9d5aa..314f716 100644
> --- a/utils.c
> +++ b/utils.c
> @@ -27,6 +27,9 @@
> _addr; \
> _addr = va_arg(_arg, void **), _len = _addr ? va_arg(_arg,
> size_t) : 0)
>
> +#define C_PTR_ALIGN(2*sizeof(size_t))
> +#define C_PTR_MASK (-C_PTR_ALIGN)
> +
sizeof(long) should be used for C_PTR_ALIGN, though I cannot find the
quote at the moment...
yousong
> void *__calloc_a(size_t len, ...)
> {
> va_list ap, ap1;
> @@ -40,7 +43,7 @@ void *__calloc_a(size_t len, ...)
>
> va_copy(ap1, ap);
> foreach_arg(ap1, cur_addr, cur_len, &ret, len)
> - alloc_len += cur_len;
> + alloc_len += (cur_len + C_PTR_ALIGN - 1 ) & C_PTR_MASK;
> va_end(ap1);
>
> ptr = calloc(1, alloc_len);
> @@ -49,7 +52,7 @@ void *__calloc_a(size_t len, ...)
> alloc_len = 0;
> foreach_arg(ap, cur_addr, cur_len, &ret, len) {
> *cur_addr = &ptr[alloc_len];
> - alloc_len += cur_len;
> + alloc_len += (cur_len + C_PTR_ALIGN - 1) & C_PTR_MASK;
> }
> va_end(ap);
>
> --
> 2.7.4
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kmodloader: don't store aliases info in struct module
On 23 February 2017 at 21:58, Felix Fietkau wrote: >> I actually thought about patching calloc_a to make sizeof_long-aligned >> allocation as the comment in libubox/utils.h says the func should "allocate a >> block of memory big enough to hold multiple aligned objects." >> >> But that's too corase a solution for a fundamental lib and can waste runtime >> memory. Maybe we should reword that comment and provide a few helper macros >> like SHORT_ALIGN, INT_ALIGN, LONG_ALIGN? > I think aligning to 4 bytes by default in calloc_a might be a good idea. > For cases where it's important to not waste any bytes, we could have an > unaligned variant of it. Fixing it to 4 bytes is not enough. The AArch64 ref manual says in C2.2 Loads and stores that "Apart from Load-Exclusive, Store-Exclusive, Load-Acquire, and Store-Release, addresses can have any alignment unless strict alignment checking is enabled, that is if SCTLR_ELx.A == 1." and otherwise Alignment fault can happen on misaligned access. yousong ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] libubox: Fix calloc_a() to return mem aligned pointers
-Original Message- From: Yousong Zhou Sent: Thursday, February 23, 2017 7:15 PM To: Ted Hess Cc: lede-dev Subject: Re: [LEDE-DEV] [PATCH] libubox: Fix calloc_a() to return mem aligned pointers On 24 February 2017 at 05:20, Ted Hess wrote: The current implementation of calloc_a() returns packed pointers for the extra arguments. These packed, unaligned, pointers are OK for a lot of architectures, but not all. This patch will aligned the pointers returned in a manner congruent with malloc(). I do not believe the extra padding overhead is all the burdensome considering the overhead of separate malloc/calloc/free call to accomplish the same thing. Signed-off-by: Ted Hess --- utils.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/utils.c b/utils.c index 5d9d5aa..314f716 100644 --- a/utils.c +++ b/utils.c @@ -27,6 +27,9 @@ _addr; \ _addr = va_arg(_arg, void **), _len = _addr ? va_arg(_arg, size_t) : 0) +#define C_PTR_ALIGN(2*sizeof(size_t)) +#define C_PTR_MASK (-C_PTR_ALIGN) + sizeof(long) should be used for C_PTR_ALIGN, though I cannot find the quote at the moment... yousong I picked the expression from malloc in the musl sources. No hard preferences, but it does do proper alignment for 64-bit systems and other sensitive data-types AFAICT. /ted ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] libubox: Fix calloc_a() to return mem aligned pointers
On 24 February 2017 at 08:30, Ted Hess wrote: > > > -Original Message- From: Yousong Zhou > Sent: Thursday, February 23, 2017 7:15 PM > To: Ted Hess > Cc: lede-dev > Subject: Re: [LEDE-DEV] [PATCH] libubox: Fix calloc_a() to return mem > aligned pointers > > > On 24 February 2017 at 05:20, Ted Hess wrote: >> >> The current implementation of calloc_a() returns packed pointers for the >> extra >> arguments. These packed, unaligned, pointers are OK for a lot of >> architectures, >> but not all. This patch will aligned the pointers returned in a manner >> congruent >> with malloc(). I do not believe the extra padding overhead is all the >> burdensome >> considering the overhead of separate malloc/calloc/free call to accomplish >> the >> same thing. >> >> >> Signed-off-by: Ted Hess >> --- >> utils.c | 7 +-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/utils.c b/utils.c >> index 5d9d5aa..314f716 100644 >> --- a/utils.c >> +++ b/utils.c >> @@ -27,6 +27,9 @@ >> _addr; \ >> _addr = va_arg(_arg, void **), _len = _addr ? va_arg(_arg, >> size_t) : 0) >> >> +#define C_PTR_ALIGN(2*sizeof(size_t)) >> +#define C_PTR_MASK (-C_PTR_ALIGN) >> + > > > sizeof(long) should be used for C_PTR_ALIGN, though I cannot find the > quote at the moment... > >yousong > > I picked the expression from malloc in the musl sources. No hard > preferences, but it does do proper alignment for 64-bit systems and other > sensitive data-types AFAICT. > > /ted > Okay, according to the c99, size_t is supposed be able to express sizeof(char[LONG_MAX]). So I guess your code is safer than sizeof(long) actually ;) But as a side note, at the moment, musl malloc uses (4*sizeof(size_t)) as SIZE_ALIGN, uClibc uses (2 * (sizeof(size_t))) as MALLOC_ALIGNMENT yousong ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/3] mac80211: hwsim: select DRIVER_11AC_SUPPORT and DRIVER_11W_SUPPORT
This is required for default wireless configuration of malta target to work out of the box again. Fixes "77ece30e: hostapd: Add ability to specify that that wireless driver supports 802.11ac" Signed-off-by: Yousong Zhou --- package/kernel/mac80211/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile index 5a591e4..578014f 100644 --- a/package/kernel/mac80211/Makefile +++ b/package/kernel/mac80211/Makefile @@ -1022,7 +1022,7 @@ endef define KernelPackage/mac80211-hwsim $(call KernelPackage/mac80211/Default) TITLE:=mac80211 HW simulation device - DEPENDS+= +kmod-mac80211 +@DRIVER_11N_SUPPORT + DEPENDS+= +kmod-mac80211 +@DRIVER_11AC_SUPPORT +@DRIVER_11N_SUPPORT +@DRIVER_11W_SUPPORT FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/mac80211_hwsim.ko AUTOLOAD:=$(call AutoProbe,mac80211_hwsim) endef -- 2.6.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/3] ppp: ppp6-up: add executable permission bit
Signed-off-by: Yousong Zhou --- package/network/services/ppp/files/lib/netifd/ppp6-up | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 package/network/services/ppp/files/lib/netifd/ppp6-up diff --git a/package/network/services/ppp/files/lib/netifd/ppp6-up b/package/network/services/ppp/files/lib/netifd/ppp6-up old mode 100644 new mode 100755 -- 2.6.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 3/3] ubox: fix possible address alignment issue
Fixes FS#544 3dc78a4 kmodloader: don't store aliases info in struct module Signed-off-by: Yousong Zhou --- package/system/ubox/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/system/ubox/Makefile b/package/system/ubox/Makefile index c3eb442..ff8dead 100644 --- a/package/system/ubox/Makefile +++ b/package/system/ubox/Makefile @@ -5,9 +5,9 @@ PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git PKG_SOURCE_URL=$(LEDE_GIT)/project/ubox.git -PKG_SOURCE_DATE:=2017-02-21 -PKG_SOURCE_VERSION:=c553354dd9f0ccd4afa45b14dd7afc87f37e6fa0 -PKG_MIRROR_HASH:=70fce5e14b27afb0186ed5443a95c6ee96d2430b8ebff200fb6e4b61923afd0d +PKG_SOURCE_DATE:=2017-02-23 +PKG_SOURCE_VERSION:=3dc78a47685b74f8a30739b41df365ef90535d54 +PKG_MIRROR_HASH:=0f039eea1046273767882de093e57aca720825ea49c80fd64e221ab64cc5d590 CMAKE_INSTALL:=1 PKG_LICENSE:=GPL-2.0 -- 2.6.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] automated signed firmware upgrades / hide a secret in image
Bastian Bittorf wrote: > * Michael Richardson [23.02.2017 07:57]: >> Yes, use an asymmetric key, and distribute the public part only. > thanks people, for all the input and your ideas. our approach is now > this: we hook into the 'usign' sourcecode and "hide" a secret there: 2 > large random primenumbers. On the serverside, we store the product > (aka: solution) of these 2 numbers. This is repeated for each generated > image. (sorry, it breaks reproducable builds for now) Anyone can multiply two large prime numbers to get the solution. So I can't understand what you are doing. You can't hide things in binaries. That's total snake oil. > I'am not an expert in crypto, but as far as I understand the approach > is an asymetric key. I'am interested in feedback, see the patch > attached. I am an expert. I don't understand what your goals are here. If you can explain them better, then I can help. I thought from the subject line and explanation that it was to permit a firmware image to be validated as being uncorrupted/tained. One might do this before flashing a device with it. Now I get the impression that the idea for a user to be able to prove which firmware image they actually used? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] libubox: Fix calloc_a() to return mem aligned pointers
Yousong - As a side note to your side note - If you examine the actual mechanics of the allocation, the memory block is indeed size aligned to (4*sizeof(size_t)), but the actual pointer returned is offset of (2*sizeof(size_t)) within the block. As in CHUNK_TO_MEM... Peace, /ted (sorry for the top-post) -Original Message- From: Yousong Zhou Sent: Thursday, February 23, 2017 8:07 PM To: Ted Hess Cc: lede-dev Subject: Re: [LEDE-DEV] [PATCH] libubox: Fix calloc_a() to return mem aligned pointers On 24 February 2017 at 08:30, Ted Hess wrote: -Original Message- From: Yousong Zhou Sent: Thursday, February 23, 2017 7:15 PM To: Ted Hess Cc: lede-dev Subject: Re: [LEDE-DEV] [PATCH] libubox: Fix calloc_a() to return mem aligned pointers On 24 February 2017 at 05:20, Ted Hess wrote: The current implementation of calloc_a() returns packed pointers for the extra arguments. These packed, unaligned, pointers are OK for a lot of architectures, but not all. This patch will aligned the pointers returned in a manner congruent with malloc(). I do not believe the extra padding overhead is all the burdensome considering the overhead of separate malloc/calloc/free call to accomplish the same thing. Signed-off-by: Ted Hess --- utils.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/utils.c b/utils.c index 5d9d5aa..314f716 100644 --- a/utils.c +++ b/utils.c @@ -27,6 +27,9 @@ _addr; \ _addr = va_arg(_arg, void **), _len = _addr ? va_arg(_arg, size_t) : 0) +#define C_PTR_ALIGN(2*sizeof(size_t)) +#define C_PTR_MASK (-C_PTR_ALIGN) + sizeof(long) should be used for C_PTR_ALIGN, though I cannot find the quote at the moment... yousong I picked the expression from malloc in the musl sources. No hard preferences, but it does do proper alignment for 64-bit systems and other sensitive data-types AFAICT. /ted Okay, according to the c99, size_t is supposed be able to express sizeof(char[LONG_MAX]). So I guess your code is safer than sizeof(long) actually ;) But as a side note, at the moment, musl malloc uses (4*sizeof(size_t)) as SIZE_ALIGN, uClibc uses (2 * (sizeof(size_t))) as MALLOC_ALIGNMENT yousong ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] MikroTik RB493G supported?
I noticed that the MikroTik RB493G has been removed from the list of supported devices. Why was that? What would it take to add it back? I have serial access so I can pull logs. I don't want to risk installing 17.01 after reading the thread: MikroTik RB411AH sysupgrade issues. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] MikroTik RB493G supported?
RB493G hasn't been removed AFAICS, but was never listed as supported. If you know which firmware files are needed for installation, you can update the dataentry accordingly [1]. Datafields to be updated: Firmware LEDE Install URL Firmware LEDE Upgrade URL LEDE Supported Current Rel If you know more MikroTik devices which should be supported, feel free to update the dataentries accordingly. All mikrotik devices + firmware download links can be found at [2]. [1] https://lede-project.org/toh/hwdata/mikrotik/mikrotik_rb493g [2] https://lede-project.org/toh/views/toh_fwdownload?dataflt%5BBrand*%7E%5D=mikrotik > -Ursprüngliche Nachricht- > Von: Lede-dev [mailto:lede-dev-boun...@lists.infradead.org] Im Auftrag > von John Ricardo > Gesendet: Freitag, 24. Februar 2017 03:43 > An: lede-dev@lists.infradead.org > Betreff: [LEDE-DEV] MikroTik RB493G supported? > > I noticed that the MikroTik RB493G has been removed from the list of > supported devices. Why was that? What would it take to add it back? > I have serial access so I can pull logs. I don't want to risk > installing 17.01 after reading the thread: MikroTik RB411AH sysupgrade > issues. > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] [17.01] Kernel: bump to 4.4.51
Hi Rafal, I talked this through with jow, a lot of targets have already dropped 4.4 support in trunk, which makes backporting 4.4 updates to 17.01 non-trivial. He was OK with me sending in a patch just for 17.01. Cheers Stijn Op do, 23 feb 2017 om 10:44 , schreef Rafał Miłecki : On 23 February 2017 at 22:35, Stijn Segers wrote: Updates the 17.01 kernel to .51. Compile-tested on: * ar71xx * ramips/mt7621 * x86/64 Run-tested on: * ar71xx * ramips/mt7621 Signed-off-by: Stijn Segers Why not the common way? Update kernel in master & cherry-pick to lede-17.01 branch? What makes this 17.01 specific? ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
