Re: [OpenWrt-Devel] Security Vulnerability Reporting and Database

2015-03-26 Thread Jean-Michel Pouré - GOOZE
Le mercredi 25 mars 2015 à 14:31 -0500, Eric Schultz a écrit :
 During the discussions for the OpenWireless/OpenWrt security hackathon
 in April, one of the participants asked if there's a way to report
 security vulnerabilities in OpenWrt. I didn't know of one so I figured
 I should ask. Is there a recommended process for reporting a security
 vulnerability in OpenWrt?

+1. I am also interested in an answer.

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


Re: [OpenWrt-Devel] Why OpenWrt sucks?

2015-03-26 Thread bkil
If anyone wants to organize a BattleMesh event in Hungary, I would
vote for that and have a near industrial amount of various compatible
hardware standing by!

On Wed, Mar 25, 2015 at 9:36 PM, Gergely Kiss mail.g...@gmail.com wrote:
 On 03/21/2015 08:51 PM, valent.turko...@gmail.com wrote:
 On 10 March 2015 at 21:26, Gergely Kiss mail.g...@gmail.com wrote:
 Hi Valent,

 first of all, I strongly disagree with people claiming that OpenWrt sucks
 because it doesn't. For me it rather looks like a well-maintained, rapidly
 improving project with a great number of actively supported hardware and
 quite a few people contributing to

 snip

 Do you think OpenWrt sucks? Then stop complaining and do something to make
 it better. It's that simple.

 Cheers,
 Gergely

 Hi Gergely,
 thanks for your reply and for your contribution to OpenWrt. But I have
 to ask - have you read my message apart from headline? If you have
 read it you will see that I'm defending OpenWrt and I definitely don't
 think it sucks!

 Hi Valent,

 I'm sorry, that paragraph wasn't addressed to you but to people claiming 
 that OpenWrt sucks.

 Of course, I have read your message, I never reply to a message I haven't 
 read in its entirety.


 I contribute to it everyday, but not (yet) as a developer but as
 advanced user, forum and wiki contributor and have organized multiple
 workshops all accross Croatia, Serbia and Macedonia to get people to
 use OpenWrt.


 That's great! Any plans to come to Hungary someday? :)

 Cheers,
 Valent.

 ___
 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] Security Vulnerability Reporting and Database

2015-03-26 Thread Jo-Philipp Wich
Hi.
 During the discussions for the OpenWireless/OpenWrt security hackathon
 in April, one of the participants asked if there's a way to report
 security vulnerabilities in OpenWrt. I didn't know of one so I figured
 I should ask. Is there a recommended process for reporting a security
 vulnerability in OpenWrt?

I suggest to send such reports to openwrt-hack...@lists.openwrt.org.


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


Re: [OpenWrt-Devel] Rebuilding for specific hardware, example ar71xx/image for TP-Link TL-WR841ND

2015-03-26 Thread Jean-Michel Pouré - GOOZE
Le mercredi 25 mars 2015 à 11:43 -0400, John Szakmeister a écrit :
 Why not just use:
 
 ./scripts/config/conf --savedefconfig=config.seed Config.in

When building systems for release, one has to be very careful for
security. 

IMHO, I would not leave a toolchain and configuration on a build server
and change it from time to time. If this is the way OpenWRT is built,
there is a higher risk for an attacker to modify the build environment
and/or binaries.

I prefer:
build script = debian chroot = config = toolchain = compilation

I will enquire more about conf --savedefconfig=config.seed Config.in
to see if it suits my needs. From a first approach, I prefer to use a
small script which turns on/off features and builds a .config from
scratch. The only thing is that I need to keep the build script. But
this has to be studies in more details as I am new in the community and
have to learn.

Thanks for pointing it out. There is a lot to learn about OpenWRT, which
seems a very rich environment.

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


Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

2015-03-26 Thread Steven Barth

Hello Arjen,

most likely, your DHCPv6 client implementation is faulty and you should 
probably file a bug for more than one reason.


If the DHCPv6 server sends values for T1 and / or T2 which are valid the 
client must honor them and not try to be smart about lifetimes of 
addresses.


Besides you also get addresses with higher values for preferred lifetime 
using RAs so you always have usable IPv6 addresses, so if your 
network-manager / OS behaves sanely you shouldn't have any issues.


A work-around for this is setting:
option ra_management 0
in the lan-section of /etc/config/dhcp which will cause most clients to 
not use DHCPv6 and rely on RAs only.



Cheers,

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


[OpenWrt-Devel] EAP-TLS / EAP-TTLS PAP

2015-03-26 Thread Bernd Naumann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Maybe you have been at the Chaos Communication Congress in Germany the
last years. Then may you saw the WPA2 802.1X encrypted /public open
wireless access points/, where a user/client can choose their own
(random) name/password credentials.

https://events.ccc.de/congress/2014/wiki/Static:Network#WPA2_802.1X.2C_e
ncryption
(CA-CERT, sha-1 fingerprint:
4C:11:E8:BA:DE:12:79:08:45:4F:53:33:1F:E9:B9:60:56:1D:63:9F)

Due to popular demand (and with security in mind) we provide WPA2
802.1X. This will encrypt your traffic, preventing attackers from
sniffing your data. Keep in mind that this won't protect you from
other network attacks and you should still be aware that you are at a
hacker conference! Your link layer should be secure if you do
certificate checking (see below).


Back in 2010 and 2012 one paper and some emails claim, that it is
possible to patch hostapd to not have the need for client certificates.
/* Mails from californiajack at tormail.org via [OpenWireless Tech]) */



So what now? There is a project (
https://github.com/OpenSecurityResearch/hostapd-wpe ) where people
have patched and open sourced hostapd to do not request client
certificates (and other things). So far so good, there are patches.
But I'm not a C/C++ hacker and I will not touch TLS  and other
critical encryption and fuck it up to compile my version of hostapd.
If I want to use it, I want to use a well maintained version, it there
is any. (?!)

However, I saw that all this stuff is specified:
http://en.wikipedia.org/wiki/Extensible_Authentication_Protocol#EAP-TLS
and
there is FreeRadius which will do similar stuff, I heard about.


  I was curious in that technology cause it would be a nice thing for
our wireless community network. The sad fact today is, that we do not
have wireless security because in a flat organised community you will
not have central credentials (that is stupid and not open) and you
will not have a central comity which verifies user client
certificates, which is even more a closed system and can restrict user
access (realy realy bad!).

But if a user could choose his own (fake) credentials we have some
security against passive network sniffing. As you may know that there
are hunderds of shitty mobile apps with broken api-calls and poor
tls/ssl quality. We don't have to put our users at unnecessary risks.
We can not expect that every user can use end-to-end vpn connections.
Further, if we had an active network scanner within our infrastructure
we had an other problem. ...


K back to the plot:
Know you any hostapd configurations or other software in openwrt which
can achieve that goal? Are there any issues which might can lead to
problems or other downsides I may have missed? Reasons against?

Thanks for comments and pointers!

Greetings,
Bernd

- -- 
Bernd Naumann be...@kr217.de

PGP:   0xA150A04F via pool.sks-keyservers.net
XMPP:  b...@weimarnetz.de

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJVFAqUAAoJEEYW3OihUKBPOLkQAIHn8ovj3qEIjKnQ5YGLQr/Z
rttoYAeC1uZePbVTCe5c/DOZVvDp0tn174Eu8itKA5E+NUOJ4RjQ/Xr9tWdtQme/
kXnJoYS15+m2tivRbpYvHGTV47bWYYEBMg+P0Wg0XOHsy580CT88ZuBZDL1FlTcr
VjwibSwoNT7ZVO7UemrBmt8LNaItgNVwyhID6Eo//JyTWft2idPA9X4DPiMYndJG
cE3UwBcq5nqTh0whZXsUCmcjWzZ91hV+D2BfDf6rsWCIzdoFA+42HqwX4RSgJaQn
TCQeQYZpYgeysqBoAuetJc2AEGHRA3Vt+pxuX2HCerfk+pWU1F4ZCKRQ1q1u7XQk
p3ZD8tSofLZjmyXxAMrWJnNk74T1qLF/YuS2g5ms9kKIWzre6xOQ7Exe5yn0W+Mq
uKLexEI6BAJtDEiGKRMtn7tw70v6G0lhNtrbebgIULbHpaY+ToxozksGxUtyfbQ7
PnTnGqk2HS0XHn7noZgzqbLh6X9MniGrAEU3zJkhdcbAVTF//0lC/YUcrQKlOX5u
dpvcFu6FzvLUzncRXIJVjovuYzGpkP054fY379spSGyZo7/MDuUkKwT3bOYbf7oL
gOs0OA4e9RfIEvy0avR9SgR02n+w/QTSiqz3bl6UdZ5TTO810LXK8FpJMZV2gJcz
WdUg2cAuqsEC+7vp27v8
=8QL5
-END PGP SIGNATURE-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] Updating dnsmasq 2.73rc1 new dnssec timestamp checking option

2015-03-26 Thread Kevin Darbyshire-Bryant
Hi All,

New here, new to openwrt, not really a developer, more a willing idiot. 
Appreciate your help, patience, guidance etc.

I've been following dnsmasq git master for a year or two on other router
firmware projects and have always tried to keep them up to date.  I'd
like to do the same with/for openwrt.  I've a local clone of openwrt
following CC master (bleeding edge) and have updated the dnsmasq package
makefile to pull RC1, removed unneeded patches and got something
compiling  working (on one box, one platform - yeah huge test base!)  
I'd like to contribute these changes but I'm very unsure how to go about it.

There have been quite a few little fixes and improvements gone into
dnsmasq 2.73 (having gone through a number of test revisions)  One
particular feature relates to the 'dnssec validation/time not set/lookup
ntp server' chicken  egg problem.  Simon Kelly took the seed of an idea
that I had, ran with it, greatly improved it and came up with a
'timestamp file' which helps dnsmasq determine automatically whether the
current time is to be considered 'good' or not and hence whether to
check dnssec certificate time validity or not.  I personally think this
is the final hurdle removed with regard to getting dnssec validation to
an easily deployable state when using dnsmasq (luci needs a few extra
options though - I've had ideas for that too)

I've updated the package dnsmasq init script so that it uses this new
option if dnssec is enabled.  The location of the timestamp file is
currently '/etc/dnsmasq.d/dnsmasq.timestamp' but is this the best
location for it?  The file needs to survive reboots and a further
complication is that it must be r/w by the unprivileged user that
dnsmasq drops to (nobody) hence the new directory and init script doing
chown nobody:nogroup /etc/dnsmasq.d (I can't work out how to do that as
part of the image build process)

Your advice, help appreciated.

Kevin



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

2015-03-26 Thread Arjen de Korte

Citeren Steven Barth cy...@openwrt.org:


Hello Arjen,

most likely, your DHCPv6 client implementation is faulty and you  
should probably file a bug for more than one reason.


In that case, I have a lot of bug reports to file, because none of the  
DHCPv6 clients I tried were happy with preferred lifetimes of 1 second  
on their leases (which includes Windows 7, 8.1 and openSUSE 13.2).  
Removing lines


813 if (!a-accept_reconf  iface-managed  RELAYD_MANAGED_NO_AFLAG 
814 addrs[i].prefix == 64)
815 n.preferred = htonl(1);

and all were good again. I'm still looking for why setting a preferred  
lifetime of 1 second is not going to render the IPv6 address that is  
provided in the reply by odhcpd useless.


If the DHCPv6 server sends values for T1 and / or T2 which are valid  
the client must honor them and not try to be smart about lifetimes  
of addresses.


I'm not sure if preferred lifetime  T1 and/or T2 is expected behavior  
of the DHCPv6 server. One second after receiving the address, clients  
can't use the address for new connections, but also can't renew (until  
T1) or rebind (until T2). And that's precisely what I'm seeing here.  
Note that the continuous renewals were only with the first patch  
applied, for the most recent version of odhcpd the clients will just  
give up on the DHCPv6 address after one second and use SLAAC instead.  
But this is not what I want (and I can't switch off SLAAC either,  
since I have also clients to support which don't do DHCPv6).


Besides you also get addresses with higher values for preferred  
lifetime using RAs so you always have usable IPv6 addresses, so if  
your network-manager / OS behaves sanely you shouldn't have any  
issues.


They don't have an issue with IPv6 connectivity, its the source  
address that is used *I* have a problem with.



A work-around for this is setting:
option ra_management 0
in the lan-section of /etc/config/dhcp which will cause most clients  
to not use DHCPv6 and rely on RAs only.


This is not an option, as the whole purpose of using DHCPv6 for  
address configuration is to give clients a fixed IPv6 address. This  
has worked correctly since Barrier Breaker was released, I see no  
reason why it no longer should.

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


[OpenWrt-Devel] Alfa Hornet-UB no longer supports OpenWrt?

2015-03-26 Thread Joshua Judson Rosen
I've been buying batches of Hornet-UB based routers with OpenWrt preinstalled
from data-alliance.net for a while now; today I got a message from them that
they were unable to install the OpenWrt image they'd been using on any
of the Hornet-UB boards in the latest batch they received from Alfa.

From my initial discussion with them, it sounds like they were able to
TFTP the image and write it to flash, but it didn't boot as expected
after the reset command was issued in U-Boot. So we're trying to figure
out what's going wrong right now; did Alfa make some change to the hardware
in `recent' history (recent being a relative term--bearing in mind that
sometimes it can take years to run through old stock, depending on how
many old units exist and the rate at which they get sold...)? Something
like...:

- different flash layout?

- different components?

- something else?

Anything that would prevent the early Attitude Adjustment (pre-release)
builds from booting on the newer Hornet-UB boards? And if there has been
some sort of change, do newer builds of OpenWrt work on these boards?

I notice that there are actually two hornet-ub images for download
these days--one of which is for hornet-ub-x2? What is that?
There's no mention of it on in the wiki AFAICT, and I'm having
trouble finding useful pages with that name on it elsewhere
on the web

-- 
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] synchronous network reload/restart

2015-03-26 Thread Jo-Philipp Wich
Hi.

 Is there any way to synchronously (blocking) reload or restart the
 network configuration?
 
 ubus call network reload (or restart) returns immediately, and the
 re-configuration happens asynchronously in the background. I'd like the
 command to block or otherwise wait until the reconfiguration is
 complete. Any way to achieve this?

No.

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


[OpenWrt-Devel] synchronous network reload/restart

2015-03-26 Thread Bruno Randolf
Hello,

Is there any way to synchronously (blocking) reload or restart the
network configuration?

ubus call network reload (or restart) returns immediately, and the
re-configuration happens asynchronously in the background. I'd like the
command to block or otherwise wait until the reconfiguration is
complete. Any way to achieve this?

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


Re: [OpenWrt-Devel] seccomp patch lead to build failures

2015-03-26 Thread John Crispin


On 26/03/2015 19:17, Dirk Neukirchen wrote:
 procd: add jail support 45010
 
 leads to build errors on some? arches
 
 On omap I get:
 /jail/seccomp-bpf.h:72:3: error: #w$
  # warning Platform does not support seccomp filter yet
 
 which fails the build completely (-Werror issue)
 
 I think there are some issues with other arch/detection when building 
 libseccomp
 especially for PowerPC arch:
 - 
 http://buildbot.openwrt.org:8010/broken_packages/mpc85xx/libseccomp/compile.txt
 - http://buildbot.openwrt.org:8010/broken_packages/mpc83xx/
 
 because I think atm there is no powerpc support:
 I looked in: https://github.com/seccomp/libseccomp/tree/master/src

Hi Dirk,

pushed a fix, please test it and let me know if the problem is gone

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


Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

2015-03-26 Thread Arjen de Korte

Citeren Steven Barth cy...@openwrt.org:

This breaks clients that need fixed IPs (in my case, mostly webmail  
clients).
I wonder why they are so sensitive to source-address changes since  
their old address is still valid and not deprecated so there is no  
need to switch.


Webmail clients usually don't keep a connection open to the server,  
hence every connection is a new one. The webmail server only sees the  
source IP, so even if the DHCPv6 address is still valid for the  
client, a re-login is needed because the source IP changes.


I would gladly send the DHCPv6 address with 0 preferred lifetime but  
Apple's DHCPv6 client has issues and discard addresses therefore the  
1.



I could create a patch for this, but for now I consider this a  
regression, rather than a feature that needs to be configurable. I  
fail to understand the reasons why this change, which deliberately  
breaks the outgoing addresses (even if only momentarily) was  
introduced.
The reason for this change is that no host seems to support DHCPv6  
reconfiguration so we cannot update clients whenever we see fit  
(e.g. ISP goes down / is switched / designates a different PD).  
Which means that in absence of that in worst case client  
connectivity is lost for T1 seconds.


I don't see how this fixes things then. When ra_management is '2'  
you'd still run into the exact same problem (just without the fallback  
to SLAAC). In contrast, if the ip6prefix is configured statically (as  
in my case), there is no chance this will ever happen, since changes  
will never happen unexpectedly.


I think this would be much better fixed by making the client renew its  
lease more frequently (by lowering the valid and preferred lifetimes).  
The present fix will also not work for anthing else than a /64.

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


[OpenWrt-Devel] seccomp patch lead to build failures

2015-03-26 Thread Dirk Neukirchen
procd: add jail support 45010

leads to build errors on some? arches

On omap I get:
/jail/seccomp-bpf.h:72:3: error: #w$
 # warning Platform does not support seccomp filter yet

which fails the build completely (-Werror issue)

I think there are some issues with other arch/detection when building libseccomp
especially for PowerPC arch:
- 
http://buildbot.openwrt.org:8010/broken_packages/mpc85xx/libseccomp/compile.txt
- http://buildbot.openwrt.org:8010/broken_packages/mpc83xx/

because I think atm there is no powerpc support:
I looked in: https://github.com/seccomp/libseccomp/tree/master/src
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

2015-03-26 Thread Steven Barth


This breaks clients that need fixed IPs (in my case, mostly webmail 
clients).
I wonder why they are so sensitive to source-address changes since their 
old address is still valid and not deprecated so there is no need to switch.


I would gladly send the DHCPv6 address with 0 preferred lifetime but 
Apple's DHCPv6 client has issues and discard addresses therefore the 1.



I could create a patch for this, but for now I consider this a 
regression, rather than a feature that needs to be configurable. I 
fail to understand the reasons why this change, which deliberately 
breaks the outgoing addresses (even if only momentarily) was introduced.
The reason for this change is that no host seems to support DHCPv6 
reconfiguration so we cannot update clients whenever we see fit (e.g. 
ISP goes down / is switched / designates a different PD). Which means 
that in absence of that in worst case client connectivity is lost for T1 
seconds.




Cheers,

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


Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

2015-03-26 Thread Kevin Darbyshire-Bryant
On 26/03/2015 18:36, Arjen de Korte wrote:
 Citeren Steven Barth cy...@openwrt.org:

 In that case, I have a lot of bug reports to file, because none of
 the DHCPv6 clients I tried were happy with preferred lifetimes of 1
 second on their leases (which includes Windows 7, 8.1 and openSUSE
 13.2).
 Sorry, I cannot confirm this. I just tried it with both Windows 8.1
 and Debian testing (w/ network-manager) both didn't react strangely
 or tried to renew the lease every second. Connectivity was okay.

 The constant refreshes were only with the first patch that introduced
 this behavior (sorry for the confusion), with the current odhcpd
 clients will indeed not attempt to renew continuously. But they won't
 be able to use the address provided by DHCPv6 for outgoing connections
 either. They will use the address from SLAAC most of the time, but at
 the time the lease is renewed, switch to the DHCPv6 address and back
 again to SLAAC 1 second later. Although the window of opportunity for
 this to happen may seem to be small, it is enough for webmail clients
 that happen to check for the source IP to require logging in again
 when this happens (twice in a row actually, as the source IP changes
 twice).

 Besides you also get addresses with higher values for preferred
 lifetime using RAs so you always have usable IPv6 addresses, so if
 your network-manager / OS behaves sanely you shouldn't have any
 issues.

 They don't have an issue with IPv6 connectivity, its the source
 address that is used *I* have a problem with.
 Unless you disable RAs there is no way to tell the client which
 source address to pick anyway. If some OS use the DHCPv6 addresses by
 default then thats by chance.

 True. But most OSes will pick either one and will stick to that.
 Windows seems to favor DHCPv6, while Linux by defaults selects SLAAC
 then. Both are OK with me. The problem I have with the current
 implementation in odhcpd, is that systems favoring DHCPv6 will switch
 between the two.

 A work-around for this is setting:
 option ra_management 0
 in the lan-section of /etc/config/dhcp which will cause most
 clients to not use DHCPv6 and rely on RAs only.

 This is not an option, as the whole purpose of using DHCPv6 for
 address configuration is to give clients a fixed IPv6 address. This
 has worked correctly since Barrier Breaker was released, I see no
 reason why it no longer should.
 That still works. The client will just not use the address for
 outgoing traffic.

 This breaks clients that need fixed IPs (in my case, mostly webmail
 clients).

 I'm fine with making this configurable (current behavior as default)
 though and would welcome a patch for this. I could put it on my todo
 but don't really know when I have the time to deal with this.

 I could create a patch for this, but for now I consider this a
 regression, rather than a feature that needs to be configurable. I
 fail to understand the reasons why this change, which deliberately
 breaks the outgoing addresses (even if only momentarily) was introduced.
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

I know this isn't ideal and I've come in late to this discussion, have
you considered using the DHCPv6 functionality in dnsmasq?   I have
strenuously avoided radvd  odhcpv6 in preference for keeping everything
in one place.   I shall now return to my cupboard :-)



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] seccomp patch lead to build failures

2015-03-26 Thread John Crispin


On 26/03/2015 19:47, Kevin Darbyshire-Bryant wrote:
 On 26/03/2015 18:39, John Crispin wrote:

 On 26/03/2015 19:17, Dirk Neukirchen wrote:
 procd: add jail support 45010

 leads to build errors on some? arches

 On omap I get:
 /jail/seccomp-bpf.h:72:3: error: #w$
  # warning Platform does not support seccomp filter yet

 which fails the build completely (-Werror issue)

 I think there are some issues with other arch/detection when building 
 libseccomp
 especially for PowerPC arch:
 - 
 http://buildbot.openwrt.org:8010/broken_packages/mpc85xx/libseccomp/compile.txt
 - http://buildbot.openwrt.org:8010/broken_packages/mpc83xx/

 because I think atm there is no powerpc support:
 I looked in: https://github.com/seccomp/libseccomp/tree/master/src
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


 fix coming up, just started a ppc build to verify
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
 
 Hi John,
 
 Earlier today I was working on some dnsmasq changes.  When I pulled the
 latest updates I was surprised by the (new to me) 'jail' related
 updates.  Is there any documentation that I may be able to read to
 understand how I can update my latest changes and retain compatibility? 

upcoming, i'll write some docs tomorrow

 I was more than surprised to find dnsmasq running as root :-)  I'm

should not be will have a look at that

 guessing this is some sort of 'sandboxing'/chroot/virtual filesystem
 type arrangement but I'm guessing.

yes using namespaces and a staged readonly fs and with seccomp, more
features like cgroups etc coming up.

 
 Many thanks,
 
 Kevin
 
 
 
 ___
 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] seccomp patch lead to build failures

2015-03-26 Thread John Crispin


On 26/03/2015 19:17, Dirk Neukirchen wrote:
 procd: add jail support 45010
 
 leads to build errors on some? arches
 
 On omap I get:
 /jail/seccomp-bpf.h:72:3: error: #w$
  # warning Platform does not support seccomp filter yet
 
 which fails the build completely (-Werror issue)
 
 I think there are some issues with other arch/detection when building 
 libseccomp
 especially for PowerPC arch:
 - 
 http://buildbot.openwrt.org:8010/broken_packages/mpc85xx/libseccomp/compile.txt
 - http://buildbot.openwrt.org:8010/broken_packages/mpc83xx/
 
 because I think atm there is no powerpc support:
 I looked in: https://github.com/seccomp/libseccomp/tree/master/src
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
 


fix coming up, just started a ppc build to verify
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] seccomp patch lead to build failures

2015-03-26 Thread Kevin Darbyshire-Bryant
On 26/03/2015 19:27, John Crispin wrote:


 Hi John,

 Earlier today I was working on some dnsmasq changes.  When I pulled the
 latest updates I was surprised by the (new to me) 'jail' related
 updates.  Is there any documentation that I may be able to read to
 understand how I can update my latest changes and retain compatibility? 
 upcoming, i'll write some docs tomorrow

 I was more than surprised to find dnsmasq running as root :-)  I'm
 should not be will have a look at that

 guessing this is some sort of 'sandboxing'/chroot/virtual filesystem
 type arrangement but I'm guessing.
 yes using namespaces and a staged readonly fs and with seccomp, more
 features like cgroups etc coming up.

 Many thanks,

 Kevin


Thanks John.  Very much appreciated.  Will look out for the docs.



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH 3/3] rb532: switch to 3.18

2015-03-26 Thread Roman Yeryomin
Signed-off-by: Roman Yeryomin ro...@advem.lv
---
 target/linux/rb532/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/rb532/Makefile b/target/linux/rb532/Makefile
index 0a6bd71..e5c6ad7 100644
--- a/target/linux/rb532/Makefile
+++ b/target/linux/rb532/Makefile
@@ -11,7 +11,7 @@ BOARD:=rb532
 BOARDNAME:=Mikrotik RouterBoard 532
 FEATURES:=pci targz
 
-KERNEL_PATCHVER:=3.14
+KERNEL_PATCHVER:=3.18
 
 include $(INCLUDE_DIR)/target.mk
 DEFAULT_PACKAGES += wpad-mini kmod-ath5k kmod-input-rb532
-- 
2.1.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH] syslog: use appropriate levels for logging

2015-03-26 Thread Christian Mehlis
Signed-off-by: Christian Mehlis christ...@m3hlis.de
---
 kmodloader.c  | 2 +-
 log/logread.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/kmodloader.c b/kmodloader.c
index 8f41e74..387678a 100644
--- a/kmodloader.c
+++ b/kmodloader.c
@@ -751,7 +751,7 @@ static int main_loader(int argc, char **argv)
if (scan_module_folders())
return -1;
 
-   syslog(0, kmodloader: loading kernel modules from %s\n, path);
+   syslog(LOG_INFO, kmodloader: loading kernel modules from %s\n, path);
 
if (glob(path, gl_flags, NULL, gl)  0)
goto out;
diff --git a/log/logread.c b/log/logread.c
index a7ab567..871cd5b 100644
--- a/log/logread.c
+++ b/log/logread.c
@@ -79,7 +79,7 @@ static void log_handle_reconnect(struct uloop_timeout 
*timeout)
uloop_timeout_set(retry, 1000);
} else {
uloop_fd_add(sender, ULOOP_READ);
-   syslog(0, Logread connected to %s:%s\n, log_ip, log_port);
+   syslog(LOG_INFO, Logread connected to %s:%s\n, log_ip, 
log_port);
}
 }
 
@@ -154,7 +154,7 @@ static int log_notify(struct blob_attr *msg)
err = send(sender.fd, buf, strlen(buf), 0);
 
if (err  0) {
-   syslog(0, failed to send log data to %s:%s via %s\n,
+   syslog(LOG_INFO, failed to send log data to %s:%s via 
%s\n,
log_ip, log_port, (log_udp) ? (udp) : 
(tcp));
uloop_fd_delete(sender);
close(sender.fd);
-- 
2.3.4.263.gf53fc38
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

2015-03-26 Thread Arjen de Korte

Citeren Steven Barth cy...@openwrt.org:

In that case, I have a lot of bug reports to file, because none of  
the DHCPv6 clients I tried were happy with preferred lifetimes of 1  
second on their leases (which includes Windows 7, 8.1 and openSUSE  
13.2).
Sorry, I cannot confirm this. I just tried it with both Windows 8.1  
and Debian testing (w/ network-manager) both didn't react strangely  
or tried to renew the lease every second. Connectivity was okay.


The constant refreshes were only with the first patch that introduced  
this behavior (sorry for the confusion), with the current odhcpd  
clients will indeed not attempt to renew continuously. But they won't  
be able to use the address provided by DHCPv6 for outgoing connections  
either. They will use the address from SLAAC most of the time, but at  
the time the lease is renewed, switch to the DHCPv6 address and back  
again to SLAAC 1 second later. Although the window of opportunity for  
this to happen may seem to be small, it is enough for webmail clients  
that happen to check for the source IP to require logging in again  
when this happens (twice in a row actually, as the source IP changes  
twice).


Besides you also get addresses with higher values for preferred  
lifetime using RAs so you always have usable IPv6 addresses, so if  
your network-manager / OS behaves sanely you shouldn't have any  
issues.


They don't have an issue with IPv6 connectivity, its the source  
address that is used *I* have a problem with.
Unless you disable RAs there is no way to tell the client which  
source address to pick anyway. If some OS use the DHCPv6 addresses  
by default then thats by chance.


True. But most OSes will pick either one and will stick to that.  
Windows seems to favor DHCPv6, while Linux by defaults selects SLAAC  
then. Both are OK with me. The problem I have with the current  
implementation in odhcpd, is that systems favoring DHCPv6 will switch  
between the two.



A work-around for this is setting:
option ra_management 0
in the lan-section of /etc/config/dhcp which will cause most  
clients to not use DHCPv6 and rely on RAs only.


This is not an option, as the whole purpose of using DHCPv6 for  
address configuration is to give clients a fixed IPv6 address. This  
has worked correctly since Barrier Breaker was released, I see no  
reason why it no longer should.
That still works. The client will just not use the address for  
outgoing traffic.


This breaks clients that need fixed IPs (in my case, mostly webmail clients).

I'm fine with making this configurable (current behavior as default)  
though and would welcome a patch for this. I could put it on my todo  
but don't really know when I have the time to deal with this.


I could create a patch for this, but for now I consider this a  
regression, rather than a feature that needs to be configurable. I  
fail to understand the reasons why this change, which deliberately  
breaks the outgoing addresses (even if only momentarily) was introduced.

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


Re: [OpenWrt-Devel] seccomp patch lead to build failures

2015-03-26 Thread Kevin Darbyshire-Bryant
On 26/03/2015 18:39, John Crispin wrote:

 On 26/03/2015 19:17, Dirk Neukirchen wrote:
 procd: add jail support 45010

 leads to build errors on some? arches

 On omap I get:
 /jail/seccomp-bpf.h:72:3: error: #w$
  # warning Platform does not support seccomp filter yet

 which fails the build completely (-Werror issue)

 I think there are some issues with other arch/detection when building 
 libseccomp
 especially for PowerPC arch:
 - 
 http://buildbot.openwrt.org:8010/broken_packages/mpc85xx/libseccomp/compile.txt
 - http://buildbot.openwrt.org:8010/broken_packages/mpc83xx/

 because I think atm there is no powerpc support:
 I looked in: https://github.com/seccomp/libseccomp/tree/master/src
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


 fix coming up, just started a ppc build to verify
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Hi John,

Earlier today I was working on some dnsmasq changes.  When I pulled the
latest updates I was surprised by the (new to me) 'jail' related
updates.  Is there any documentation that I may be able to read to
understand how I can update my latest changes and retain compatibility? 
I was more than surprised to find dnsmasq running as root :-)  I'm
guessing this is some sort of 'sandboxing'/chroot/virtual filesystem
type arrangement but I'm guessing.

Many thanks,

Kevin



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

2015-03-26 Thread Steven Barth
Radvd isn't part of OpenWrt for a while. dnsmasq doesn't support 
downstream delegation and its DHCPv6 features aren't well integrated if 
you have a dynamic prefix e.g. delegated from your ISP.



Cheers,

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


[OpenWrt-Devel] [PATCH 1/3] rb532: add 3.18 support

2015-03-26 Thread Roman Yeryomin
Signed-off-by: Roman Yeryomin ro...@advem.lv
---
 target/linux/rb532/config-3.18 | 146 +
 .../rb532/patches-3.18/001-cmdline_hack.patch  |  20 +++
 .../rb532/patches-3.18/002-rb532_nand_fixup.patch  |  47 +++
 ...tion_info-rename-rootfs-to-rootfs_onboard.patch |  11 ++
 4 files changed, 224 insertions(+)
 create mode 100644 target/linux/rb532/config-3.18
 create mode 100644 target/linux/rb532/patches-3.18/001-cmdline_hack.patch
 create mode 100644 target/linux/rb532/patches-3.18/002-rb532_nand_fixup.patch
 create mode 100644 
target/linux/rb532/patches-3.18/004-rb532_partition_info-rename-rootfs-to-rootfs_onboard.patch

diff --git a/target/linux/rb532/config-3.18 b/target/linux/rb532/config-3.18
new file mode 100644
index 000..246c5d2
--- /dev/null
+++ b/target/linux/rb532/config-3.18
@@ -0,0 +1,146 @@
+CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
+CONFIG_ARCH_DISCARD_MEMBLOCK=y
+CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
+CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
+CONFIG_ARCH_HIBERNATION_POSSIBLE=y
+CONFIG_ARCH_REQUIRE_GPIOLIB=y
+CONFIG_ARCH_SUSPEND_POSSIBLE=y
+CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
+CONFIG_ATA=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_CEVT_R4K=y
+CONFIG_CLONE_BACKWARDS=y
+CONFIG_CPU_GENERIC_DUMP_TLB=y
+CONFIG_CPU_HAS_PREFETCH=y
+CONFIG_CPU_HAS_SYNC=y
+CONFIG_CPU_LITTLE_ENDIAN=y
+CONFIG_CPU_MIPS32=y
+CONFIG_CPU_MIPS32_R1=y
+CONFIG_CPU_MIPSR1=y
+CONFIG_CPU_R4K_CACHE_TLB=y
+CONFIG_CPU_R4K_FPU=y
+CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y
+CONFIG_CPU_SUPPORTS_HIGHMEM=y
+CONFIG_CRC16=y
+CONFIG_CRYPTO_CRC32C=y
+CONFIG_CRYPTO_HASH=y
+CONFIG_CRYPTO_HASH2=y
+CONFIG_CSRC_R4K=y
+CONFIG_DMA_NONCOHERENT=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+CONFIG_EXT4_FS=y
+CONFIG_FS_MBCACHE=y
+CONFIG_GENERIC_ATOMIC64=y
+CONFIG_GENERIC_CLOCKEVENTS=y
+CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_IO=y
+CONFIG_GENERIC_IRQ_SHOW=y
+CONFIG_GENERIC_PCI_IOMAP=y
+CONFIG_GENERIC_SMP_IDLE_THREAD=y
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_DEVRES=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_HARDWARE_WATCHPOINTS=y
+CONFIG_HAS_DMA=y
+CONFIG_HAS_IOMEM=y
+CONFIG_HAS_IOPORT=y
+# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
+CONFIG_HAVE_ARCH_JUMP_LABEL=y
+CONFIG_HAVE_ARCH_KGDB=y
+# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
+CONFIG_HAVE_C_RECORDMCOUNT=y
+CONFIG_HAVE_DEBUG_KMEMLEAK=y
+CONFIG_HAVE_DMA_API_DEBUG=y
+CONFIG_HAVE_DMA_ATTRS=y
+CONFIG_HAVE_DYNAMIC_FTRACE=y
+CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
+CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
+CONFIG_HAVE_FUNCTION_TRACER=y
+CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
+CONFIG_HAVE_GENERIC_DMA_COHERENT=y
+CONFIG_HAVE_GENERIC_HARDIRQS=y
+CONFIG_HAVE_IDE=y
+CONFIG_HAVE_MEMBLOCK=y
+CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
+CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
+CONFIG_HAVE_NET_DSA=y
+CONFIG_HAVE_OPROFILE=y
+CONFIG_HAVE_PERF_EVENTS=y
+# CONFIG_HIGH_RES_TIMERS is not set
+CONFIG_HW_HAS_PCI=y
+CONFIG_HW_RANDOM=y
+CONFIG_HZ=250
+# CONFIG_HZ_100 is not set
+CONFIG_HZ_250=y
+CONFIG_HZ_PERIODIC=y
+CONFIG_IMAGE_CMDLINE_HACK=y
+CONFIG_INITRAMFS_SOURCE=
+CONFIG_IRQ_CPU=y
+CONFIG_IRQ_FORCED_THREADING=y
+CONFIG_IRQ_WORK=y
+CONFIG_JBD2=y
+CONFIG_KEXEC=y
+CONFIG_KORINA=y
+CONFIG_LEDS_MIKROTIK_RB532=y
+CONFIG_MIKROTIK_RB532=y
+CONFIG_MIPS=y
+# CONFIG_MIPS_HUGE_TLB_SUPPORT is not set
+CONFIG_MIPS_L1_CACHE_SHIFT=4
+# CONFIG_MIPS_MACHINE is not set
+CONFIG_MIPS_MT_DISABLED=y
+CONFIG_MODULES_USE_ELF_REL=y
+CONFIG_MTD_BLOCK2MTD=y
+CONFIG_MTD_CFI_ADV_OPTIONS=y
+# CONFIG_MTD_CFI_AMDSTD is not set
+CONFIG_MTD_CFI_GEOMETRY=y
+# CONFIG_MTD_CFI_INTELEXT is not set
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_ECC=y
+CONFIG_MTD_NAND_PLATFORM=y
+CONFIG_MTD_PHYSMAP=y
+# CONFIG_MTD_ROOTFS_ROOT_DEV is not set
+CONFIG_MTD_ROOTFS_SPLIT=y
+# CONFIG_MTD_SM_COMMON is not set
+# CONFIG_MTD_SPLIT is not set
+CONFIG_NEED_DMA_MAP_STATE=y
+CONFIG_NEED_PER_CPU_KM=y
+CONFIG_NO_GENERIC_PCI_IOPORT_MAP=y
+CONFIG_PAGEFLAGS_EXTENDED=y
+CONFIG_PATA_RB532=y
+CONFIG_PCI=y
+CONFIG_PCI_DISABLE_COMMON_QUIRKS=y
+CONFIG_PCI_DOMAINS=y
+CONFIG_PERF_USE_VMALLOC=y
+# CONFIG_PREEMPT_RCU is not set
+CONFIG_RC32434_WDT=y
+# CONFIG_RCU_STALL_COMMON is not set
+CONFIG_SCSI=y
+# CONFIG_SCSI_LOWLEVEL is not set
+# CONFIG_SCSI_MULTI_LUN is not set
+# CONFIG_SCSI_PROC_FS is not set
+# CONFIG_SWAP is not set
+CONFIG_SWAP_IO_SPACE=y
+CONFIG_SYS_HAS_CPU_MIPS32_R1=y
+CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y
+CONFIG_SYS_SUPPORTS_ARBIT_HZ=y
+CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y
+CONFIG_TICK_CPU_ACCOUNTING=y
+CONFIG_UIDGID_CONVERTED=y
+CONFIG_USB_ARCH_HAS_XHCI=y
+CONFIG_VIA_RHINE=y
+CONFIG_VIA_RHINE_MMIO=y
+CONFIG_YAFFS_9BYTE_TAGS=y
+# CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED is not set
+CONFIG_YAFFS_AUTO_YAFFS2=y
+# CONFIG_YAFFS_DISABLE_BACKGROUND is not set
+# CONFIG_YAFFS_DISABLE_BLOCK_REFRESHING is not set
+# CONFIG_YAFFS_DISABLE_TAGS_ECC is not set
+# CONFIG_YAFFS_EMPTY_LOST_AND_FOUND is not set
+CONFIG_YAFFS_FS=y
+CONFIG_YAFFS_XATTR=y
+CONFIG_YAFFS_YAFFS1=y
+CONFIG_YAFFS_YAFFS2=y

[OpenWrt-Devel] [PATCH 2/3] rb532: align partitions to 128KB

2015-03-26 Thread Roman Yeryomin
because block2mtd wants erasesize must be a divisor of device size since 3.15

Signed-off-by: Roman Yeryomin ro...@advem.lv
---
 target/linux/rb532/image/Makefile | 10 +-
 target/linux/rb532/image/gen_image.sh |  3 ++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/target/linux/rb532/image/Makefile 
b/target/linux/rb532/image/Makefile
index 706c768..284b3d4 100644
--- a/target/linux/rb532/image/Makefile
+++ b/target/linux/rb532/image/Makefile
@@ -63,10 +63,18 @@ define Image/cmdline/yaffs2
 root=/dev/mtdblock1 rootfstype=yaffs2
 endef
 
+define Image/Build/squashfs
+   $(call prepare_generic_squashfs,$(KDIR)/root.squashfs)
+endef
+
 define Image/Build
+   $(call Image/Build/$(1),$(1))
$(CP) $(KDIR)/vmlinux.elf $(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel
$(STAGING_DIR_HOST)/bin/patch-cmdline 
$(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel '$(strip $(call Image/cmdline/$(1))) '
-   ./gen_image.sh $(BIN_DIR)/$(IMG_PREFIX)-combined-$(1).bin 4 
$(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel $(CONFIG_TARGET_ROOTFS_PARTSIZE) 
$(KDIR)/root.$(1)
+   ./gen_image.sh $(BIN_DIR)/$(IMG_PREFIX)-combined-$(1).bin \
+   4 $(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel \
+   $(CONFIG_TARGET_ROOTFS_PARTSIZE) $(KDIR)/root.$(1) \
+   128
 endef
 
 $(eval $(call BuildImage))
diff --git a/target/linux/rb532/image/gen_image.sh 
b/target/linux/rb532/image/gen_image.sh
index 8875834..a2d6f40 100755
--- a/target/linux/rb532/image/gen_image.sh
+++ b/target/linux/rb532/image/gen_image.sh
@@ -4,11 +4,12 @@ KERNELSIZE=$2
 KERNELIMAGE=$3
 ROOTFSSIZE=$4
 ROOTFSIMAGE=$5
+ALIGN=$6
 
 rm -f $OUTPUT
 
 # create partition table
-set `ptgen -o $OUTPUT -h 16 -s 32 -t 0x27 -p ${KERNELSIZE}m -t 0x83 -p 
${ROOTFSSIZE}m`
+set `ptgen -o $OUTPUT -h 16 -s 32 -l ${ALIGN} -t 0x27 -p ${KERNELSIZE}m -t 
0x83 -p ${ROOTFSSIZE}m`
 
 KERNELOFFSET=$(($1 / 512))
 ROOTFSOFFSET=$(($3 / 512))
-- 
2.1.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

2015-03-26 Thread Steven Barth




In that case, I have a lot of bug reports to file, because none of the 
DHCPv6 clients I tried were happy with preferred lifetimes of 1 second 
on their leases (which includes Windows 7, 8.1 and openSUSE 13.2).
Sorry, I cannot confirm this. I just tried it with both Windows 8.1 and 
Debian testing (w/ network-manager) both didn't react strangely or tried 
to renew the lease every second. Connectivity was okay.




Besides you also get addresses with higher values for preferred 
lifetime using RAs so you always have usable IPv6 addresses, so if 
your network-manager / OS behaves sanely you shouldn't have any issues.


They don't have an issue with IPv6 connectivity, its the source 
address that is used *I* have a problem with.
Unless you disable RAs there is no way to tell the client which source 
address to pick anyway. If some OS use the DHCPv6 addresses by default 
then thats by chance.





A work-around for this is setting:
option ra_management 0
in the lan-section of /etc/config/dhcp which will cause most clients 
to not use DHCPv6 and rely on RAs only.


This is not an option, as the whole purpose of using DHCPv6 for 
address configuration is to give clients a fixed IPv6 address. This 
has worked correctly since Barrier Breaker was released, I see no 
reason why it no longer should.
That still works. The client will just not use the address for outgoing 
traffic. I'm fine with making this configurable (current behavior as 
default) though and would welcome a patch for this. I could put it on my 
todo but don't really know when I have the time to deal with this.




Cheers,

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