date:20150926

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

2015-09-26 Thread Baptiste Jonglez

Hi David,

Package-related patches should be submitted to the Github package repository:

  https://github.com/openwrt/packages/

Baptiste

On Thu, Sep 17, 2015 at 11:32:36AM +0100, David Woodhouse wrote:
> In my old AA setup, the nut package had an init script which built
> ups.conf and upsd.users from the configuration in /etc/config, before
> starting the dæmons.
> 
> Having just upgraded to CC, this no longer happens, and the UPS isn't
> configured. What happened? Is this just an oversight, and should I
> submit a patch to reinstate the configuration handling? Or was there a
> plan...?
> 
> There follows a few other patches to fix other breakage, and I've
> worked around the config problem for now by editing the files in
> /etc/nut in my (writeable) root file system.



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



pgprGw1NjMG6J.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-26 Thread Baptiste Jonglez

nbd, did you have time to look at this new version of the patch?

Thanks,
Baptiste

On Mon, Sep 14, 2015 at 12:25:33PM +0200, Baptiste Jonglez wrote:
> From: Baptiste Jonglez 
> 
> 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);
> + }
>   }
>   }
>  


pgptA0mfanG4W.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2015-09-26 Thread Felix Fietkau

On 2015-09-14 11:53, Dmitry Ivanov wrote:
> 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.
Applied with some modifications. Again, please don't repeat the message
subject in the email text, as it gets duplicated in the git commit.

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

Re: [OpenWrt-Devel] UML not working in master

2015-09-26 Thread Bastian Bittorf

* Javier Domingo Cansino  [26.09.2015 13:26]:
> Hi,
> 
> I wanted to setup for some tests an environment running uml, and I found
> it's not compiling on master with default config. The error seems similar
> to a previous one I found in the bug tracker.

IMHO this is a macro problem and we locally have this fix running:
https://github.com/glycoknob/builder/commit/4dbb2911ec890ff698e1df6cad86584b5628f99f

please test and report, we can send it if it's useful for others too.

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

Re: [OpenWrt-Devel] HTTPS with 'letsencrypt.org' on OpenWrt

2015-09-26 Thread Michael Richardson

Joris de Vries  wrote:
> I would be interested in this as well, although I'm not sure how useful
> this is without configuring a good hostname for routers, also maybe
> automatically.

Fundamentally, this is the problem for devices without names.
I just don't think that Lets Encrypt is going to be at all helpful for the
users that are most vulnerable.

This applies to openwrt routers, but also to things like ILOMs (e.g. Dell
iDRAC systems) and also things like a home NAS appliance.

What we need is a variation on the Extended Valiation Cert: a cert that the
browser recognizes having a DN that binds to the devices' MAC address.
The browser would then put that into the Location bar. Of course this is an
entirely new beast, but I don't see another way to intelligently get a
certificate for a router without a name.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] How to add ubus users?

2015-09-26 Thread Rüdiger , Christoph

Hi Jow,

thank you for that information.

> If the password option is specified like "$p$" then the password hash
> for  is validated against /etc/shadow.
> 
> If the password option is specified like "$1$" then the client supplied
> login password is hashed through crypt() and compared against the hash in
> the config. You can generate such a hash with "mkpasswd -5 password" or
> "uhttpd -m password".

Are there also other options available? We have a bit strange offline 
two-factor authentication in use and have a pam plugin for this. Is there a way 
to authenticate against pam? If not, can you point me to the source code 
location, which is a good starting point to add such functionality?


Best regards,
Christoph

-- 
ThyssenKrupp Elevator Innovation GmbH
PDC Neuhausen
TKEI Elevator Control
Bernhaeuser Straße 45
73765 Neuhausen, Germany

Phone +49 7158 12-2615
christoph.ruedi...@thyssenkrupp.com

Company domicile: Essen  Commercial register: Essen HRB 20 839
Postal address: ThyssenKrupp Allee 1, 45143 Essen, Germany 
Executive Board: Gerhard Thumm, Katrin Huenger, Philippe Choleau


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

Re: [OpenWrt-Devel] UML not working in master

2015-09-26 Thread Martin Tippmann

2015-09-26 20:48 GMT+02:00 Javier Domingo Cansino :
> Hi Bastian,
>
> I have patched, compiled correctly, and working alright! =)
>
> You should really send that patch upstream!

Hi,

it's already fixed in the Kernel since June:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=30b11ee9ae23d78de66b9ae315880af17a64ba83
- But it's not in Kernel 3.18

Maybe it's better to just raise the Kernel version? Or should I submit
the patch to the list?

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

Re: [OpenWrt-Devel] UML not working in master

2015-09-26 Thread Javier Domingo Cansino

Doesn't seem like 3.18 has something that 4.0 or 4.1 have, although it
might be interesting for proper UML support in CC.

I would just submit the patch as it is, to have it included in master ASAP.
Although the migration to any of the 4.x kernels does seem
straightforward...

It's up to you =)

On Sat, Sep 26, 2015 at 11:35 PM Martin Tippmann 
wrote:

> 2015-09-26 20:48 GMT+02:00 Javier Domingo Cansino :
> > Hi Bastian,
> >
> > I have patched, compiled correctly, and working alright! =)
> >
> > You should really send that patch upstream!
>
> Hi,
>
> it's already fixed in the Kernel since June:
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=30b11ee9ae23d78de66b9ae315880af17a64ba83
> - But it's not in Kernel 3.18
>
> Maybe it's better to just raise the Kernel version? Or should I submit
> the patch to the list?
>
> regards
> Martin
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ar71xx: Add Gainstrong MiniBox v1.0 support to trunk

2015-09-26 Thread Stijn Segers


Hi John,

You commented on my first patches a while ago for the MiniBox, don't 
know if

mailing list 'etiquette' expected me to CC you for this updated patch.

Doing it now in case I should have :)

Cheers

Stijn Segers



Date: Sun, 20 Sep 2015 21:53:33 +0200
From: Stijn Segers 
To: openwrt-devel@lists.openwrt.org
Subject: [OpenWrt-Devel] [PATCH v5] ar71xx: Add Gainstrong MiniBox
v1.0support to trunk
Message-ID:
<1442778813-2539-1-git-send-email-francesco.borrom...@inventati.org>

This patch supersedes the v1 from September 17th.

Bumping the patch version - the MiniBox profile showed up under M, but
since it's called 'Gainstrong MiniBox v1.0' now it looks out of place.
Renamed the profile to gs-minibox-v1.mk to fix that.

The following patch adds support for the Gainstrong MiniBox into trunk
(or 'Designated Driver' :D ).

Fixed items:

- Inverted LED polarity (OOLITE seems to suffer from the same 
problem).

- Changed uppercase MINIBOX_V1_ prefix as requested.
- Prefixes are now gs_minibox_ similar to gs_oolite_ (same vendor).
- Mention the vendor (Gainstrong) in code headers.

Compiles fine, has been confirmed working by owners on 15.05.

Question: I've seen some boards use 
tools/firmware-utils/src/mktplinkfw.c,
the MiniBox images build fine without, so I'm wondering: do I need to 
add

it in there as well? Any added benefit?

Thank you

Signed-off by: Stijn Segers 

---
 target/linux/ar71xx/base-files/etc/diag.sh |  3 +
 .../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-gs-minibox-v1.c | 85 
++

 target/linux/ar71xx/generic/profiles/minibox-v1.mk | 17 +
 target/linux/ar71xx/image/Makefile |  9 +++
 .../799-MIPS-ath79-add-minibox-v1-support.patch| 39 ++
 9 files changed, 162 insertions(+)
 create mode 100644 
target/linux/ar71xx/files/arch/mips/ath79/mach-gs-minibox-v1.c

 create mode 100644 target/linux/ar71xx/generic/profiles/minibox-v1.mk
 create mode 100644 
target/linux/ar71xx/patches-4.1/799-MIPS-ath79-add-minibox-v1-support.patch


diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh

index cfba6b4..2732994 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -225,6 +225,9 @@ get_status_led() {
smart-300)
status_led="nc-link:green:system"
;;
+   minibox-v1)
+   status_led="minibox-v1:green:system"
+   ;;
oolite)
status_led="oolite:red:system"
;;
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 880953c..a93a9ad 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -433,6 +433,7 @@ dir-615-e4 |\
 hiwifi-hc6361 |\
 ja76pf |\
 mc-mac1200r|\
+minibox-v1 |\
 mynet-n600 |\
 oolite |\
 qihoo-c301 |\
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh

index efb3d16..edaad73 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -119,6 +119,9 @@ tplink_board_detect() {
"3C0001"*)
model="OOLITE"
;;
+   "3C0002"*)
+   model="MINIBOX_V1"
+   ;;
"070300"*)
model="TP-Link TL-WR703N"
;;
@@ -514,6 +517,9 @@ ar71xx_board_detect() {
*"MAC1200R")
name="mc-mac1200r"
;;
+   *"MiniBox V1.0")
+   name="minibox-v1"
+   ;;
*MR12)
name="mr12"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh

index cad8b43..043b6ed 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -317,6 +317,7 @@ platform_check_image() {
el-mini | \
gl-inet | \
mc-mac1200r | \
+   minibox-v1 |\
onion-omega | \
oolite | \
smart-300 | \
diff --git a/target/linux/ar71xx/config-4.1 
b/target/linux/ar71xx/config-4.1

index 51f2f2f..883d0d7 100644
--- a/target/linux/ar71xx/config-4.1
+++ b/target/linux/ar71xx/config-4.1
@@ -75,6 +75,7 @@ CONFIG_ATH79_MACH_ESR900=y
 CONFIG_ATH79_MACH_EW_DORIN=y
 CONFIG_ATH79_MACH_F9K1115V2=y
 CONFIG_ATH79_MACH_GL_INET=y
+CONFIG_ATH79_MACH_GS_MINIBOX_V1=y
 CONFIG_ATH79_MACH_GS_OOLITE=y
 CONFIG_ATH79_MACH_HIWIFI_HC6361=y

Re: [OpenWrt-Devel] Introducing "fastpath" - Kernel module for speeding up IP forwarding

2015-09-26 Thread Weedy

Did this die?
On 22 Dec 2014 9:06 am, "Tomer Eliyahu"  wrote:

> Hi,
>
> We are software developers, part of Marvell's cellular platform
> infrastructure team.
>
> Our team has been working on a project named "fastpath" for speeding
> up IP forwarding in embedded systems.
> The initial version (fastpath v1) has already been successfully
> deployed in our latest pxa1801 (cellular modem) based products.
>
> We are in the final stages of fastpath v2 development, which is
> completely hardware independent and requires minimal changes in the
> generic networking code (the project consists of a kernel module and a
> single kernel patch); despite being hardware independent, fastpath v2
> already achieved the same level of performance (as fastpath v1) and
> even increased stability.
>
> Our development platform is running openwrt Barrier Breaker (r43694),
> so naturally we chose to suggest this to the openwrt development
> community first.
>
> You can find a brief description of our fastpath solution below.
>
> We are anxious to hear your thoughts/comments and will gladly share the
> code.
>
> Best Regards,
>
> Ram Marzin r...@marvell.com
> Tomer Eliyahu tom...@marvell.com
>
>
> Fastpath in a nutshell
> --
>
> The basic concept of fastpath is to optimize the data-plane while
> keeping the control-plane in the generic networking stack.
> This is a known concept in the industry which is commonly used in
> embedded systems [1], but so far we couldn't find any open source
> implementation for it.
>
> Fast path implements an optimized data-plane, which replaces the
> generic data-plane forwarding code for selected connections. The
> data-plane implementation includes a straight forward optimized packet
> processing engine which handles all the required packet manipulation
> for IP forwarding, such as decrement ttl/hop count, checksum
> adjustment, MAC header encapsulation and "dummy NAT" (TCP/UDP traffic
> which does not carry any L3/L4 information in the packet payload).
>
> As noted above, the control-plane is handled by the generic networking
> stack, with the only exception of learning new connections and marking
> the valid ones as fastpath - some connections can't participate in
> fastpath, such as any "non-dummy NAT" connections (e.g. FTP control
> port), local traffic, and any protocol which is not supported (e.g.
> IPv6 extensions, IPSec, IPv4 fragmanted packets, etc.).
> Needless to say that ALL non-fastpath connections / protocols will
> work as is, i.e. they simply won't go through fastpath.
>
> As a rule of thumb, it is safe to assume that in most of the cases,
> 90% of the data will go through fastpath. In our experiments on
> pxa1801, fastpath alone *almost doubled* the performance (both
> Throughput and MIPS consumption) for TCP/UDP IPv4/IPv6 forwarding.
>
> References
> [1]
> http://www.embedded.com/design/operating-systems/4403058/Accelerating-network-packet-processing-in-Linux
> ___
> 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] UML not working in master

2015-09-26 Thread Javier Domingo Cansino

Hi Bastian,

I have patched, compiled correctly, and working alright! =)

You should really send that patch upstream!

On Sat, Sep 26, 2015 at 5:39 PM Bastian Bittorf 
wrote:

> * Javier Domingo Cansino  [26.09.2015 13:26]:
> > Hi,
> >
> > I wanted to setup for some tests an environment running uml, and I found
> > it's not compiling on master with default config. The error seems similar
> > to a previous one I found in the bug tracker.
>
> IMHO this is a macro problem and we locally have this fix running:
>
> https://github.com/glycoknob/builder/commit/4dbb2911ec890ff698e1df6cad86584b5628f99f
>
> please test and report, we can send it if it's useful for others too.
>
> bye, bastian
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

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

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

Re: [OpenWrt-Devel] UML not working in master

Re: [OpenWrt-Devel] HTTPS with 'letsencrypt.org' on OpenWrt

Re: [OpenWrt-Devel] How to add ubus users?

Re: [OpenWrt-Devel] UML not working in master

Re: [OpenWrt-Devel] UML not working in master

Re: [OpenWrt-Devel] ar71xx: Add Gainstrong MiniBox v1.0 support to trunk

Re: [OpenWrt-Devel] Introducing "fastpath" - Kernel module for speeding up IP forwarding

Re: [OpenWrt-Devel] UML not working in master

11 matches

Site Navigation

Mail list logo

Footer information