Re: [OpenWrt-Devel] AT91: what's happening ?
Hi Christian Gagneraud, Il 23 aprile 2012 14:52, Christian Gagneraud ha scritto: > Hi all, > > I've manifested my interest in the AT91 a couple of weeks ago, and nobody > even answer any of my calls. > I would like to work hand in hand with other peoples that use AT91 based > boards. > Obviously, someone started some important modifications on the at91 > directory, which look like a good idea to me, but my point is that why this > person never speak about these changes on the mailing list. > One of the big change is the linux version bump, now it seems that it has to > be the untested 3.3.2 instead of the working 2.6.38.8. Well, important changes was applied to at91 target and subtarget, as you can see those improvement is not only related to the at91 target but to the whole OpenWrt project. Our intention is to update all target to latest kernel and than make a new release soon, so the kernel dump is a the first step in this direction. > Could this person gives details on what the plans are for the AT91 target? > Maybe we could share some thoughts and ideas. > > I have access to the stamp9G20 and the portux9G20, so i can tests these two > boards. I really would like to help and contribute, but it would be nice if > the plans are known in advance. > The spare time is always a rare resource and the facto I didn't develop this target until a couple of days ago. So I start to read all the missing think that was remarked on mailing list (few topics in a years, not exactly a famous platform) and also your interest to stampg20 was noted. The Stampg20 is now merged with the old netus subtaget inside the new 9g20 subtarget, the reorganization was mainly done to avoid the increase of subtarget that are all using the same SoC. https://dev.openwrt.org/browser/trunk/target/linux/at91/9g20/config-default The default image generated by buildbot should work on StampG20, and other G20 card enabled as well. Hope that this can help. Claudio PS I just discover that some empty directories are not deleted by the git dcommit and it is really frustating to deal with svn-git inteoperability issues... some additional cleanup will follow. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Test
Hi, I had problems sending mails to the list yesterday. Please ignore this test. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: implement new config "root_readonly" (RESENT)
Don't use format=flowed.
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
On 4/21/12 6:50 PM, ching wrote:
> sorry again, the previous email subject is wrong
>
> I don't know why my attachment is detected as binary, i reposted it here
> as plain text
>
> Index: trunk/package/base-files/files/etc/init.d/boot
> ===
> --- trunk/package/base-files/files/etc/init.d/boot(revision 31391)
> +++ trunk/package/base-files/files/etc/init.d/boot(working copy)
> @@ -7,7 +7,11 @@
> system_config() {
> local cfg="$1"
>
> -local hostname conloglevel timezone
> +local hostname conloglevel timezone root_readonly
> +
> +#remount root as readonly
> +config_get root_readonly "$cfg" root_readonly '0'
> +[ "$root_readonly" -eq 1 ]&& mount -o remount,ro /
>
> config_get hostname "$cfg" hostname 'OpenWrt'
> echo "$hostname"> /proc/sys/kernel/hostname
>
>
>
>
> On Sunday, April 22, 2012 01:44 AM,
> openwrt-devel-requ...@lists.openwrt.org wrote:
>> --
>>
>> Date: Sat, 21 Apr 2012 20:54:44 +0800
>> From: ching
>> To: openwrt-devel@lists.openwrt.org
>> Subject: [OpenWrt-Devel] [PATCH] base-files: implement new config
>> "root_readonly" (RESENT)
>> Message-ID:<4f92ae14@gmail.com>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>
>> In the view of user, we always hard power-off router, and do not expect
>> any unexpected background flashing which can lead to fs corruption.
>>
>> As the number of package of OpenWRT increases, the probability of
>> unexpected background flashing will increase.
>>
>> Although OpenWRT developers are brilliant and hard-working, it is
>> impossible to guarantee all packages are bug-free.
>>
>> This change try to implement a new config "root_readonly" in
>> /etc/config/system, which will remount root to read only when reading
>> system config during boot process. This should prevent background flashing.
>>
>> root_readonly=0 #0 - root will be read-write, 1 - root will be read-only
>>
>> Assumption
>> 1. Early boot process do not trigger unnecessary flashing
>> 2. default setting=0 (read-write) to preserve backward compatibility
>> 3. user know how to remount root rw manually if he/she set this option
>>
>> Signed-off-by: ching
>>
>> 1 files changed
>>
>> -- next part --
>> A non-text attachment was scrubbed...
>> Name: root_readonly.patch
>> Type: text/x-patch
>> Size: 635 bytes
>> Desc: not available
>>
>> URL:
>>
>> --
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, though really OT, its a really important point for a "Router-Distro" as which I love OpenWRT; so I'd want to explain my point. And I also read the RIPE-lists where I often have to swallow *not* to respond to all those IPv6-hurrays which arent present in real world IMHO.. First of all, don't get me wrong, I'm technically not against IPv6, we're even offering it for customers (without any extra-price on top) it's just a fact that 0,000% ever asked for (or would pay a cent more for having it), because 100% are running v4.. Am 23.04.2012 11:26, schrieb Gert Doering: > There are ISPs in Asia today(!) that *will* *not* give you an IPv4 > address, because they have none left. Ok, but I have over 10 sites far east with IPv4 running.. not representative/much but well, it works right here&now. And I'm sure they have some measures to reach 99% of the Internet on this planet through IPv4.. (I remember the IPv6-day last year, it was funny, even Google failed 30-50%..) OTOH, none of my upstreams gives me native IPv6, only tunnel-crap at best (I won't name them, AS42283 for anyone who could Google/read BGP..) So give me one reason to change Upstream, make me 2 weeks of work and maybe pay more, just to be able to participate in this big experiment. > IPv6 is most relevant to real-life. I came along without so far ;) Though, again, I could have it running, just don't want as I see no need and many risks/problems.. > Many of the problems we see in IPv6 deployments are caused exactly > by this attitude Agreed but lets get realisitic, my objectives (home, office & customers) are: 1) security 2) it works 3) technically perfect v6 only meets #3.. Do you expect any DSL user or Soho-Admin which doesn't even understand what an (IPv4) Subnet-mask is to understand that.. a) It's a big security risk at first as noone really knows whats going on with IPv6 (at least on customer/user-side!) So the first thing before even considering it, is the Firewall on the router (here: OpenWRT) should be at least as closed as for IPv4 with NAT by default. Is it? Or whats happens if John Doe gets assigned a /64 or John Does Company a /48? Anyone on this planet could Airplay in her/his home, funny :p They are at first widely open, with current OS's having IPv6 happily enabled by default. Thats IMHO a real problem.. I spend more time telling my customers what this really means than why they need v6 sometime in future.. That beams the Internet back to 1990, where you just trusted that the others won't do no harm anyway, the only current protection is IMHO that noone knows, how to exploit it.. b) As you mentioned in later posts, it's a pain mixed with more pain, 6to4, 6rd, causes timeouts, problems, troubles (how do I teach that my 6 Cisco Border-Routers? oh well I could buy new ones with 8x RAM etc..)-> which end-user wants them and - who pays for? Noone.. To find some conclusion at least for myself, as soon as deploying IPv6 on End-Users is painless *and at least as secure as v4 with NAT* I'd think about to enable it - and happy to work on. But really, currently I dont see this on the horizon. Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+V3O0ACgkQaWRHV2kMuAJo8wCfW8NxeKWuO1TLf+uCcMX9M0WV It4AoKaSiswc9vLWuQaGbanOWpojq7Bg =FrSy -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Comprehensive ipv4 and ipv6 unaligned access, patch for ar71xx
On Mon, 2012-04-23 at 22:32 +0200, Gert Doering wrote: > On Mon, Apr 23, 2012 at 07:43:36PM +0100, David Woodhouse wrote: > > It's documented here: http://wiki.openwrt.org/doc/uci/dhcp6c > > Oh! This is tremendously cool! Thanks to everyone who made that > possible. > > Nit to pick: calling this "sla_len" is a bit weird. Especially if > you don't know whether the ISP will assign a /48, /56 or /60, this > sounds a bit awkward to ensure /64 on an interface - or am I > misreading this? No, I think you have it right. I've just routed individual /64s to my ADSL lines before, and I see just one of them advertised in DHCPv6 PD. Not quite sure why they aren't all listed. I added a fresh /60 to my line and saw it advertised, but then I had to tweak the the sla_len to match before anything more would work. It doesn't make sense - we ought to be able to say "give the first /64 to the wired lan", "give the second to wireless", etc. Then if we get separate /64s or a larger delegation it should just dish it out accordingly. We shouldn't have to calculate and preconfigure sla_len. > > We should make sure it's enabled by default. > > That, and IPv6 for PPP (for PPP-enabled WAN interfaces). Definitely. There's almost no chance that trying IPv6CP would cause a problem; you'll just get a ProtRej from 20th century servers. It's just the same as CCP with servers that don't want it. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Comprehensive ipv4 and ipv6 unaligned access, patch for ar71xx
Hi, On Mon, Apr 23, 2012 at 01:33:00PM -0700, Dave Taht wrote: > > (And no, I wouldn't advocate 6to4 being enabled by default anyway). > > I had it enabled by default during comcast's trials. It worked great, > on their network (and having a /48 was good too). It didn't work very > well elsewhere, so it's in there, but disabled by default. > > I also have HE tunnels and 6rd working. > > I'm more of the opinion that ipv6 needs to be made to work, using > every method possible, and if possible, those methods should be able > to co-exist, using policy routing. That proves to be hard. We're getting a bit off-topic, I'm afraid, but I need to add a rant here :-) I think that HE+6rd are useful transition technologies, while 6to4 is harmful, and "no IPv6" is much better than "only via 6to4". Let me explain: The problem with 6to4 as the sole connection "to the IPv6 world" is the anycast relays, so you have no control over the return paths - *and*, to add insult to injury, people are known to drop proto-41 packets coming *back* from the relays, so users end up with blackholes. So "SYN - timeout - SYN - timeout - SYN - timeout" instead of "SYN - immediate 'no route to host' - fallback to IPv4" if you have no IPv6 at all. There are no IPv6-only services out there today, and turning on 6to4 with its associated risk of having unreliable and slow connections to random *parts* of the IPv6 world is doing IPv6 a disservice - users will discover "things get faster if I turn off IPv6", spread that lore, and that's not useful. (Now there are certainly cases where 6to4 is useful - if you are talking 6to4-to-6to4 only, routing only 2002::/16 into the 6to4 tunnel. But please do not, never ever, point a default route to the 6to4 tunnel, unless the user has explicitly asked for it). (*) 6rd is OK, even if using the same underlying "tech" as 6to4, because unlike 6to4, it knows it's relay, and the path to and from the relay is inside the ISP's domain - so you actually have someone who can troubleshoot issues, and latency is likely to be as good as IPv4. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgp9CNxWxuUdp.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Comprehensive ipv4 and ipv6 unaligned access, patch for ar71xx
Hi, On Mon, Apr 23, 2012 at 07:43:36PM +0100, David Woodhouse wrote: > It's documented here: http://wiki.openwrt.org/doc/uci/dhcp6c Oh! This is tremendously cool! Thanks to everyone who made that possible. Nit to pick: calling this "sla_len" is a bit weird. Especially if you don't know whether the ISP will assign a /48, /56 or /60, this sounds a bit awkward to ensure /64 on an interface - or am I misreading this? Anyway, finally need to get my act together and setup the ISP-side of DHCP-PD - so far, our IPv6 customers had manually-configured IPv6 prefixes, but I *want* DHCP-PD so "off-the-shelf CPEs" will work just automatically, and this is enough of an incentive to get going :-) > I haven't actually tried it; I have to manually configure the range of > Legacy IP addresses anyway, so it's easy enough to configure the IPv6 > too. But I *will* try it, and make sure it interoperates with my ISP > correctly. > > We should make sure it's enabled by default. That, and IPv6 for PPP (for PPP-enabled WAN interfaces). > There should be no need for anyone to disable IPv6, except perhaps if > they mean by that "turn off automatic 6to4". If they're stuck in the > 20th century and don't have IPv6 routing, they won't get IPv6. What's to > disable? +1, and do *not* turn on "automatic 6to4" - that's known to be harmful, and "no IPv6" is much more useful today than "IPv6 only via 6to4". > (And no, I wouldn't advocate 6to4 being enabled by default anyway). +1 :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpYFxWQZWPP8.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Comprehensive ipv4 and ipv6 unaligned access, patch for ar71xx
On Mon, Apr 23, 2012 at 11:43 AM, David Woodhouse wrote: > On Mon, 2012-04-23 at 20:14 +0200, Gert Doering wrote: >> (Now, what I'm not sure whether OpenWRT already has this: to fully >> utilize IPv6 over here, what you need to have is dynamic IPv6 prefix >> support using DHCP-PD. As in "router queries ISP for a prefix, ISP >> assigns 2001:db8:1::/56, router assigns 2001:db8:1:1::/64 to LAN, >> 2001:db8:1:2::/64 for WiFi and informs radvd that this is the prefix >> to be used". AVM's Fritz!Box does this nicely today, but not with >> open source components...) > > It's documented here: http://wiki.openwrt.org/doc/uci/dhcp6c > > I haven't actually tried it; I have to manually configure the range of > Legacy IP addresses anyway, so it's easy enough to configure the IPv6 > too. But I *will* try it, and make sure it interoperates with my ISP > correctly. It has long been a goal of mine to have both cerowrt and openwrt builds ready for world ipv6 launch day and be able to fully meet this spec: http://www.worldipv6launch.org/form/?q=3 I'd like to think I'm close. But truly getting there will require more folk to want to do it, by that date. Please goferit! All the machines in the bloatlab are native dual-stack (see, for example, http://europa.lab.bufferbloat.net/cerowrt/ ), and I have several running dhcp-pd, sorta. It's my last remaining bug. I tried dibbler (crashes after 24 hrs), and isc-dhcp (too big, too complex) and have fallen back to wide. I have reports of it working in New Zealand. The biggest problem that I have (in America, at least) is that comcast's first rollout is only going to be a single /64 delegation, which breaks cerowrt's multiple interface scheme, but will hopefully work ok with openwrt. Still, /64 only is crazy and I'm told they intend to do better by fall. Certainly other providers are handing out /56s and /60s. > We should make sure it's enabled by default. Latest build for me, wide-dhcpv6 is installed but not enabled by default. After some testing, it will. > There should be no need for anyone to disable IPv6, except perhaps if > they mean by that "turn off automatic 6to4". If they're stuck in the > 20th century and don't have IPv6 routing, they won't get IPv6. What's to > disable? > > (And no, I wouldn't advocate 6to4 being enabled by default anyway). I had it enabled by default during comcast's trials. It worked great, on their network (and having a /48 was good too). It didn't work very well elsewhere, so it's in there, but disabled by default. I also have HE tunnels and 6rd working. I'm more of the opinion that ipv6 needs to be made to work, using every method possible, and if possible, those methods should be able to co-exist, using policy routing. That proves to be hard. > > -- > dwmw2 > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] kmod-rfkill dependencies
In package/kernel/modules/001-depends.mk there are the following lines: define SetDepends/rfkill DEPENDS:= @(TARGET_ar71xx||TARGET_brcm47xx||TARGET_s3c24xx||TARGET_x86||TARGET_gemini) endef - define AddDepends/rfkill DEPENDS+= +(TARGET_ar71xx||TARGET_brcm47xx||TARGET_s3c24xx||TARGET_x86):kmod-rfkill $(1) endef This means "rfkill" does not show up as an option in menuconfig unless one is building for one of these targets. I have a Bluetooth USB dongle and may need/use rfkill, what is the reason for these dependencies? Also, I noticed that "TARGET_gemini" is part of the first set but not the second - intentionally? Thanks, Jeroen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/2] [luci] Add openconnect support
Signed-off-by: David Woodhouse
---
contrib/package/luci/Makefile |1 +
protocols/openconnect/Makefile |2 +
.../model/cbi/admin_network/proto_openconnect.lua | 62 +++
.../luasrc/model/network/proto_openconnect.lua | 63
4 files changed, 128 insertions(+), 0 deletions(-)
create mode 100644 protocols/openconnect/Makefile
create mode 100644
protocols/openconnect/luasrc/model/cbi/admin_network/proto_openconnect.lua
create mode 100644
protocols/openconnect/luasrc/model/network/proto_openconnect.lua
diff --git a/contrib/package/luci/Makefile b/contrib/package/luci/Makefile
index 0f590fe..398ab11 100644
--- a/contrib/package/luci/Makefile
+++ b/contrib/package/luci/Makefile
@@ -214,6 +214,7 @@ endef
$(eval $(call protocol,core,Support for static/dhcp/none))
$(eval $(call protocol,ppp,Support for PPP/PPPoE/PPPoA))
$(eval $(call protocol,pptp,Support for PPtP,+pptp))
+$(eval $(call protocol,openconnect,Support for OpenConnect VPN,+openconnect))
$(eval $(call protocol,6x4,Support for 6in4/6to4,+6in4 +6to4))
$(eval $(call protocol,3g,Support for 3G,+comgt))
$(eval $(call protocol,relay,Support for relayd pseudo
bridges,+PACKAGE_luci-proto-relay:relayd))
diff --git a/protocols/openconnect/Makefile b/protocols/openconnect/Makefile
new file mode 100644
index 000..f7fac77
--- /dev/null
+++ b/protocols/openconnect/Makefile
@@ -0,0 +1,2 @@
+include ../../build/config.mk
+include ../../build/module.mk
diff --git
a/protocols/openconnect/luasrc/model/cbi/admin_network/proto_openconnect.lua
b/protocols/openconnect/luasrc/model/cbi/admin_network/proto_openconnect.lua
new file mode 100644
index 000..9746c26
--- /dev/null
+++ b/protocols/openconnect/luasrc/model/cbi/admin_network/proto_openconnect.lua
@@ -0,0 +1,62 @@
+--[[
+LuCI - Lua Configuration Interface
+
+Copyright 2011 Jo-Philipp Wich
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+]]--
+
+local map, section, net = ...
+
+local server, username, password
+local buffering, defaultroute, metric, peerdns, dns
+
+
+server = section:taboption("general", Value, "server", translate("VPN Server"))
+server.datatype = "host"
+port = section:taboption("general", Value, "port", translate("VPN Server
port"))
+
+port.placeholder = "443"
+port.datatype= "port"
+
+cookie = section:taboption("advanced", Value, "cookie", translate("Cookie"))
+cookie.password = true
+
+username = section:taboption("general", Value, "username",
translate("Username"))
+password = section:taboption("general", Value, "password",
translate("Password"))
+password.password = true
+--[[
+
+defaultroute = section:taboption("advanced", Flag, "defaultroute",
+ translate("Use default gateway"),
+ translate("If unchecked, no default route is configured"))
+
+defaultroute.default = defaultroute.enabled
+
+
+metric = section:taboption("advanced", Value, "metric",
+ translate("Use gateway metric"))
+
+metric.placeholder = "0"
+metric.datatype= "uinteger"
+metric:depends("defaultroute", defaultroute.enabled)
+
+
+peerdns = section:taboption("advanced", Flag, "peerdns",
+ translate("Use DNS servers advertised by peer"),
+ translate("If unchecked, the advertised DNS server addresses are
ignored"))
+
+peerdns.default = peerdns.enabled
+
+
+dns = section:taboption("advanced", DynamicList, "dns",
+ translate("Use custom DNS servers"))
+
+dns:depends("peerdns", "")
+dns.datatype = "ipaddr"
+dns.cast = "string"
+]]--
diff --git a/protocols/openconnect/luasrc/model/network/proto_openconnect.lua
b/protocols/openconnect/luasrc/model/network/proto_openconnect.lua
new file mode 100644
index 000..55bde0e
--- /dev/null
+++ b/protocols/openconnect/luasrc/model/network/proto_openconnect.lua
@@ -0,0 +1,63 @@
+--[[
+LuCI - Network model - 3G, PPP, PPtP, PPPoE and PPPoA protocol extension
+
+Copyright 2011 Jo-Philipp Wich
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+
+]]--
+
+local netmod = luci.model.network
+local interface = luci.model.network.interface
+local proto = netmod:register_protocol("openconnect")
+
+function proto.get_i18n(self)
+ return luci.i18n.translate("Cisco AnyConnect (openconnect)")
+end
+
+function proto.ifname(self)
+ return "vpn-" .. self.sid
+end
+
+function proto.
Re: [OpenWrt-Devel] Comprehensive ipv4 and ipv6 unaligned access, patch for ar71xx
On Mon, 2012-04-23 at 20:14 +0200, Gert Doering wrote: > (Now, what I'm not sure whether OpenWRT already has this: to fully > utilize IPv6 over here, what you need to have is dynamic IPv6 prefix > support using DHCP-PD. As in "router queries ISP for a prefix, ISP > assigns 2001:db8:1::/56, router assigns 2001:db8:1:1::/64 to LAN, > 2001:db8:1:2::/64 for WiFi and informs radvd that this is the prefix > to be used". AVM's Fritz!Box does this nicely today, but not with > open source components...) It's documented here: http://wiki.openwrt.org/doc/uci/dhcp6c I haven't actually tried it; I have to manually configure the range of Legacy IP addresses anyway, so it's easy enough to configure the IPv6 too. But I *will* try it, and make sure it interoperates with my ISP correctly. We should make sure it's enabled by default. There should be no need for anyone to disable IPv6, except perhaps if they mean by that "turn off automatic 6to4". If they're stuck in the 20th century and don't have IPv6 routing, they won't get IPv6. What's to disable? (And no, I wouldn't advocate 6to4 being enabled by default anyway). -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Comprehensive ipv4 and ipv6 unaligned access, patch for ar71xx
Hi, On Mon, Apr 23, 2012 at 10:40:00AM -0700, Bill Moffitt wrote: > On the subject of being able to turn off V6, I agree with both sides, > but with a caveat. > > On one side, V6 is necessary today in Asia, but, on the other had, it's > not at all necessary or even desirable yet in North America and Europe, > so I think it is desirable to be able to turn it off. I agree with that. Giving people options is always welcome (especially on memory- or flash-limited platforms where every single byte counts). Can I have --disable-ipv4 for everything, please? Most everything I do these days is done over IPv6, except for web surfing to some minor sites. > Right now I don't know of a consumer ISP in North America that will GIVE > you an IPv6 address, never mind require it, although some business ISPs > tout V6 routing. Comcast will give you IPv6 in America (though not everywhere yet, just rolling out out). T-Mobile USA is beta-testing it on their 3G network. Almost all business ISPs have it in their portfolio now - since smaller ISPs have been asking for it for over 10 years now, larger ISPs had to deliver. > Because of the foot-dragging in rolling out V6, I believe that adoption > is not going to be a gradual affair - I believe that, at some point, > someone (probably in Asia) is going to invent the "Next Big Thing that > Everybody HAS to HAVE," (i.e. the next new Google, Facebook, Twitter, > Pinterest, Dropbox, whatever) and it will only be accessible via V6. At > that point, everyone in North America and Europe will suddenly change > from ignoring V6 to HAVING TO HAVE IT RIGHT NOW!!! The "next big thing" is "being able to communicate with your customers, or with your friends, or remote VPN users that happen to be in Asia". Even in Europe, we're already seeing large-scale ISPs move towards "customers will not get a public IPv4 address anymore, just a private address and be NATted" - so goodbye to dyndns-provided home accessibility, etc. (Telefonica announced this end of last year for Spain) > I believe the ISPs will mostly be blindsided - the few who thought that > this might happen will be able to move users to V6 and will be "winners" > in this scenario, while those who didn't plan ahead (or thought they'd > be able to move people gradually to v6) will be roasted alive in the > court of consumer opinion. It will be a "crisis" that "no one could have > predicted." Indeed, for many people this will come as a complete surprise and nasty shock. Others will just laugh. > While we consumers in N. America and Europe can still afford to be > complacent for a while, I think that we, as OpenWRT developers, need to > be very diligent in ensuring OpenWRT "plays well" on V6 in anticipation > of this event, should it come to pass. It may be a nice opportunity for > OpenWRT to get some nice publicity by "saving the day" when the "crisis" > occurs. OpenWRT is already pretty good :-) (Now, what I'm not sure whether OpenWRT already has this: to fully utilize IPv6 over here, what you need to have is dynamic IPv6 prefix support using DHCP-PD. As in "router queries ISP for a prefix, ISP assigns 2001:db8:1::/56, router assigns 2001:db8:1:1::/64 to LAN, 2001:db8:1:2::/64 for WiFi and informs radvd that this is the prefix to be used". AVM's Fritz!Box does this nicely today, but not with open source components...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpMdT5VSf5C3.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Comprehensive ipv4 and ipv6 unaligned access, patch for ar71xx
On Mon, 2012-04-23 at 10:40 -0700, Bill Moffitt wrote: > > > On the subject of being able to turn off V6, I agree with both sides, > but with a caveat. > > On one side, V6 is necessary today in Asia, but, on the other had, it's > not at all necessary or even desirable yet in North America and Europe, > so I think it is desirable to be able to turn it off. I've been using IPv6 for years, and have lost count of the number of times that it saved connectivity between my machines when Legacy IP wasn't working. > Right now I don't know of a consumer ISP in North America that will GIVE > you an IPv6 address, never mind require it, although some business ISPs > tout V6 routing. They certainly exist in the UK. The ISP I use, Andrews and Arnold, are in their tenth year of providing IPv6. We get native IPv6 alongside the Legacy IP on the ADSL line (via PPPoATM or PPPoEoA) and all their services are available over IPv6. > Because of the foot-dragging in rolling out V6, I believe that adoption > is not going to be a gradual affair - I believe that, at some point, > someone (probably in Asia) is going to invent the "Next Big Thing that > Everybody HAS to HAVE," (i.e. the next new Google, Facebook, Twitter, > Pinterest, Dropbox, whatever) and it will only be accessible via V6. At > that point, everyone in North America and Europe will suddenly change > from ignoring V6 to HAVING TO HAVE IT RIGHT NOW!!! You mean the dancing kame and www.loopsofzen.co.uk aren't considered killer apps? :) > While we consumers in N. America and Europe can still afford to be > complacent for a while, I think that we, as OpenWRT developers, need to > be very diligent in ensuring OpenWRT "plays well" on V6 in anticipation > of this event, should it come to pass. It may be a nice opportunity for > OpenWRT to get some nice publicity by "saving the day" when the "crisis" > occurs. OpenWrt already works fairly well. For consumer use there are a couple of things that need to be improved — firstly it needs to obtain a prefix from the ISP by DHCPv6, to be advertised on the internal subnets. I think this is mostly already supportable, but not enabled out-of-the-box. It should be. If the ISP *doesn't* provide DHCPv6, there's no harm. We should make sure SiXXS (via aiccu) and other tunnels re very simple to set up, too. I concede I haven't looked at those since I don't need them. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] svn.openwrt.org down?
Hi - ./script/feeds update -a can't connect. Connection refused. Other feeds are working fine. Cheers, Elektra -- Elektra ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Comprehensive ipv4 and ipv6 unaligned access, patch for ar71xx
On the subject of being able to turn off V6, I agree with both sides, but with a caveat. On one side, V6 is necessary today in Asia, but, on the other had, it's not at all necessary or even desirable yet in North America and Europe, so I think it is desirable to be able to turn it off. Right now I don't know of a consumer ISP in North America that will GIVE you an IPv6 address, never mind require it, although some business ISPs tout V6 routing. Because of the foot-dragging in rolling out V6, I believe that adoption is not going to be a gradual affair - I believe that, at some point, someone (probably in Asia) is going to invent the "Next Big Thing that Everybody HAS to HAVE," (i.e. the next new Google, Facebook, Twitter, Pinterest, Dropbox, whatever) and it will only be accessible via V6. At that point, everyone in North America and Europe will suddenly change from ignoring V6 to HAVING TO HAVE IT RIGHT NOW!!! I believe the ISPs will mostly be blindsided - the few who thought that this might happen will be able to move users to V6 and will be "winners" in this scenario, while those who didn't plan ahead (or thought they'd be able to move people gradually to v6) will be roasted alive in the court of consumer opinion. It will be a "crisis" that "no one could have predicted." While we consumers in N. America and Europe can still afford to be complacent for a while, I think that we, as OpenWRT developers, need to be very diligent in ensuring OpenWRT "plays well" on V6 in anticipation of this event, should it come to pass. It may be a nice opportunity for OpenWRT to get some nice publicity by "saving the day" when the "crisis" occurs. -- Bill Moffitt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] add new router UR-336UN
2012.04.23. 13:42 keltezéssel, Дмитрий Лебедев írta: > add new router UR-336UN Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: rt305x: add add support for the Asus WL-330N3G board
2012.04.22. 11:31 keltezéssel, Frédéric Leroy írta: > This patch adds support for the ASUS WL-330N3G > > Comparing to the WL-330N, It have 32MB ram, usb support and a bicolor led. > > The bi-color led is driven by 2 gpio. > I don't know how to handle this, so I simply made 2 leds : one red, one blue. > But the red light takes precedence over the blue one according to the chart > below. > > r = led is red > b = led is blue > 0 = led is off > > xy= x->r for red, b for blue led, y->value of brightness in > /sys/class/leds/x/brughtness > > initial state action ledgpio state > > r0b0 r0->r1 r r0 b0 > r0b0 b0->b1 b r0 b1 > > r1b0 r1->r0 0 r0 b0 > r1b0 b0->b1 r r1 *b1* > > r1b1 r1->r0 b r0 b1 > r1b1 b1->b0 r r1 b0 > > r0b1 r0->r1 r r1 *b1* > r0b1 b1->b0 0 r0 r0 > > Signed-off-by: Frédéric Leroy Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] avahi version bump to 0.6.31, Makefile improvements, take 3!!
I promise this is the last fix to this patch submission! This patch updates avahi to latest version -- 0.6.31. From the release notes: "This is a bugfix release and mostly makes things work with current autoconf again." It allows us to remove the OpenWrt-specific automake patch. This patch also ensures that when you change from omitting D-Bus support to including it, or vice-versa, the correct packages are actually generated. Until now, you had to do a make clean when you made a change like that. [V2 -- fixed MD5SUM calculation oops] [V3 -- removed non-functional Build/Configure stanza] Signed-off-by Mike Brady Index: libs/avahi/patches/020-automake-compat.patch === --- libs/avahi/patches/020-automake-compat.patch(revision 31444) +++ libs/avahi/patches/020-automake-compat.patch(working copy) @@ -1,26 +0,0 @@ a/service-type-database/Makefile.am -+++ b/service-type-database/Makefile.am -@@ -18,13 +18,12 @@ - EXTRA_DIST=build-db.in service-types - - pkgdata_DATA=service-types --pkglib_DATA= - - if HAVE_PYTHON - if HAVE_GDBM - - noinst_SCRIPTS=build-db --pkglib_DATA+=service-types.db -+pkgdata_DATA+=service-types.db - - build-db: build-db.in - $(AM_V_GEN)sed -e 's,@PYTHON\@,$(PYTHON),g' \ -@@ -41,7 +40,7 @@ endif - if HAVE_DBM - - noinst_SCRIPTS=build-db --pkglib_DATA+=service-types.db.pag service-types.db.dir -+pkgdata_DATA+=service-types.db.pag service-types.db.dir - - build-db: build-db.in - $(AM_V_GEN)sed -e 's,@PYTHON\@,$(PYTHON),g' \ Index: libs/avahi/Makefile === --- libs/avahi/Makefile (revision 31444) +++ libs/avahi/Makefile (working copy) @@ -7,21 +7,23 @@ include $(TOPDIR)/rules.mk -ifeq ($(BUILD_VARIANT),dbus) -PKG_BUILD_DIR=$(BUILD_DIR)/$(PKG_NAME)-dbus/$(PKG_NAME)-$(PKG_VERSION) +# Avahi comes in two flavours -- with and without D-Bus support built in. + +ifdef CONFIG_AVAHI_INCLUDE_DBUS_SUPPORT + PKG_BUILD_DIR=$(BUILD_DIR)/$(PKG_NAME)/dbus/$(PKG_NAME)-$(PKG_VERSION) + PKG_ALT_DIR=$(BUILD_DIR)/$(PKG_NAME)/nodbus/$(PKG_NAME)-$(PKG_VERSION) else -PKG_BUILD_DIR=$(BUILD_DIR)/$(PKG_NAME)-nodbus/$(PKG_NAME)-$(PKG_VERSION) + PKG_BUILD_DIR=$(BUILD_DIR)/$(PKG_NAME)/nodbus/$(PKG_NAME)-$(PKG_VERSION) + PKG_ALT_DIR=$(BUILD_DIR)/$(PKG_NAME)/dbus/$(PKG_NAME)-$(PKG_VERSION) endif - PKG_NAME:=avahi -PKG_VERSION:=0.6.30 -PKG_RELEASE:=4 +PKG_VERSION:=0.6.31 +PKG_RELEASE:=1 - PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://avahi.org/download/ -PKG_MD5SUM:=e4db89a2a403ff4c47d66ac66fad1f43 +PKG_MD5SUM:=2f22745b8f7368ad5a0a3fddac343f2d PKG_BUILD_DEPENDS:=libexpat libdaemon libgdbm intltool/host libpthread dbus @@ -31,8 +33,6 @@ PKG_INSTALL:=1 PKG_BUILD_PARALLEL:=1 - - include $(INCLUDE_DIR)/package.mk define Package/avahi/Default @@ -54,6 +54,10 @@ and is very convenient. endef +define Package/libavahi/config + source "$(SOURCE)/Config.in" +endef + define Package/libavahi $(call Package/avahi/Default) SECTION:=libs @@ -70,8 +74,9 @@ libavahi-core and libavahi-common libraries. By default, it is compiled without D-Bus support, i.e. the --disable-dbus compilation flag is set. - To enable D-Bus support, select the package - libavahi-dbus-support. + D-Bus support will be selected automatically by libavahi-client + and avahi-utils. To enable D-Bus support manually, + select the "include D-Bus support" option. endef define Package/avahi-autoipd @@ -125,34 +130,11 @@ in a DHCP-like fashion. Especially useful on IPv6. endef -define Package/libavahi-dbus-support - $(call Package/avahi/Default) - SECTION:=libs - CATEGORY:=Libraries - VARIANT:=dbus - DEPENDS:=+dbus +libavahi - TITLE+= (D-Bus support) -endef - -define Package/libavahi-dbus-support/description -$(call Package/libavahi/description) - . - The libavahi-dbus-support package enables - D-Bus support in libavahi, needed to support - the libavahi-client library and avahi-utils. - Selecting this package modifies the contents of the - libavahi package by setting the --enable-dbus compilation flag; - it does not generate a separate binary of its own. - It also automatically adds the D-Bus package to the build. - libavahi-dbus-support is selected automatically if you select - libavahi-client or avahi-utils. -endef - define Package/libavahi-client $(call Package/avahi/Default) SECTION:=libs CATEGORY:=Libraries - DEPENDS:=+libavahi-dbus-support +avahi-daemon + DEPENDS:=+dbus +libavahi +@AVAHI_INCLUDE_DBUS_SUPPORT TITLE+= (libavahi-client library) endef @@ -161,7 +143,7 @@ . This packages adds the libavahi-client library. It also automatically adds the required - libavahi-dbus-support and the avahi-daemon packages. + libavahi, avahi-daemon and dbus packages. For more information please see the avahi documentation. endef @@ -223,7 +205,7 @@ --disable-stack-protect
[OpenWrt-Devel] [PATCH 2/3 V1] remove the possibility to select eglibc trunk and disable eglibc SVN revision selection
When selecting a specific eglibc version, it comes with a specific SVN revision that should not be modified as it (more or less) correspond to a tagged release. This patch disable the possibility to select a specific SVN revision on known eglib versions. This patch also disables the possibility to select the trunk branch of eglibc. There are multiple reasons for that: * trunk/HEAD may not even compile * the OpenWRT built system makes using trunk/HEAD a difficult thing, as OpenWRT fetches the source tree and store it in a compressed tar archive. Subsequent build get the source from the tar archive - not from SVN, making the use of trunk/HEAD largelly innefective. * we cannot know the corresponding version of trunk/HEAD, meaning that we'll face compiling issues when we'll try to copy the libc files - unless the build system is fixed with this specific issue in mind. Signed-off-by: Emmanuel Deloget Index: toolchain/eglibc/Config.version === --- toolchain/eglibc/Config.version (révision 31444) +++ toolchain/eglibc/Config.version (copie de travail) @@ -4,4 +4,4 @@ default "2.12.2" if EGLIBC_VERSION_2_12 default "2.13" if EGLIBC_VERSION_2_13 default "2.14.1" if EGLIBC_VERSION_2_14 - default "trunk" + default "2.13" Index: toolchain/eglibc/Config.in === --- toolchain/eglibc/Config.in (révision 31444) +++ toolchain/eglibc/Config.in (copie de travail) @@ -17,19 +17,14 @@ bool "eglibc 2.14" depends !GCC_VERSION_LLVM - config EGLIBC_VERSION_TRUNK - bool "eglibc trunk" - endchoice config EGLIBC_REVISION string - prompt "eglibc revision" depends on TOOLCHAINOPTS && USE_EGLIBC default "14661" if EGLIBC_VERSION_2_12 default "15508" if EGLIBC_VERSION_2_13 default "16488" if EGLIBC_VERSION_2_14 - default "HEAD" if EGLIBC_VERSION_TRUNK default "" menu "eglibc configuration" Index: toolchain/eglibc/Makefile === --- toolchain/eglibc/Makefile (révision 31444) +++ toolchain/eglibc/Makefile (copie de travail) @@ -24,9 +24,6 @@ ifneq ($(CONFIG_EGLIBC_VERSION_2_14),) PKG_SOURCE_URL:=svn://svn.eglibc.org/branches/eglibc-2_14 endif -ifneq ($(CONFIG_EGLIBC_VERSION_TRUNK),) - PKG_SOURCE_URL:=svn://svn.eglibc.org/trunk -endif PATCH_DIR:=./patches/$(PKG_VERSION) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3 V1] disable SVN revision selection for non-trunk eglibc
When selecting a specific eglibc version, it comes with a specific SVN revision that should not be modified as it (more or less) correspond to a tagged release. This patch disable the possibility to select a specific SVN revision on known eglib versions while it still provide the functionnality if the selected version is the eglibc trunk. Some labels are modified in the process to clarify the system. Signed-off-by: Emmanuel Deloget Index: toolchain/eglibc/Config.in === --- toolchain/eglibc/Config.in (révision 31444) +++ toolchain/eglibc/Config.in (copie de travail) @@ -18,18 +18,23 @@ depends !GCC_VERSION_LLVM config EGLIBC_VERSION_TRUNK - bool "eglibc trunk" + bool "eglibc SVN trunk" endchoice +config EGLIBC_TRUNK_REVISION + string + prompt "eglibc SVN trunk revision" + depends on TOOLCHAINOPTS && USE_EGLIBC && EGLIBC_VERSION_TRUNK + default "HEAD" + config EGLIBC_REVISION string - prompt "eglibc revision" depends on TOOLCHAINOPTS && USE_EGLIBC default "14661" if EGLIBC_VERSION_2_12 default "15508" if EGLIBC_VERSION_2_13 default "16488" if EGLIBC_VERSION_2_14 - default "HEAD" if EGLIBC_VERSION_TRUNK + default EGLIBC_TRUNK_REVISION if EGLIBC_VERSION_TRUNK default "" menu "eglibc configuration" ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/3 V1] correct eglibc version numbers
eglibc version number depends on the branch and on the maintenance release (i.e. the SVN revision). Changing the revision may change the maintenance version. This patch correlate the SVN revision to the correct version number - without this change, both eglibc 2.12 and eglibc 2.14 provoke build errors when compiling the base-files package (example, for 2.12): $ make package/base-files/compile V=1 make[1] package/base-files/compile make[2] -C package/opkg host-compile make[2] -C package/base-files-network compile make[2] -C package/base-files compile cp: cannot stat `/home/me/openwrt/trunk/staging_dir/toolchain-arm_v7-a_gcc-4.6-linaro_eglibc-trunk_eabi/lib/ld-2.12.so': No such file or directory make[2]: *** [/home/me/openwrt/trunk/bin/omap4/packages/libc_trunk-106_omap4.ipk] Error 1 make[1]: *** [package/base-files/compile] Error 2 make -r package/base-files/compile: build failed. Please re-run make with V=99 to see what's going on make: *** [package/base-files/compile] Erreur 1 Signed-off-by: Emmanuel Deloget Index: toolchain/eglibc/Config.version === --- toolchain/eglibc/Config.version (révision 31444) +++ toolchain/eglibc/Config.version (copie de travail) @@ -1,7 +1,7 @@ config EGLIBC_VERSION string depends on USE_EGLIBC - default "2.12" if EGLIBC_VERSION_2_12 + default "2.12.2" if EGLIBC_VERSION_2_12 default "2.13" if EGLIBC_VERSION_2_13 - default "2.14" if EGLIBC_VERSION_2_14 + default "2.14.1" if EGLIBC_VERSION_2_14 default "trunk" ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] AT91: what's happening ?
Hi all, I've manifested my interest in the AT91 a couple of weeks ago, and nobody even answer any of my calls. I would like to work hand in hand with other peoples that use AT91 based boards. Obviously, someone started some important modifications on the at91 directory, which look like a good idea to me, but my point is that why this person never speak about these changes on the mailing list. One of the big change is the linux version bump, now it seems that it has to be the untested 3.3.2 instead of the working 2.6.38.8. Could this person gives details on what the plans are for the AT91 target? Maybe we could share some thoughts and ideas. I have access to the stamp9G20 and the portux9G20, so i can tests these two boards. I really would like to help and contribute, but it would be nice if the plans are known in advance. Regards, Chris -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] eglibc 2.12 fails to build
Hello, Le 19/04/2012 18:40, Emmanuel Deloget a écrit : I have no idea on how we can fix this, other than setting the correct version numbers in the CONFIG_EGLIBC_VERSION. I can provide a patch to fix the current state, but that would not make much sense if 2.12 is to be removed from the tree. Of course, such a patch shall also cure the problem when the user handpick a revision in the eglibc trunk (but again, this might be removed as well). No answer on that, so I submit and you decide. I think the best course of action is to re-fetch the source in those cases: * if the package is not prepared yet (i.e. if the user cleans the package or before the package is built for the first time). * if the package fails to compile But we should avoid re-fetching the source once the package has been successfully built. For packages, these conditions can be factorized into the following one: $(PKG_BUILD_DIR)/.built exists. No patch for this, as I didn't come with any working and elegant solution. Introducing OPENWRT_BLEEDING_EDGE raises the impression of over-engineering to me. We still should try to avoid fetching HEAD of sources (see above), however IF we provide the possibility - which is opt-in and just for developers anyway - I don't see the point of "un-hide" respective options first. Fine with me. That was just yet another idea :) Do you want me to resubmit a patch without OPENWRT_BLEEDING_EDGE? No response on this subject, so I'll submit, and you'll decice :) I'm going to post 3 patches. The first one correct the current compilation issues. It's indepependant of the other patches (but rely on the SVN revision to be correctly defined, otherwise it won't work ; so applying either patch 2 or 3 is still a good idea otherwise the user might break things by selecting bad eglibc revisions). The second one disable the possibility to select a specific revision for known versions of eglibc. The third one provide the same functionnality, and removes the possibility to select the trunk version. Of course, this patch is not compatible with the previous one, so you either apply 1 and 2 or you apply 1 and 3 - but not 1, 2 and 3. All patches will be posted in the next 10/15 minutes. Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] add new router UR-336UN
add new router UR-336UN -- Lebedev Dmitry target_changes.path Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] [package] Add openconnect protocol support to network scripts
This is very basic — username/password only, and doesn't even check
certificates which it *definitely* should. But it's a good start.
Signed-off-by: David Woodhouse
---
net/openconnect/Makefile |8 ++-
net/openconnect/files/openconnect.sh | 39 +++
net/openconnect/files/run-openconnect | 86 +
3 files changed, 130 insertions(+), 3 deletions(-)
create mode 100755 net/openconnect/files/openconnect.sh
create mode 100755 net/openconnect/files/run-openconnect
diff --git a/net/openconnect/Makefile b/net/openconnect/Makefile
index 372841c..969eda2 100644
--- a/net/openconnect/Makefile
+++ b/net/openconnect/Makefile
@@ -20,7 +20,7 @@ include $(INCLUDE_DIR)/package.mk
define Package/openconnect
SECTION:=net
CATEGORY:=Network
- DEPENDS:=+libxml2 +libopenssl +kmod-tun
+ DEPENDS:=+libxml2 +libopenssl +kmod-tun +vpnc-scripts
TITLE:=VPN client for Cisco's AnyConnect SSL VPN
URL:=http://www.infradead.org/openconnect/
SUBMENU:=VPN
@@ -37,9 +37,11 @@ endef
CONFIGURE_ARGS+=--disable-shared
define Package/openconnect/install
+ $(INSTALL_DIR) $(1)/lib/network
+ $(INSTALL_BIN) ./files/openconnect.sh $(1)/lib/network/
$(INSTALL_DIR) $(1)/usr/sbin
- $(INSTALL_BIN) $(PKG_BUILD_DIR)/openconnect \
- $(1)/usr/sbin/
+ $(INSTALL_BIN) ./files/run-openconnect $(1)/usr/sbin/
+ $(INSTALL_BIN) $(PKG_BUILD_DIR)/openconnect $(1)/usr/sbin/
endef
$(eval $(call BuildPackage,openconnect))
diff --git a/net/openconnect/files/openconnect.sh
b/net/openconnect/files/openconnect.sh
new file mode 100755
index 000..13221ab
--- /dev/null
+++ b/net/openconnect/files/openconnect.sh
@@ -0,0 +1,39 @@
+find_gw() {
+ route -n | awk '$1 == "0.0.0.0" { print $2; exit }'
+}
+
+scan_openconnect() {
+ config_set "$1" device "vpn-$1"
+}
+
+stop_interface_openconnect() {
+ local config="$1"
+ local lock="/var/lock/openconnect-$config"
+
+uci_set_state network "$config" up 0
+
+ lock "$lock"
+
+ SERVICE_PID_FILE="/var/run/openconnect-${config}.pid" \
+ SERVICE_SIG=HUP service_stop /bin/sh
+
+ remove_dns "$config"
+
+ lock -u "$lock"
+}
+
+setup_interface_openconnect() {
+ local config="$2"
+
+ /sbin/insmod tun 2>&- >&-
+
+ # creating the tunnel below will trigger a net subsystem event
+# prevent it from touching or iface by disabling .auto here
+uci_set_state network "$config" ifname "vpn-$config"
+uci_set_state network "$config" auto 0
+uci_set_state network "$config" up 1
+
+ SERVICE_PID_FILE="/var/run/openconnect-${config}.pid" \
+ SERVICE_WRITE_PID=1 SERVICE_DAEMONIZE=1 \
+service_start /usr/sbin/run-openconnect $config
+}
diff --git a/net/openconnect/files/run-openconnect
b/net/openconnect/files/run-openconnect
new file mode 100755
index 000..e835891
--- /dev/null
+++ b/net/openconnect/files/run-openconnect
@@ -0,0 +1,86 @@
+#!/bin/sh -x
+
+. /etc/functions.sh
+
+[ $# = 0 ] && { echo " $0 "; exit; }
+
+include /lib/network
+scan_interfaces
+
+config="$1"
+export OPENWRT_INTERFACE="$config"
+
+config_get proto "$config" proto
+
+if [ "$proto" != "openconnect" ]; then
+echo "Interface $config is $proto not openconnect" >&2
+exit 1
+fi
+
+config_get device "$config" device
+
+local server
+config_get server "$config" server
+
+local port
+config_get port "$config" port
+if [ -n "$port" ]; then
+args="$server:$port"
+else
+args="$server"
+fi
+
+local cookie
+config_get cookie "$config" cookie
+[ -n "$cookie" ] && args="$args -C $cookie"
+
+local username
+config_get username "$config" username
+[ -n "$username" ] && args="$args -u $username"
+
+local password
+config_get password "$password" password
+
+/sbin/insmod tun
+
+local lock="/var/lock/openconnect-$config"
+
+# creating the tunnel below will trigger a net subsystem event
+# prevent it from touching or iface by disabling .auto here
+uci_set_state network "$config" ifname $link
+uci_set_state network "$config" auto 0
+
+local gw="$(find_gw)"
+[ -n "$gw" ] && {
+local serv_addrs=""
+for ip in $(resolveip -4 -t 3 "$server"); do
+ append serv_addrs "$ip"
+ route delete -host "$ip" 2>/dev/null
+ route add -host "$ip" gw "$gw"
+done
+uci_toggle_state network "$config" serv_addrs "$serv_addrs"
+}
+
+RECON=$(date +%s)
+
+trap "[ -r /var/run/openconnect-$config-oc.pid ] && kill -HUP \$(cat
/var/run/openconnect-$config-oc.pid)" SIGHUP
+while [ "$(uci_get_state network ${config} up)" = "1" ]; do
+NOW=$(date +%s)
+if [ $RECON -gt $NOW ]; then
+ DELAY=$(expr $RECON - $NOW)
+ logger -t openconnect "Waiting for $DELAY seconds before reconnecting"
+ sleep $(expr $DELAY)
+fi
+
+# The lock prevents a race condition where /lib/network/openconnect.sh
could
+# send us SIGHUP after we spawn openconnect, but before we store its pid.
+# Thus leavi
[OpenWrt-Devel] [PATCH 1/2] [package] Add vpnc-scripts package with up-to-date script
Switch to a separate vpnc-scripts package. It's used by both vpnc and openconnect now, and openconnect will want an up-to-date version that has IPv6 support. And won't want to pull in the whole of the vpnc package just to get it. This removes the hard-coded masquerading configuration from vpnc-script. It's possible to do it in a hook now, but it also shouldn't be necessary, because we should be invoking the hotplug scripts to plumb the interface properly anyway. Signed-off-by: David Woodhouse --- net/vpnc-scripts/Makefile | 56 + net/vpnc-scripts/files/etc/vpnc/connect.d/ifstate |7 +++ net/vpnc/Makefile |6 +-- 3 files changed, 65 insertions(+), 4 deletions(-) create mode 100644 net/vpnc-scripts/Makefile create mode 100644 net/vpnc-scripts/files/etc/vpnc/connect.d/ifstate diff --git a/net/vpnc-scripts/Makefile b/net/vpnc-scripts/Makefile new file mode 100644 index 000..7481dea --- /dev/null +++ b/net/vpnc-scripts/Makefile @@ -0,0 +1,56 @@ +# +# Copyright (C) 2006 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:=vpnc-scripts +PKG_VERSION:=20120423 +PKG_RELEASE:=1 + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz +PKG_SOURCE_URL:=ftp://ftp.infradead.org/pub/vpnc-scripts/ +PKG_MD5SUM:=3265dc7fe57ae9b4c905961a28699c4c + +include $(INCLUDE_DIR)/package.mk + +define Package/vpnc-scripts + SECTION:=net + CATEGORY:=Network + DEPENDS:=+ip + TITLE:=VPN configuration script for vpnc and OpenConnect + URL:=http://www.infradead.org/openconnect/vpnc-script.html + SUBMENU:=VPN +endef + +define Package/vpnc/vpnc-scripts + This package contains the vpnc-script which is used by vpnc + and OpenConnect to configure the tunnel interface. +endef + +define Package/vpnc-scripts/conffiles +/etc/vpnc/connect.d/ +/etc/vpnc/post-connect.d/ +/etc/vpnc/disconnect.d/ +/etc/vpnc/post-connect.d/ +/etc/vpnc/reconnect.d/ +endef + +define Build/Compile +endef + +define Package/vpnc-scripts/install + $(INSTALL_DIR) $(1)/etc/vpnc + $(INSTALL_DIR) $(1)/etc/vpnc/connect.d + $(INSTALL_DIR) $(1)/etc/vpnc/post-connect.d + $(INSTALL_DIR) $(1)/etc/vpnc/disconnect.d + $(INSTALL_DIR) $(1)/etc/vpnc/post-disconnect.d + $(INSTALL_DIR) $(1)/etc/vpnc/reconnect.d + $(INSTALL_BIN) ./files/etc/vpnc/connect.d/ifstate $(1)/etc/vpnc/connect.d/ + $(INSTALL_BIN) $(PKG_BUILD_DIR)/vpnc-script $(1)/etc/vpnc/ +endef + +$(eval $(call BuildPackage,vpnc-scripts)) diff --git a/net/vpnc-scripts/files/etc/vpnc/connect.d/ifstate b/net/vpnc-scripts/files/etc/vpnc/connect.d/ifstate new file mode 100644 index 000..8d2a157 --- /dev/null +++ b/net/vpnc-scripts/files/etc/vpnc/connect.d/ifstate @@ -0,0 +1,7 @@ +if [ -n "$OPENWRT_INTERFACE" ]; then +uci_set_state network "$OPENWRT_INTERFACE" banner "$CISCO_BANNER" +uci_set_state network "$OPENWRT_INTERFACE" ifname "$TUNDEV" +[ -n "$INTERNAL_IP4_ADDRESS" ] && uci_set_state network "$OPENWRT_INTERFACE" ipaddr "$INTERNAL_IP4_ADDRESS" +[ -n "$INTERNAL_IP6_NETMASK" ] && uci_set_state network "$OPENWRT_INTERFACE" ip6addr "$INTERNAL_IP6_NETMASK" +env -i ACTION="ifup" INTERFACE="$OPENWRT_INTERFACE" DEVICE="$TUNDEV" PROTO=openconnect /sbin/hotplug-call "iface" +fi diff --git a/net/vpnc/Makefile b/net/vpnc/Makefile index 0b9d07e..ad1592e 100644 --- a/net/vpnc/Makefile +++ b/net/vpnc/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=vpnc PKG_VERSION:=0.5.3 -PKG_RELEASE:=1 +PKG_RELEASE:=2 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://www.unix-ag.uni-kl.de/~massar/vpnc/ @@ -20,7 +20,7 @@ include $(INCLUDE_DIR)/package.mk define Package/vpnc SECTION:=net CATEGORY:=Network - DEPENDS:=+libgpg-error +libgcrypt +kmod-tun +ip + DEPENDS:=+libgpg-error +libgcrypt +kmod-tun +vpnc-scripts TITLE:=VPN client for Cisco EasyVPN URL:=http://www.unix-ag.uni-kl.de/~massar/vpnc/ SUBMENU:=VPN @@ -36,7 +36,6 @@ endef define Package/vpnc/conffiles /etc/vpnc/default.conf -/etc/vpnc/vpnc-script endef define Build/Compile @@ -57,7 +56,6 @@ define Package/vpnc/install $(1)/usr/sbin/ install -d -m0700 $(1)/etc/vpnc $(INSTALL_CONF) $(PKG_INSTALL_DIR)/etc/vpnc/default.conf $(1)/etc/vpnc/ - $(INSTALL_BIN) $(PKG_INSTALL_DIR)/etc/vpnc/vpnc-script $(1)/etc/vpnc/ endef $(eval $(call BuildPackage,vpnc)) -- 1.7.7.6 -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Adding wifi eeprom extract for ARV752DPW - Easybox 802
Thanks, applied in r31443 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] scanning kernel packages for targets
Thanks, applied in r31442 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
Hi, On Mon, Apr 23, 2012 at 01:49:18AM +0200, Michael Markstaller wrote: > Appreciate your work really but just my 5ct: noone needs IPv6 if not in > search for troubles or many new (security)-problems. Welcome to the 21st century. There are ISPs in Asia today(!) that *will* *not* give you an IPv4 address, because they have none left. > I love the --disable-ipv6 switch, please keep it working without this > experiment, I guess there are many other fields to work on - with more > relationship to real-life :o IPv6 is most relevant to real-life. Many of the problems we see in IPv6 deployments are caused exactly by this attitude - instead of *using* it and fixing the problems that are still left, disabling it and hoping that it won't be needed before personal retirement. This won't get any of the issues fixed, and one day you'll find yourself in need of IPv6, and the problems are still there. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpGLg8CjygRJ.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
