Re: [OpenWrt-Devel] PCengines APU2c2 running openwrt
Hi,
On Tue, Jan 03, 2017 at 01:15:28PM -0500, Derek Werthmuller wrote:
> Looking to upgrade to the PCengines APU2c2 from the Lamobo R1 (Banana Pi
> router board). There is a wiki page for the APU2 with limited information
> https://wiki.openwrt.org/toh/pcengines/apu2:
>
> Anyone with experience running Openwrt Trunk or CC on this platform send me
> some advice on the hardware?
I'm very much interested in the replies :-) - I have a number of APU2c2
that currently run "stock Debian" (a 16G SSD is cheap and plenty of space),
but for a router-ish device I like OpenWRT much more than all the systemd
opaqueness...
What I'm specifically interested in is success (or problem) reports of
using the Huawei ME909u-512 Mini-PCIe LTE modem with OpenWRT - my intended
usage of these boxes is OpenVPN-over-LTE routers.
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
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3] packaget/network/services/openvpn: Drop ifconfig/route in favour of ip
Hi,
On Sun, Jan 31, 2016 at 03:49:58PM -0800, Daniel Dickinson wrote:
> On 21/01/16 02:31 PM, Felix Fietkau wrote:
> > On 2016-01-20 20:22, open...@daniel.thecshore.com wrote:
> >> From: Daniel Dickinson <open...@daniel.thecshore.com>
> >>
> >> NB: Only compile tested.
>
> Based on live testing it appears that openvpn upstream does not work
> properly at least with the busybox ip applet, but likely also with full
> iproute2 due to race condition (tun device goes away before ip command
> runs and sets up networking).
That would surprise me a bit... can I have the openvpn log for that race
condition? Is this something special in OpenWRT? Normally, the tun device
can never "go away" unless OpenVPN tells it to - and if we do that, we do
not call ip/ifconfig on it afterwards.
(Also, for the busybox ip applet, our use of ip is not exactly esoteric -
setup ipv4/ipv6 addresses on tun if, add ipv4/ipv6 routes)
gert,
openvpn upstream
--
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
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: For sysfixtime use hwclock if RTC available
Hi,
On Sun, Jan 10, 2016 at 04:47:05AM -0500, Daniel Dickinson wrote:
> I used git send-email so there shouldn't be any whitepspace mangling
> issues, unless patchwork is to blame.
Over at openvpn-devel, we recently discovered that some versions of
MS Exchange mangle whitespace for "mails in transit" - so even when the
user did everything right (git send-email, etc.) Exchange still converted
all tabs to 8x Space, leading to non-applying patches.
Solution: send via freemail provider, using direct SMTP+Auth (which
git send-email can do).
> That leaves receive-side error. It seems likely given the line the
> error is on, that patchwork is pickier than git or the vim bit you sent
> me. That is the 'offending' line is a shell script that happens to have
> 8 spaces instead of tab. Methinks this is not a relevant thing to
> complain about in a shell script; also I wonder whether it would do the
> same with with e.g. Python? I suspect patchwork is applying Makefile
> rules to all patches, which is just wrong.
The problem often is context. If the parts before or after the actual
change get whitespace-modified, git am will not accept it (traditional
patch will, and complain about fuzz needed).
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
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] buildroot: improve git submodule handling for packages
Hi, On Thu, Jul 16, 2015 at 09:12:02PM -0400, Darik Horn wrote: Patch is badly whitespace mangled and does not apply. Okay, I've rebased the this patch to HEAD and am resending it with a different MUA. (First Gmail, now Outlook.) git send-email is what you really want. 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 pgpgX6iDB49Qz.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] openvpn: bump PKG_RELEASE.
Hi, On Sun, Jun 14, 2015 at 12:04:48PM +0800, Yousong Zhou wrote: --- a/package/network/services/openvpn/Makefile +++ b/package/network/services/openvpn/Makefile @@ -10,7 +10,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=openvpn PKG_VERSION:=2.3.6 -PKG_RELEASE:=4 +PKG_RELEASE:=5 While at it, you could bump to upstream 2.3.7... 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 pgpDbBjKa0A6V.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2
Hi, On Wed, May 27, 2015 at 02:41:31PM +0200, Jo-Philipp Wich wrote: For example: consider a switch port group containing five ports, 4 external RJ45 ports and one internal connected to the SoC - when would you consider that interface down? When no port except the CPU one has a link? Whenever a cable is plugged into one of the four ports? I'd consider no external link at all to be sufficient criteria to signal link down internally. (Which is how certain commercial platforms handle this - if all L2 ports in a given VLAN go down, the L3 routing interface will also go down, and I found that usually to be what I expect and want to happen) Now, I'm not saying that this would be trivial to do, but tremendously useful :-) 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 pgpfIEgajtTyK.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH procd 3/8] Fix curses applications to work with procd
Hi, On Thu, Oct 02, 2014 at 02:56:18PM +0200, Michel Stam wrote: The problem was caused by procd not opening /dev/tty* (which ever was specified in /etc/inittab), causing /proc/PID/fd to point to /console instead. /dev/console is a non-controlling tty (CTTY), and cannot be used as one, which is exactly what curses applications want. Since this is very likely to cause problems with other programs, procd now opens /dev/tty? when the ID field of the inittab assigns one, and forces this to be a CTTY. I won't claim to understand the OpenWRT intricacies here, so take this with a grain of salt. In traditional unix systems, setting up a tty and acquiring a controlling tty is getty's job, and not that of the init system - and init should not start interactive programs (or possibly interactive programs) from /etc/inittab. Changing this is fairly invasive into the way the system works and what programs can expect regarding signal delivery etc. - like, someone pressing ctrl-c on a tty, and a background process being started on that tty will get a SIGINT (while it normally wouldn't). Genuinely curious: can you explain a bit better in which cases this change would be needed and/or beneficial? thanks, 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 pgpnKgLckH1oR.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] AA: update openvpn-devel to compile against polarssl 1.2.x
Hi, On Wed, Sep 24, 2014 at 07:43:13PM +0200, Stefano De Carlo wrote: Il 24/09/2014 18:30, Gert Doering ha scritto: OpenVPN Upstream would recommend to go up to HEAD in git/master, aka 9048d50b0a27a724ad088dc4904eb4888b0bca87 - this is all openvpn-devel anyway, but what we have in-tree right now has seen some more minor bugfixes in SSL land (nothing security critical, but documentation, proper logging, fixing compile-time warnings and such) plus a few nice features, compared to that revision from 2013... Hi, my rationale for not going all the way up to the last commit is that * AA gets rarely touched these days (this is after all an almost 2 years old issue), so I didn't want to discourage applying this by introducing too big a change without proper testing. * This patch has been deployed on 20+ nodes in our mesh network without any issue for several months now. Well, and the counterargument is that a *devel* version should not be over a year old, if there have been bugfixes and useful functionality added in the mean time :-) - I can see your argument about stability, but be assured, current HEAD is very well tested (no *major* code changes have been done in that time frame, and what we have has seen deployment in some commercial environments as server, and is used under the hood in the OpenVPN for Android client). If OpenWrt developers are interested in commiting this to the 12.09 package feed but would rather have a newer revision of OpenVPN I could and will align the patch to v.2.3.4 or later after proper testing. Yeah. I'm happy to help, but leave the decision to the OpenWRT devs. 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 pgpC_LA5HSDa1.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] AA: update openvpn-devel to compile against polarssl 1.2.x
Hi, On Wed, Sep 24, 2014 at 01:01:42AM +0200, Stefano De Carlo wrote: r35529 updated polarssl to v1.2.x, introducing a compiling regression in package openvpn-devel-polarssl. This patch updates openvpn-devel to the commit that added support for the API changes introduced in PolarSSL-1.2. OpenVPN Upstream would recommend to go up to HEAD in git/master, aka 9048d50b0a27a724ad088dc4904eb4888b0bca87 - this is all openvpn-devel anyway, but what we have in-tree right now has seen some more minor bugfixes in SSL land (nothing security critical, but documentation, proper logging, fixing compile-time warnings and such) plus a few nice features, compared to that revision from 2013... One of the important bits you might want to have is the display of the SSL library + version used in openvpn --version plus sending this to the server as part of --push-peer-info (so server admins can poke users to upgrade, if needed). 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 pgpZmKVJGEfrK.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
Hi, On Sun, Jul 20, 2014 at 03:50:24PM -0700, David Lang wrote: I'm well aware of all the bullshit that is knocking on my doors all day. Point is, firewalls on the *routers* are not goint to help the laptop that moves around, attaches to a Wifi Hotspot, is hacked there, gets moved back behind your firewall, and starts hacking others from there. And it doesn't help the desktop PC that neglected to do any updates, gets infected by flash/pdf/word exploit, and starts scanning your network, behind the firewall. The problem here isn't with laptops, it's with TVs, light Bulbs, Thermostats, digital picture frames, etc. These are the types of devices that I'm worried about protecting. Yes, so how do you protect them from the malware on your PC and Laptop, which both are behind the firewall? A hacker from the wild is likely to not even *find* the device if it's using EUI64 IPv6 addressing and not registered in DNS, while an attacker on the same LAN just needs to ping ff02::1 to see them all, wide open... 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 pgppN212beHLO.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
Hi, On Mon, Jul 21, 2014 at 12:18:46AM -0700, David Lang wrote: While it is nice to say that IPv6 has a large address space and so nobody will ever scan it, I don't believe it. Don't believe. Try math. 2^64 is big enough that if you manage to send a few 1000 packets a second, you'll need up to the heat death of the universe to scan a single /64 subnet... (Of course this can be optimized if you're targeting very specific devices and only need to scan 2^24 potential EUI64 addresses in a given vendor's MAC range - but that's not your Joe Random attacker. If someone is that determined, he'll just target your PC first, and jump from there to the devices on your LAN. Way easier in general) 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 pgp9RQ4rBklXV.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
Hi, On Fri, Jul 18, 2014 at 04:08:02PM -0700, David Lang wrote: Yes, there will be some attacks that get through and start from the inside, but there are far fewer that get into my network than to get into the network of everyone I share an ISP with. I also don't want these random external users to be eating up my wireless bandwidth hammering uselessly against my devices, even if they will withstand the hammering. In that case, you should ask your *ISP* to install the filter - after all, you wouldn't want them to eat up your WAN bandwidth, no? go do a tcpdump of your WAN interface some time, look at all the attacks that are going on there (especially with an ISP that's not blocking it for you) I'm well aware of all the bullshit that is knocking on my doors all day. Point is, firewalls on the *routers* are not goint to help the laptop that moves around, attaches to a Wifi Hotspot, is hacked there, gets moved back behind your firewall, and starts hacking others from there. And it doesn't help the desktop PC that neglected to do any updates, gets infected by flash/pdf/word exploit, and starts scanning your network, behind the firewall. These things are all so commonplace that the firewall on the router adds dubious value - but at the same time, it breaks stuff. So if you have to decide about something that adds little positive but significant negative, why would you go for enabling it, except for we've done it that way for the last 20 years? And yes, I do agree that too many software and hardware vendors have no clue how to properly secure their systems. Will it help hide them behind a magic firewall, until they get hacked via proxy (there *will* be a hacked machine behind that firewall), or will it help more to expose them, *get* them hacked, raise a big fuzz in the press about, say, printer vendor XYZ being too stupid to get their firmware right, and get it actually *fixed*, instead of having a time bomb in your network? If nothing ever got compromised from network attacks, the malware wouldn't bother trying them. Serves get compromised from network attacks all day. Unfortunately, servers usually sit behind firewalls that permit just those ports that enable the attacks, like php based attack du jour or sip attacks on weak credentials, etc. To turn that argument around: why are bots mailing me infected documents, or trying to lure me into web sites that contain malware if network attacks are so successful? (But anyway - I already stated far upthread that this is one of the threads where people will not listen and stick to their religion anyway. So I should spend my time coding instead) 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 pgp3MtiaZYaXj.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
Hi, On Thu, Jul 17, 2014 at 10:20:09AM +0200, Steven Barth wrote: Regarding firewalling: I understand and support your point for end-to-end connectivity though there are still quite a few people (including myself) who have reservations about the security implications. This discussion here is very much the same discussion as everywhere when the topic pops up. There's basically 3 sides here: - I want a firewall that mimics IPv4 NAT default-closed behaviour - I want IPv6 to be end-to-end so applications can just work and not bother with PCP, firewall traversal, etc. - I want a firewall but one that defaults to open for $somestuff and to close for $otherstuff (swisscom model) I don't think we will be able to agree here any more than on the IETF lists or whatever. But what we (uh, Steven :) ) can do is: provide easily selectable firewall profiles that match the 3 common scenarios. As of today, OpenWRT routers are not autoconfig yet, but you need to put in some config anyway (like, the protocol and username/password used to connect to your ISP). If we could have a basic firewall switch there that has 4 settings closed, fully open, balanced (swisscom model) or customized, this should enable users to get what they want without having to really think about firewall rules, ports, etc. Of course the question remains what should the default be, and I'm not sure we can come to an agreement on this. 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 pgpG13MFLVJiR.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
Hi, On Thu, Jul 17, 2014 at 12:07:57PM -0400, Soren Harward wrote: the worst case scenario is that the user's machine gets compromised. This is an extreme likely case, but it will not happen by a network based attack. Compromises these days on end hosts happen due to garbage the users click on (in mail, in web sites, etc.), much less due to network attacks (because client systems have become more robust to these, and they all come with a host firewall by default today). So always assume that the compromised host is already *in* your network, and then re-evaluate your router firewall requirements. 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 pgpz91XsOUdoy.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Hi, On Wed, Jul 16, 2014 at 08:41:50AM -0300, Gui Iribarren wrote: then, what happens when those devices are deployed in a myriad of real-world scenarios? hackers rejoice! This actually is a somewhat moot arguments. Devices travel today, and while your home network and office network might be behind a firewall, the hotspot you're using while waiting for your train might not be. So with todays devices, every device needs to be able to protect itself (i.e.: host firewall, services only accepting connection from local network, etc. - windows 7 doing a fairly good job with this today). The old model strong firewall, weak devices behind it is just a thing not matching reality anymore... 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 pgp1z1dVC3e9u.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] openssl: version bump
Hi, On Thu, Jun 05, 2014 at 11:54:40PM +0200, joerg jungermann wrote: today appeared another serious vulnerability in openssl. More info is here http://ccsinjection.lepidum.co.jp. Users are advised to update to openssl 1.0.1h. Thank you for your patch, it was committed in r41026 and 41027. Will there be a backport to AA 12.09? Seconded - that would be very welcome (because OpenVPN is vulnerable to CVE-2014-0224). 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 pgpKjTwnFL2Wa.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hnet tests
valid_lft 3448sec preferred_lft 1648sec inet6 2001:608:0:62:12fe:edff:fee6:5f33/64 scope global dynamic valid_lft 2591971sec preferred_lft 604771sec inet6 fe80::12fe:edff:fee6:5f32/64 scope link valid_lft forever preferred_lft forever $ ip -6 route 2001:608:5:b5::/64 dev eth1 proto static metric 1024 So it looks good to me. Though... ip -6 route actually brings up the next huh, what? question: root@OpenWrt:~# ip -6 route default from :: via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024 default from 2001:608:0:62::/64 via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024 default from 2001:608:5::/56 via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024 2001:608:0:62::/64 dev eth1 proto kernel metric 256 expires 2591907sec 2001:608:5:b5::/64 dev eth1 proto static metric 1024 unreachable 2001:608:5::/56 dev lo proto static metric 10 error -128 unreachable 2001:608:5::/56 dev lo proto static metric 2147483647 error -128 unreachable fd83:af19:9ef::/48 dev lo proto static metric 2147483647 error -128 I understand the defaults (eth0=wan, source dependent, could be multiple routers, but there is only one, so all the same), and the unreachables. I do not understand this one: 2001:608:0:62::/64 dev eth1 proto kernel metric 256 expires 2591907sec this network is connected to the *WAN* side of things (eth0), and announced by RA from the Cisco to the WRT. The address from that /64 is visible on both eth0 + eth1, which I find a bit surprising but otherwise harmless, but the route shouldn't point to eth1 - my belly says this would make the box unable to reach other devices on the :0:62:: LAN. Incidentially, when I ping6 the GUA address of the router, it *does* work: root@OpenWrt:~# ping6 2001:608:0:62:: PING 2001:608:0:62:: (2001:608:0:62::): 56 data bytes 64 bytes from 2001:608:0:62::: seq=0 ttl=64 time=0.810 ms 64 bytes from 2001:608:0:62::: seq=1 ttl=64 time=0.658 ms whut? Anyway. Short summary: with the change to hnet.sh, it seems to be working and I get all the addresses and prefixes I expect to see. There is just confusion in what should the output of some commands look like. thanks, 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 pgpejeKsv4_9z.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hnet tests
Hi, On Sat, May 03, 2014 at 04:44:49PM +0200, Steven Barth wrote: If I do proto dhcp and no forceprefix, the wan interface gets an IPv6 address from the RAs received (plus default route). Right now, I have neither an IPv6 default route nor an address, so it very much looks like it's ignoring my RAs. Strange as RA handling is done independently but OK. Mmmh. Something is funny in that box - the address from RA and the default route appeared as soon as the DHCPv6-PD issue was resolved. [..] Thanks for testing against ISC DHCP (other mail). I'm not sure what is different here - maybe ISC is returning the prefix right away, while IOS just tells the router go away? Might be IOS weirdness of this specific version. We have tested against other Cisco devices which works fine. Which version is it? This is a 6500 with 12.2(33)SXI3 - which can't do IA_NA at all. More recent versions (12.4T something) can do IA_NA for static assignments, but as far as I could find, no IOS can do IA_NA from pools, the traditional stateful DHCP thing. I will add a box with some 12.4T release in the mix tomorrow, upstreaming the second router. We'll see what happens there... # ifup lan_6 [ not showing any activity ] as per your definition, this is not working, right?. Not necessarily. The _6 interfaces are only showing information acquired from DHCPv6-servers/RAs so this only matters if its an uplink. ifstatus lan without _6 shows the data from homenet / hnetd such as IP address, firewall zone. OK, understood. So the downstream activity (assigning a LAN prefix, HNCP neighbours, ...) will be in the syslog, or ip -6 addr. [..] 2001:608:0:62::/64 dev eth1 proto kernel metric 256 expires 2591907sec [..] I wonder where that comes from. Could you check if its in ifstatus lan? Don't know where this comes from though. Doesn't really make sense. Are there spurious RAs on eth1 with that address? Summarizing the discussion we had in parallel on IRC: this might have been an artefact of me not renaming the lan and wan interfaces, so possibly other bits of OpenWRT fiddled in parallel to hnetd. One indication is that the route has a lifetime, which hnetd never sets, so it came from elsewhere. I've now changed lan/wan interface names config to: config interface 'hlan' option ifname 'eth1' option proto 'hnet' config interface 'hwan' option ifname 'eth0' option proto 'hnet' and everything that refers to interface/proto is gone (so no more wan6 either) and rebooted - and now the result is what I would naively expect: root@GreenISPRouter:~# ip -6 addr 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qlen 1000 inet6 2001:608:0:62:12fe:edff:fee6:5f33/64 scope global dynamic valid_lft 2591987sec preferred_lft 604787sec 3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qlen 1000 inet6 2001:608:5:5b:12fe:edff:fee6:5f32/64 scope global dynamic valid_lft 3462sec preferred_lft 1662sec root@GreenISPRouter:~# ip -6 route default from :: via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024 default from 2001:608:0:62::/64 via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024 default from 2001:608:5::/56 via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024 2001:608:0:62::/64 dev eth0 proto static metric 256 2001:608:5:b1::/64 dev eth1 proto static metric 1024 unreachable 2001:608:5::/56 dev lo proto static metric 10 error -128 unreachable 2001:608:5::/56 dev lo proto static metric 2147483647 error -128 unreachable fd83:af19:9ef::/48 dev lo proto static metric 2147483647 error -128 ... though there still is weirdness in my box, just for the record :-) - ifdown hlan makes hnetd go crazy (logging 50+ messages/second, not recovering until you do network restart) - /etc/init.d/network restart restarts, but after that, some of the routes are gone - in one case, 2001:608:0:62::/64, in the other case, the 2001:608:5:b1::/64 one. This (again, FTR) is due to hnetd not noticing that network restart has removed the routes, so if you do that, you need to also do hnetd restart. (Noted :)). Anyway, thanks for helping me gettings this off the ground. More questions (and answers for the archive) to come :-) 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 pgpExLCWy38iC.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] option ip6assign 60
Hiya, I've installed trunk (r40576) on a few boxes because I want to play around with homenet (hnetd / package hnet-full). Before I even get there, I'm wondering about something. The sample /etc/config/network file has an option in there which confuses me: config interface 'lan' option ifname 'eth1' #option type 'bridge' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' what is option ip6assign good for, and why does it default to 60? (option bridge commented out by me, as hnetd supposedly does not like bridges) The effect it has is that the interface in question receives a /60 as IPv6 network connected to it: root@OpenWrt:/etc/config# ifconfig -a eth1 Link encap:Ethernet HWaddr 10:FE:ED:E6:5F:32 inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0 inet6 addr: fe80::12fe:edff:fee6:5f32/64 Scope:Link inet6 addr: fd83:af19:9ef::1/60 Scope:Global inet6 addr: 2001:608:0:c10::1/60 Scope:Global ... which is not exactly what the IETF says should be on a LAN - but some other parts of the system see the prefix as /64, like when sending out a RA on that LAN 17:51:19.741002 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 192) fe80::12fe:edff:fee6:5f32 ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 192 hop limit 0, Flags [managed, other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s source link-address option (1), length 8 (1): 10:fe:ed:e6:5f:32 mtu option (5), length 8 (1): 1500 prefix info option (3), length 32 (4): 2001:608:0:c10::/64, Flags [onlink, auto], valid time 2817s, pref. time 1017s prefix info option (3), length 32 (4): fd83:af19:9ef::/64, Flags [onlink, auto], valid time 7200s, pref. time 1800s ... which is perfectly correct, as SLAAC only works for /64. So, well, my question boils down to why is that default there?, and what effects does this option have, besides assigning /60 prefixes to LAN interfaces?. (As a side note: I really like the way IPv6 has gotten integrated into newer releases. Plug in that thing, received DHCPv6-PD from upstream routers, offer v6 to connected LANs, off you go...) 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 pgpj0iFsvpaNY.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] option ip6assign 60
Hi, On Fri, May 02, 2014 at 11:28:29AM -0700, Owen Kirby wrote: A /64 prefix and SLAAC can only really be applied to a single link in your network, so if you wanted to separate your network into multiple links (ie: not bridging) then you would use a shorter prefix to get the routing right between each of those links. For example, the IPv6 prefix generated by your router might be fd83:af19:9ef::/60, but your your ethernet devices would see fd83:af19:9ef:1::/64 for SLAAC, and your WiFi devices might see fd83:af19:9ef:2::/64 for SLAAC. Because they are both subnets of the broader /60 prefix, your router can advertise itself as the router for all of the links in your home network. I do understand *that*, and I can see that if you do multi-level DHCPv6-PD, the first router might want to give the second router a /60, so that this one has 16 /64s for all of its LANs (and so on). But you'd then normally not configure the /60 onto a LAN segment in between, but have a /64 between router A and router B, and the /60 routed across that... 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 pgpXyce0NB9VQ.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] option ip6assign 60
Hi, On Fri, May 02, 2014 at 08:44:06PM +0200, Steven Barth wrote: In regular OpenWrt ip6assign means that - as already written - a /60 (if available) is taken from the DP and the assigned to the given interface. That value was chosen rather arbitrarily. The first /64 of that DP is handed out via RA and stateful DHCPv6 (IA_NA). The rest of the /60 (or whatever you set in ip6assign) can be acquired by downstream routers on that interface via DHCPv6-PD. Ah! So it's a reservation for downstream-DHCPv6-PD. It's still slightly confusing, tbh, to see the ifconfig and route values point the /60 towards the actual interface. But maybe that's just me :-) - it certainly isn't causing problems, just to say that again. Regarding homenet / hnetd, please see http://www.homewrt.org for some documentation. Also feel free to ask me (I'm one of the authors of the draft and implementation) or join us on #hnet-hackers on freenode about anything you might need / want to know. Thanks for the offer. Right now, only one of the routers is life (due to convenience of access to stuff, like arbitrary upstream routers, I'm building this at office, and 3 out of 4 boxes are still at home...), but I'm planning to have this operational in the next few days - and I'm sure questions will come. I've read everything that's linked from the start page on http://www.homewrt.org/ - but it's not really much as far as how can I see what it does? how can I debug it? Is there only one single option to turn this on and off (option proto 'hnet'), or is there more? Does hnetd handle IPv4 and IPv6 today? How do I force selection of a certain /64 on a specific interface? question go... :-) (I *have* read all the *-homenet-* drafts, so I feel I understand the basic concepts and requirements, but now I need to see it) hnetd implements its own prefix delegation algorithm (as its managed throughout the homenet) so usual ip6assign-stuff doesn't apply here. You Understood. I was just curious what it was, spending too much time on side-track curiousity again :-) can also use it with bridges but it might make more sense to use individual ports instead to e.g. avoid unnecessary traffic on WiFi or make proper use of the border detection (e.g. use one switch-port for a second uplink and another for downstream or so). I think the does not like bridges thing came from the old stuff on http://github.org/fingon/hnet-core/ or something like that - can't find it right now. It's good to know that it works, though I'm fully intending to not use bridging anyway :-) - I really really like the hnet approach. Will let you know how it works out! thanks, 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 pgpnvZ5qjUsp7.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hnet tests
Hi,
On Fri, May 02, 2014 at 09:31:43PM +0200, Steven Barth wrote:
I've read everything that's linked from the start page on
http://www.homewrt.org/ - but it's not really much as far as how can
I see what it does? how can I debug it? Is there only one single
option to turn this on and off (option proto 'hnet'), or is there more?
Does hnetd handle IPv4 and IPv6 today? How do I force selection of a
certain
/64 on a specific interface? question go... :-)
Yeah to turn it on on a given interface simply change the proto to
hnet (and remove any previous interface using the same interface in
/etc/config/network). If you want to not use bridging you need to create
one logical interface in /etc/config/network for each switch-port / vlan.
OK. What about the wan6 interface? Default OpenWRT config has
config interface 'wan'
option ifname 'eth0'
option proto 'dhcp'
config interface 'wan6'
option ifname '@wan'
option proto 'dhcpv6'
so I assume the wan6 interface would completely go away, leading to
config interface 'wan'
option ifname 'eth0'
option proto 'hnet'
#config interface 'wan6'
#option ifname '@wan'
#option proto 'dhcpv6'
right?
... but that doesn't work out for me :-( - I can see hnetd talk, but I
completely lost global IPv6 - no RA learning on the WAN anymore, and
no DHCPv6 PD either.
The upstream server complains about IA-NA not being supported (Cisco),
but I don't see a PD request in there...
May 2 22:47:09: IPv6 DHCP: Received SOLICIT from FE80::CC4F:57BB:3A1:93FD on
Vlan2
May 2 22:47:09: IPv6 DHCP: Option IA-NA(3) is not supported yet
May 2 22:47:09: IPv6 DHCP: Sending ADVERTISE to FE80::CC4F:57BB:3A1:93FD on
Vlan2
May 2 22:47:09: IPv6 DHCP: Received SOLICIT from FE80::12FE:EDFF:FEE6:5F33 on
Vlan62
May 2 22:47:09: IPv6 DHCP: Option USER-CLASS(15) is not processed
May 2 22:47:09: IPv6 DHCP: Option RECONF-ACCEPT(20) is not processed
May 2 22:47:09: IPv6 DHCP: Option UNKNOWN(39) is not processed
May 2 22:47:09: IPv6 DHCP: Option IA-NA(3) is not supported yet
May 2 22:47:09: IPv6 DHCP: Sending ADVERTISE to FE80::12FE:EDFF:FEE6:5F33 on
Vlan62
(Upstream router sends RA with A and O bit set, and that worked nicely
with proto dhcpv6)
and ifstatus wan also looks very much passive...
root@OpenWrt:~# ifstatus wan
{
up: true,
pending: false,
available: true,
autostart: true,
uptime: 419,
l3_device: eth0,
proto: hnet,
device: eth0,
metric: 0,
delegation: true,
ipv4-address: [
],
ipv6-address: [
],
ipv6-prefix: [
],
ipv6-prefix-assignment: [
],
route: [
],
dns-server: [
195.30.0.2
],
dns-search: [
],
inactive: {
ipv4-address: [
],
ipv6-address: [
],
route: [
],
dns-server: [
],
dns-search: [
]
},
data: {
dhcpv4: disabled,
dhcpv6: disabled,
ra: disabled,
ra_management: 1,
zone: wan
}
}
... so, something I am missing... :-/
thanks,
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
pgp9S8EpMh09K.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hnet tests
Hi, On Fri, May 02, 2014 at 10:56:07PM +0200, Gert Doering wrote: May 2 22:47:09: IPv6 DHCP: Received SOLICIT from FE80::CC4F:57BB:3A1:93FD on Vlan2 May 2 22:47:09: IPv6 DHCP: Option IA-NA(3) is not supported yet May 2 22:47:09: IPv6 DHCP: Sending ADVERTISE to FE80::CC4F:57BB:3A1:93FD on Vlan2 Ooops, *this* was a red herring. Some other device in that test LAN... May 2 22:47:09: IPv6 DHCP: Received SOLICIT from FE80::12FE:EDFF:FEE6:5F33 on Vlan62 May 2 22:47:09: IPv6 DHCP: Option USER-CLASS(15) is not processed May 2 22:47:09: IPv6 DHCP: Option RECONF-ACCEPT(20) is not processed May 2 22:47:09: IPv6 DHCP: Option UNKNOWN(39) is not processed May 2 22:47:09: IPv6 DHCP: Option IA-NA(3) is not supported yet May 2 22:47:09: IPv6 DHCP: Sending ADVERTISE to FE80::12FE:EDFF:FEE6:5F33 on Vlan62 But *that* is the WRT Box... 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 pgp79HgkYe95i.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hnet tests
Hi,
On Fri, May 02, 2014 at 10:56:07PM +0200, Gert Doering wrote:
... so, something I am missing... :-/
Oh well. First thing is I should have looked at 'ifstatus wan_6' which
indeed tells me WAN is working:
root@OpenWrt:/etc/config# ifstatus wan_6
{
up: false,
pending: true,
available: true,
autostart: true,
proto: dhcpv6,
device: eth0,
data: {
}
}
Second thing is what tcpdump tells me...
21:07:24.773303 IP6 (hlim 1, next-header UDP (17) payload length: 148)
fe80::12fe:edff:fee6:5f33.546 ff02::1:2.547: [udp sum ok] dhcp6 solicit
(xid=eacb5 (elapsed-time 12979) (option-request SIP-servers-domain
SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server
AFTR-Name opt_67 opt_82 opt_83) (client-ID hwaddr type 1 10feede65f33)
(user-class) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD
IAID:1 T1:0 T2:0 (IA_PD-prefix ::/0 pltime:0 vltime:0)))
21:07:24.774839 IP6 (class 0xe0, hlim 255, next-header UDP (17) payload length:
59) fe80::214:1cff:fed2:30c0.547 fe80::12fe:edff:fee6:5f33.546: [udp sum ok]
dhcp6 advertise (xid=eacb5 (server-ID hwaddr type 1 00141cd230c0) (client-ID
hwaddr type 1 10feede65f33) (status-code no addresses))
... so hnetd is asking for IA_NA and IA_PD, which the upstream Cisco doesn't
support (at least not in the IOS version that's running, need to research
whether a different Cisco platform could do IA_NA), so the Cisco returns no
addresses, and then hnetd is unhappy and does not want to ask again for
only IA_PD.
Questions :-)
- is hnetd intentionally ignoring the A-Bit in RA?
- what's the recommended config on the upstream side to make it work?
Remove the O-Bit? (I have that because I cannot send RFC6106 info
from IOS, so RA+stateless DHCP is what we currently use to get IPv6
addresses + DNS addresses into the client devices)
thanks,
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
pgpgZawD_JHMS.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Hi, On Tue, Apr 08, 2014 at 10:34:21PM +0200, Steven Barth wrote: Hi Gert, i find it very strange that your ISP doesn't offer public addresses on the WAN interface however I think this is actually standards compliant so we have to deal with it. It's called IPv4 exhaustion... DS-Lite is one of the way to deal with it (which effectively gives you only one NAT in the path), the other way is hand out RFC1918 or 100.64.* addresses and double-NAT. Both stinks, but unless someone finds another few billion IPv4 addresses somewhere, this is what large scale providers need to do. I'm sorry but it seems you misunderstood me. We were talking about IPv6 addresses here. Indeed, I misunderstood you. I was just returning from yet another discussion about the unfairness of global IPv4 run-out... It seems that Hennings' ISP only offers a delegated prefix but no global IPv6-address on the WAN-connection (or there is an unknown issue acquiring said address which I don't know of). I know that RFC 7084 requires a CER to actually deal with this (Weak ES model and all) so I added a fix to allow the DS-Lite source endpoint address to be acquired from a downstream interface. There has been quite a bit of discussion in the ISP camp regarding WAN IPv6 addresses. It's not actually straightforward what to do as an ISP, so multiple variants exist - RA for WAN, DHCPv6-PD for LAN disadvantage: on PPPoE-type deployments, you need two prefixes per client, one /64 for the WAN-RA, one /56 for DHCP (but this works quite nicely in cable deployments where you have a large shared WAN segment anyway) - DHCPv6-IA for WAN, DHCPv6-PD for LAN disadvantage: extra pool management for WAN needed, basically similar to RA for WAN - require use of an IPv6 address out of the delegated /56 for WAN disadvantage: this sort of forces a certain way to segment the /56 onto the client, so I have not actually seen this in the wild - run the WAN over link-local only advantage: only single prefix per customer, easier management for the ISP (in point-to-point deployment scenarios, like PPPoE) disadvantage: well, it complicates source address selection on the CPE, as locally sourced packets leaving via WAN need to use a global address elsewhere - you named it, already. 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 pgpMFKHwsHgb4.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Hi, On Tue, Apr 08, 2014 at 08:22:45AM +0200, Steven Barth wrote: i find it very strange that your ISP doesn't offer public addresses on the WAN interface however I think this is actually standards compliant so we have to deal with it. It's called IPv4 exhaustion... DS-Lite is one of the way to deal with it (which effectively gives you only one NAT in the path), the other way is hand out RFC1918 or 100.64.* addresses and double-NAT. Both stinks, but unless someone finds another few billion IPv4 addresses somewhere, this is what large scale providers need to do. 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 pgpBKyu5CNqOd.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][feeds] openvpn-devel: make openvpn compatible with polarssl 1.2.3 or newer [AA]
Hi, On Wed, Jan 22, 2014 at 03:34:56PM +0100, Tijs Van Buggenhout wrote: Only relevant for Attitude Adjustment, see trac #12982 [1]. Commit r35529 [2] upgrades polarssl from v 1.1(.3) to 1.2(.5), but introduces compile errors for openvpn-devel (2.2.2) package present in feeds, as detailed in [1]. Given that PolarSSL up to 1.2.9 has security relevant bugs, I'd suggest to upgrade PolarSSL up to 1.2.10, and openvpn-devel to 2.3.2 (which has the necessary changes to compile with polarssl 1.2.x). 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 pgpfRH7MEuErv.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] new package: openvpn-interface
Hi, On Sat, Jan 11, 2014 at 01:58:50PM +0100, Ji??í ??lachta wrote: look at the date in the email you are responding to. In that time 2.3 beta was the latest version. Yeah, good point. I thought the mail was new, but it wasn't - someone else hijacked the thread by replying to it (with a completely unrelated subject) and that bumped the whole thread up in my too-large inbox. So I saw a seemingly-new OpenVPN mail referring to an older beta... Will check more closely. 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 pgpHNoajovfYp.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] new package: openvpn-interface
Hi, On Mon, Jan 14, 2013 at 10:53:55AM +0100, Joachim Schlipper wrote: I am intensively using this package for about 3 months now and it fits all my needs, including IPv6 over OpenVPN (using version 2.3 beta) functionality. Specific reasons to use 2.3 beta, and not 2.3.2? 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 pgpnb1ThllAtF.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPIP6 Fragmentation
Hi, On Wed, Nov 06, 2013 at 03:20:45AM -0500, Pietro Paolini wrote: Hi, no hope :-( I tried with 1300 without success. What make me worry is that in the Kernel, referring at the graph http://open-source.arkoon.net/kernel/kernel_net.png the fragmentation is performed in the ip_finish_output() function, and only after that function I can see the print I placed in the ip6_tnl_xmit. ip_fragment: 1460 1300 Fragment packet ip6_tnl_xmit2: Enapsulate Packet Size (1300) ip6_tnl_xmit2: Enapsulate Packet Size (180) Sorry, I actually misled you there. I was thinking IPv6 in IPv4, and you want IPv6 fragmented - for *that* case, the tun1 mtu needs to be so small that the inner packet is fragmented, and the outer packet does not need to be - and what you see is confirming that this is working as expected, it's just not what you *want*. So you want IPv4 in IPv6, and you want to see fragmentation on the IPv6 packets. This *should* work if you set the tun1 mtu to 1500, as the IPv4 stack would then have no incentive to fragment (now one could argue that Linux would run as a router in this case and should not fragment IPv6 packets, but I'd argue that it is the host that is creating the IPv6 packet, and it *should* fragment it). What happens if you put the tun1 mtu to 1500? Then it seems to me that the whole IPv4 stack is taking care of the packet without considering that the destination is an IPIP6 tunnel, I am using the Kernel version 2.6.33.5. Sure it does - the inner fragmentation is governed by the tun1 interface MTU, and that is fully independent of the underlying transport layer, so when checking for fragmentation or not, the kernel doesn't *know* that this is going to end up as an IPv6 packet. Layering, and that. 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 pgpYQjRRPMmfq.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPIP6 Fragmentation
Hi,
On Wed, Nov 06, 2013 at 04:43:54AM -0500, Pietro Paolini wrote:
So you want IPv4 in IPv6, and you want to see fragmentation on the IPv6
packets.
What happens if you put the tun1 mtu to 1500?
In that case it does not fragment the IPv4 packet but the whole packet is
discarded in this piece of code:
mtu = dst_mtu(dst) - sizeof (*ipv6h);
if (skb-len mtu) { -- 1496 1460 --
*pmtu = mtu;
err = -EMSGSIZE;
goto tx_err_dst_release;
}
Interesting. So Linux doesn't handle this as an IPv6 packet created
by myself, following the normal rules for packets sourced locally =
fragment if needed, but follows shortcuts.
which is in the ip6_tnl_xmit2() placed in ip6_tunnel.c, I am assuming this
borderline case is not handled by the kernel (!) then any ideas regarding how
to solve this issues ?
I have to pass here, sorry, no idea. I don't know these areas well enough
to understand what would be needed here.
As a workaround, you could use iptables to lower TCP MSS side on the IPv4
packets, to avoid having full-sized packets on the IPv4 side - no need
for IPv6 fragmentation. But that will not help UDP or other IP protocols.
Or accept IPv4 fragmentation...
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
pgpt5agSZn1rv.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPIP6 Fragmentation
Hi, On Mon, Nov 04, 2013 at 07:52:57AM -0500, Pietro Paolini wrote: I am working for an embedded Linux firmware running on a CPE and I am using an IP4 over IPv6 tunnel configured as following: ip -f inet6 tunnel add tun1 mode ipip6 remote XX:XX:XX local XX:XX:XX dev eth0 By setting an appropriate MTU on the tun1 interface (outer mtu minus ipv6 header size) you should see the fragmentation happen only on the IPv6 side of things. What you are doing is telling the stack yes, tun1 can take my 1500 byte packets just fine!, and then the resulting packet will be too large for the IPv4 path it takes (which is not necessarily so, you could have an IPv4 MTU of 9000 bytes... who knows), so it needs to fragment IPv4, but at that point in time, IPv6 is just payload so it can't do anything about the IPv6 packet anymore (aka send back ICMP PTB). [..] Is there any options to disable the fragmentation on IPV4 ? In that case, you'd need to drop the IPv4 packet. Gain? Zero :-) 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 pgpcLQWMPETFP.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPIP6 Fragmentation
Hi,
try reducing the tun1 mtu further, to see whether it makes the issue go
away - I'm not sure right now if 40 is the right size for ipipv6
(it's the extra IPv4 headers that you need to count, not the IPv6 header)
I'm not exactly sure how to test interface mtu on linux right now -
ifconfig tun1 should show, though...
gert
On Tue, Nov 05, 2013 at 08:43:16AM -0500, Pietro Paolini wrote:
Hi,
thanks for your response, the MTU of my input interface is 1500 and the MTU
of the tunnel interface is 1460 but I still have this problem.
If I try to put another printk:
static int ip_finish_output(struct sk_buff *skb)
{
if ((skb-ipsec_offload == 0)
skb-len ip_skb_dst_mtu(skb) !skb_is_gso(skb)) {
printk(KERN_ERR %s: %d %d Fragment packet input device
(%s)\n,
__FUNCTION__,
skb-len,
dst_mtu(skb_dst(skb)),
skb-dev-name);
return ip_fragment(skb, ip_finish_output2);
}
..
}
I can see that when I send a packet of 1433 - UDP payload, total size 1461 -
( I am using hping3 and I verify with wireshark ), the result is
ip_fragment: 1461 1460 Fragment packet input device (dslite-vlan1)
then the packet is fragmented by the IPv4 Stack even if the MTU 1500 vs 1460
(40 is the size of ipv6 headers)
Any ideas ?
Pietro Paolini
pulsarpie...@aol.com
-Original Message-
From: Gert Doering g...@greenie.muc.de
To: OpenWrt Development List openwrt-devel@lists.openwrt.org
Sent: Tue, Nov 5, 2013 12:02 pm
Subject: Re: [OpenWrt-Devel] IPIP6 Fragmentation
Hi,
On Mon, Nov 04, 2013 at 07:52:57AM -0500, Pietro Paolini wrote:
I am working for an embedded Linux firmware running on a CPE and I am
using an IP4 over IPv6 tunnel configured as following:
ip -f inet6 tunnel add tun1 mode ipip6 remote XX:XX:XX local XX:XX:XX
dev eth0
By setting an appropriate MTU on the tun1 interface (outer mtu minus
ipv6 header size) you should see the fragmentation happen only on
the IPv6 side of things.
What you are doing is telling the stack yes, tun1 can take my 1500 byte
packets just fine!, and then the resulting packet will be too large for
the IPv4 path it takes (which is not necessarily so, you could have an
IPv4 MTU of 9000 bytes... who knows), so it needs to fragment IPv4,
but at that point in time, IPv6 is just payload so it can't do anything
about the IPv6 packet anymore (aka send back ICMP PTB).
[..]
Is there any options to disable the fragmentation on IPV4 ?
In that case, you'd need to drop the IPv4 packet. Gain? Zero :-)
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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
--
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
pgpkohMZAcoLv.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why is everyone patching broadcom-wl-5.100.138
Hi, On Wed, Sep 18, 2013 at 05:45:26AM -0500, James Hilliard wrote: I thought DD-WRT was only using public tarball drivers.I looked through their source and everything seems to match up with tarbar type wl.o files and so on. Try building from their public source. Half of the relevant broadcom bits are not there, so you plainly *can't*... 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 pgpiQmMKViLQF.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [odhcp6c] [PATCH] Add -H option to override the host id
Hi, On Tue, Jun 18, 2013 at 11:35:41AM +0200, Thomas Bächler wrote: Documentation in pppd is incomplete here, at best. While I can define an interface identifier using the 'ipv6' option, it doesn't say anything about hand-shaking. My impression (from the wording of the documentation) is that this is useful if you have a static local and remote LL (know a-priori on both ends) and want to omit IPv6CP completely (just like specifying a local and remote IP for IPv4). That interface identifier is used for the IPv6CP handshake - it's what the client proposes, and the server side can then accept it, or assign something else. DSL providers usually accept, 3G providers usually reject... [..] The point of my patch was that we are not forced to do that. As long as we perform DAD (which the kernel does automatically), we do not violate RFC 4862 by choosing whatever interface identifier we want (I used the term hostid in the patch, but I just noticed that the RFC refers to interface identifier instead). Another point of my patch is that it takes the path of least resistance: Instead of messing with the pppd negotiation, it applies its settings at a point where there is no negotiation and a large degree of freedom. I think this change is useful (without having looked at the actual code), for exactly these reasons. With the IPv6CP handshake, you'll arrive at something the provider controls - but then in the /64 that is announced by RA, you can choose whatever host id / interface identifier you want, and I can see people wanting to use something easy to type and remember, like ::1. (And you can't configure fully static IPv6 addresses here, as the assigned prefix can - and likely, will - change) 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 pgpiw7ZUJ1cYA.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [odhcp6c] [PATCH] Add -H option to override the host id
Hi, On Tue, Jun 18, 2013 at 02:14:18PM +0200, Bjørn Mork wrote: I think this change is useful (without having looked at the actual code), for exactly these reasons. With the IPv6CP handshake, you'll arrive at something the provider controls - but then in the /64 that is announced by RA, you can choose whatever host id / interface identifier you want, and I can see people wanting to use something easy to type and remember, like ::1. I must be missing something here... Exactly how do you communicate an interface identifier via RA? You don't. Which is the point :-) - ISP announces the RA, end user gets to pick whatever prefix they like, inside the /64 announced. One could argue that they should only use the interface identifier that PPP/IPv6CP negotiated, but in practice, that would break at least privacy addresses - so what I've seen so far is if the ISP sends RA with A=1, the user can use any address in that /64 they want. Which even holds true for 3G networks that force link-local to very specific IDs. 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 pgpu1T_DL5sDR.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] bump openvpn to 2.3.1
Hi, On Fri, May 31, 2013 at 10:51:06PM -0400, Adam Gensler wrote: I've been keeping an eye on the openvpn project but I haven't seen 2.3.2 drop yet. Can we push forward with 2.3.1? The tarball is there since yesterday afternoon, but the full announcement (including linking from web pages etc.) will happen on Monday. Here's the announcement mail: http://article.gmane.org/gmane.network.openvpn.devel/7645 and the tarballs are here: http://swupdate.openvpn.org/community/releases/openvpn-2.3.2.tar.gz http://swupdate.openvpn.org/community/releases/openvpn-2.3.2.tar.xz http://swupdate.openvpn.org/community/releases/openvpn-2.3.2.zip 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 pgpv8H6jtsqZZ.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] bump openvpn to 2.3.1
Hi, On Wed, May 29, 2013 at 11:17:13PM -0400, Adam Gensler wrote: The following patch bumps OpenVPN to 2.3.1. Version 2.3.1 adds native support for PolarSSL 1.2+, so I dropped the existing 100-polarssl_update.patch from OpenVPN. Compile tested both the -polarssl and -openssl versions on ar71xx. Runtime tested the -openssl version on a WNDR3800. It's working fine. Interestingly, the OpenVPN package Makefile doesn't include an MD5 hash? Thanks for that. Just as a side note, OpenVPN upstream is likely to release 2.3.2 with a few extra bugfixes tomorrow, so you might want to go right there... (As far as OpenWRT goes, the necessary patches for 2.3.1 and 2.3.2 should be the same) gert, speaking as OpenVPN maintainer -- 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 pgpJbaOFOxOZ_.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenVPN 2.3.1
Hi, upstream has released OpenVPN 2.3.1 yesterday. This is relevant for OpenWRT, I think, because it's the first release ever to support PolarSSL 1.2.x, which in turn is the first branch of PolarSSL to support blowfish. In other words, if you want a small and lean OpenVPN client compiled with PolarSSL that can talk to an OpenVPN-with-OpenSSL server using the default cipher blowfish, you want 2.3.1 + polar 1.2.6... In addition to that, there's a nasty bug in 2.3.0 that will impact OpenVPN connections over TCP if there is congestion (user stuffing too much data into the tun/tap interface for the TCP session to carry) leading to session aborts, instead of proper handling of this (dropping excess packets). For OpenSSL and UDP-only users, the changes are not that drastic - a few bug fixes here and there, lots of documentation updates, etc. https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23 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 pgpgS9xDG_uSJ.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] TP-Link TL-WR841ND to replace WRT54GL?
Hi, On Wed, Mar 06, 2013 at 07:33:44PM +0100, a...@mykolab.com wrote: The TL-WR841ND may very well be a good choice. You can also consider the TL-WR1043ND, it has solid support (I have had about four of them and tested rather heavily over time). It is probably the best tested OpenWrt supported router today. It also fits you budget with a margin: http://www.amazon.com/TP-LINK-TL-WR1043ND-Ultimate-Wireless-Detachable/dp/B002YLAUU8 +1 on the 1043ND. If you do not need 5GHz WiFi, this is a really good buy. Using them with various versions of OpenWRT as 1wire hub, OpenVPN client, server, 3G router (using an USB UMTS dongle, with OpenVPN and IPv6 over OpenVPN), ... 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 pgpgiBZpKThog.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] TP-Link TL-WR841ND to replace WRT54GL?
Hi, On Wed, Mar 06, 2013 at 02:29:30PM -0500, Aaron Z wrote: Thanks all, we will be going with the TL-WR1043ND to allow for some future-proofing. Its currently the same price as a WRT54GL through Amazon so it will fit well in the budget. In that case, make this a +5, at least :-) - more RAM, more Flash, GigE switch, faster CPU, ... There's really no reason for a 54GL anymore, unless you specifically need *that* hardware, for example because you have a highly customized image already... 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 pgpVect2PRbsy.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Change Default IP?
Hi, On Thu, Nov 29, 2012 at 11:56:29PM +, David Woodhouse wrote: Hm, do we really only have Legacy IP enabled by default? We should really set an IPv6 address too (ULA or perhaps site-local). That would be *much* easier to deal with when connecting it to an existing network. No site-locals, please. RFC3879 Deprecating Site Local Addresses. C. Huitema, B. Carpenter. September 2004. (Format: TXT=24142 bytes) (Status: PROPOSED STANDARD) ULAs would be one option, but just having link-local active also helps (I've locked out myself a number of times of IPv4, and being able to get back via link-local was useful, even if slightly cumbersome due to the interface-dependent syntax fe80::1:2:3%eth0 on the client side) 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 pgp5Xh7kfyV3c.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenVPN with netifd
Hi, On Thu, Oct 04, 2012 at 11:29:49AM +0200, Joachim Schlipper wrote: as I didn't get reply in the forum (well, except for that spambot who kindly wrote on the thread), I dare to post my question again here. I'm quite eager to contribute my work on the OpenVPN netifd integration into the repository, but don't know which way to go. I'm neutral on whether netifd is right or wrong, but want to comment on something else. In the forum post, I've seen that you call openvpn with --route-noexec, and leave routing entries to netifd. I'm fine with that, but please make sure this also works for IPv6. IPv6 support in OpenVPN has come a long way, and it would be a shame to see a new framework support only the IPv4 side of things. (openvpn-devel-* are the packages that have full IPv6 support, based on upstream git of the soon-to-be released 2.3 version) If you need a remote server that has working IPv6 and will push IPv6 routes, to see that everything works, let me know and I'll set up something. 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 pgpE5WH71exPy.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenVPN with netifd
Hi, On Thu, Oct 04, 2012 at 01:44:00PM +0200, Joachim Schlipper wrote: IPv6 works just fine with my setup, at least in my simple setup: Cool :-) [..] All of this works like a charm, so I'd say there's no problem with routing IPv6. But I'd be grateful to have someone with more experience look at it and test it with more complex scenarios, since I've just started with IPv6 recently. I'm willing to make it perfect, so I'm eager to learn. There is not much more to it - ifconfig-ipv6 needs to work, and pushing route-ipv6. If it's working for you right now, I think you have tested everything there is, as far as operating system framework is needed. (If you have specific questions about IPv6 in OpenVPN, feel free to mail me directly, of course) 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 pgpCoLgNDnuzN.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenVPN-Devel default packages break IPv6
Hi, On Wed, Sep 12, 2012 at 10:06:00AM +0800, Mirko Vogt wrote: On 09/12/2012 03:30 AM, Gert Doering wrote: Commited to openvpn upstream in cae102ae0c2ff934c456cd584cbf87a33cd95206 Nice - glad to see fixes get applied that fast upstream. I also committed the fix into OpenWrt yesterday (https://dev.openwrt.org/changeset/33375) to make sure it goes into the AA builds. Thanks! However it seems meanwhile some other fixes got applied to the OpenVPN project as well - unlikely to cause regressions, so I went for commit 5d4f5435 (cae102ae+1) in https://dev.openwrt.org/changeset/33376. Yep, that's reasonable. kind regards, 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 pgpbFWFjJGbuG.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] e3200 support question
Hi, On Tue, Sep 11, 2012 at 09:30:14AM +0200, Tobias Waldvogel wrote: I have seen that DD-WRT supports the E3200, at least the switch and the integrated WiFi is working (tried it yesterday). The 5Ghz Wifi however does not work. May be this can be a starting point as DD-WRT provide the source as well. Unfortuantely they use a 2.6.24 kernel, but probably this is better than nothing. Unfortunately I don't have much time the next month, but afterwards I'm going to continue to investigate. I have some experience wih kernel driver development. The USB itself shouldn't be a big problem as I would expect that it is EHCI compliant. Another option would be to check if anyone else is using the same chipset with Linux and to ask for the GPL code. Last time I looked (about a year ago), DD-WRT had working images for the E3200, but from their SVN it was not possible to recreate these, as some vital bits were missing (panic'ed on boot while attaching bcm hardware). At that time, 5 GHz radio *was* working nicely, but all broadcom chipset support came from binary blobs... Did you build from DD-WRT SVN, or use pre-built images? 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 pgpYSr2I6TI4O.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenVPN-Devel default packages break IPv6
Hi, On Tue, Sep 11, 2012 at 04:12:14PM +0800, Mirko Vogt wrote: [..] and while I see some space benefit in not depending on the ip package, I wonder whether this could be changed to have *ENABLE_IPROUTE2 default to 'on', so the pre-built packages *work*, and if someone is really space constrained, he can turn it off...? That is, apply the following patch... The disadvantage in regard of space is enormous.. if there's no other way to get this fixed, okay, I'm fine with that. Defaulting to ENABLE_IPROUTE2 would be a quick fix (and compared to the openssl dependency, ip is tiny :-) - I hope polarssl gets blowfish support RSN, so the default). However busybox's ifconfig IS capable of manage ipv6 settings, so I'd rather like to see openvpn interacting with ifconfig correctly. I'll try to figure out how busybox's ifconfig wants to be called, and prepare a patch for OpenVPN to handle that. This would have to be a local patch in the package feed, as upstream is unlikely to accept a special #ifdef for LINUX_BUSYBOX_IFCONFIG. 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 pgp0D5ABWgzvW.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] make ipv6 ifconfig on linux compatible with busybox ifconfig
We used to call ifconfig tun0 inet6 add The inet6 part is optional,
and not understood by busybox. So now we call ifconfig tun0 add ...,
which works on all supported Linux variants.
Tested on Gentoo, RHEL5+, Debian Lenny up.
Signed-off-by: Gert Doering g...@greenie.muc.de
---
src/openvpn/tun.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 3d60857..4b0365d 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -760,7 +760,7 @@ do_ifconfig (struct tuntap *tt,
if ( do_ipv6 )
{
argv_printf (argv,
- %s %s inet6 add %s/%d,
+ %s %s add %s/%d,
IFCONFIG_PATH,
actual,
ifconfig_ipv6_local,
--
1.7.8.6
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenVPN-Devel default packages break IPv6
Hi, On Tue, Sep 11, 2012 at 12:37:42PM +0200, Joachim Schlipper wrote: this little patch does the trick. Busybox ifconfig just just doesn't want the 'inet6' parameter, the rest is the same. You beat me to it :-) Indeed, it's that simple. I have just sent a patch upstream to change this in the openvpn git sources, as all non-busybox Linux versions accept that syntax as well - so we don't need to maintain an OpenWRT specific patch here. I'll let you know as soon as it has been committed upstream. 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 pgpsFGshyzjEw.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] make ipv6 ifconfig on linux compatible with busybox ifconfig
Hi, On Tue, Sep 11, 2012 at 01:51:11PM +0200, Gert Doering wrote: We used to call ifconfig tun0 inet6 add The inet6 part is optional, and not understood by busybox. So now we call ifconfig tun0 add ..., which works on all supported Linux variants. Tested on Gentoo, RHEL5+, Debian Lenny up. D'oh, that should go to the open*vpn*-devel list. Sorry. 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 pgpnyM7t9Qj7W.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenVPN-Devel default packages break IPv6
Hi, On Tue, Sep 11, 2012 at 03:00:10PM +0200, Joachim Schlipper wrote: Am 11.09.2012 13:53, schrieb Gert Doering: Indeed, it's that simple. I have just sent a patch upstream to change this in the openvpn git sources, as all non-busybox Linux versions accept that syntax as well - so we don't need to maintain an OpenWRT specific patch here. That's great, I was already having my scripts invoke openvpn with the --ifconfig-noexec parameter and call ifconfig in the up script by myself to circumvent the problem with a unpatched openvpn (2.3_alpha3) package. That won't be necessary anymore if the patch makes it into the 2.3 release. I'm just waiting for someone to ACK it on the openvpn-devel list, so it can make its way into 2.3-beta1, to be released end of this week... :-) (http://sourceforge.net/mailarchive/forum.php?forum_name=openvpn-devel) 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 pgp7Cn8I1Y34p.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenVPN-Devel default packages break IPv6
Hi, On Tue, Sep 11, 2012 at 04:12:14PM +0800, Mirko Vogt wrote: However busybox's ifconfig IS capable of manage ipv6 settings, so I'd rather like to see openvpn interacting with ifconfig correctly. Commited to openvpn upstream in cae102ae0c2ff934c456cd584cbf87a33cd95206 please update :-) (As a side note heads up: we're likely going to tag the openvpn git tree as 2.3_beta1 tomorrow or Friday) 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 pgpRJBc9ORejp.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenVPN-Devel default packages break IPv6
Hi, I just installed Attitude Adjustment plus precompiled openvpn-devel-openssl package, and was somewhat surprised to see IPv6 fail (and subsequently, the whole OpenVPN connection). The reason is this: Sep 10 19:51:47 OpenWrt daemon.notice openvpn(sheeva)[1408]: /sbin/ifconfig tun0 10.30.22.18 pointopoint 10.30.22.17 mtu 1500 Sep 10 19:51:47 OpenWrt daemon.notice openvpn(sheeva)[1408]: /sbin/ifconfig tun0 inet6 add 2001:608:4:ee0::1:3/64 Sep 10 19:51:47 OpenWrt daemon.err openvpn(sheeva)[1408]: Linux ifconfig inet6 failed: external program exited with error status: 1 Sep 10 19:51:47 OpenWrt daemon.notice openvpn(sheeva)[1408]: Exiting due to fatal error busybox' ifconfig program does not understand the normal Linux ifconfig syntax to configure an IPv6 address on the tun0 interface. Last time I tested IPv6 with openvpn on openwrt, the openvpn-devel package unconditionally built with --enable-iproute2, which handles IPv6 just fine. Nowadays, we have: DEPENDS:=+kmod-tun +OPENVPN_DEVEL_$(1)_ENABLE_LZO:liblzo +OPENVPN_DEVEL_$(1)_E NABLE_IPROUTE2:ip $(3) ... $(if $(CONFIG_OPENVPN_DEVEL_$(BUILD_VARIANT)_ENABLE_IPROUTE2),-- enable,--disable)-iproute2 \ so --enable-iproute2 depends on CONFIG_OPENVPN_DEVEL_(openssl)_ENABLE_IPROUTE2, which defaults to off, which breaks IPv6 in the packages shipped by default. I'd very much like to see this fixed, obviously :-) - and while I see some space benefit in not depending on the ip package, I wonder whether this could be changed to have *ENABLE_IPROUTE2 default to 'on', so the pre-built packages *work*, and if someone is really space constrained, he can turn it off...? That is, apply the following patch... Index: net/openvpn-devel/Config-openssl.in === --- net/openvpn-devel/Config-openssl.in (Revision 32420) +++ net/openvpn-devel/Config-openssl.in (Arbeitskopie) @@ -63,6 +63,6 @@ config OPENVPN_DEVEL_openssl_ENABLE_IPROUTE2 bool Enable support for iproute2 - default n + default y endmenu thanks, 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 pgp8KQrRufM4x.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] openvpn-polarssl: RNG signature change
Hi, On Thu, Jun 14, 2012 at 07:43:25PM +0200, Mirko Vogt wrote: This is upstream breakage for the combination of --disable-plugins + PolarSSL, caused by historically accumulated #ifdef brokenness in too many places. As a quick fix, just remove #include config.h from ssl_polarssl.h. Patch is in the queue, however I'd like to reproduce the problem on my side before committing. Upstream commit dc4abbb3a8a184d9c696dbba90cdb98b7da70e77 does now contain this quick fix - just removing the extraneous config.h from deep inside the .h hierarchy... (reviewd on the openvpn-devel list, considered reasonable, ACKed). 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 pgpSDEagP4OTd.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] openvpn-polarssl: RNG signature change
Hi, On Fri, Jun 01, 2012 at 07:53:49PM +0200, Mirko Vogt wrote: The OpenVPN stuff needs some love in general. I'll try to get openvpn, openvpn-devel and openvpn-polarssl consolidated and reworked in a reasonable way this weekend / next week (which includes updating openvpn-polarssl). Thanks for your work - this is really so much better than what was there before. Especially using git directly is nice. openvpn-devel-polarssl is not compiling for me right now, though -- some linkage problem around symbols that should be in pf.o and are not. Some bits of the code see ENABLE_PF as #define'ed, and others as #undef, so the caller compiles the function call in, and pf.o is compiled into an empty module... This is upstream breakage for the combination of --disable-plugins + PolarSSL, caused by historically accumulated #ifdef brokenness in too many places. As a quick fix, just remove #include config.h from ssl_polarssl.h. We'll get this fixed upstream in one way or the other, and I'll send over a new commit ID with the fix. 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 pgpYFWvTAlJmB.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] openvpn-polarssl: RNG signature change
Hi, On Fri, Jun 01, 2012 at 07:53:49PM +0200, Mirko Vogt wrote: The OpenVPN stuff needs some love in general. I'll try to get openvpn, openvpn-devel and openvpn-polarssl consolidated and reworked in a reasonable way this weekend / next week (which includes updating openvpn-polarssl). I'm the one who submitted openvpn-devel for inclusion, and I'm quite sorry that I haven't found time yet to test submit an update to a more recent snapshot (with the named polarssl patch and the new build system). I've been distracted by work on the OpenVPN upstream side, but I'm very interested to have a current snapshot available for OpenWRT (because 2.2-release does not have IPv6, while -devel does) - both as an OpenWRT user, and as an OpenVPN lobbyist :-) So if there is anything I can do to help you with this, just mail me. 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 pgpojLIGfkXnr.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Kernel test (on E3000)
Hi, On Sat, Apr 28, 2012 at 01:58:30PM +0200, Alberich de megres wrote: Let's suppose I don't have the jtag access, and normally we don't hit with the first try (on a new kernel porting) a full working kernel. How you test those new kernels? The E3000 has a serial port (hidden on the back side of the WAN port), and can be re-flashed on the boot rom from tftp - and on the serial console you can see later on what it likes or not :-) There's lots of info about that in the dd-wrt forum: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=62998 http://www.dd-wrt.com/phpBB2/viewtopic.php?p=484264 http://www.dd-wrt.com/phpBB2/viewtopic.php?t=56739 I'm not sure if it has a jtag, but I've needed it - even if I had a kernel in flash that paniced on boot. (Note: I never tried openwrt on these, but the boot rom via serial port thingie is completely independent on the specific firmware you want to load - be it original linksys, dd-wrt or tomatoUSB :-) ) 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 pgpGMlT8yeguc.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 Tue, Apr 24, 2012 at 07:13:58PM +1000, Andrew Byrne wrote: I've moved house recently and no longer have access to an ISP that provides native IPv6. This makes it difficult for me to test, however I will see what I can do. Would it help if I provided a tunnel with DHCP-PD on it, potentially with different accounts with different prefix lengths? (This would likely have to be pptp-based, to make this work with a dynamic IP on the client side) 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 pgpnFxq58EflH.pgp Description: PGP signature ___ 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 Tue, Apr 24, 2012 at 03:23:50PM +0200, Emmanuel Deloget wrote: There is no evidence that a pure B2B or B2C market will deplete the IPv4 address space any time soon. The only problem with the IPv4 address space is that it's too small for M2M communication. Asia-PAC has *already* run out of IPv4 addresses at the RIR (APNIC) in May 2011, and the first Telcos are *already* not giving their customers IPv4 addresses anymore. RIPE land (Europe and near East) will run out approximately in August, and the first large-scale carriers are already buying and deploying carrier-grade NAT44 boxes to work around IPv4 shortage. I'm perfectly fine with people not liking IPv6 for a number of reasons (I have my own list), but this isn't going to change the numbers. 7 billion humans on earth, 4 billion IPv4 addresses - whatever we do, it will just delay the inevitable (rearranging deck chairs on the titanic). 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 pgpHSrElN8MPL.pgp Description: PGP signature ___ 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
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
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
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] Seeing bad IP checksums on TCP connection w/ bridging
Hi, On Sat, Dec 31, 2011 at 08:00:07PM -0700, Philip Prindeville wrote: So tcp isn't generating bad checksums... but tcpdump is seeing corrupt packets. Hardware with TCP checksum offloading is known to cause this effect. 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 pgpeFWWvjUy0p.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] maccalc: add option to read mac from temp file
Hi, On Sun, Sep 18, 2011 at 09:30:09PM +0300, Roman Yeryomin wrote: I think how it can be that you can't read 6 bytes from stdin in one attempt but can do it from file? pipe semantics are different from file semantics. A pipe read will return as soon as everything that has been written so far has been read, and not wait for the reader buffer to fill up. 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 pgpUxBbCtfzzb.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] maccalc: add option to read mac from temp file
Hi, On Sun, Sep 18, 2011 at 10:58:23PM +0400, Alexander Gordeev wrote: BTW you shouldn't even expect to read() 6 bytes from file at once. For normal files, read() will never read less than requested, unless you hit an error or eof. $ strace -f -e trace=read,write sh -c 'dd if=/dev/urandom bs=1 count=6 | cat /dev/null' /dev/urandom is not a *file*... cat tries to read 32768 but gets 1 byte on every read. ... and cat does not read from /dev/urandom in the first place here, but from the pipe from dd. 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 pgpgd6wzN41Vm.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1ag support in OpenWRT
Hi, On Fri, Jul 01, 2011 at 05:21:45PM +0530, santosh wrote: I'm not aware if there is any open source implementation of 802.1ag. I hope someone with the correct knowledge will respond to you. Good luck. Googling leads to... https://noc.sara.nl/nrg/dot1ag-utils/index.html The IEEE 802.1ag standard is a set of protocols for Ethernet OAM (Operations, Administration, and Management). The dot1ag-utils software package is an Open Source (new BSD License) implementation of the IEEE 802.1ag protocol and is supported on Linux, FreeBSD and MacOSX server Wasn't *that* particularily hard to find. 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 pgpCybzz41Jhq.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1ag support in OpenWRT
Hi, On Fri, Jul 01, 2011 at 05:51:29PM +0530, Satendra... wrote: The dot1ag-utils software package are the user space utilities to configure CFM OAM and provide support to send various OAM PDUs such as Connectivity Control Messages, Loop Back messages and Link Trace messages etc. But as far I could understand , for OAM protocols to be supported under linux, Linux networking stack does require support for OAM protocols. I am looking for that part of CFM OAM. Well, since the web page says it is supported under Linux, I think the easiest approach would be to ask those people what's needed to do this on Linux, no? 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 pgpnWxVUDaYJK.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] generic: Include IPv6 support into the kernel for 2.6.38+
Hi, On Tue, May 03, 2011 at 03:04:04PM -0600, so...@guug.org wrote: Do not enforce IPv6! Last time I enforce it on end users was a mess, really, I was an IPv6 enthusiast until I had to step back and turn it off. DJ Bernstein and others were plain right: http://weblog.kernelcode.com/2010/02/25/ipv6-is-a-failure-stop-wasting-everyones-time/ Unless someone finds a magic lantern that has a few more billion IPv4 addresses in it, IPv6 is all we have. Looking at the global IPv6 routing table, ISPs seem to have finally noticed as well... (And DJB is part of the problem, not helping with any solution at all) 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 pgpx5yqY6yr56.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] On RoboSwitches and more than 15 VLANs
Hi, I wonder what the current words of wisdom regarding VLAN configuration on the various embedded switches in OpenWRT (and maybe Linux in general) is, especially regarding more than 15 VLANs. I have recently been faced with a customer project where I needed to hand over some stuff on VLAN ID 920, 930 and 940, which doesn't work out of the box on an E3000 using DD-WRT - DD-WRT only knows about 15 VLANs, while the switch in the E3000 (BCM53115) can do full 4k according to the marketing blurb found in the web. Now, before you tell me this is not DD-WRT here, I know that ;-) - and I already solved it there... http://www.dd-wrt.com/phpBB2/viewtopic.php?p=535915#535915 ... basically this can be done by changing the number of vlan setting in switch-robo.c from 16 to 1020, thus creating 1020 subdirs (yuck) in /proc/switch/eth0/vlan/..., and then echo'ing the necessary port settings in there. Since OpenWRT also uses switch-robo for some platforms, this would apply here as well. OTOH, this is seriously ugly if extended for full 4k VLANs - it wastes a fair bit of memory in kernel space for stuff hardly ever required, and I'm basically wondering - how switch stuff is generally done in OpenWRT today - whether there's other switches that can do more than 15 VLANs and that are properly supported (and if yes, how that is done) - I have seen a mail from Peter Lebbing regarding the infineon ADM6996 switch, using a swconfig interface (that one seems to support up to 15 VLANs in use, but all 4k VLAN IDs are available while the 53115 seems to support all 4k VLANs in use in parallel). - what is this swconfig interface, and how is it used? It does not seem to use the /proc/switch/ thing, but some other interface? - is someone working on migrating the roboswitch stuff to swconfig? (is this desirable?) ... basically trying to get some better understanding about the different things involved here. 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 pgpHkirlg9H4e.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] 802.1q range on Broadcom based WRTs
Hi, I hope that someone here on the list knows enough about the Broadcom WRT hardware used in the Linksys E3000 to help me answer something that googling didn't get me anywhere. I have a setup where I need to have 802.1q tagged frames come out of this E3000, and the site network admin has assigned vlan IDs 920, 930, and 940. All the documentation I can find always talks about vlans 1..15, and vlan 3 always maps to 802.1q vlan ID 3 (if tagged on an external port). So - can someone point me to the actual hardware capabilities of the switch chip built into these boxes? Is it 15 parallel VLANs, no matter which VIDs or 802.1q VLAN IDs up to 15 (read: no way to use 920)? 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 pgp7r5YBUXyiQ.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT610n v2 support
Hi, On Fri, Dec 17, 2010 at 10:45:07AM +0100, Tomas Kopal wrote: BrainSlayer, the guy behind DD-Wrt, has signed NDA with Broadcom, so he has access to original driver sources. Of course, he does not distribute these sources, he distributes only self-compiled binaries. These are mostly useless for OpenWRT, as they are built for the kernel used by DD-WRT, with a lot of hacks and modifications. I was not aware of that. Thanks for that information. So, the thing that DD-Wrt supports WRT610n is, unfortunately, completely irrelevant for OpenWRT. I understand that now. This is a real pity. 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 pgpMlKfUYnasO.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] miniupnpd config change
Hi, On Tue, Dec 14, 2010 at 10:14:46AM -0800, Bogdan Giuglea wrote: -append args -p 5000 -U +if [ $upnp = 1 ]; then +append args -p 5000 +echo enable_upnp=yes /tmp/miniupnpd.conf +else +echo enable_upnp=no /tmp/miniupnpd.conf +fi Don't run echo commands in the background. There is no benefit to it, it needs more resources (extra shell) and will create potential race conditions. IOW: the is completely unnecessary and potentially dangerous. 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 pgpKSvs89AIM0.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] porting to Linksys E3000?
Hi, so far, I've only *used* OpenWRT and have been quite happy with it (and have contributed a package :-) ). Now I am considering actually *porting* OpenWRT and have no idea where to start... Target platform is Cisco/Linksys E3000 (identical to the WRT610Nv2), based on Broadcom 4718 chips, and fully supported by DD-WRT with kernel 2.6. Unfortunately, DD-WRT is not to my liking - everything is nvram set style config, no nice rc scripts to look at tweak, etc. - OpenWRT is my style of doing things. ... so: given that OpenWRT has bcm47xx support, but not E3000/N610 - what are the usual problems in getting a certain platform to actually *work*? Is there a howto or anything? 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 pgpkrM2UGfdQ8.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Update for openvpn-devel
Hi, On Wed, Nov 24, 2010 at 08:16:35PM +0100, Florian Fainelli wrote: On Wednesday 24 November 2010 19:46:54 Gert Doering wrote: ping? I have it committed locally, I will push this later tonight. Sorry about that. Thanks! (I know how busy you folks are, so I usually patiently wait for a while :) ) 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 pgphuNHA9wYKd.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Update for openvpn-devel
the following patch brings openvpn-devel up to week 45 (most recent) openvpn-devel version from git, which has one important bugfix (route command with special-case targets was broken) and enables parallel building. Also, it seems that --enable-small was lost in the application of the last commit - or my local SVN is confused. I know I sent this last time, but svn diff claims it's not in the repository right now... Anyway, here's the output of svn update ; svn diff on the packages feed tree... Please include :-) Signed-off-by: Gert Doering g...@greenie.muc.de Index: openvpn-devel/Makefile === --- openvpn-devel/Makefile (Revision 23955) +++ openvpn-devel/Makefile (Arbeitskopie) @@ -5,14 +5,15 @@ include $(TOPDIR)/rules.mk PKG_NAME:=openvpn-devel -PKG_VERSION:=201035 +PKG_VERSION:=201045 PKG_RELEASE:=1 PKG_SOURCE:=openvpn-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=ftp://ftp.secure-computing.net/pub/FreeBSD/ports/openvpn-devel/ -PKG_MD5SUM:=1f0d2cbfb735df92d7fd8bef5d80a291 +PKG_MD5SUM:=0c54fe19381e8756f40bc1050d7016d8 PKG_INSTALL:=1 +PKG_BUILD_PARALLEL:=1 PKG_BUILD_DIR:=$(BUILD_DIR)/openvpn-devel include $(INCLUDE_DIR)/package.mk @@ -44,6 +45,7 @@ --disable-socks \ --enable-password-save \ --enable-iproute2 \ + --enable-small \ --with-iproute-path=/usr/sbin/ip \ ,\ ac_cv_func_epoll_create=no \ -- 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 pgpVunb82obPY.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Development board/unit
Hi, On Tue, Sep 21, 2010 at 11:14:27AM +0200, Dennis M.D. Ljungmark wrote: There are some requirements ( Decent amount of RAM (24+ Megs), USB support, ethernet ) but they are quite generic, I'm mostly looking for suggestions on devkits or boards to get started from. SheevaPlug comes to mind (Kirkwood SoC). 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 pgpeVAtjDh7SC.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] busybox parallel build (Makefile)
Hi, On Mon, Sep 06, 2010 at 11:31:22PM +0200, Michael Büsch wrote: (I guess you already compiletested them. It's also useful to do one or two dircleans or similar and rebuild the whole tree to make sure they behave well in parallel build). What are the requirements to enable parallel building for a package? Is it sufficient if the package itself builds cleanly with make -j4, or do I need to take some sort of cross-package things into account? (I'm fairly sure openvpn-devel will handle parallel building nicely, but it might not be well-behaved regarding dependencies or something like that...) 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 pgp8sTv5jbi1m.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Update for openvpn-devel
Hi, the following patch brings openvpn-devel up to week 36 (most recent) openvpn-devel version from git, and enables building with --enable-small. This option removes most of the large help messages, saving about 50-60kbyte from the resulting binary (the ipk is 12k smaller already). Tested on 10.03/ar71xx with udp and tcp TUN, IPv4+IPv6 payload, tests passed. Please include :-) Signed-off-by: Gert Doering g...@greenie.muc.de 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 Index: openvpn-devel/Makefile === --- openvpn-devel/Makefile (Revision 22473) +++ openvpn-devel/Makefile (Arbeitskopie) @@ -5,12 +5,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=openvpn-devel -PKG_VERSION:=201026 +PKG_VERSION:=201035 PKG_RELEASE:=1 PKG_SOURCE:=openvpn-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=ftp://ftp.secure-computing.net/pub/FreeBSD/ports/openvpn-devel/ -PKG_MD5SUM:=b7a1836d033096c4d70f86581c2fc49d +PKG_MD5SUM:=1f0d2cbfb735df92d7fd8bef5d80a291 PKG_INSTALL:=1 PKG_BUILD_DIR:=$(BUILD_DIR)/openvpn-devel @@ -43,6 +43,7 @@ --disable-socks \ --enable-password-save \ --enable-iproute2 \ + --enable-small \ --with-iproute-path=/usr/sbin/ip \ ,\ ac_cv_func_epoll_create=no \ pgpA5jj9XzBUh.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] adding openvpn-devel package?
Hi Florian, On Sun, Aug 01, 2010 at 12:35:19AM +0200, Florian Fainelli wrote: Le Wednesday 7 July 2010 10:46:50, Gert Doering a écrit : [..] OTOH, that package does not have any sort of IPv6 support, which means that IPv6-on-OpenWRT users need to compile their own OpenVPN package, which is not that easy for non-developers. [..] I applied in r22445 your Makefile in a new package, called openvpn-devel Thanks for including the package, and for the necessary changes you did to my Makefile. I have test-built it (for ar71xx), and everything worked nicely! I'll send patches to this list if something major changes in openvpn-devel and we need to bump the PKG_VERSION. 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dnsmasq not responding on IPv6
Hi, On Mon, Jul 19, 2010 at 10:24:43AM +0200, Gabriel Kerneis wrote: - check that dnsmasq is actually bound to an IPv6 socket, if support for these are disabled, it may just silently drop binding on these netstat -l -u seems to indicate this is the case (bound to ::1). This is actually not so good - ::1 is the loopback address *only*, so packets destined to the IPv6 interface address would not be caught. :: is the unspecified address, and dnsmasq should listen there, not on ::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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
