Re: [OpenWrt-Devel] [PATCH 0/3] Add support of ARC architecture

[Alexey Brodkin]

Hi Felix,

On Fri, 2015-09-11 at 15:09 +0200, Felix Fietkau wrote:
> On 2015-08-27 13:03, Alexey Brodkin wrote:
> > This patch series adds support for the Synopsys DesignWare ARC architecture.
> > 
> > DesignWare ARC700 is family of 32-bit CPUs developed by Synopsys, Inc.
> > 
> > Since version 3.9 ARC architecture is supported in mainline Linux 
> > developemnt.
> > Since version 2014.04 ARC architecture is supported in mainline U-Boot.
> > For quite some time ARC architecture is supported in upstream uClibc
> > development but since there were no recent releases of uClibc support of
> > ARC is available from uClibc's fork uClibc-ng now.
> Does Synopsys plan to add ARC support to musl as well? The code quality
> of musl is so much better than uClibc, and it also requires much less
> architecture specific code.
> I think more projects will switch from uClibc to musl in the future.

We do have plans for adding support of ARC in musl.
But these are long-term plans and we don't have any dates in mind yet.

So for now we'll keep using uClibc.
And I hope this fact won't block ARC port from being accepted in OpenWRt.

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

[OpenWrt-Devel] Questions about "binutils: add binutils 2.25.1"

[Alexey Brodkin]

Hi Hauke,

I noticed your change made in "toolchain/binutils" recently:
->8-
http://git.openwrt.org/?p=openwrt.git;a=commit;h=fece50d94033c1dcfc3f290acbd428f9125c30aa

binutils: add binutils 2.25.1

This adds binutils 2.25.1 as an option to OpenWrt.

Signed-off-by: Hauke Mehrtens 

git-svn-id: svn://svn.openwrt.org/openwrt/trunk@46874 
3c298f89-4303-0410-b956-a3cf2f4a3e73
->8-

First of all I cannot find that patch in neither OpenWRT mailing list
(I mean openwrt-devel@lists.openwrt.org) nor in OpenWRT patchwork.

Did I overlook something?

But my real question was in "toolchain/binutils/Config.in" you added
the following:
->8-
   config BINUTILS_VERSION_2_25_1
   bool "Linaro binutils 2.25.1" <-- note "Linaro" word
->8-

But in all other places I see there's no mention of "Linaro" for that
2.25.1 version.

In fact PKG_SOURCE_URL:=@GNU/binutils/ for it so it looks like this is
pristine binutils with no Linaro changes.

So probably description of BINUTILS_VERSION_2_25_1 should be changed.

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

Re: [OpenWrt-Devel] [PATCH 0/3] Add support of ARC architecture

[John Crispin]

On 14/09/2015 13:35, Alexey Brodkin wrote:
> Hi Felix,
> 
> On Fri, 2015-09-11 at 15:09 +0200, Felix Fietkau wrote:
>> On 2015-08-27 13:03, Alexey Brodkin wrote:
>>> This patch series adds support for the Synopsys DesignWare ARC architecture.
>>>
>>> DesignWare ARC700 is family of 32-bit CPUs developed by Synopsys, Inc.
>>>
>>> Since version 3.9 ARC architecture is supported in mainline Linux 
>>> developemnt.
>>> Since version 2014.04 ARC architecture is supported in mainline U-Boot.
>>> For quite some time ARC architecture is supported in upstream uClibc
>>> development but since there were no recent releases of uClibc support of
>>> ARC is available from uClibc's fork uClibc-ng now.
>> Does Synopsys plan to add ARC support to musl as well? The code quality
>> of musl is so much better than uClibc, and it also requires much less
>> architecture specific code.
>> I think more projects will switch from uClibc to musl in the future.
> 
> We do have plans for adding support of ARC in musl.
> But these are long-term plans and we don't have any dates in mind yet.
> 
> So for now we'll keep using uClibc.
> And I hope this fact won't block ARC port from being accepted in OpenWRt.
> 

not a blocker but something we wanted to be sure that cannot be avoided :)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/3] Add support of ARC architecture

[Alexey Brodkin]

Hi John,

On Mon, 2015-09-14 at 13:41 +0200, John Crispin wrote:
> 
> On 14/09/2015 13:35, Alexey Brodkin wrote:
> > Hi Felix,
> > 
> > On Fri, 2015-09-11 at 15:09 +0200, Felix Fietkau wrote:
> > > On 2015-08-27 13:03, Alexey Brodkin wrote:
> > > > This patch series adds support for the Synopsys DesignWare ARC 
> > > > architecture.
> > > > 
> > > > DesignWare ARC700 is family of 32-bit CPUs developed by Synopsys, Inc.
> > > > 
> > > > Since version 3.9 ARC architecture is supported in mainline Linux 
> > > > developemnt.
> > > > Since version 2014.04 ARC architecture is supported in mainline U-Boot.
> > > > For quite some time ARC architecture is supported in upstream uClibc
> > > > development but since there were no recent releases of uClibc support of
> > > > ARC is available from uClibc's fork uClibc-ng now.
> > > Does Synopsys plan to add ARC support to musl as well? The code quality
> > > of musl is so much better than uClibc, and it also requires much less
> > > architecture specific code.
> > > I think more projects will switch from uClibc to musl in the future.
> > 
> > We do have plans for adding support of ARC in musl.
> > But these are long-term plans and we don't have any dates in mind yet.
> > 
> > So for now we'll keep using uClibc.
> > And I hope this fact won't block ARC port from being accepted in OpenWRt.
> > 
> 
> not a blocker but something we wanted to be sure that cannot be avoided :)

Unfortunately for now we don't have any option other than uClibc.

But as mentioned above we do plan to support with time more and more 
alternatives.
The problem is we have plenty of things to support while still being a small 
group
of engineers.

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

Re: [OpenWrt-Devel] OpenWRT www version banner a security risk

[MauritsVB]

I agree that adding a robots.txt with
User-agent: *
Disallow: /
would be worth it, considering it’s a small effort and minimal space penalty.

It doesn’t stop Banner Grabbing tools but it does stop casual indexing by 
benign search tools.

Of course, removing the version banner or adding a robots.txt doesn’t stop a 
determined attacker specifically targeting a known machine. What it does do is 
prevent these systems ending up in a detailed database of vulnerable systems. 
It should not be considered a replacement (or “job done”) for other security 
measures, just an extra line of protection.

Maurits

> On 13 Sep 2015, at 21:49, Daniel Dickinson  
> wrote:
> 
> On 2015-09-13 4:41 PM, Luiz Angelo Daros de Luca wrote:
>> While openwrt doesn't offer security release, hiding version in banner
>> is not very effective. If the attacker can detect it is OpenWRT and if
>> there is a known security issue for any major version, it is enough to
>> try an attack.
>> 
>> Robot.txt is effective as Google is a common tool to look for targets. I
> 
> Do you have any references / statistics / facts to justify this claim?
> 
>> guess brute force scanners would not care to detect luci open to web as
>> it is a rare target (if Google does not list them). If they care, again,
> 
> Erm, if luci is rare target, then who is going to bother with searching for 
> vulnerable banners?
> 
> Furthermore, the far better way to avoid this exposure is prevent exposing 
> the web interface unintentionally in the first place.
> 
> I'm not convinced robots.txt prevents a significant number attacks, although 
> given small size of robots.txt I don't think it would hurt to include it 
> anyway.
> 
> I'm merely pointing out that the robots.txt is really not a very effective 
> solution to the stated reason for wanting it (protecting user from accidental 
> exposure, or from choosing to expose without realize the risks of doing so).
> 
> I think solving the real problem is more important than relying on a bandaid 
> and saying 'job done'.
> 
> (Which is how I view Etienne's robots.txt email).
> 
> Regards,
> 
> Daniel
> 
>> they would just try the known attack.
>> 
>> Regards,
>> 
>> 
>> Em dom, 13 de set de 2015 17:05, Daniel Dickinson
>> >
>> escreveu:
>> 
>>I do think allowing to choose to disable the banner is a minor benefit,
>>however, as I've said, there are much more effective means of preventing
>>accidential exposure, and quite frankly if the user is *choosing* to
>>open the web interface I think an warning and disabling the banner if
>>the user foolishly insists on opening the interface despite the warning
>>is more useful thank disabling the banner by default.
>> 
>>If you're going to argue it prevents against internal threats than I
>>would argue that if your internal network is hostile enough that you
>>need to worry about attacks on openwrt from your internal network AND
>>you're not skilled enough to limit access to LuCI (or better, build an
>>image without LuCI and just use SSH) to the specific trusted hosts
>>(preferably by combination of MAC address and IP address) in the
>>firewall, or (better) to use a 'management' VPN or VLAN that only
>>trusted hosts can get on, then you're in a lot more trouble than
>>eliminating the banner for LuCI will solve.
>> 
>>Regards,
>> 
>>Daniel
>> 
>>On 2015-09-13 10:21 AM, MauritsVB wrote:
>> > At the moment the OpenWRT www login screen provides *very*
>>detailed version information before anyone has even entered a
>>password. It displays not just “15.05” or “Chaos Calmer” but even
>>the exact git version on the banner.
>> >
>> > While it’s not advised to open this login screen to the world,
>>fact is that it does happen intentionally or accidentally. Just a
>>Google search for “Powered by LuCI Master (git-“ will provide many
>>accessible OpenWRT login screens, including exact version information.
>> >
>> > As soon as someone discovers a vulnerability in a OpenWRT version
>>all an attacker needs to do is perform a Google search to find many
>>installations with versions that are vulnerable (even if a patch is
>>already available).
>> >
>> > In the interest of hardening the default OpenWRT install, can I
>>suggest that by default OpenWRT doesn’t disclose the version (not
>>even 15.05 or “Chaos Calmer”) on the login screen? For extra safety
>>I would even suggest to leave “OpenWRT” off the login screen, the
>>only people who should use this screen already know it’s running
>>OpenWRT.
>> >
>> > Any thoughts?
>> >
>> > Maurits
>> > ___
>> > openwrt-devel mailing list
>> > openwrt-devel@lists.openwrt.org
>>
>> > 

Re: [OpenWrt-Devel] Chaos Calmer 15.05

[Rafał Miłecki]

On 11 September 2015 at 11:29, John Crispin  wrote:
> On 11/09/2015 11:27, Daniel Golle wrote:
>> However, it seems like images for some boards got missing at least on
>> lantiq and oxnas.
>
> ah indeed, i missed the IB images. will add them during the weekend

They are available now, thanks John!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT www version banner a security risk

[Joshua Judson Rosen]

On 2015-09-13 15:30, Daniel Dickinson wrote:
> Oh and 1 has the benefit of actually securing the device against wan access
> to LuCI even in the case of firewall not blocking such access, whereas the
> robots.txt and hiding banner are classic 'security through obscurity' which
> is the > security pundit's favourite target for good reason.

On 2015-09-13 15:42, Daniel Dickinson wrote:
> I just remembered that robots.txt is just a text file to stick in /www, so it 
> is
> certainly is not high cost, although now that I remember that is also less
> useful than I was thinking because it really only prevents indexing by
> cooperative robots that obey robots.txt

Indeed: robots.txt is exactly the opposite of `security through _obscurity_':
it's a listing that explicitly tells clients what they're not supposed to look 
at.

Trying to use robots.txt as a security measure is actually worse than nothing:
you protect yourself from your friends at the expense marking yourself
for the bad guys :)

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr."
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT www version banner a security risk

[Joshua Judson Rosen]

On 2015-09-13 10:21, MauritsVB wrote:
> At the moment the OpenWRT www login screen provides *very* detailed version 
> information before anyone has even entered a password. It displays not just 
> “15.05” or “Chaos Calmer” but even the exact git version on the banner.
> 
> While it’s not advised to open this login screen to the world, fact is that 
> it does happen intentionally or accidentally. Just a Google search for 
> “Powered by LuCI Master (git-“ will provide many accessible OpenWRT login 
> screens, including exact version information.
> 
> As soon as someone discovers a vulnerability in a OpenWRT version all an 
> attacker needs to do is perform a Google search to find many installations 
> with versions that are vulnerable (even if a patch is already available).
> 
> In the interest of hardening the default OpenWRT install, can I suggest that 
> by default OpenWRT doesn’t disclose the version (not even 15.05 or “Chaos 
> Calmer”) on the login screen? For extra safety I would even suggest to leave 
> “OpenWRT” off the login screen, the only people who should use this screen 
> already know it’s running OpenWRT.
> 
> Any thoughts?

I think you'd also need to change a number of services to stop
reporting detailed information in their protocol.

For example: have you noticed that the ETag and Last-Modified
values that uhttpd returns for a given path are identical
across all installations of a given version of OpenWrt?
It doesn't really matter if there's an OpenWrt version-number
in the *content* fetched over HTTP--the client has already
got that information before they even get the content.

Another example: the version-info exchanged at the start
of the SSH protocol.

It's like deciding that you want to send an anonymous letter
and so avoid signing your name on that letter, but still putting
your name and return address on the outside of the envelope.

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr."
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] QinQ on MT7530/MT7621

[Sven Eckelmann]

On Tuesday 08 September 2015 15:01:09 Sven Eckelmann wrote:
> Hi,
> 
> I was testing QinQ/stacked vlan/double vlan/doubletag on MT7621 and
> noticed that it didn't work. I see packets correctly send with the
> the stacked VLAN tag but the replies are never received by eth0.
[...]

Just some notes:

If I change the REG_ESW_PORT_PCR of each port from 0x00ff0003 (only
allow frame when vlan member of vid) to 0x00ff0001 (broadcasting the
port matrix members when port not member of vid) then I can see the
frame on eth0 (port 6).

I would therefore conclude that I need to switch the incoming port to
a state were it doesn't try to get the vlan header from the frame. The
correct one seems to be the transparent mode as already used by the
port matrix (enable_vlan == 0) mode.

My proof of concept patch (yes, I know it is currently in the wrong
place and it should be differentiated between tagged/untagged and
not between CPU port and not CPU port).

--- a/target/linux/ramips/files/drivers/net/ethernet/ralink/mt7530.c
+++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/mt7530.c
@@ -500,8 +500,12 @@ mt7530_apply_config(struct switch_dev *dev)
mt7530_w32(priv, REG_ESW_PORT_PCR(i), 0x00ff0003);
 
/* set all ports as user port */
-   for (i = 0; i < MT7530_NUM_PORTS; i++)
-   mt7530_w32(priv, REG_ESW_PORT_PVC(i), 0x8100);
+   for (i = 0; i < MT7530_NUM_PORTS; i++) {
+   if (i == MT7530_CPU_PORT)
+   mt7530_w32(priv, REG_ESW_PORT_PVC(i), 0x8100);
+   else
+   mt7530_w32(priv, REG_ESW_PORT_PVC(i), 0x81c0);
+   }
 
for (i = 0; i < MT7530_NUM_VLANS; i++) {
u16 vid = priv->vlan_entries[i].vid;


I am currently not perfectly sure how to best solve the problem that
this setting is per port and the tagging/non-tagging setting is per
vlan. Maybe I will propose a patch that first checks if a port is
used in a vlan in tag/untag mode and then set the port mode to
transparent when it is not used as tagged in any vlan (and print a
warning when used in a mixed mode).

But here are my notes just in case I get struck by an improper
installed accesspoint.

Kind regards,
Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Target profiles: making "make" build every profile

[Felix Fietkau]

On 2015-09-14 12:06, Jonas Gorski wrote:
> Hi,
> 
> On Mon, Sep 14, 2015 at 11:30 AM, Rafał Miłecki  wrote:
>> Quick summary:
>> Subtargets - used for building modified kernels
>> Profiles - used for including specific software
>>
>> There are two ways of using profiles:
>>
>> 1) Changing some software for all devices
>> Used when profile is used for all devices (no filtering, no per device
>> profiles).
>> This is used e.g. by brcm47xx. Normally all images will be built with
>> b43. However by changing a profile you can get *all* images to include
>> wl.ko.
>>
>> 2) Including extra software for specific devices
>> Used when profile is (group) device specific. E.g. including USB
>> drivers for devices with USB only.
>> This is something I'd like to use with bcm53xx. I'd like to include
>> brcmfmac.ko in two images only (R8000 and SR400ac). Of course, I'll
>> need to adjust target/bcm53xx/image/Makefile to:
>> a) Stop building SR400ac and R8000 images for TARGET_bcm53xx_Generic
>> b) Build above images for something new like TARGET_bcm53xx_brcmfmac
> 
> I don't think there is an issue with letting Generic build all images
> with a "common" package set as default, and still having a defined
> profile for it with a specialized package set.
> 
>> If I add TARGET_bcm53xx_brcmfmac as explained above, its images won't
>> be build anymore by default.
>> I'd like to to have a way to ask "make" for building all profiles by
>> setting some variable in target/bcm53xx/Makefile
>>
>> Can someone give me some help with implementing this?
> 
> Changing the buildroot for that would be a lot of work, as you would
> need to force all packages needed by all images as =m, and you would
> have to require them, as else the image generation will fail if the
> user decides to delect any of them (or silently drop it). And then the
> issue of deciding if a package should be included in the image or not
> based on the selected profile's default packages, the image's default
> profile's packages, and the actual selection states in .config
> 
> I think a better place would be the image builder for that. There we
> could just add e.g. a new build target like allimages that will
> iterate over all available images and build them. Or maybe
> "alldevices", and it would hook into the new Device-stuff and iterate
> over all defined devices, with the assumption that these define their
> specific profile so we don't need to add code to skip the common
> profiles.
> 
> so we would then have something like
> 
> define Device/FooDevice
> DEVICE_PROFILE=Foo
> endef
> 
> define Device/BarDevice
>DEVICE_PROFILE=Bar
> endef
> 
> 
> and enhance the code in include/image.mk to collect these
> DEVICE_PROFILEs to iterate over.
I like this idea. To make it easier to build an image builder for that,
we could change the metadata script to generate a hidden config symbol,
which is set to =m, depends on CONFIG_IB, and selects all packages used
by every single profile of that target (so you don't necessarily have to
use CONFIG_ALL).

We could add another symbol to guard it, so that you can also build an
image builder with a more restricted feature set that can't build all
profiles.

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

[OpenWrt-Devel] [RFC] ralink: Allow to receive vlan over untag ports on MT7530

[Sven Eckelmann]

The MT7530 switch driver with enable_vlan set will automatically set all
ports to the user port mode. The hardware will remove the incoming vlan tag
on these ports and use it for its internal vlan. This is usually not wanted
and makes it impossible to communicate via vlan over the switch in both
directions.

It is possible to configure a switch port to "transparent mode" when this
port is only used as untag in the switch VLANs. This will disable the VLAN
untagging of packets when they were received on this port. The tagging on
"tag" ports based on the vlan id is still working.

The transparent port mode cannot be used when a port is both used in a VLAN
as "tag" and in another one as "untag" port.

The problem with this approach is the limit of the MTU of 1496 bytes for
the VLAN device on top of eth0.X. Larger packets can still be send but will
not be received.

Signed-off-by: Sven Eckelmann 
---
 .../files/drivers/net/ethernet/ralink/mt7530.c | 36 --
 1 file changed, 33 insertions(+), 3 deletions(-)

diff --git a/target/linux/ramips/files/drivers/net/ethernet/ralink/mt7530.c 
b/target/linux/ramips/files/drivers/net/ethernet/ralink/mt7530.c
index 51e16f2..4e00315 100644
--- a/target/linux/ramips/files/drivers/net/ethernet/ralink/mt7530.c
+++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/mt7530.c
@@ -484,6 +484,8 @@ mt7530_apply_config(struct switch_dev *dev)
 {
struct mt7530_priv *priv = container_of(dev, struct mt7530_priv, swdev);
int i, j;
+   u8 tag_ports;
+   u8 untag_ports;
 
if (!priv->global_vlan_enable) {
for (i = 0; i < MT7530_NUM_PORTS; i++)
@@ -499,9 +501,37 @@ mt7530_apply_config(struct switch_dev *dev)
for (i = 0; i < MT7530_NUM_PORTS; i++)
mt7530_w32(priv, REG_ESW_PORT_PCR(i), 0x00ff0003);
 
-   /* set all ports as user port */
-   for (i = 0; i < MT7530_NUM_PORTS; i++)
-   mt7530_w32(priv, REG_ESW_PORT_PVC(i), 0x8100);
+   /* check if a port is used in tag/untag vlan egress mode */
+   tag_ports = 0;
+   untag_ports = 0;
+
+   for (i = 0; i < MT7530_NUM_VLANS; i++) {
+   u8 member = priv->vlan_entries[i].member;
+   u8 etags = priv->vlan_entries[i].etags;
+
+   if (!member)
+   continue;
+
+   for (j = 0; j < MT7530_NUM_PORTS; j++) {
+   if (!(member & BIT(j)))
+   continue;
+
+   if (etags & BIT(j))
+   tag_ports |= 1u << j;
+   else
+   untag_ports |= 1u << j;
+   }
+   }
+
+   /* set all untag-only ports as transparent and the rest as user port */
+   for (i = 0; i < MT7530_NUM_PORTS; i++) {
+   u32 pvc_mode = 0x8100;
+
+   if (untag_ports & BIT(i) && !(tag_ports & BIT(i)))
+   pvc_mode = 0x81c0;
+
+   mt7530_w32(priv, REG_ESW_PORT_PVC(i), pvc_mode);
+   }
 
for (i = 0; i < MT7530_NUM_VLANS; i++) {
u16 vid = priv->vlan_entries[i].vid;
-- 
2.5.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Chaos Calmer 15.05

[Bruno Randolf]

On 09/11/2015 09:56 AM, Rafał Miłecki wrote:
> On 11 September 2015 at 10:54, Steven Barth  wrote:
>> The OpenWrt developers are proud to announce the final release of OpenWrt 
>> Chaos Calmer.
> 
> Before someone asks, it's
> r46767
> 483dac821788b457d349233e770329186a0aa860
> ramips: fix devicetree corruption with some boot loaders if the caches
> are not ready at boot

Could someone please tag this in the git repository?

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

[OpenWrt-Devel] i2c device not in /dev

[Baptiste Clenet]

Hi,

I'm using a MT7628 chip and I try to implement an I2C device which
will use i2c-ralink adapter. I registered my i2c device with
module_i2c_driver(i2c_device_driver);

I can see it on my bus:
./sys/bus/i2c/drivers/i2c_device_driver
But it doesn't appear in /dev.

What am I doing wrong?

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

[OpenWrt-Devel] [PATCH v2 0/7] target: mxs: various fixes

[Michael Heimpold]

This patch series is to bring OpenWrt's Duckbill support back in shape:
- U-Boot build is fixed
- SD card generation is adopted for Duckbill images

I've tested my changes with I2SE Duckbill and Olimex OLinuXino
Maxi board, however, I've no Micro/Mini at hand.

This series obsoletes my series "packages: uboot-mxs: various fixes"
from Mon, 31 Aug 2015 21:49:28 +0200, so I've choosen to name this
one "v2".

It's possible to pull this series from
https://github.com/mhei/openwrt/tree/mxs-fixes, but I'm
rebasing this branch from time to time.

Changes in v2:
- don't break Olimex (i.MX233) based boards anymore
- SD card generation now support Duckbill's partitioning scheme

Michael Heimpold (7):
  packages: uboot-mxs: place binaries in the designated path
  packages: uboot-mxs: do no modify the U-Boot image, copy as-is
  packages: uboot-mxs: bless UBOOT_IMAGE with a meaning, otherwise we
could drop this C left-over
  target/mxs: adopt SD card generation to fixed U-Boot path
  packages: uboot-mxs: fix I2SE Duckbill variant
  tools: add sdimage (for mxs target)
  target: mxs: re-work SD card image generation

 package/boot/uboot-mxs/Makefile|   10 +--
 .../uboot-mxs/patches/001-add-i2se-duckbill.patch  |   82 +++-
 target/linux/mxs/image/Config.in   |9 ++-
 target/linux/mxs/image/Makefile|   36 +
 target/linux/mxs/image/gen_mxs_sdcard_img.sh   |   38 -
 target/linux/mxs/image/gen_sdcard_ext4_ext4.sh |   33 
 target/linux/mxs/image/gen_sdcard_vfat_ext4.sh |   37 +
 tools/Makefile |2 +-
 tools/sdimage/Makefile |   37 +
 9 files changed, 186 insertions(+), 98 deletions(-)
 delete mode 100755 target/linux/mxs/image/gen_mxs_sdcard_img.sh
 create mode 100755 target/linux/mxs/image/gen_sdcard_ext4_ext4.sh
 create mode 100755 target/linux/mxs/image/gen_sdcard_vfat_ext4.sh
 create mode 100644 tools/sdimage/Makefile

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

[OpenWrt-Devel] r46816, remove unused crypt() algorithms -> switch to sha512?

[Etienne Champetier]

Hi Felix,

Maybe we should keep sha512 and switch to it? md5 is not best security
practice these days.
I've checked, ubuntu 14.04 and fedora 22 both use sha512 in /etc/shadow

I wonder if AF_ALG can be of any interest here (integrate needed algo by
default into the kernel, then patch core software to use kernel
implementation)

To conclude maybe you should emit a clear error when we try a now
unsupported hash,
because crypt can be used by other app, so maybe you just broke another app
and someone will waste a good amount of time debugging it

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

[OpenWrt-Devel] [PATCH v2 7/7] target: mxs: re-work SD card image generation

[Michael Heimpold]

- Duckbill uses a different partitioning approach than standard
  FSL and Olimex
- use new sdimage to integrate U-Boot into the SD card images

Signed-off-by: Michael Heimpold 
---

Changes in v2:
- new patch

 target/linux/mxs/image/Config.in   |9 --
 target/linux/mxs/image/Makefile|   34 +
 target/linux/mxs/image/gen_mxs_sdcard_img.sh   |   38 
 target/linux/mxs/image/gen_sdcard_ext4_ext4.sh |   33 
 target/linux/mxs/image/gen_sdcard_vfat_ext4.sh |   37 +++
 5 files changed, 97 insertions(+), 54 deletions(-)
 delete mode 100755 target/linux/mxs/image/gen_mxs_sdcard_img.sh
 create mode 100755 target/linux/mxs/image/gen_sdcard_ext4_ext4.sh
 create mode 100755 target/linux/mxs/image/gen_sdcard_vfat_ext4.sh

diff --git a/target/linux/mxs/image/Config.in b/target/linux/mxs/image/Config.in
index b71edf7..250553e 100644
--- a/target/linux/mxs/image/Config.in
+++ b/target/linux/mxs/image/Config.in
@@ -1,5 +1,8 @@
-config MXS_SD_BOOT_PARTSIZE
+config TARGET_BOOTFS_PARTSIZE
int "Boot (SD Card) filesystem partition size (in MB)"
-   depends on TARGET_mxs
+   depends on TARGET_mxs_olinuxino-maxi || TARGET_mxs_olinuxino-micro
default 8
-
+   help
+   On the Olimex OLinuXino boards, mainline U-Boot loads the
+   linux kernel and device tree file from a FAT partition.
+   The default value of 8 MB should be more than adequate.
diff --git a/target/linux/mxs/image/Makefile b/target/linux/mxs/image/Makefile
index 7e6a1a0..94fed82 100644
--- a/target/linux/mxs/image/Makefile
+++ b/target/linux/mxs/image/Makefile
@@ -7,13 +7,13 @@
 
 include $(TOPDIR)/rules.mk
 include $(INCLUDE_DIR)/image.mk
-include $(INCLUDE_DIR)/host.mk
 
 BOARDS:= \
imx23-olinuxino \
imx28-duckbill
+
 FAT32_BLOCK_SIZE=1024
-FAT32_BLOCKS=$(shell echo 
$$(($(CONFIG_MXS_SD_BOOT_PARTSIZE)*1024*1024/$(FAT32_BLOCK_SIZE
+FAT32_BLOCKS=$(shell echo 
$$(($(CONFIG_TARGET_BOOTFS_PARTSIZE)*1024*1024/$(FAT32_BLOCK_SIZE
 
 define Image/BuildKernel
mkimage -A arm -O linux -T kernel -C none \
@@ -44,37 +44,45 @@ define Image/InstallKernel
 
 endef
 
-define Image/Build/SDCard
+define Image/Build/SDCard-vfat-ext4
rm -f $(KDIR)/boot.img
mkdosfs $(KDIR)/boot.img -C $(FAT32_BLOCKS)
 
-   mcopy -i $(KDIR)/boot.img $(DTS_DIR)/$(2).dtb ::$(2).dtb
+   mcopy -i $(KDIR)/boot.img $(DTS_DIR)/$(3).dtb ::$(3).dtb
mcopy -i $(KDIR)/boot.img $(BIN_DIR)/$(IMG_PREFIX)-uImage ::uImage
 
-   ./gen_mxs_sdcard_img.sh \
-   $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-sdcard-vfat-$(1).img \
+   ./gen_sdcard_vfat_ext4.sh \
+   $(BIN_DIR)/$(2) \
+   $(BIN_DIR)/uboot-mxs-$(4)/uboot-mxs-$(4).sb \
$(KDIR)/boot.img \
$(KDIR)/root.$(1) \
-   $(CONFIG_MXS_SD_BOOT_PARTSIZE) \
-   $(CONFIG_TARGET_ROOTFS_PARTSIZE) \
-   $(BIN_DIR)/uboot-mxs-$(3)/uboot-mxs-$(3).sb
+   $(CONFIG_TARGET_BOOTFS_PARTSIZE) \
+   $(CONFIG_TARGET_ROOTFS_PARTSIZE)
+endef
+
+define Image/Build/SDCard-ext4-ext4
+   ./gen_sdcard_ext4_ext4.sh \
+   $(BIN_DIR)/$(2) \
+   $(BIN_DIR)/uboot-mxs-$(4)/uboot-mxs-$(4).sb \
+   $(KDIR)/root.$(1) \
+   $(CONFIG_TARGET_ROOTFS_PARTSIZE)
 endef
 
 define Image/Build/Profile/olinuxino-maxi
-   $(call Image/Build/SDCard,$(1),imx23-olinuxino,mx23_olinuxino)
+   $(call 
Image/Build/SDCard-vfat-ext4,$(1),$(2),imx23-olinuxino,mx23_olinuxino)
 endef
 
 define Image/Build/Profile/olinuxino-micro
-   $(call Image/Build/SDCard,$(1),imx23-olinuxino,mx23_olinuxino)
+   $(call 
Image/Build/SDCard-vfat-ext4,$(1),$(2),imx23-olinuxino,mx23_olinuxino)
 endef
 
 define Image/Build/Profile/duckbill
-   $(call Image/Build/SDCard,$(1),imx28-duckbill,duckbill)
+   $(call Image/Build/SDCard-ext4-ext4,$(1),$(2),imx28-duckbill,duckbill)
 endef
 
 define Image/Build
$(call Image/Build/$(1),$(1))
-   $(call Image/Build/Profile/$(PROFILE),$(1))
+   $(call 
Image/Build/Profile/$(PROFILE),$(1),$(IMG_PREFIX)-$(PROFILE)-sdcard.img)
dd if=$(KDIR)/root.$(1) of=$(BIN_DIR)/$(IMG_PREFIX)-root.$(1) bs=128k 
conv=sync
 endef
 
diff --git a/target/linux/mxs/image/gen_mxs_sdcard_img.sh 
b/target/linux/mxs/image/gen_mxs_sdcard_img.sh
deleted file mode 100755
index 7faa8d5..000
--- a/target/linux/mxs/image/gen_mxs_sdcard_img.sh
+++ /dev/null
@@ -1,38 +0,0 @@
-#!/usr/bin/env bash
-
-#
-# Copyright (C) 2015 OpenWrt.org
-#
-# This is free software, licensed under the GNU General Public License v2.
-# See /LICENSE for more information.
-#
-
-set -x 
-[ $# -eq 6 ] || {
-echo "SYNTAX: $0 
 "
-exit 1
-}
-
-OUTPUT="$1"
-BOOTFS="$2"
-ROOTFS="$3"
-BOOTFSSIZE="$4"
-ROOTFSSIZE="$5"
-UBOOT="$6"
-
-head=4
-sect=63
-
-# Set the u-boot storage to 2M
-set `ptgen -o 

[OpenWrt-Devel] [PATCH v2 2/7] packages: uboot-mxs: do no modify the U-Boot image, copy as-is

[Michael Heimpold]

Signed-off-by: Michael Heimpold 
---

Changes in v2:
- none

 package/boot/uboot-mxs/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/boot/uboot-mxs/Makefile b/package/boot/uboot-mxs/Makefile
index a6a137c..eee73d2 100644
--- a/package/boot/uboot-mxs/Makefile
+++ b/package/boot/uboot-mxs/Makefile
@@ -77,7 +77,7 @@ endef
 
 define Package/uboot/install/default
$(INSTALL_DIR) $(BIN_DIR)/uboot-$(BOARD)-$(1)
-   dd if=$(PKG_BUILD_DIR)/u-boot.sb 
of=$(BIN_DIR)/uboot-$(BOARD)-$(1)/uboot-$(BOARD)-$(1).sb bs=512 seek=4
+   $(CP) $(PKG_BUILD_DIR)/u-boot.sb 
$(BIN_DIR)/uboot-$(BOARD)-$(1)/uboot-$(BOARD)-$(1).sb
 endef
 
 define Package/uboot/install/template
-- 
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] r46816, remove unused crypt() algorithms -> switch to sha512?

[Felix Fietkau]

On 2015-09-15 00:22, Etienne Champetier wrote:
> Hi Felix,
> 
> Maybe we should keep sha512 and switch to it? md5 is not best security
> practice these days.
I don't see the point. It's true that for file integrity purposes, md5
is weaker than sha512, but for salted passwords it should not make much
of a practical difference. Cryptographic attacks against MD5 don't work
here, brute force is still the fastest way to crack those.

> I've checked, ubuntu 14.04 and fedora 22 both use sha512 in /etc/shadow
Not a very convincing reason for me. The impractical aspect of switching
password hashing algorithms is that we then need to support both the new
one and the old one for a long time.

> I wonder if AF_ALG can be of any interest here (integrate needed algo by
> default into the kernel, then patch core software to use kernel
> implementation)
That would just make it more bloated without making any real practical
difference. This approach would be especially bad for CPU intensive
crypto if the kernel can only do software crypto. In that case bouncing
between kernel and user space would waste many CPU cycles.

> To conclude maybe you should emit a clear error when we try a now
> unsupported hash,
> because crypt can be used by other app, so maybe you just broke another
> app and someone will waste a good amount of time debugging it
I don't think anything's using crypt() with a custom generated non-md5
salt. Most programs that store password hashes simply do their own crypto.

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

[OpenWrt-Devel] [PATCH v2 3/7] packages: uboot-mxs: bless UBOOT_IMAGE with a meaning, otherwise we could drop this C left-over

[Michael Heimpold]

Signed-off-by: Michael Heimpold 
---

Changes in v2:
- none

 package/boot/uboot-mxs/Makefile |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/boot/uboot-mxs/Makefile b/package/boot/uboot-mxs/Makefile
index eee73d2..373b8d8 100644
--- a/package/boot/uboot-mxs/Makefile
+++ b/package/boot/uboot-mxs/Makefile
@@ -62,7 +62,7 @@ endef
 ifdef BUILD_VARIANT
 $(eval $(call uboot/$(BUILD_VARIANT)))
 UBOOT_CONFIG:=$(if $(CONFIG),$(CONFIG),$(BUILD_VARIANT))
-UBOOT_IMAGE:=$(if 
$(IMAGE),$(IMAGE),openwrt-$(BOARD)-$(BUILD_VARIANT)-u-boot.bin)
+UBOOT_IMAGE:=$(if $(IMAGE),$(IMAGE),u-boot.sb)
 endif
 
 define Build/Configure
@@ -72,12 +72,12 @@ endef
 
 define Build/Compile
$(MAKE) -C $(PKG_BUILD_DIR) \
-   CROSS_COMPILE=$(TARGET_CROSS) u-boot.sb
+   CROSS_COMPILE=$(TARGET_CROSS) $(UBOOT_IMAGE)
 endef
 
 define Package/uboot/install/default
$(INSTALL_DIR) $(BIN_DIR)/uboot-$(BOARD)-$(1)
-   $(CP) $(PKG_BUILD_DIR)/u-boot.sb 
$(BIN_DIR)/uboot-$(BOARD)-$(1)/uboot-$(BOARD)-$(1).sb
+   $(CP) $(PKG_BUILD_DIR)/$(UBOOT_IMAGE) 
$(BIN_DIR)/uboot-$(BOARD)-$(1)/uboot-$(BOARD)-$(1).sb
 endef
 
 define Package/uboot/install/template
-- 
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 5/7] packages: uboot-mxs: fix I2SE Duckbill variant

[Michael Heimpold]

The current patch to add Duckbill support is wrong and does not
even compile. So replace this patch with a working one.

Signed-off-by: Michael Heimpold 
---

Changes in v2:
- none

 .../uboot-mxs/patches/001-add-i2se-duckbill.patch  |   82 +++-
 1 file changed, 46 insertions(+), 36 deletions(-)

diff --git a/package/boot/uboot-mxs/patches/001-add-i2se-duckbill.patch 
b/package/boot/uboot-mxs/patches/001-add-i2se-duckbill.patch
index 30bb840..f410b19 100644
--- a/package/boot/uboot-mxs/patches/001-add-i2se-duckbill.patch
+++ b/package/boot/uboot-mxs/patches/001-add-i2se-duckbill.patch
@@ -1,20 +1,20 @@
-From 201bd7bba4a7c08c49d4ec36da651eec1c3d156b Mon Sep 17 00:00:00 2001
+From 4d9a32780ec795b9edc83c7b3a1e947cec49a5a4 Mon Sep 17 00:00:00 2001
 From: Michael Heimpold 
-Date: Mon, 24 Nov 2014 23:29:30 +0100
+Date: Sat, 15 Aug 2015 20:26:18 +0200
 Subject: [PATCH] Add support for I2SE Duckbill boards
 
 Signed-off-by: Michael Heimpold 
 ---
- arch/arm/Kconfig  |   6 ++
- arch/arm/include/asm/mach-types.h |  14 +++
- board/i2se/duckbill/Kconfig   |  15 
- board/i2se/duckbill/MAINTAINERS   |   6 ++
- board/i2se/duckbill/Makefile  |  12 +++
- board/i2se/duckbill/duckbill.c| 103 +
- board/i2se/duckbill/iomux.c   | 125 ++
- configs/duckbill_defconfig|   4 +
- include/configs/duckbill.h| 183 ++
- 9 files changed, 468 insertions(+)
+ arch/arm/Kconfig  |6 ++
+ arch/arm/include/asm/mach-types.h |   13 +++
+ board/i2se/duckbill/Kconfig   |   15 
+ board/i2se/duckbill/MAINTAINERS   |6 ++
+ board/i2se/duckbill/Makefile  |   12 +++
+ board/i2se/duckbill/duckbill.c|  112 +++
+ board/i2se/duckbill/iomux.c   |  125 ++
+ configs/duckbill_defconfig|9 ++
+ include/configs/duckbill.h|  177 +
+ 9 files changed, 475 insertions(+)
  create mode 100644 board/i2se/duckbill/Kconfig
  create mode 100644 board/i2se/duckbill/MAINTAINERS
  create mode 100644 board/i2se/duckbill/Makefile
@@ -24,22 +24,22 @@ Signed-off-by: Michael Heimpold 
  create mode 100644 include/configs/duckbill.h
 
 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
-index 5eb1d03..03ffb99 100644
+index 9908b43..7c795ac 100644
 --- a/arch/arm/Kconfig
 +++ b/arch/arm/Kconfig
-@@ -293,6 +293,11 @@ config TARGET_MX28EVK
+@@ -178,6 +178,11 @@ config TARGET_MX28EVK
select CPU_ARM926EJS
select SUPPORT_SPL
  
 +config TARGET_DUCKBILL
-+  bool "I2SE Duckbill"
++  bool "Support I2SE Duckbill"
 +  select CPU_ARM926EJS
 +  select SUPPORT_SPL
 +
  config TARGET_MX23_OLINUXINO
bool "Support mx23_olinuxino"
select CPU_ARM926EJS
-@@ -922,6 +927,7 @@ source "board/genesi/mx51_efikamx/Kconfig"
+@@ -926,6 +931,7 @@ source "board/genesi/mx51_efikamx/Kconfig"
  source "board/gumstix/pepper/Kconfig"
  source "board/h2200/Kconfig"
  source "board/hale/tt01/Kconfig"
@@ -48,19 +48,18 @@ index 5eb1d03..03ffb99 100644
  source "board/imx31_phycore/Kconfig"
  source "board/isee/igep0033/Kconfig"
 diff --git a/arch/arm/include/asm/mach-types.h 
b/arch/arm/include/asm/mach-types.h
-index d4a447b..5c71573 100644
+index 5afe791..330a88d 100644
 --- a/arch/arm/include/asm/mach-types.h
 +++ b/arch/arm/include/asm/mach-types.h
-@@ -1108,6 +1108,8 @@ extern unsigned int __machine_arch_type;
+@@ -1109,6 +1109,7 @@ extern unsigned int __machine_arch_type;
  #define MACH_TYPE_COLIBRI_T30  4493
  #define MACH_TYPE_APALIS_T30   4513
  #define MACH_TYPE_OMAPL138_LCDK2495
 +#define MACH_TYPE_DUCKBILL 4754
-+
  
  #ifdef CONFIG_ARCH_EBSA110
  # ifdef machine_arch_type
-@@ -14261,6 +14263,18 @@ extern unsigned int __machine_arch_type;
+@@ -14262,6 +14263,18 @@ extern unsigned int __machine_arch_type;
  # define machine_is_apalis_t30()  (0)
  #endif
  
@@ -132,10 +131,10 @@ index 000..b5577e3
 +endif
 diff --git a/board/i2se/duckbill/duckbill.c b/board/i2se/duckbill/duckbill.c
 new file mode 100644
-index 000..3fa3ddb
+index 000..7794f65
 --- /dev/null
 +++ b/board/i2se/duckbill/duckbill.c
-@@ -0,0 +1,103 @@
+@@ -0,0 +1,112 @@
 +/*
 + * I2SE Duckbill board
 + *
@@ -221,6 +220,15 @@ index 000..3fa3ddb
 +
 +  return ret;
 +}
++
++void mx28_adjust_mac(int dev_id, unsigned char *mac)
++{
++  mac[0] = 0x00;
++  mac[1] = 0x01;
++
++  if (dev_id == 1) /* Let MAC1 be MAC0 + 1 by default */
++  mac[5] += 1;
++}
 +#endif
 +
 +int misc_init_r(void)
@@ -372,22 +380,27 @@ index 000..538e138
 +}
 diff --git a/configs/duckbill_defconfig b/configs/duckbill_defconfig
 new file mode 100644
-index 000..d86f5e2
+index 000..2edf895
 --- /dev/null
 +++ b/configs/duckbill_defconfig
-@@ -0,0 +1,4 @@
+@@ -0,0 +1,9 @@
++CONFIG_ARM=y

[OpenWrt-Devel] [PATCH v2 4/7] target/mxs: adopt SD card generation to fixed U-Boot path

[Michael Heimpold]

Signed-off-by: Michael Heimpold 
---

Changes in v2:
- none

 target/linux/mxs/image/Makefile |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/mxs/image/Makefile b/target/linux/mxs/image/Makefile
index 256d4e6..7e6a1a0 100644
--- a/target/linux/mxs/image/Makefile
+++ b/target/linux/mxs/image/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2013 OpenWrt.org
+# Copyright (C) 2013-2015 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -57,7 +57,7 @@ define Image/Build/SDCard
$(KDIR)/root.$(1) \
$(CONFIG_MXS_SD_BOOT_PARTSIZE) \
$(CONFIG_TARGET_ROOTFS_PARTSIZE) \
-   $(BIN_DIR)/uboot-mxs-$(3).sb
+   $(BIN_DIR)/uboot-mxs-$(3)/uboot-mxs-$(3).sb
 endef
 
 define Image/Build/Profile/olinuxino-maxi
-- 
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 6/7] tools: add sdimage (for mxs target)

[Michael Heimpold]

This tool is used for SD card generation on Freescale i.MX23/i.MX28
platforms. These CPU's ROM need a tiny header of front of a boot stream.

Signed-off-by: Michael Heimpold 
---

Changes in v2:
- new patch

 tools/Makefile |2 +-
 tools/sdimage/Makefile |   37 +
 2 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 tools/sdimage/Makefile

diff --git a/tools/Makefile b/tools/Makefile
index dda429f..df384d4 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -31,7 +31,7 @@ tools-y += mm-macros missing-macros xz cmake scons bc 
findutils gengetopt patche
 tools-$(CONFIG_TARGET_orion_generic) += wrt350nv2-builder upslug2
 tools-$(CONFIG_powerpc) += upx
 tools-$(CONFIG_TARGET_x86) += qemu
-tools-$(CONFIG_TARGET_mxs) += elftosb
+tools-$(CONFIG_TARGET_mxs) += elftosb sdimage
 tools-$(CONFIG_TARGET_brcm2708)$(CONFIG_TARGET_sunxi)$(CONFIG_TARGET_mxs) += 
mtools dosfstools
 tools-$(CONFIG_TARGET_ar71xx) += lzma-old squashfs
 tools-y += lzma squashfs4
diff --git a/tools/sdimage/Makefile b/tools/sdimage/Makefile
new file mode 100644
index 000..e590417
--- /dev/null
+++ b/tools/sdimage/Makefile
@@ -0,0 +1,37 @@
+#
+# Copyright (C) 2015 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=imx-uuc
+PKG_VERSION=2015-09-13-$(PKG_SOURCE_VERSION)
+PKG_RELEASE:=1
+
+PKG_SOURCE_PROTO:=git
+PKG_SOURCE_URL:=https://github.com/mhei/fsl-imx-uuc.git
+PKG_SOURCE_VERSION:=2b99403b6dc60a22b07eb7a5cc0cb184abb89bdd
+PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_SOURCE_VERSION)
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_SOURCE_VERSION).tar.bz2
+
+PKG_LICENSE:=GPL-2.0+
+PKG_LICENSE_FILES:=LICENSE
+
+HOST_BUILD_DIR:=$(BUILD_DIR_HOST)/$(PKG_SOURCE_SUBDIR)
+
+include $(INCLUDE_DIR)/host-build.mk
+
+define Host/Configure
+endef
+
+define Host/Install
+   $(INSTALL_BIN) $(HOST_BUILD_DIR)/sdimage $(STAGING_DIR_HOST)/bin/sdimage
+endef
+
+define Host/Clean
+   rm -f $(STAGING_DIR_HOST)/bin/sdimage
+endef
+
+$(eval $(call HostBuild))
-- 
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH procd v2 0/5] jail work

[Etienne Champetier]

hi,

2015-08-27 13:38 GMT+02:00 John Crispin :

>
>
> On 27/08/2015 13:25, Etienne Champetier wrote:
> >
> >
> > 2015-08-27 12:18 GMT+02:00 John Crispin  > >:
> >
> >
> >
> > On 26/08/2015 18:20, Etienne Champetier wrote:
> > >
> > >
> > > 2015-08-26 15:48 GMT+02:00 John Crispin  
> > > >>:
> > >
> > > On 26/08/2015 01:00, Etienne CHAMPETIER wrote:
> > > > This patch series rework a bit ujail,
> > > > and add capabilities support to it
> > >
> > > nice
> > >
> > > >
> > > > Seccomp filter are very powerful but not totally generic,
> > > > each arch can have different set of syscalls,
> > > > each libc can use different syscall for the same function,
> > > > and seccomp isn't supported on all arch.
> > > >
> > > > Capabilities are more high level, but still can restrict
> > > > jail to a sane minimum of privileges.
> > >
> > > >
> > > > Patch 4 is a bit big and i can split it if needed, just tell
> me how
> > >
> > > will have a closer look next few days
> > >
> > > forgot to say it's tested on ar71xx with CC (and also on ubuntu
> 14.04)
> > >
> > > there seem to be a way to escape from the rebind mount jail
> that QCA has
> > > found
> > >
> > > more than one ;) can you share? (with root rights you can kexec,
> mount
> > > /dev, ...)
> >
> > well if you are root you are root and can delete the bootloader. the
> > idea of the jail is that you are not root.
> >
> >
> > Totaly disagree on that.
> > Many core program need 1 or a few capabilities, but don't start if you
> > are not root
> > take for exemple busybox ntpd,
> > http://git.busybox.net/busybox/tree/networking/ntpd.c#n2122
> > i'm pretty sure it only need CAP_SYS_TIME, but it check for root rights
> :)
> >
> > root give you 2 things:
> > all the capabilities,
> > read write access on root file
> > there is no uid==0 in the kernel, only capabilities check
> >
> > If you drop all capabilities, root is a normal user,
> > with the exception that he is in general the owner of most or all the
> file
> > (that's when namespaces come into play)
> >
> > For me the idea of the jail is to restrict the daemon as much as
> possible,
> > without patching it, so if it need to be root ...
> >
>
>
> we just need support for the USERNS. i think but there will always be
> apps that refuse to start if !root.
>
> i had already added !root support to ubus using ACLs. this allows us to
> run at least all the openwrt services in the jail as !root
>
> so lets assume that we can run the majority of apps as !root but i agree
> that for the left overs we can implement CAPS support and we also need
> CGROUPS support i think. i hjope that i have time at the end of the year
> or start of 2016 to add all these.
>
> i think that we should always try to run as !root and only use real root
> if there is no technical way to avoid this (and patching lots of
> services is not a solution, as in remove the root check form ntp)
>
>
> >
> > i will prvide details later on
> >
> > cool
> >
> >
> >
> > > that's why you really need to limit rights with capabilities drop
> or
> > > seccomp filter
> > > (i'm adding a vague warning in usage)
> >
> > why do you want to run a privileged user and restrict is perms rather
> > than just use an unprivileged user ?
> >
> > see comment before
> >
> >
> >
> > >
> > >
> > > and i have not had the time yet to finish my jailfs module.
> > >
> > > with my patches you don't see all the bind mount anymore ("in the
> host"),
> > > they are only in the jail mount namespace.
> > >
> > > to see the mounts inside the jail you can still do
> > > cat /proc//mounts
> >
> > we dont want rebind mounts at all, they were only an intermediate
> > solution
> >
> >
> > why? what's the problem with rebind mounts?
> > It work for me TM :)
> >
>
> sure we were also able to boot linux using shell scripts but the current
> c  code is nicer i think. having a filesystem level implementation seems
> much more powerful and clean to me.
>
> >
> >
> > >
> > > it
> > > runs and loads, i can do mounts and access files inside them
> using
> > > normal shell calls. however if is point a jail instance at the
> > > mountpoint it oops horribly. i suspect that i am either using
> vfs wrong
> > > or am missing locking/ref-counting somewhere. i'll throw the
> code onto
> > > github later today or tomorrow and post the link. maybe
> someone with
> > > more knowledge of vfs can help fix it.
> > >
> > > what problem are you fixing with jailfs? (real question/to be sure
> there
> > > is no 

Re: [OpenWrt-Devel] [PATCH] AP121 target: fix board detection in ar71xx.sh

[John Crispin]

On 31/08/2015 12:58, Attila Lendvai wrote:
> hi!
> 
> resending this patch properly, including a signed-off entry.
> 
> it would be nice if this could make its way into CC, because this
> fixes a regression.
> 
> the obsolete copy is this: https://patchwork.ozlabs.org/patch/508527/
> 
> 

Hi,

the patch needs to be sent inline. the email needs to have the subject
and description that is currently int he attachment.

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

Re: [OpenWrt-Devel] [PATCH procd v2 0/5] jail work

[John Crispin]

On 15/09/2015 00:11, Etienne Champetier wrote:
> 
> Just some random stuffs:
> 
> -new in kernel 4.3: ambient capabilities (great explanation in the commits)
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=58319057b7847667f0c9585b9de0e8932b0fdb08
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=746bf6d64275be0c65b0631d8a72b16f1454cfa1
> This allow to keep capabilities across execve, without being root,
> so if i've understood it right, i can launch a program as nobody, give
> him CAP_NET_ADMIN, and this program can execve 'ip', and we can make it
> work \o/
> 
> -userns are a bit more complicated to setup, but there is great exemples
> in https://github.com/netblue30/firejail
> 
> -I'll definitly give jailfs a try, but since it's there to add security,
> it think it would be great to send it upstream for review before we use
> it for everyone
> 
> -I don't know the performance overhead of cgroup, but memory cgroup
> could be really great for "hungry" softwares like transmission
> 
> -And for caps, my patches should do the trick
> 
> -we should add an option to set PR_SET_NO_NEW_PRIVS (if we don't use
> seccomp),
> another option to switch user,
> another to launch with strace (/etc/init.d/ strace),
> (and also we need to write the glue code to use all this from the init
> scripts)
> 
> Good night


before adding anything new i will dig through the patches currently
sitting in the queue. once those are in the tree we can see what the
next steps are. i'll also try to throw the jailfs patches on github
today. with the release out the door i now have some free time again.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] uci: add import call

[John Crispin]

Hi,

SoB is missing and  

On 02/09/2015 02:14, Alexander Couzens wrote:
> similiar to import from uci cli.
> import removes all old configs and import the new config.
> 
> example:
> ubus call uci import \
>   '{"config": "dhcp", "values": { "srv": { ".type": "host", ".name": "srv", 
> "mac": "00:11:22:33:44:55", "ip": "192.168.1.2" } } }'
> ---
>  uci.c | 152 
> ++
>  1 file changed, 152 insertions(+)
> 
> changelog:
> - cleanup whitespace/tab indention
> - add {} around to make it more readable
> - implement same coding style than file.c
> 
> diff --git a/uci.c b/uci.c
> index 8b5dafd..c59f24d 100644
> --- a/uci.c
> +++ b/uci.c
>   */
> @@ -659,8 +691,10 @@ rpc_uci_add(struct ubus_context *ctx, struct ubus_object 
> *obj,
>   {
>   case BLOBMSG_TYPE_ARRAY:
>   blobmsg_for_each_attr(elem, cur, rem2)
> + {
>   if (rpc_uci_format_blob(elem, 
> ))
>   uci_add_list(cursor, );
> + }
>   break;
>  


.. this is either unrelated or important, so please remove or explain it

John











>   default:
> @@ -729,6 +763,123 @@ rpc_uci_merge_set(struct blob_attr *opt, struct uci_ptr 
> *ptr)
>  }
>  
>  static int
> +rpc_uci_add_section(struct uci_package *p, struct blob_attr *msg)
> +{
> + struct uci_section *s;
> + struct uci_ptr ptr = { 0 };
> + struct blob_attr *cur, *elem;
> + struct blob_attr *tb[__RPC_ADD_MAX];
> + int rem, rem2;
> +
> + blobmsg_parse(rpc_uci_add_section_policy, __RPC_ADD_MAX, tb,
> +   blobmsg_data(msg), blobmsg_len(msg));
> +
> + ptr.package = p->e.name;
> +
> + if (!tb[RPC_ADD_TYPE])
> + goto out;
> +
> + /* add named section */
> + if (tb[RPC_ADD_NAME])
> + {
> + ptr.section = blobmsg_data(tb[RPC_ADD_NAME]);
> + ptr.value = blobmsg_data(tb[RPC_ADD_TYPE]);
> + ptr.option = NULL;
> +
> + if (rpc_uci_lookup() || uci_set(cursor, ))
> + goto out;
> + } else {
> + if (uci_add_section(cursor, p, blobmsg_data(tb[RPC_ADD_TYPE]), 
> ) || !s)
> + goto out;
> +
> + ptr.section = s->e.name;
> + }
> +
> + blobmsg_for_each_attr(cur, msg, rem)
> + {
> + if (!strcmp(blobmsg_name(cur), ".type") ||
> + !strcmp(blobmsg_name(cur), ".anonymous") ||
> + !strcmp(blobmsg_name(cur), ".name") ||
> + !strcmp(blobmsg_name(cur), ".index"))
> + continue;
> + ptr.o = NULL;
> + ptr.option = blobmsg_name(cur);
> +
> + if (rpc_uci_lookup() || !ptr.s)
> + continue;
> +
> + switch (blobmsg_type(cur))
> + {
> + case BLOBMSG_TYPE_ARRAY:
> + blobmsg_for_each_attr(elem, cur, rem2)
> + if (rpc_uci_format_blob(elem, 
> ))
> + uci_add_list(cursor, );
> + break;
> +
> + default:
> + if (rpc_uci_format_blob(cur, ))
> + uci_set(cursor, );
> + break;
> + }
> + }
> +
> + return 0;
> +out:
> + return 1;
> +}
> +
> +/* blobmsg example: { "wan": { ".type": "interface", ".name":"wan", 
> ".anonymous": false }, .. } */
> +static int
> +rpc_uci_import(struct ubus_context *ctx, struct ubus_object *obj,
> +struct ubus_request_data *req, const char *method,
> +struct blob_attr *msg)
> +{
> + struct blob_attr *tb[__RPC_I_MAX];
> + struct blob_attr *cur;
> + struct uci_package *p = NULL;
> + struct uci_element *e, *tmp;
> + struct uci_ptr ptr = { 0 };
> + int rem;
> +
> +
> + blobmsg_parse(rpc_uci_import_policy, __RPC_I_MAX, tb,
> + blob_data(msg), blob_len(msg));
> +
> + if (!tb[RPC_I_CONFIG] || !tb[RPC_I_VALUES])
> + return UBUS_STATUS_INVALID_ARGUMENT;
> +
> + if (!rpc_uci_write_access(tb[RPC_I_SESSION], tb[RPC_I_CONFIG]))
> + return UBUS_STATUS_PERMISSION_DENIED;
> +
> + ptr.package = blobmsg_data(tb[RPC_I_CONFIG]);
> +
> + if (uci_load(cursor, ptr.package, ))
> + return rpc_uci_status();
> +
> + /* delete all section within package */
> + uci_foreach_element_safe(>sections, tmp, e)
> + {
> + ptr.s = NULL;
> + ptr.section = e->name;
> + rpc_uci_merge_delete(NULL, );
> + }
> +
> + /* add new sections */
> + blobmsg_for_each_attr(cur, tb[RPC_I_VALUES], rem)
> + {
> + if 

Re: [OpenWrt-Devel] [PATCH] extra configuration options for OpenVPN in init script

[John Crispin]

On 28/08/2015 15:27, François Kooman wrote:
> Hi Mirko,
> 
> To accompany my patch to the OpenVPN configuration module for luci [0]
> to support some extra fields here also the change to the OpenVPN init
> script.
> 
> It adds the following fields:
> 
> tls_version_min
> tls_version_max
> key_direction
> 
> They are needed to support "eduVPN" [1]. The change here is not
> depending on the change in [0] so can be done without any side effect.
> 
> Thanks in advance for your consideration.
> 
> Cheers,
> François


Hi,

this package is maintained on github. please send a properly formatted
PR via github. also you patch is missing the SoB line and it is attached
and not inline.

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

Re: [OpenWrt-Devel] [PATCH] [package] firewall: Adds support for IPv6 DNAT, SNAT, and REDIRECT

[Timothy Ace]

I've created a fork of the firewall3 git repo at git://nbd.name/firewall3.git 
on github repo, that contains this patch, for easier pulling:

Please see: https://github.com/ecammit/firewall3

> On Aug 13, 2015, at 1:58 PM, Timothy Ace  wrote:
> 
> From: Timothy Ace 
> 
> Adds support for IPv6 DNAT, SNAT, and REDIRECT.
> 
> Signed-off-by: Timothy Ace 
> ---
> This is a git patch for the firewall3 git repo at git://nbd.name/firewall3.git
> 
> Note1: Luci updates still need to be made in a separate patch to support IPv6 
> address entry on the port forwards page, but this works using manual entries 
> in /etc/config/firewall for now.
> 
> Note2: I changed the section in compare_addr() from this:
> 
> - return ((a->address.v4.s_addr & a->mask.v4.s_addr) ==
> - (b->address.v4.s_addr & a->mask.v4.s_addr));
> 
> to this:
> 
> + return ((a->address.v4.s_addr & a->mask.v4.s_addr) ==
> + (b->address.v4.s_addr & b->mask.v4.s_addr));
> 
> ... because using "a->mask" instead of "b->mask" on the second line looked 
> wrong to me. Please let me know if that was intentional and I'll re-submit a 
> patch that accounts for that change for the v4 and new v6 sections.
> 
> 
> From 83cdcf604b8c81c75065a91f50459721e87740b0 Mon Sep 17 00:00:00 2001
> From: Timothy Ace 
> Date: Thu, 13 Aug 2015 00:28:02 -0400
> Subject: [PATCH] Adds support for IPv6 DNAT, SNAT, and REDIRECT
> 
> ---
> defaults.c  |  8 
> redirects.c | 42 ++
> snats.c |  1 +
> ubus.c  | 24 
> utils.c | 10 --
> zones.c | 13 -
> 6 files changed, 75 insertions(+), 23 deletions(-)
> 
> diff --git a/defaults.c b/defaults.c
> index 396cbf7..45d6de6 100644
> --- a/defaults.c
> +++ b/defaults.c
> @@ -32,10 +32,10 @@ static const struct fw3_chain_spec default_chains[] = {
>   C(ANY, FILTER, CUSTOM_CHAINS, "forwarding_rule"),
>   C(ANY, FILTER, SYN_FLOOD, "syn_flood"),
> 
> - C(V4,  NAT,UNSPEC,"delegate_prerouting"),
> - C(V4,  NAT,UNSPEC,"delegate_postrouting"),
> - C(V4,  NAT,CUSTOM_CHAINS, "prerouting_rule"),
> - C(V4,  NAT,CUSTOM_CHAINS, "postrouting_rule"),
> + C(ANY, NAT,UNSPEC,"delegate_prerouting"),
> + C(ANY, NAT,UNSPEC,"delegate_postrouting"),
> + C(ANY, NAT,CUSTOM_CHAINS, "prerouting_rule"),
> + C(ANY, NAT,CUSTOM_CHAINS, "postrouting_rule"),
> 
>   C(ANY, MANGLE, UNSPEC,"mssfix"),
>   C(ANY, MANGLE, UNSPEC,"fwmark"),
> diff --git a/redirects.c b/redirects.c
> index 5b8d7a9..0751e93 100644
> --- a/redirects.c
> +++ b/redirects.c
> @@ -116,11 +116,26 @@ check_families(struct uci_element *e, struct 
> fw3_redirect *r)
> static bool
> compare_addr(struct fw3_address *a, struct fw3_address *b)
> {
> - if (a->family != FW3_FAMILY_V4 || b->family != FW3_FAMILY_V4)
> + if (a->family != b->family)
>   return false;
> 
> - return ((a->address.v4.s_addr & a->mask.v4.s_addr) ==
> - (b->address.v4.s_addr & a->mask.v4.s_addr));
> + if (a->family == FW3_FAMILY_V4)
> + {
> + return ((a->address.v4.s_addr & a->mask.v4.s_addr) ==
> + (b->address.v4.s_addr & b->mask.v4.s_addr));
> + }
> + else if (a->family == FW3_FAMILY_V6)
> + {
> + int i;
> + for (i = 0; i < 16; i++)
> + {
> + if ((a->address.v6.s6_addr[i] & a->mask.v6.s6_addr[i]) 
> !=
> + (b->address.v6.s6_addr[i] & b->mask.v6.s6_addr[i]))
> + return false;
> + }
> + return true;
> + }
> + return false;
> }
> 
> static bool
> @@ -278,6 +293,7 @@ fw3_load_redirects(struct fw3_state *state, struct 
> uci_package *p)
>   else
>   {
>   set(redir->_src->flags, FW3_FAMILY_V4, 
> redir->target);
> + set(redir->_src->flags, FW3_FAMILY_V6, 
> redir->target);
>   redir->_src->conntrack = true;
>   valid = true;
> 
> @@ -293,6 +309,9 @@ fw3_load_redirects(struct fw3_state *state, struct 
> uci_package *p)
>   set(redir->_dest->flags, FW3_FAMILY_V4, 
> FW3_FLAG_ACCEPT);
>   set(redir->_dest->flags, FW3_FAMILY_V4, 
> FW3_FLAG_DNAT);
>   set(redir->_dest->flags, FW3_FAMILY_V4, 
> FW3_FLAG_SNAT);
> + set(redir->_dest->flags, FW3_FAMILY_V6, 
> FW3_FLAG_ACCEPT);
> + set(redir->_dest->flags, FW3_FAMILY_V6, 
> FW3_FLAG_DNAT);
> + set(redir->_dest->flags, FW3_FAMILY_V6, 
> 

[OpenWrt-Devel] Question about openwrt release revision

[pupie]

Hello everyone,
I am so glad that openwrt 15.05 has been release.

I noticed that since AA release, openwrt team neither tag the source tree
in subversion/git after an official release nor provide the revision/commit
sha-1 along with release note.
I just want to know where can I get this info and why this is not provided
officially?
Per my understanding to release procedure in some opensource projects,
developers tag source tree with referential info/version number so that
downstream followers can precisely checkout that snapshot of source from
which the release image is built.

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

Re: [OpenWrt-Devel] Question about openwrt release revision

[John Crispin]

On 14/09/2015 09:34, pupie wrote:
> Hello everyone,
> I am so glad that openwrt 15.05 has been release.
> 
> I noticed that since AA release, openwrt team neither tag the source
> tree in subversion/git after an official release nor provide the
> revision/commit sha-1 along with release note.
> I just want to know where can I get this info and why this is not
> provided officially?
> Per my understanding to release procedure in some opensource projects,
> developers tag source tree with referential info/version number so that
> downstream followers can precisely checkout that snapshot of source from
> which the release image is built.
> 
> thanks
> pupie

i'll get the list ready today. i was busy fixing up the missing images
fromt he IB run which are rsyncing just now. once that is done i will
get the list of exact commits used from the release branch and the feeds.




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

Re: [OpenWrt-Devel] OpenWRT www version banner a security risk

[Etienne Champetier]

Hi,

Le 14 sept. 2015 06:36, "Daniel Dickinson"  a
écrit :
>
> On 2015-09-14 12:30 AM, Daniel Dickinson wrote:
>>
>> On 2015-09-13 11:39 PM, Florian Fainelli wrote:
>>>
>>> On Sep 13, 2015 2:00 PM, "Etienne Champetier"
>>> >
>>> wrote:
>>>  >
>>>  > Hi Daniel,
>>>  >
>>>  > Le 13 sept. 2015 22:04, "Daniel Dickinson"
>>> > a
>>> écrit :
>>>  > >
>>>  > > I do think allowing to choose to disable the banner is a minor
>>> benefit, however, as I've said, there are much more effective means of
>>> preventing accidential exposure, and quite frankly if the user is
>>> *choosing* to open the web interface I think an warning and disabling
>>> the banner if the user foolishly insists on opening the interface
>>> despite the warning is more useful thank disabling the banner by
default.
>>>  > >
>>>  > > If you're going to argue it prevents against internal threats than
>>> I would argue that if your internal network is hostile enough that you
>>> need to worry about attacks on openwrt from your internal network AND
>>> you're not skilled enough to limit access to LuCI (or better, build an
>>> image without LuCI and just use SSH) to the specific trusted hosts
>>> (preferably by combination of MAC address and IP address) in the
>>> firewall, or (better) to use a 'management' VPN or VLAN that only
>>> trusted hosts can get on, then you're in a lot more trouble than
>>> eliminating the banner for LuCI will solve.
>>>  > >
>>>  > >
>>>  > > Regards,
>>>  > >
>>>  > > Daniel
>>>  > >
>>>  > > On 2015-09-13 10:21 AM, MauritsVB wrote:
>>>  > >>
>>>  > >> At the moment the OpenWRT www login screen provides *very*
>>> detailed version information before anyone has even entered a password.
>>> It displays not just “15.05” or “Chaos Calmer” but even the exact git
>>> version on the banner.
>>>  > >>
>>>  > >> While it’s not advised to open this login screen to the world,
>>> fact is that it does happen intentionally or accidentally. Just a Google
>>> search for “Powered by LuCI Master (git-“ will provide many accessible
>>> OpenWRT login screens, including exact version information.
>>>  > >>
>>>  > >> As soon as someone discovers a vulnerability in a OpenWRT version
>>> all an attacker needs to do is perform a Google search to find many
>>> installations with versions that are vulnerable (even if a patch is
>>> already available).
>>>  > >>
>>>  > >> In the interest of hardening the default OpenWRT install, can I
>>> suggest that by default OpenWRT doesn’t disclose the version (not even
>>> 15.05 or “Chaos Calmer”) on the login screen? For extra safety I would
>>> even suggest to leave “OpenWRT” off the login screen, the only people
>>> who should use this screen already know it’s running OpenWRT.
>>>  > >>
>>>  > >> Any thoughts?
>>>  > >>
>>>  > >> Maurits
>>>  > >>
>>>  >
>>>  > For me listenning only on lan will break all my setups (15+):
>>>  > - On most of my openwrt there is no lan, it's management, or
>>> 'name-of-the-site' ...
>>>  > - on some of them i can access from multiple interface (VPNs + ...)
>>>  >
>>>  > You can't prevent people from shooting themselves in the foot (maybe
>>> port openning was on purpose),
>>>  > but you can:
>>>  > -Put a huge warning in luci when you set firewall default to 'ACCEPT'
>>>  > -add robots.txt (i think the router will still end up on shodan)
>>>  > -add a big warning if robots.txt is accessed (reliable way to know
>>> that you're open on the internet)
>>>  >
>>>  > Also you are talking about luci but what about dropbear (ssh)? There
>>> is no anti brute force, and maybe there is a banner (on my phone, can't
>>> check)
>>>
>>> For that you could setup different things ranging from using iptables'
>>> mlimit match per protocol all the way to having something like fail2ban
>>> (written in python though) which can do more complex
>>> blacklisting/blackholing.
>>>
>>> All of that is more of a security policy that you deploy rather than
>>> want it by default, even though it may seem very sensible for a default
>>> use case.
>>>
>>> The bottom line is that if you are exposed to the wild internet, just
>>> brace yourself, it is only a matter of time before your host gets
>>> scanned, brute forced or even penetrated.
>>
>>
>> Hence my suggestion to make the default configuration luci and ssh on
>> lan only.  If that doesn't work because you're changing the network
>> config then you're already making configuration changes, it's not that
>> much harder to also change the ssh and luci config (although perhaps it
>> would be useful for this, and for other 'tied' configs (sorry can't
>> think of an example right now, but there are a few times where I've
>> thought it would have been convenient) to have some sort of unified
>> interface for changing all relevant sections at once; I'm not sure that
>> kind of thing is worth the 

Re: [OpenWrt-Devel] i2c device not in /dev

[Daniel Golle]

On Mon, Sep 14, 2015 at 07:47:08PM +0200, John Crispin wrote:
> On 14/09/2015 19:28, Baptiste Clenet wrote:
> > Hi,
> > 
> > I'm using a MT7628 chip and I try to implement an I2C device which
> > will use i2c-ralink adapter. I registered my i2c device with
> > module_i2c_driver(i2c_device_driver);
> > 
> > I can see it on my bus:
> > ./sys/bus/i2c/drivers/i2c_device_driver
> > But it doesn't appear in /dev.
> > 
> > What am I doing wrong?
> > 
> > Regards,
> > 
> 
> you are missing CONFIG_I2C_CHARDEV in the kernel config

or maybe i2c-dev isn't loaded? try
modprobe i2c-dev
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] i2c device not in /dev

[John Crispin]

On 14/09/2015 19:28, Baptiste Clenet wrote:
> Hi,
> 
> I'm using a MT7628 chip and I try to implement an I2C device which
> will use i2c-ralink adapter. I registered my i2c device with
> module_i2c_driver(i2c_device_driver);
> 
> I can see it on my bus:
> ./sys/bus/i2c/drivers/i2c_device_driver
> But it doesn't appear in /dev.
> 
> What am I doing wrong?
> 
> Regards,
> 

you are missing CONFIG_I2C_CHARDEV in the kernel config

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

Re: [OpenWrt-Devel] [PATCH] build: fixes feeds with Makefile in root directory (#20392)

[Ryan Lindeman]

I sent this (my first ever) patch in a few weeks ago, has anyone had time
to review it?  If I did something wrong, please let me know. Thanks.

*[image: cid:image001.png@01CFCC2A.38674B20]*

*  Ryan Lindeman*, Software Engineer

  11778 South Election Road, Suite 260 *|* Draper, UT 84020 *|* USA

  801.748.4900, ext. 38 (*office*)

  rlinde...@caengineering.com | www.caengineering.com



*|* CONFIDENTIALITY NOTICE *|*

The information in this email may be confidential and/or privileged. This
email is intended to be reviewed by onlythe individual or organization
named as a recipient or cc:. If you are not the intended recipient or an
authorized representative of the intended recipient, you are hereby
notified that any review, dissemination or copying of this email and its
attachments, if any, or the information contained herein is prohibited. If
you have received this email in error, please immediately notify the sender
by return email and delete this email from your system.

On Fri, Aug 28, 2015 at 2:05 PM, Ryan Lindeman 
wrote:

> This patch addresses an error caused by adding feeds that contain a
> Makefile
> in the root directory. The error is typically shown as follows:
> .../info/.files-packageinfo.mk:1: * target pattern contains no `%'. Stop.
> OR
> .../info/.files-targetinfo.mk:1: * target pattern contains no `%'. Stop.
>
> The root cause of the error is due to problems with the $(FILELIST): rule
> in
> the include/scan.mk file which attempts to strip off the $(SCAN_DIR)/ and
> /Makefile: ... contents of the lines provided by the FIND_L command. When a
> feed contains a single Makefile in the root directory the /Makefile: ...
> portion is not removed since the $(SCAN_DIR)/ has already removed the
> preceding / before the Makefile. This then causes extra characters to be
> evaluated by grep in the $(TMP_DIR)/info/.files-$(SCAN_TARGET).mk: rule
> which
> is where the above error is eventually reported by Make.
>
> The solution is to allow for a portion of the $(SCAN_DIR) to be included
> in the
> results produced by the $(FILELIST): rule. This patch creates a new
> variable
> called PREFIX_DIR which becomes the directory portion of $(SCAN_DIR)
> removed.
> This variable is specified by the update_index method of the scripts/feeds
> file. Since the include/scan.mk file is also used to scan the packages
> folder
> the default value for PREFIX_DIR must be empty (which is specified at the
> top
> of the include/scan.mk file). These changes results in the
> info/.files-$(SCAN_TARGET).mk files to include the remainder of the
> $(SCAN_DIR) path not removed so the $(SCAN_DIR) path information is removed
> from the PackageDir rule specified in include/scan.mk. This has the added
> benefit of simplifying the readability of this rule IMHO.
>
> Signed-off-by: Ryan Lindeman 
> ---
>  include/scan.mk |   21 +++--
>  scripts/feeds   |4 ++--
>  2 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/include/scan.mk b/include/scan.mk
> index 5af0359..8561b30 100644
> --- a/include/scan.mk
> +++ b/include/scan.mk
> @@ -8,6 +8,7 @@ include $(TOPDIR)/include/host.mk
>  SCAN_TARGET ?= packageinfo
>  SCAN_NAME ?= package
>  SCAN_DIR ?= package
> +PREFIX_DIR ?=
>  TARGET_STAMP:=$(TMP_DIR)/info/.files-$(SCAN_TARGET).stamp
>  FILELIST:=$(TMP_DIR)/info/.files-$(SCAN_TARGET)-$(SCAN_COOKIE)
>  OVERRIDELIST:=$(TMP_DIR)/info/.overrides-$(SCAN_TARGET)-$(SCAN_COOKIE)
> @@ -28,15 +29,15 @@ endef
>
>  define PackageDir
>$(TMP_DIR)/.$(SCAN_TARGET): $(TMP_DIR)/info/.$(SCAN_TARGET)-$(1)
> -  $(TMP_DIR)/info/.$(SCAN_TARGET)-$(1): $(SCAN_DIR)/$(2)/Makefile
> $(SCAN_STAMP) $(foreach DEP,$(DEPS_$(SCAN_DIR)/$(2)/Makefile)
> $(SCAN_DEPS),$(wildcard $(if $(filter
> /%,$(DEP)),$(DEP),$(SCAN_DIR)/$(2)/$(DEP
> +  $(TMP_DIR)/info/.$(SCAN_TARGET)-$(1): $(2)/Makefile $(SCAN_STAMP)
> $(foreach DEP,$(DEPS_$(2)/Makefile) $(SCAN_DEPS),$(wildcard $(if $(filter
> /%,$(DEP)),$(DEP),$(2)/$(DEP
> { \
> -   $$(call progress,Collecting $(SCAN_NAME) info:
> $(SCAN_DIR)/$(2)) \
> -   echo Source-Makefile: $(SCAN_DIR)/$(2)/Makefile; \
> +   $$(call progress,Collecting $(SCAN_NAME) info: $(2)) \
> +   echo Source-Makefile: $(2)/Makefile; \
> $(if $(3),echo Override: $(3),true); \
> -   $(NO_TRACE_MAKE) --no-print-dir -r DUMP=1 FEED="$(call
> feedname,$(2))" -C $(SCAN_DIR)/$(2) $(SCAN_MAKEOPTS) 2>/dev/null || { \
> -   mkdir -p "$(TOPDIR)/logs/$(SCAN_DIR)/$(2)"; \
> -   $(NO_TRACE_MAKE) --no-print-dir -r DUMP=1
> FEED="$(call feedname,$(2))" -C $(SCAN_DIR)/$(2) $(SCAN_MAKEOPTS) >
> $(TOPDIR)/logs/$(SCAN_DIR)/$(2)/dump.txt 2>&1; \
> -   $$(call progress,ERROR: please fix
> $(SCAN_DIR)/$(2)/Makefile - see logs/$(SCAN_DIR)/$(2)/dump.txt for
> details\n) \
> +   $(NO_TRACE_MAKE) --no-print-dir -r DUMP=1 

Re: [OpenWrt-Devel] i2c device not in /dev

[John Crispin]

On 14/09/2015 20:09, Daniel Golle wrote:
> On Mon, Sep 14, 2015 at 07:47:08PM +0200, John Crispin wrote:
>> On 14/09/2015 19:28, Baptiste Clenet wrote:
>>> Hi,
>>>
>>> I'm using a MT7628 chip and I try to implement an I2C device which
>>> will use i2c-ralink adapter. I registered my i2c device with
>>> module_i2c_driver(i2c_device_driver);
>>>
>>> I can see it on my bus:
>>> ./sys/bus/i2c/drivers/i2c_device_driver
>>> But it doesn't appear in /dev.
>>>
>>> What am I doing wrong?
>>>
>>> Regards,
>>>
>>
>> you are missing CONFIG_I2C_CHARDEV in the kernel config
> 
> or maybe i2c-dev isn't loaded? try
> modprobe i2c-dev
> 

i2c-dev is part of i2c-core if that symbol is selected. i2c-core uses
AutoLoad and not AutoProbe so it should always load.

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

Re: [OpenWrt-Devel] [PATCH] [LANTIQ] ARV7519RW22 dts fix

[John Crispin]

On 02/09/2015 16:34, José Vázquez Fernández wrote:
> From a9d8a4d04c5564abb0440a3b67dd21e8645e2c43 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Jos=C3=A9=20V=C3=A1zquez=20Fern=C3=A1ndez?=
>  
> Date: Tue, 1 Sep 2015 19:30:26 +0200
> Subject: [OpenWrt-Devel] [PATCH] [LANTIQ] ARV7519RW22 dts fix
> 
> The ARV7519RW22 has only one flash chip.
> This patch fixes a detection issue of the mtd partitions that cause the
> kernel not to be able to find rootfs.
> 
> Signed off by: 

this is not valid and git am refuses to merge it



> ---
>  target/linux/lantiq/dts/ARV7519RW22.dts |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/linux/lantiq/dts/ARV7519RW22.dts
> b/target/linux/lantiq/dts/ARV7519RW22.dts
> index 6823753..10ce8c9 100644
> --- a/target/linux/lantiq/dts/ARV7519RW22.dts
> +++ b/target/linux/lantiq/dts/ARV7519RW22.dts
> @@ -18,7 +18,7 @@
>   nor-boot@0 {
>   compatible = "lantiq,nor";
>   bank-width = <2>;
> - reg = <0 0x0 0x200>, <1 0x200 
> 0x200>;
> + reg = <0 0x0 0x200>;
>   #address-cells = <1>;
>   #size-cells = <1>;
>  
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] base-files: assign proper GPIO pin for Ubiquiti Nanostation models

[John Crispin]

you used the wrong prefix, i fixed it manually, please double check it
next time

John

On 13/09/2015 00:33, Lars Kruse wrote:
> The GPIO pins for "POE passthrough" of Ubiquiti Nanostation models are the
> following:
> * Ubiquiti Nanostation M XM: Pin 8
> * Ubiquiti Nanostation M XW: Pin 2
> 
> The previous definition of the pins was mixed up between XM and XW model.
> 
> Signed-off-by: Lars Kruse 
> ---
>  target/linux/ar71xx/base-files/etc/uci-defaults/01_gpio-switches | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_gpio-switches 
> b/target/linux/ar71xx/base-files/etc/uci-defaults/01_gpio-switches
> index 81d3982..b41f275 100644
> --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_gpio-switches
> +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_gpio-switches
> @@ -10,10 +10,10 @@ board=$(ar71xx_board_name)
>  
>  case "$board" in
>  nanostation-m)
> - ucidef_set_gpio_switch "poe_passthrough" "PoE Passthrough" "2"
> + ucidef_set_gpio_switch "poe_passthrough" "PoE Passthrough" "8"
>   ;;
>  nanostation-m-xw)
> - ucidef_set_gpio_switch "poe_passthrough" "PoE Passthrough" "8"
> + ucidef_set_gpio_switch "poe_passthrough" "PoE Passthrough" "2"
>   ;;
>  cpe510)
>   ucidef_set_gpio_switch "poe_passthrough" "PoE Passthrough" "20"
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: add TP-LINK TL-WDR3320 v2 support

[John Crispin]

Hi,

On 09/09/2015 16:56, Weijie Gao wrote:
> Signed-off-by: Weijie Gao 

this line should be the last line and not the first, i manually fixed
this during the merge

John

> 
> This patch adds support for TP-LINK TL-WDR3320 v2.
> 
> This router uses a chinese version 2 firmware header,.
> ---
>  target/linux/ar71xx/base-files/etc/diag.sh |   1 +
>  .../ar71xx/base-files/etc/uci-defaults/01_leds |   4 +
>  .../ar71xx/base-files/etc/uci-defaults/02_network  |   1 +
>  target/linux/ar71xx/base-files/lib/ar71xx.sh   |   6 +
>  .../ar71xx/base-files/lib/upgrade/platform.sh  |   1 +
>  target/linux/ar71xx/config-4.1 |   1 +
>  .../files/arch/mips/ath79/mach-tl-wdr3320-v2.c | 146 
> +
>  target/linux/ar71xx/generic/profiles/tp-link.mk|  11 ++
>  target/linux/ar71xx/image/Makefile |  46 ++-
>  .../816-MIPS-ath79-add-tl-wdr3320-v2-support.patch |  40 ++
>  10 files changed, 256 insertions(+), 1 deletion(-)
>  create mode 100644 
> target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3320-v2.c
>  create mode 100644 
> target/linux/ar71xx/patches-4.1/816-MIPS-ath79-add-tl-wdr3320-v2-support.patch
> 
> diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
> b/target/linux/ar71xx/base-files/etc/diag.sh
> index 36de775..0dcc844 100644
> --- a/target/linux/ar71xx/base-files/etc/diag.sh
> +++ b/target/linux/ar71xx/base-files/etc/diag.sh
> @@ -256,6 +256,7 @@ get_status_led() {
>   tl-wa901nd | \
>   tl-wa901nd-v2 | \
>   tl-wa901nd-v3 | \
> + tl-wdr3320-v2 | \
>   tl-wdr3500 | \
>   tl-wr1041n-v2 | \
>   tl-wr1043nd | \
> diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds 
> b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
> index e7f7a4c..4dafc1e 100644
> --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
> +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
> @@ -425,6 +425,10 @@ tl-wa901nd-v2)
>   ucidef_set_led_wlan "wlan" "WLAN" "tp-link:green:wlan" "phy0tpt"
>   ;;
>  
> +tl-wdr3320-v2)
> + ucidef_set_led_wlan "wlan5g" "WLAN5G" "tp-link:green:wlan5g" "phy0tpt"
> + ;;
> +
>  tl-wdr3500)
>   ucidef_set_led_usbdev "usb" "USB" "tp-link:green:usb" "1-1"
>   ucidef_set_led_wlan "wlan2g" "WLAN2G" "tp-link:green:wlan2g" "phy0tpt"
> diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network 
> b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
> index 686fce9..37d5a63 100644
> --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
> +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
> @@ -435,6 +435,7 @@ tew-712br |\
>  tl-mr3220 |\
>  tl-mr3220-v2 |\
>  tl-mr3420 |\
> +tl-wdr3320-v2 |\
>  tl-wdr3500 |\
>  tl-wr741nd |\
>  tl-wr741nd-v4 |\
> diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
> b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> index e1f345e..c5440f9 100755
> --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> @@ -221,6 +221,9 @@ tplink_board_detect() {
>   "342000"*)
>   model="TP-Link TL-MR3420"
>   ;;
> + "332000"*)
> + model="TP-Link TL-WDR3320"
> + ;;
>   "35"*)
>   model="TP-Link TL-WDR3500"
>   ;;
> @@ -763,6 +766,9 @@ ar71xx_board_detect() {
>   *"TL-WA901ND v3")
>   name="tl-wa901nd-v3"
>   ;;
> + *"TL-WDR3320 v2")
> + name="tl-wdr3320-v2"
> + ;;
>   *"TL-WDR3500")
>   name="tl-wdr3500"
>   ;;
> diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
> b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> index c1962e4..1d56d99 100755
> --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> @@ -338,6 +338,7 @@ platform_check_image() {
>   tl-wa901nd | \
>   tl-wa901nd-v2 | \
>   tl-wa901nd-v3 | \
> + tl-wdr3320-v2 | \
>   tl-wdr3500 | \
>   tl-wdr4300 | \
>   tl-wdr4900-v2 | \
> diff --git a/target/linux/ar71xx/config-4.1 b/target/linux/ar71xx/config-4.1
> index 21c4601..d0a6602 100644
> --- a/target/linux/ar71xx/config-4.1
> +++ b/target/linux/ar71xx/config-4.1
> @@ -121,6 +121,7 @@ CONFIG_ATH79_MACH_TL_WA830RE_V2=y
>  CONFIG_ATH79_MACH_TL_WA901ND=y
>  CONFIG_ATH79_MACH_TL_WA901ND_V2=y
>  CONFIG_ATH79_MACH_TL_WAX50RE=y
> +CONFIG_ATH79_MACH_TL_WDR3320_V2=y
>  CONFIG_ATH79_MACH_TL_WDR3500=y
>  CONFIG_ATH79_MACH_TL_WDR4300=y
>  CONFIG_ATH79_MACH_TL_WDR6500_V2=y
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3320-v2.c 
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3320-v2.c
> new file mode 100644
> index 000..3e452f2
> --- /dev/null
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3320-v2.c
> @@ -0,0 +1,146 @@
> +/*
> + *  TP-LINK TL-WDR3320 v2 

Re: [OpenWrt-Devel] Chaos Calmer 15.05

[Arturo Rinaldi]

First of all, congratulations to all of you for the great effort. I just
want to post a simple questionI have noticed that the the LUCI control
panel still returns a null MAC Address for both the wired and wireless
network cards. If I remember well, the developers are well aware of this
issue which is related to UBUS and LuCi itself.

Any chance to get this bug solved in one of the next maintenance commits ?

 Regards, Arturo

2015-09-11 18:19 GMT+02:00 elektra :

> Congratiulations and thank you all very much!
>
> You rock!
>
> Cheers,
> Elektra
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Target profiles: making "make" build every profile

[Rafał Miłecki]

Quick summary:
Subtargets - used for building modified kernels
Profiles - used for including specific software

There are two ways of using profiles:

1) Changing some software for all devices
Used when profile is used for all devices (no filtering, no per device
profiles).
This is used e.g. by brcm47xx. Normally all images will be built with
b43. However by changing a profile you can get *all* images to include
wl.ko.

2) Including extra software for specific devices
Used when profile is (group) device specific. E.g. including USB
drivers for devices with USB only.
This is something I'd like to use with bcm53xx. I'd like to include
brcmfmac.ko in two images only (R8000 and SR400ac). Of course, I'll
need to adjust target/bcm53xx/image/Makefile to:
a) Stop building SR400ac and R8000 images for TARGET_bcm53xx_Generic
b) Build above images for something new like TARGET_bcm53xx_brcmfmac

If I add TARGET_bcm53xx_brcmfmac as explained above, its images won't
be build anymore by default.
I'd like to to have a way to ask "make" for building all profiles by
setting some variable in target/bcm53xx/Makefile

Can someone give me some help with implementing this?

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

[OpenWrt-Devel] [PATCH] musl: fix build on sh3

[Zoltan HERPAI]

musl fails to build when compiled with gcc on sh3 (GCC target/#67260).
Work it around.

Signed-off-by: Zoltan HERPAI 
---
 toolchain/musl/common.mk |5 +
 1 file changed, 5 insertions(+)

diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk
index 82c1543..ba467fb 100644
--- a/toolchain/musl/common.mk
+++ b/toolchain/musl/common.mk
@@ -23,6 +23,11 @@ 
HOST_BUILD_DIR:=$(BUILD_DIR_TOOLCHAIN)/$(PKG_NAME)-$(PKG_VERSION)

 include $(INCLUDE_DIR)/toolchain-build.mk
 include $(INCLUDE_DIR)/hardening.mk

+ifeq ($(CONFIG_sh3),y)
+TARGET_CFLAGS+= \
+   -fno-optimize-sibling-calls
+endif
+
 MUSL_CONFIGURE:= \
$(TARGET_CONFIGURE_OPTS) \
CFLAGS="$(TARGET_CFLAGS)" \
--
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH][netifd] Initialize wireless interface attributes in proper function

[Dmitry Ivanov]

Initialize wireless interface attributes in proper function.

Currently multicast to unicast feature may be configured for incorrect wireless 
interface in case of reconfiguration.

Test case:

Initial wireless configuration:

config wifi-iface
  option mode ap
  option disabled 1

config wifi-iface
  option mode sta
  option disabled 0

config wifi-iface
  option mode ap
  option disabled 0

After reboot, multicast to unicast feature is configured for interface #3 
(wlan0-1) only.

Next, enable interface #1 and issue "wifi" command. Now, multicast to unicast 
feature is configured for interface #2 (wlan0) which is wrong.
It should be configured for interfaces #1 and #3 only. This patch resolves this 
problem.


Signed-off-by: Dmitry Ivanov 
---
 wireless.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/wireless.c b/wireless.c
index dcadfad..f0b19aa 100644
--- a/wireless.c
+++ b/wireless.c
@@ -559,6 +559,14 @@ wireless_interface_init_config(struct wireless_interface 
*vif)
 
if ((cur = tb[VIF_ATTR_NETWORK]))
vif->network = cur;
+
+   cur = tb[VIF_ATTR_ISOLATE];
+   if (cur && blobmsg_get_bool(cur))
+   vif->isolate = blobmsg_get_bool(cur);
+
+   cur = tb[VIF_ATTR_MODE];
+   if (cur)
+   vif->ap_mode = !!!strcmp(blobmsg_get_string(cur), "ap");
 }
 
 static void
@@ -715,14 +723,6 @@ void wireless_interface_create(struct wireless_device 
*wdev, struct blob_attr *d
vif->section = section;
vif->isolate = false;
 
-   cur = tb[VIF_ATTR_ISOLATE];
-   if (cur && blobmsg_get_bool(cur))
-   vif->isolate = blobmsg_get_bool(cur);
-
-   cur = tb[VIF_ATTR_MODE];
-   if (cur && !strcmp(blobmsg_get_string(cur), "ap"))
-   vif->ap_mode = true;
-
vlist_add(>interfaces, >node, vif->name);
 }
 
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

[Baptiste Jonglez]

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 
---
 interface-ip.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/interface-ip.c b/interface-ip.c
index 8eb2ff3..439b8af 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -473,11 +473,16 @@ interface_update_proto_addr(struct vlist_tree *tree,
if ((a_new->flags & DEVADDR_FAMILY) == DEVADDR_INET4 &&
!a_new->broadcast) {
 
-   uint32_t mask = ~0;
-   uint32_t *a = (uint32_t *) _new->addr;
-
-   mask >>= a_new->mask;
-   a_new->broadcast = *a | htonl(mask);
+   /* /31 addressing needs 255.255.255.255 broadcast */
+   if (a_new->mask == 31) {
+   a_new->broadcast = (uint32_t) ~0;
+   } else {
+   uint32_t mask = ~0;
+   uint32_t *a = (uint32_t *) _new->addr;
+
+   mask >>= a_new->mask;
+   a_new->broadcast = *a | htonl(mask);
+   }
}
}
 
-- 
2.5.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2][netifd] Initialize wireless interface attributes in proper function

[Dmitry Ivanov]

Initialize wireless interface attributes in proper function.

Currently multicast to unicast feature may be configured for incorrect wireless 
interface in case of reconfiguration.

Test case:

Initial wireless configuration:

config wifi-iface
  option mode ap
  option disabled 1

config wifi-iface
  option mode sta
  option disabled 0

config wifi-iface
  option mode ap
  option disabled 0

After reboot, multicast to unicast feature is configured for interface #3 
(wlan0-1) only.

Next, enable interface #1 and issue "wifi" command. Now, multicast to unicast 
feature is configured for interface #2 (wlan0) which is wrong.
It should be configured for interfaces #1 and #3 only. This patch resolves this 
problem.


Signed-off-by: Dmitry Ivanov 
---
 wireless.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/wireless.c b/wireless.c
index dcadfad..f0b19aa 100644
--- a/wireless.c
+++ b/wireless.c
@@ -559,6 +559,14 @@ wireless_interface_init_config(struct wireless_interface 
*vif)
 
if ((cur = tb[VIF_ATTR_NETWORK]))
vif->network = cur;
+
+   cur = tb[VIF_ATTR_ISOLATE];
+   if (cur && blobmsg_get_bool(cur))
+   vif->isolate = blobmsg_get_bool(cur);
+
+   cur = tb[VIF_ATTR_MODE];
+   if (cur)
+   vif->ap_mode = !strcmp(blobmsg_get_string(cur), "ap");
 }
 
 static void
@@ -715,14 +723,6 @@ void wireless_interface_create(struct wireless_device 
*wdev, struct blob_attr *d
vif->section = section;
vif->isolate = false;
 
-   cur = tb[VIF_ATTR_ISOLATE];
-   if (cur && blobmsg_get_bool(cur))
-   vif->isolate = blobmsg_get_bool(cur);
-
-   cur = tb[VIF_ATTR_MODE];
-   if (cur && !strcmp(blobmsg_get_string(cur), "ap"))
-   vif->ap_mode = true;
-
vlist_add(>interfaces, >node, vif->name);
 }
 
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Target profiles: making "make" build every profile

[Jonas Gorski]

Hi,

On Mon, Sep 14, 2015 at 11:30 AM, Rafał Miłecki  wrote:
> Quick summary:
> Subtargets - used for building modified kernels
> Profiles - used for including specific software
>
> There are two ways of using profiles:
>
> 1) Changing some software for all devices
> Used when profile is used for all devices (no filtering, no per device
> profiles).
> This is used e.g. by brcm47xx. Normally all images will be built with
> b43. However by changing a profile you can get *all* images to include
> wl.ko.
>
> 2) Including extra software for specific devices
> Used when profile is (group) device specific. E.g. including USB
> drivers for devices with USB only.
> This is something I'd like to use with bcm53xx. I'd like to include
> brcmfmac.ko in two images only (R8000 and SR400ac). Of course, I'll
> need to adjust target/bcm53xx/image/Makefile to:
> a) Stop building SR400ac and R8000 images for TARGET_bcm53xx_Generic
> b) Build above images for something new like TARGET_bcm53xx_brcmfmac

I don't think there is an issue with letting Generic build all images
with a "common" package set as default, and still having a defined
profile for it with a specialized package set.

> If I add TARGET_bcm53xx_brcmfmac as explained above, its images won't
> be build anymore by default.
> I'd like to to have a way to ask "make" for building all profiles by
> setting some variable in target/bcm53xx/Makefile
>
> Can someone give me some help with implementing this?

Changing the buildroot for that would be a lot of work, as you would
need to force all packages needed by all images as =m, and you would
have to require them, as else the image generation will fail if the
user decides to delect any of them (or silently drop it). And then the
issue of deciding if a package should be included in the image or not
based on the selected profile's default packages, the image's default
profile's packages, and the actual selection states in .config

I think a better place would be the image builder for that. There we
could just add e.g. a new build target like allimages that will
iterate over all available images and build them. Or maybe
"alldevices", and it would hook into the new Device-stuff and iterate
over all defined devices, with the assumption that these define their
specific profile so we don't need to add code to skip the common
profiles.

so we would then have something like

define Device/FooDevice
DEVICE_PROFILE=Foo
endef

define Device/BarDevice
   DEVICE_PROFILE=Bar
endef


and enhance the code in include/image.mk to collect these
DEVICE_PROFILEs to iterate over.


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

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

[Baptiste Jonglez]

From: Baptiste Jonglez 

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 incorrect.

For consistency with the Linux kernel, /32-addressed interfaces are
treated in the same way.

Signed-off-by: Baptiste Jonglez 
---
 interface-ip.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/interface-ip.c b/interface-ip.c
index 8eb2ff3..0c72e46 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -473,11 +473,17 @@ interface_update_proto_addr(struct vlist_tree *tree,
if ((a_new->flags & DEVADDR_FAMILY) == DEVADDR_INET4 &&
!a_new->broadcast) {
 
-   uint32_t mask = ~0;
-   uint32_t *a = (uint32_t *) _new->addr;
-
-   mask >>= a_new->mask;
-   a_new->broadcast = *a | htonl(mask);
+   /* /31 and /32 addressing need 255.255.255.255
+* as broadcast address. */
+   if (a_new->mask >= 31) {
+   a_new->broadcast = (uint32_t) ~0;
+   } else {
+   uint32_t mask = ~0;
+   uint32_t *a = (uint32_t *) _new->addr;
+
+   mask >>= a_new->mask;
+   a_new->broadcast = *a | htonl(mask);
+   }
}
}
 
-- 
2.5.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel