[PATCH opkg 2/5] libopkg: factor out checksum and size verification

From: Baptiste Jonglez This is a sizeable chunk of code that be can pretty well isolated in its own function. This refactoring will be necessary for an upcoming feature in which opkg_download_pkg() will need to verify the checksum of packages in the cache. This is the reason why the new

Re: [PATCH opkg v2] libopkg: harden checksum verification in error cases

On 24-08-20, Baptiste Jonglez wrote: > From: Baptiste Jonglez > > This should make it harder to exploit bugs such as CVE-2020-7982. > > If we can't compute the checksum of a package, we should abort. > > Similarly, if we can't find any checksum in the package index

[PATCH opkg] opkg: allow to configure the path to the signature verification script

From: Baptiste Jonglez Currently, package index signatures are only checked when opkg runs on the OpenWrt device. The verification script is hard-coded to a path in /usr/sbin/. Making this path configurable is a first step to implement signature verification in host builds of opkg (e.g

[PATCH opkg] man: remove obsolete manual pages

From: Baptiste Jonglez The man pages have not been updated since 2010. Options are documented in the usage message obtained when running "opkg" without arguments. In addition, the man page are no longer used anywhere in the build system since 2017: the autoconf-based build system w

[PATCH opkg v2] libopkg: harden checksum verification in error cases

From: Baptiste Jonglez This should make it harder to exploit bugs such as CVE-2020-7982. If we can't compute the checksum of a package, we should abort. Similarly, if we can't find any checksum in the package index, this should yield an error. As an exception, installing a package directly

Re: [PATCH opkg] libopkg: move file size check after checksum verification

On 24-08-20, Henrique de Moraes Holschuh wrote: > On 24/08/2020 09:01, Baptiste Jonglez wrote: > > On 24-08-20, Henrique de Moraes Holschuh wrote: > > > On 24/08/2020 07:53, Baptiste Jonglez wrote: > > > > It is more user-friendly to tell the user that the chec

Re: [PATCH opkg] libopkg: move file size check after checksum verification

On 24-08-20, Henrique de Moraes Holschuh wrote: > On 24/08/2020 07:53, Baptiste Jonglez wrote: > > The file size check was added in cb6640381808dd ("libopkg: check for file > > size mismatches"). Its purpose is to provide an additional line of > >

[PATCH opkg] libopkg: harden checksum verification in error cases

From: Baptiste Jonglez This should make it harder to exploit bugs such as CVE-2020-7982. If we can't compute the checksum of a package, we should abort. Similarly, if we can't find any checksum in the package index, this should yield an error. As an exception, installing a package directly

[PATCH opkg] libopkg: move file size check after checksum verification

From: Baptiste Jonglez The file size check was added in cb6640381808dd ("libopkg: check for file size mismatches"). Its purpose is to provide an additional line of defense against hash collisions. It is more user-friendly to tell the user that the checksum is wrong, so move the file

[PATCH 19.07] tools/tplink-safeloader: use soft_ver 1.9.1 for archer c6 v2

c6 v2 with firmware 1.3.1 Signed-off-by: Alexander Couzens (cherry picked from commit 6d5d815e3f6850a0dc754bf16053fa34490766f7) [remove changes to C6-V2-US because it's unsupported in 19.07] Signed-off-by: Baptiste Jonglez --- tools/firmware-utils/src/tplink-safeloader.c | 2 +- 1 file changed

Re: Upcoming 19.07.4 and 18.07.9 stable releases

Hi, On 07-08-20, Adrian Schmutzler wrote: > > Hi, > > There is also a new mbedtls version which fixes some security bugs, we > > should also update this: > > https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.16.7 I have added it to

Re: Simplified LuCI interface project: dashboard, quick setup, configuration

On 18-07-20, Baptiste Jonglez wrote: > > - quick setup: https://github.com/openwrt/luci/pull/4141 > > - configuration: https://github.com/openwrt/luci/pull/4186 > > This needs more discussion and feedback. > > There is one interesting question (on the github pull requ

Upcoming 19.07.4 and 18.07.9 stable releases

Hi, New point releases for 19.07 and 18.06 are starting to be overdue, and I would like to help 19.07.4 and 18.06.9 get released somewhere around mid-August. The main motivation are fixes for a libubox regression and for the musl synchronisation bug, as well as a LuCI regression (see "release

Re: [PATCH v2 firewall3] zones: apply tcp mss clamping also on ingress path

Hi, On 24-07-20, Yousong Zhou wrote: > Fixes FS#3231 It looks like this bug also affects 18.06 and 19.07, so the fix should probably be backported. Baptiste > Signed-off-by: Yousong Zhou > --- > zones.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/zones.c b/zones.c >

Re: Simplified LuCI interface project: dashboard, quick setup, configuration

Hi Michael, Thanks for your feedback. On 26-06-20, Michael Richardson wrote: > From watching the video the two tasks that you were attempting to improve > were (in laymens terms): > 1) changing the WIFI password > 2) creating a port-forward > > I think that this could be just a bit easier

Re: Simplified LuCI interface project: dashboard, quick setup, configuration

Hi, On 26-06-20, Baptiste Jonglez wrote: > The student project of Biyun and Zhao has just finished. > > The goal was to develop a simplified web interface for OpenWrt, integrated > in LuCI and complementary to the current LuCI interface. > > Feedback on the results of the

Re: [OpenWrt-Devel] [PATCH 18.06] libubox: backport additional length-checking fixes

Hi, On 20-06-20, Baptiste Jonglez wrote: > I should have added more details in the commit message: this fixes a > serious regression where procd fails to start some services, for instance > rpcd. See FS#3177. Any feedback on this regression fix? Thanks, Baptiste > This is the sam

Simplified LuCI interface project: dashboard, quick setup, configuration

Hi, The student project of Biyun and Zhao has just finished. The goal was to develop a simplified web interface for OpenWrt, integrated in LuCI and complementary to the current LuCI interface. Feedback on the results of the project is welcome, preferably in the pull requests (see below). Zhao

Re: [OpenWrt-Devel] [PATCH 18.06] libubox: backport additional length-checking fixes

of commits: I don't think I missed one, but I'm not 100% sure that the 4 commits I backported are all strictly necessary. In any case, they are all clean cherry-picks. Thanks, Baptiste On 13-06-20, Baptiste Jonglez wrote: > From: Baptiste Jonglez > > Fixes: FS#3177 > Cc: Felix Fietkau

Re: [OpenWrt-Devel] [PATCH] ath79: archer-c7-v5: fix initramfs image

On 19-06-20, Petr Štetiar wrote: > > On 17-06-20, Petr Štetiar wrote: > > > Currently it's not possible to tftpboot initramfs image as the image > > > contains tplink-v1-header which leads to: > > > > Out of curiosity, it looks like booting an initramfs image is only > > possible with serial

Re: [OpenWrt-Devel] [PATCH] ath79: archer-c7-v5: fix initramfs image

Hi, On 17-06-20, Petr Štetiar wrote: > Currently it's not possible to tftpboot initramfs image as the image > contains tplink-v1-header which leads to: Out of curiosity, it looks like booting an initramfs image is only possible with serial access to the bootloader? > ---

[OpenWrt-Devel] [PATCH 18.06] libubox: backport additional length-checking fixes

From: Baptiste Jonglez Fixes: FS#3177 Cc: Felix Fietkau Cc: Rafał Miłecki Signed-off-by: Baptiste Jonglez --- package/libs/libubox/Makefile | 2 +- ...s-iteration-in-the-blobmsg_check_arr.patch | 75 ++ ...sg-fix-length-in-blobmsg_check_array.patch | 28

Re: [OpenWrt-Devel] Google Season of Docs projects for OpenWrt

I think he was the one proposing this. Thanks, Baptiste PS: please keep discussion in the same email thread. > On Mon, Jun 8, 2020 at 3:32 AM > wrote: > > > > -- Forwarded message -- > > From: Baptiste Jonglez > > To: openwrt-devel@lists.openwrt.org &g

[OpenWrt-Devel] Google Season of Docs projects for OpenWrt

Hi, As discussed previously, OpenWrt has applied and been accepted for the Season of Docs. We have three mentors (me, Jow, Thomas Hühn), while Hauke and Paul are "project administrators". We started proposing projects here: https://openwrt.org/google-season-of-docs Feel free to discuss the

Re: [OpenWrt-Devel] Experimental "release goals" for 19.07.4

On 23-05-20, Michael Jones wrote: > On Sat, May 23, 2020, 13:01 Baptiste Jonglez > wrote: > > > If the initial concept looks good, we can think about automating some of > > it: > > tag bug reports on Flyspray/Github/Gitlab as blocking for a specific > > release

[OpenWrt-Devel] Experimental "release goals" for 19.07.4

Hi, It can be useful to have "release goals" to get a clearer idea of regression, release-blocking bugs, or wanted features for a release. I started an (experimental) list for 19.07.4 based on recent discussions on the mailing list, forum and IRC:

[OpenWrt-Devel] OpenWrt 19.07.3 service release

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, The OpenWrt community is proud to announce the third service release of OpenWrt 19.07. OpenWrt 19.07.3 focuses on security, stability and device support. Selected highlights of this service release are: * reduce opkg memory usage * allow to

[OpenWrt-Devel] [PATCH] ar71xx: Fix gigabit switch support for Mikrotik RB951G-2HnD

From: Baptiste Jonglez Without this patch, when using rev 3 of the Atheros AR9344 SoC, the gigabit switch (AR8327) does not work or works very erratically. This is a re-spin of http://patchwork.ozlabs.org/patch/419857/ with a different PLL value, according to the feedback from several users

[OpenWrt-Devel] OpenWrt 18.06.8 service release

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, The OpenWrt Community is proud to announce the eighth service release of the stable OpenWrt 18.06 series. OpenWrt 18.06.8 brings security fixes, as well as the usual device support fixes and core components update. - --- The main highlights of

[OpenWrt-Devel] OpenWrt 19.07.2 service release

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, The OpenWrt community is proud to announce the second service release of OpenWrt 19.07. OpenWrt 19.07.2 focuses on security and device support. It notably fixes a security issue in ppp and improves support for migrating devices from ar71xx to

Re: [OpenWrt-Devel] [PATCH 1/2] brcm47xx: rename target to bcm47xx

On 08-02-20, Adrian Schmutzler wrote: > This change makes the names of Broadcom targets consistent by using > the common notation based on SoC/CPU ID (which is used internally > anyway), bcm instead of brcm. > This is even used for target TITLE in make menuconfig already, > only the short

Re: [OpenWrt-Devel] 19.07.0 boot hang on Mikrotik device

Hi, You should report this bug under "openwrt-19.07": https://bugs.openwrt.org/ You are apparently using ar71xx, did you try an ath79 19.07 image? Regards, Baptiste On 25-01-20, Joe Ayers wrote: > At http:\\arednmesh.org, we've had several mikrotik devices working, > all with "LHG"

Re: [OpenWrt-Devel] Question: Migration from ar71xx to ath79

on the device? Baptiste On 10-01-20, Baptiste Jonglez wrote: > Good point, the ar71xx - ath79 migration needs more documentation. > > I have just created > https://openwrt.org/docs/guide-user/installation/ar71xx.to.ath79 > but it needs some work: is sysupgrade supposed to work in some

Re: [OpenWrt-Devel] High-level process for releases

add links as needed. Thomas, regarding the step "Update the ToH to work with the new release", do you have documentation on how to do that, and an estimation of how much time it takes? Thanks, Baptiste On 03-12-19, Baptiste Jonglez wrote: > Hi, > > Following some discussion

Re: [OpenWrt-Devel] Question: Migration from ar71xx to ath79

Good point, the ar71xx - ath79 migration needs more documentation. I have just created https://openwrt.org/docs/guide-user/installation/ar71xx.to.ath79 but it needs some work: is sysupgrade supposed to work in some cases? With/without saving the configuration? Is there any danger when forcing

Re: [OpenWrt-Devel] wlan factory defaults

Hi, On 11-11-19, Piotr Dymacz wrote: > On 11.11.2019 20:33, Ivan Baktsheev wrote: > > How to put this configuration into device? This is not a question for > > OpenWrt developers, but for people, who build customized OpenWrt firmware. > > It’s definitely better to customise build using

Re: [OpenWrt-Devel] [Battlemesh] ImageBuilder frontend projects, or how to generate custom OpenWrt images

Hi, On 30-09-19, Philipp Borgers wrote: > you should take look at the Freifunk Berlin firmware and the Gluon project: > > https://github.com/freifunk-berlin/firmware > > https://gluon.readthedocs.io/en/v2019.1.x/ > > The Freifunk Berlin firmware uses uci-defaults scripts quite a lot for

[OpenWrt-Devel] ImageBuilder frontend projects, or how to generate custom OpenWrt images

Hi, In my community network we are changing the way we generate OpenWrt firmware images, and I took this opportunity to look at the existing methods based on the OpenWrt ImageBuilder and/or SDK. In the end, I found way more projects than I thought would exist! I documented everything I found

Re: [OpenWrt-Devel] ipq40xx: fails to boot with SMP on Mikrotik hAP ac² / RBD52G-5HacD2HnD (WIP)

ry to enable SMP and see if my board boots. > If you have any insight on WiFi, please let me know. > > I'd like to help where I can. > > On Mon, Jul 29, 2019 at 4:10 PM Baptiste Jonglez < > bapti...@bitsofnetworks.org> wrote: > > > On 29-07-19, Hauke Me

Re: [OpenWrt-Devel] ipq40xx: fails to boot with SMP on Mikrotik hAP ac² / RBD52G-5HacD2HnD (WIP)

On 29-07-19, Hauke Mehrtens wrote: > On 7/29/19 11:25 AM, Baptiste Jonglez wrote: > > Is there something obviously wrong in the DTS? As far as I know, other > > ipq40xx devices don't have an issue with SMP. > > Did you try to revert this commit: > https://github.c

[OpenWrt-Devel] ipq40xx: fails to boot with SMP on Mikrotik hAP ac² / RBD52G-5HacD2HnD (WIP)

Hi, I am trying to finish the port of Mikrotik hAP ac², but I still can't get it to boot properly with SMP. Adding "nosmp" to the cmdline makes the initramfs boot fine. Here is the work-in-progress tree that Hauke based on the RB450Gx4 work:

[OpenWrt-Devel] Call for participation for BattleMesh V12 (8-14 July 2019, Paris)

Hello, The local organization team is proud to announce that this year's Battlemesh will be held near Paris, from 8 to 14 July! The event aims to bring together people from across the globe who are interested in community networks, including wireless mesh network technologies, fiber

Re: [OpenWrt-Devel] [PATCH openwrt-18.06] kernel: Add support for Winbond w25q128jv SPI NOR flash

Hi Hauke, Thanks for merging the other patch in master! Can you also merge this one in the openwrt-18.06 branch? This will add support for the newer Mikrotik boards in the next 18.06.X release. Regards, Baptiste On 18-10-18, Baptiste Jonglez wrote: > From: Baptiste Jonglez > > Newe

[OpenWrt-Devel] [PATCH openwrt-18.06] kernel: Add support for Winbond w25q128jv SPI NOR flash

From: Baptiste Jonglez Newer batches of several Mikrotik boards contain this yet-unsupported flash chip, for instance: - rb941-2nd (hAP lite) - rb952ui-5ac2nd (hAP ac lite) - RBM33G and probably other Mikrotik boards need this patch as well. The patch was submitted upstream by Robert Marko

[OpenWrt-Devel] [PATCH] kernel: Add support for Winbond w25q128jv SPI NOR flash

From: Baptiste Jonglez Newer batches of several Mikrotik boards contain this yet-unsupported flash chip, for instance: - rb941-2nd (hAP lite) - rb952ui-5ac2nd (hAP ac lite) - RBM33G and probably other Mikrotik boards need this patch as well. The patch was submitted upstream by Robert Marko

Re: [OpenWrt-Devel] lede-imagebuilder-17.01.5-ar71xx-generic.Linux-x86_64 fails to build image

On 03-09-18, Baptiste Jonglez wrote: > On 18-07-18, Mikael Bak wrote: > > Hi, > > > > Image builder for 17.01.5 seems broken. > > > > It works well for 17.01.4 and 18.06.0-rc1 on my system. > > I'm having the same issue with the ar71xx imagebuilder on Arch

Re: [OpenWrt-Devel] lede-imagebuilder-17.01.5-ar71xx-generic.Linux-x86_64 fails to build image

Hi, On 18-07-18, Mikael Bak wrote: > Hi, > > Image builder for 17.01.5 seems broken. > > It works well for 17.01.4 and 18.06.0-rc1 on my system. I'm having the same issue with the ar71xx imagebuilder on Arch Linux: 17.01.4 and 18.06.1 both work fine, but 17.01.5 fails with the same error

[OpenWrt-Devel] [RFC] A new developper documentation for OpenWrt/LEDE

Hi, As an occasional contributor to OpenWrt/LEDE, I am often frustrated by the lack of good technical documentation. By "technical documentation", I mean a detailed, reasonably complete and up-to-date documentation on "How things work under the hood" and "How to do advanced stuff with the build

Re: [OpenWrt-Devel] Loss of connectivity on ADSL reset

On Fri, Jan 13, 2017 at 09:24:04AM +, Tim Coote wrote: > > > On 12 Jan 2017, at 21:24, Hans Dedecker wrote: > > > >> config interface 'e0ext' > >>option ifname 'pppoe-e0' > > You need to configure the ifname as an aliased interface of interface e0; > > eg > >

[OpenWrt-Devel] Babeld now has procd support on OpenWRT/LEDE

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

[OpenWrt-Devel] Breaking compatibility with pre-1.5.1 babeld on OpenWRT/LEDE

Dear babeld users on OpenWRT/LEDE, Starting from babeld 1.5.1, the UCI format for configuring babeld on OpenWRT had changed to be more consistent with upstream babeld (use the same option names, and a few other changes). At the time, I had ensured backward compatibility, see:

[OpenWrt-Devel] [PATCH CC] script: download: change mirror for kernel.org

At least one mirror in the ftp.all.kernel.org DNS seems to have broken FTP, resulting in very long timeouts. Update mirror to use the same one as trunk. This is a backport of r46875 from trunk. Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org> --- scripts/download.pl |4 +

Re: [OpenWrt-Devel] [PATCH] buildroot: improve git submodule handling for packages

On Sat, Feb 27, 2016 at 01:32:52AM +, Karl Palsson wrote: > This changes the buildroot dependency from git-1.6.2 to git 1.7.12.2, > which was released September 2012. I find this annoying, since Debian wheezy only has git 1.7.10.4. Actually, sometimes I use a squeeze box for building, and it

Re: [OpenWrt-Devel] [PATCH] coova-chilli: Fix UCI parse error

Hi Rajan, On Wed, Jul 06, 2016 at 07:03:43PM +0530, Rajan Vaja wrote: > UCI commands report errors in parsing coova-chilli > sample configuration file. Fix this issue by using > proper format in configuration. This package is maintained in the openwrt-packages Github repository:

Re: [OpenWrt-Devel] [PATCH v2] firewall3: Fix multicast ICMPv6 replies not being sent by default anymore.

On Mon, May 02, 2016 at 09:37:07PM +0200, Baptiste Jonglez wrote: > On Mon, May 02, 2016 at 08:17:48PM +0200, Vittorio Gambaletta (VittGam) wrote: > > Since drop_invalid has been turned on by default, ICMPv6 echo requests > > to well-known multicast addresses, such as ff02::1,

Re: [OpenWrt-Devel] [PATCH v2] firewall3: Fix multicast ICMPv6 replies not being sent by default anymore.

Hi Vittorio, On Mon, May 02, 2016 at 08:17:48PM +0200, Vittorio Gambaletta (VittGam) wrote: > Since drop_invalid has been turned on by default, ICMPv6 echo requests > to well-known multicast addresses, such as ff02::1, are not replied to > by the router anymore, because conntrack considers those

Re: [OpenWrt-Devel] [RFC relayd 0/2] relayd: add ipv6 support

Hi, On Mon, Apr 11, 2016 at 03:14:52PM +0200, Michal Kazior wrote: > I've been recently working on adding IPv6 support > to relayd (which supported only IPv4). > > It does, however, require a kernel patch to make > it actually usable because link-local addresses > are not routable by kernel by

Re: [OpenWrt-Devel] [PATCH][ar71xx] Routerboard 951G Switch Fix

Hi, On Wed, Jan 27, 2016 at 07:03:58PM +0300, Anton Kalmykov wrote: > Hi, 951G owners! > I have RB951G-2HnD device with AR9344 rev 3. It is configured like that: > - Balanced 2 WAN ports (mwan3) > - ipsec LAN-to-LAN > - OpenVPN server > - about 30 clients (wi-fi, lan) > > My results for

Re: [OpenWrt-Devel] [PATCH v2] netifd: Request DHCP option 121 (classless route) by default

Hi, Any news on this patch? As requested, the v2 patch introduces a configuration knob to disable requesting option 121. Thanks, Baptiste On Fri, Nov 20, 2015 at 11:50:56PM +0100, Baptiste Jonglez wrote: > From: Baptiste Jonglez <g...@bitsofnetworks.org> > > This option

Re: [OpenWrt-Devel] [PATCH][ar71xx] Routerboard 951G Switch Fix

Hi, I'm bumping again, this patch is necessary to make the gigabit switch work on the Mikrotik 951G-2HnD (tested on CC). Thanks, Baptiste On Wed, Nov 25, 2015 at 06:18:29PM +0100, Baptiste Jonglez wrote: > Hi, > > Sorry to bump up the thread again. Is there anything blocking

Re: [OpenWrt-Devel] [PATCH][ar71xx] Routerboard 951G Switch Fix

#tracking_reported_experience_with_suggested_patch_for_the_5_gige_ports Thanks, Baptiste On Sat, Nov 14, 2015 at 06:30:52PM +0100, Baptiste Jonglez wrote: > Hi, > > On Wed, Dec 10, 2014 at 01:40:42PM -0700, Davey Hutchison wrote: > > Fix pll_1000 value for eth0. Traffic would not flow from the eth0 > > interface. The new P

[OpenWrt-Devel] [PATCH] ar71xx: Build initramfs by default for Mikrotik devices

From: Baptiste Jonglez <g...@bitsofnetworks.org> Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org> --- target/linux/ar71xx/mikrotik/target.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ar71xx/mikrotik/target.mk b/target/linux/ar7

Re: [OpenWrt-Devel] [PATCH] netifd: Request DHCP option 121 (classless route) by default

On Thu, Nov 19, 2015 at 03:41:10PM +0100, Hans Dedecker wrote: > On Thu, Nov 19, 2015 at 2:39 PM, Steven Barth wrote: > > > I don't see this argument as very convincing. I mean they still have > > control even if the client ORO's 121, they could simply ignore it. On top > > of

[OpenWrt-Devel] [PATCH v2] netifd: Request DHCP option 121 (classless route) by default

From: Baptiste Jonglez <g...@bitsofnetworks.org> This option is useful when the gateway configured by DHCP cannot be in the same subnet as the client. This happens, for instance, when using DHCP to hand out addresses in /32 subnets. A new configuration option "classlessroute&qu

Re: [OpenWrt-Devel] [PATCH] netifd: Request DHCP option 121 (classless route) by default

ould be much easier if OpenWRT clients worked out-of-the-box on our network. > Bye, > Hans Thanks, Baptiste > On Wed, Nov 18, 2015 at 12:33 AM, Baptiste Jonglez < > bapti...@bitsofnetworks.org> wrote: > > > From: Baptiste Jonglez <g...@bitsofnetworks.org> > &

[OpenWrt-Devel] [PATCH] netifd: Request DHCP option 121 (classless route) by default

From: Baptiste Jonglez <g...@bitsofnetworks.org> This option is very useful when the gateway configured by DHCP cannot be in the same subnet as the client. This happens, for instance, when using DHCP to hand out addresses in /32 subnets. Signed-off-by: Baptiste Jonglez <g...@bitsofnet

[OpenWrt-Devel] Enable initramfs build by default on mikrotik

Hi, Mikrotik devices need an initramfs for installation: http://wiki.openwrt.org/toh/mikrotik/common#downloading_openwrt_image However, the needed configuration option (CONFIG_TARGET_ROOTFS_INITRAMFS) is absent from the build configuration in both CC and trunk:

Re: [OpenWrt-Devel] [PATCH][ar71xx] Routerboard 951G Switch Fix

Hi, On Wed, Dec 10, 2014 at 01:40:42PM -0700, Davey Hutchison wrote: > Fix pll_1000 value for eth0. Traffic would not flow from the eth0 interface. > The new PLL enables delay, use ath79_setup_ar934x_eth_cfg to also enable > AR934X_ETH_CFG_RXD_DELAY. I can confirm that this patch works on CC

[OpenWrt-Devel] [PATCH] libnl: Fix URL

From: Baptiste Jonglez <g...@bitsofnetworks.org> Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org> --- package/libs/libnl/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/libs/libnl/Makefile b/package/libs/libnl/Makefile index 241e

Re: [OpenWrt-Devel] [PATCH] libnl: split into smaller libraries

On Sat, Oct 03, 2015 at 01:10:18PM +0200, Felix Fietkau wrote: > > As far as I understood this, libnl-tiny is a drop-in replacement for > > libnl-core. Or is there a difference in functionality or API/ABI? > libnl-tiny replaces the most commonly used parts of libnl-core + -genl. > The API is a

Re: [OpenWrt-Devel] [PATCH] libnl: split into smaller libraries

On Tue, Sep 22, 2015 at 03:42:26PM +0300, Alexandru Ardelean wrote: > So, > - bmon requires libnl-route > - aircrack-ng requires libnl-genl > - kismet i am not sure 100% ; maybe libnl-genl ; I did not want to > investigate much deeper > - ibrcommon requires libnl-genl and libnl-route > -

Re: [OpenWrt-Devel] What happened to nut UPS config? (#20515)

Hi David, Package-related patches should be submitted to the Github package repository: https://github.com/openwrt/packages/ Baptiste On Thu, Sep 17, 2015 at 11:32:36AM +0100, David Woodhouse wrote: > In my old AA setup, the nut package had an init script which built > ups.conf and

Re: [OpenWrt-Devel] [PATCH v2 netifd] interface-ip: Fix broadcast address when using /31 or /32 IPv4 addressing

nbd, did you have time to look at this new version of the patch? Thanks, Baptiste On Mon, Sep 14, 2015 at 12:25:33PM +0200, Baptiste Jonglez wrote: > From: Baptiste Jonglez <g...@bitsofnetworks.org> > > A /31-addressed interface requires a broadcast address of 255.255.255

[OpenWrt-Devel] [PATCH netifd] interface-ip: Fix broadcast address when using /31 IPv4 addressing

A /31-addressed interface requires a 255.255.255.255 broadcast, because there is no room for a proper broadcast address. Without this, any packet destinated to the other end of the link is sent as broadcast, which is incorrect. Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.

[OpenWrt-Devel] [PATCH v2 netifd] interface-ip: Fix broadcast address when using /31 or /32 IPv4 addressing

From: Baptiste Jonglez <g...@bitsofnetworks.org> A /31-addressed interface requires a broadcast address of 255.255.255.255, because there is no room for a proper broadcast address. Without this, any packet destinated to the other end of the link is sent as broadcast, which is inc

Re: [OpenWrt-Devel] [RFC] ncurses vs ncursesw

On Sun, Nov 09, 2014 at 09:40:37PM +0200, Alexandru Ardelean wrote: I'll try to get opinions about this. Since we're in the middle of packages migration, maybe it's an interesting opportunity to try to use ncursesw and drop ncurses. ncursesw is ncurses + Unicode (UTF8) support Both

Re: [OpenWrt-Devel] Ralink ethernet update

On Thu, Oct 30, 2014 at 11:04:17PM +0200, Roman Yeryomin wrote: On 30 October 2014 16:20, Mingyu Li igv...@gmail.com wrote: i checkout the latest code and rebuild for rt-n15 only test 3 times lan to wan tcp performance 60 seconds one thread netperf version 2.6.0 116.33, 116.20, 102.84

Re: [OpenWrt-Devel] [PATCH] GRE: Tos support

On Sun, Sep 28, 2014 at 09:35:05PM +0200, Hans Dedecker wrote: Tos support is added as a generic grev4/grev6 parameter which can have the following values : -inherit (outer header inherits the tos value of the inner header) -hex value Signed-off-by: Hans Dedecker

Re: [OpenWrt-Devel] [PATCH] base-files: procd initscripts restart on reload

On Sun, Sep 14, 2014 at 08:14:11AM -0400, Tristan Plumb wrote: Currently procd enabled initscripts will restart on reload when the command line changes, which works for many packages, but not anything that keeps its configuration in a file, like dnsmasq. Wouldn't it be better to check whether

Re: [OpenWrt-Devel] [PATCH] babeld: use procd to start, stop, and respawn

Hi, Note that babeld is maintained in https://github.com/openwrt-routing/packages. Nevertheless, comments inline. On Sun, Sep 07, 2014 at 05:56:32PM -0400, Tristan Plumb wrote: Changes the babeld init script to utilize procd and Nice, it was a requested feature:

Re: [OpenWrt-Devel] [PATCH] babeld: use procd to start, stop, and respawn

FYI - Forwarded message from Juliusz Chroboczek j...@pps.univ-paris-diderot.fr - Date: Mon, 08 Sep 2014 16:03:56 +0200 From: Juliusz Chroboczek j...@pps.univ-paris-diderot.fr To: Baptiste Jonglez bjong...@illyse.org Cc: openwrt-devel@lists.openwrt.org, babel-us

Re: [OpenWrt-Devel] Using - in section names

On Wed, Aug 27, 2014 at 08:38:16PM +0200, Jo-Philipp Wich wrote: Even if - would be allowed you'd still need to deal with @, ., #, : and other funny characters that are legal in ifnames. The only suitable way using the existing syntax constraints is to use an option value, similar to how

Re: [OpenWrt-Devel] Parsing list of options with the callback method

=openwrt.git;a=blob;f=package/base-files/files/lib/functions.sh;h=0d4b2a33dbbf4e18acd474ae2adaad0ea3c1c4a0;hb=HEAD or from uci itself. Any clue? On Wed, Aug 27, 2014 at 07:11:39PM +0200, Baptiste Jonglez wrote: Hi, According to [1], it should be possible to parse list of options in a UCI file using

[OpenWrt-Devel] Using - in section names

Hi, I am currently writing an init script using the callback method [1], on BB-rc3. However, it does not seem possible to use - in a section name, for instance: config interface 'tun-test' option 'rxcost' '42' The config_cb function never gets called for this section (but option_cb

[OpenWrt-Devel] Parsing list of options with the callback method

Hi, According to [1], it should be possible to parse list of options in a UCI file using an option_cb() callback. It does not seem to work as expected, for instance this block: config example list 'import_table' '42' list 'import_table' '53' leads to the following calls: config_cb

Re: [OpenWrt-Devel] Using - in section names

On Wed, Aug 27, 2014 at 07:49:21PM +0200, Jo-Philipp Wich wrote: Hi, yes there is a reason, the initial uci implementation was shell based and section names are part of generated variable names which must not contain dashes. So, it shouldn't be necessary with the C implementation? Simply

[OpenWrt-Devel] [BB-rc3] Disabling DHCPv6 also disables IPv6 SLAAC

Hi, The default behaviour of BB is to hand out statically assigned IPv6 addresses through DHCPv6. To disable this behaviour and only keep SLAAC through RA, I disabled dhcpv6 in /etc/config/dhcp: config dhcp 'lan' option interface 'lan' option start '70' option limit '64'

Re: [OpenWrt-Devel] [BB-rc3] Disabling DHCPv6 also disables IPv6 SLAAC

On Fri, Aug 22, 2014 at 07:59:27PM +0200, Steven Barth wrote: Please try with: option dhcpv6 disabled instead of none That worked, thanks! What is the default value, then? Is it none or disabled? What is the difference? Cheers, Steven ___

Re: [OpenWrt-Devel] [BB-rc3] Disabling DHCPv6 also disables IPv6 SLAAC

On Fri, Aug 22, 2014 at 10:38:24PM +0200, Bastian Bittorf wrote: * Baptiste Jonglez bjong...@illyse.org [22.08.2014 22:34]: What is the default value, then? Is it none or disabled? What is the difference? internally it's a bool/switch, which can have: 0|off|false|no|disabled or 1

Re: [OpenWrt-Devel] [PATCH] gre: Generic Routing Encapsulation package support

On Sun, Aug 03, 2014 at 11:37:51AM +0200, Steven Barth wrote: tbh. we should get rid of that option network stuff. I merged it anyway at first so we can get some experience with this gre-integration. Normally you should use something like this instead: config interface mygre option

Re: [OpenWrt-Devel] [PATCH] gre: Generic Routing Encapsulation package support

Thank you for this nice implementation. I've started some documentation on http://wiki.openwrt.org/doc/uci/network A few comments after testing gre/gretap on BB-rc2 (with netifd 2014-07-30 from trunk): 1/ the firewall rules added by zone do no seem to be flushed when the interface goes down

Re: [OpenWrt-Devel] [PATCH] gre: Generic Routing Encapsulation package support

On Sat, Aug 02, 2014 at 11:51:33PM +0900, Baptiste Jonglez wrote: 2/ tunlink does not seem to work for anything else than wan. When trying to set it to lan (which is properly defined in the network config), the tunnel is not created. There is no error in readlog. After some debugging

Re: [OpenWrt-Devel] IPv6-question / fe80 / linklocal / uniq?

On Tue, Jul 22, 2014 at 11:50:55AM +0200, Bastian Bittorf wrote: when reading http://en.wikipedia.org/wiki/IPv6#Link_local_address it seems to me, that the linklocal-address should be uniq, unique is ambiguous: do you mean that the same LL address can't be present on different interfaces? on

Re: [OpenWrt-Devel] IPv6-question / fe80 / linklocal / uniq?

On Tue, Jul 22, 2014 at 02:08:16PM +0200, Bastian Bittorf wrote: * Baptiste Jonglez bjong...@illyse.org [22.07.2014 13:21]: root@box:~ ip neigh | grep ^'fe80::' | grep lladdr $mac fe80::1cfc:fe65:769:3784 dev wlan0 lladdr 84:b1:53:b2:b8:b3 STALE fe80::cea:3b47:5812:96be dev wlan0 lladdr

Re: [OpenWrt-Devel] Duplicate netifd protocol for l2tp

Steven Barth wrote: I renamed the xl2tpd netifd protocol to l2tpv2 and kept the l2tpv3 as l2tp as documented in the wiki. Thanks :) On Mon, Jul 21, 2014 at 08:47:58AM +0200, Dirk Neukirchen wrote: The config are totally different, the problem is really a name clash. It seems they are

[OpenWrt-Devel] Duplicate netifd protocol for l2tp

Hi, Two packages provide the proto l2tp netifd protocol: xl2tpd [1] in the new packages feed, and l2tpv3tun [2] in oldpackages. The config are totally different, the problem is really a name clash. What is the recommended way to deal with name clashes in netifd protocols, without breaking

[OpenWrt-Devel] Netifd support for tunnels and address configuration

Hi, I am currently adding GRE support for OpenWRT, based on 6in4 support [1] (since I couldn't find any documentation). What is the proper way to support address configuration for tunnel interfaces? It seems redundant to handle static address configuration for each tunnel type, especially with

Re: [OpenWrt-Devel] OpenWRT IPv6 firewall

On Thu, Jul 17, 2014 at 03:21:32PM +0100, Fernando Frediani wrote: Hello guys, This discussion if becoming each day more confusing for something, which for me, is very simple assuming the following: - IPv6 as IPv4 should block *any incoming connection* on the WAN interface including

Re: [OpenWrt-Devel] Netifd support for tunnels and address configuration

On Thu, Jul 17, 2014 at 06:28:09PM +0200, Hans Dedecker wrote: Hi Baptiste, I have added GRE support (gre/gretap/grev6/grev6tap) in netifd which I'm currenlty testing. The implementation looks the same as for 6rd/dslite tunnel interfaces (thus allowing to set mtu/ttl/remote end point);

Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)

On Tue, Jul 15, 2014 at 11:45:27AM -0400, Aaron Z wrote: As I understand it, if a device on the inside of the network initiates the connection to a device on the outside (say from a VOIP phone to a VOIP server), return connections from the server are allowed. Yes, this is exactly the role of a

<    1   2   3   >