Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
On Sat, 19 Jul 2014, Gert Doering wrote: On Fri, Jul 18, 2014 at 04:08:02PM -0700, David Lang wrote: 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. 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. David Lang ___ 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)
On Thu, 17 Jul 2014, Gui Iribarren wrote: On 17/07/14 21:03, David Lang wrote: I know that IPv6 designers pine for the good old days of the Internet when no security was needed. But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. As such, the idea that IPv6 would restore the everyone can connect to everyone on any port of the early '80s was wishful thinking at best. link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. There is no answer here that will satisfy everyone. But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? Hello, thanks for joining the conversation, you might have not spotted this email https://lists.openwrt.org/pipermail/openwrt-devel/2014-July/026813.html as it is now, the situation is actually the opposite of what you're describing, it's more like: Hey, my VoIP calls are failing, as well as PopcornTime videos, since I installed OpenWRT. They were working just fine with stock TPLink firmware Have you got any examples of stock firmware that blocks incoming traffic by default? In this discussion I have only seen talk of two that don't. Every IPv4 home router I have seen defaults to 'block all incoming, unless something on the inside opens it' If IPv6 routers end up being wide open, then we are going to start seeing people getting compromized and the analysis being that it was through IPv6 and it will get an (undeserved) reputation of being less secure than IPv4 just because stupid vendors are going to have their stuff exposed. We've seen worms specifically targeting printers in the past, what makes you think we aren't going to see things like that exploiting NAS devices, DNLA servers, thermostats, etc? You would be horrified to see what passes for security in the Internet of Things. A lot of that software makes me think of stuff from the '70s and early '80s. I've seen devices manufactured in 2012 that used 4 bits for the year (with the epoc being Jan 1 2010)!! The horror stories that you have heard about how insecure SCADA and other industrial devices are are not exaggerations, if anything they understate the problems. think about the early Internet protocols (SNMP and tFTP), and think about systems that make them look sane and perfectly reasonable. Exposing these systems to inbound connections from anywhere on the Internet is irresponsible. Now, if these devices make a connection out to phone home, allowing that home to reach back is reasonable, and supporting things like upnp to allow devices to specifically open up inbound connections are reasonable. I'm not saying that it needs to be as hard to configure as getting in through IPv4 NAT, but it should NOT be the 'open end-to-end Internet the way $DIETY intended' look at how easy it is to 'root' phones, where the company involved is at least reasonable competent in writing software. For a lot of the IoT devices, the Internet is a rushed, tacked on addition (they already needed a processor to manage something, so spend a few cents more and now they can advertise this mobile device app). Try using some of these apps and devices and see how horrific the software is. David Lang cheers! Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. But that's not the world we live in. David Lang On Wed, 16 Jul 2014, Lyme Marionette wrote: - Original Message - On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren g...@altermundi.net wrote: Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. There have been many good arguments posted on this subject and to throw my opinion in, it a question of effort and expectations. I think everyone can agree that: -It takes equal effort to turn a firewall on, as it does to turn one off. -It takes equal effort to create a specific block list, as it does to create a specific allow list. -UPnP is not included by default for either the ipv4 or ipv6 stacks. I would also go further to suggest that: -Consistency is good, even if it consistent for superficial reasons. We know that, for NAT reasons, that the ipv4 stack by default blocks incoming connections: -Because it doesn't know by default where to route them. -ipv4 end-points have been traditionally insecure. The two ways to get around this (for gaming, etc): -Through setting firewall rules to route the traffic to an end-point. -Through the use of UPnP (which is used by most games to host, and gaming consoles). With the adoption
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
by the way, link local addresses are not going to be used for these devices, because they will all have some 'cloud' feature that will require they have a way to phone home. David Lang On Fri, 18 Jul 2014, David Lang wrote: Every IPv4 home router I have seen defaults to 'block all incoming, unless something on the inside opens it' If IPv6 routers end up being wide open, then we are going to start seeing people getting compromized and the analysis being that it was through IPv6 and it will get an (undeserved) reputation of being less secure than IPv4 just because stupid vendors are going to have their stuff exposed. We've seen worms specifically targeting printers in the past, what makes you think we aren't going to see things like that exploiting NAS devices, DNLA servers, thermostats, etc? You would be horrified to see what passes for security in the Internet of Things. A lot of that software makes me think of stuff from the '70s and early '80s. I've seen devices manufactured in 2012 that used 4 bits for the year (with the epoc being Jan 1 2010)!! The horror stories that you have heard about how insecure SCADA and other industrial devices are are not exaggerations, if anything they understate the problems. think about the early Internet protocols (SNMP and tFTP), and think about systems that make them look sane and perfectly reasonable. Exposing these systems to inbound connections from anywhere on the Internet is irresponsible. Now, if these devices make a connection out to phone home, allowing that home to reach back is reasonable, and supporting things like upnp to allow devices to specifically open up inbound connections are reasonable. I'm not saying that it needs to be as hard to configure as getting in through IPv4 NAT, but it should NOT be the 'open end-to-end Internet the way $DIETY intended' look at how easy it is to 'root' phones, where the company involved is at least reasonable competent in writing software. For a lot of the IoT devices, the Internet is a rushed, tacked on addition (they already needed a processor to manage something, so spend a few cents more and now they can advertise this mobile device app). Try using some of these apps and devices and see how horrific the software is. David Lang cheers! Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. But that's not the world we live in. David Lang On Wed, 16 Jul 2014, Lyme Marionette wrote: - Original Message - On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren g...@altermundi.net wrote: Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. There have been many good arguments posted on this subject and to throw my opinion in, it a question of effort and expectations. I think everyone can agree that: -It takes equal effort to turn a firewall on, as it does to turn one off. -It takes equal effort to create a specific block list, as it does to create a specific allow list. -UPnP is not included by default for either the ipv4 or ipv6 stacks. I would also go further to suggest that: -Consistency is good, even if it consistent for superficial reasons. We know that, for NAT reasons, that the ipv4 stack by default blocks incoming connections: -Because it doesn't know by default where to route them. -ipv4 end-points have been traditionally insecure. The two ways to get around this (for gaming, etc): -Through setting firewall rules to route the traffic to an end-point. -Through the use of UPnP (which is used by most games to host, and gaming consoles). With the adoption of ipv6 there is the opportunity to change this behaviour such that instead of incoming traffic being restricted for technical reasons, that incoming traffic is routed to the correct end-point. However, that begs the questions: A) Is that consistent with what people would expect? B) Are ipv6 end-points secure by design? In regards to A, from the mindset of a non-technical user, would wager that the answer is 'no'. Even though there is a change in technology with ipv6, the ipv6 technology fulfills the same role as ipv4 and this could be seen as opposing direction between the two. This would likely catch many end-users by surprize unless they read the small print regarding this. As for B, given my view of software development, applications, networks, etc (I've been in the IT business for over 25 years now) I would wager that 80% of applications are secure, and that the 0ther 20% make the potential change in policy very risky. IMO, which others may disagree with, would be to include UPnP by default which would/should resolve most of the hosting issues. Thanks. ___ openwrt-devel mailing list openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
On Fri, 18 Jul 2014, Benjamin Cama wrote: Le jeudi 17 juillet 2014 à 17:03 -0700, David Lang a écrit : But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. Do you mean, all the hackers and worms we see today despite all these systems being behind blocking firewalls and NATs? Yep, how much worse would they be if more systems were exposed? […] link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. For this, you have ULA. It is available in OpenWRT and recommanded by the RFCs cited earlier. but these low quality devices will not be using local addresses (unless the router implements outbound NAT) because they will need to connect to the cloud […] But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? This is nonsense, this will never happen as nobody cares about OpenWRT. so we should just all go home since nobody cares what we do. Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. They are exposed anyway, by other means. there are degrees of exposure, and while I agree that perimeter security by itself is not what we really want, throwing away perimeter security on the theory that every device is going to be secure, or that they are exposed anyway is just begging for trouble. David Lang___ 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
On Fri, 18 Jul 2014 10:21:56 -0700, Bill wrote: Gert Doering wrote: 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. I agree - this is an excellent approach I also agree, this set of basic defaults is good. Of course the question remains what should the default be, and I'm not sure we can come to an agreement on this. My own thoughts on this are evolving. In real life (whatever that is), I consider myself more a product manager (marketing guy) than a developer, so I'm interested in the customer experience of the final product. Of course, the final product is really a router, and OpenWRT would be a component of that router. In all fairness, as I'm building that router product, I'm going to modify OpenWRT to meet the needs of the market. So, the bottom line is that, whatever the default is in OpenWRT, I'm going to go ahead and set it to what I need it to be in my build, before I blow it on to the router (or whatever) that the customer sees. The end user of the router would be a random customer (let's just say, someone's mom), and I am responsible for that customer's experience. Being the experienced (some might say, cynical) individual I am, I'd want it to be idiot-friendly - removing as many opportunities for the end user to get into trouble as possible. So, at least at this point in time, I'm going to close all the ports by default. I'd rather face the prospect of helping the customer open the ports as they need that end-to-end connectivity than the prospect of someone saying, you sold me a router that's unexpectedly wide open to the Internet and everyone in the world is sending all manner of nasty stuff to my printer. However, *I* am actually the end user of OpenWRT - it's reasonable to assume that anyone who is downloading OpenWRT or building it from source is sufficiently advanced in their knowledge (or at least wants to be) that they would expect it to be expert-friendly, not idiot-friendly. From that perspective, I still think that having the router block all ports (as is done in v4 consumer-grade routers today) is the idiot-friendly default, but, after thinking about it more, I think that Gert's balanced approach is probably the expert-friendly default and the one I would want and expect in the OpenWRT builds. I think the default should be idiot-friendly. Having the easy knob to toggle to make it 'expert-friendly' should be enough. If the 'expert' can't flip that knob, they can't secure their network either. FWIW, Bill P.S. No, my printer is not v6-ready, either, but let's assume there are some that are... that's a real example that has been exploited in the past, especially with the very expensive, high-end printer/copiers sold to businesses. Again from companies that should know better David Lang ___ 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)
I know that IPv6 designers pine for the good old days of the Internet when no security was needed. But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. As such, the idea that IPv6 would restore the everyone can connect to everyone on any port of the early '80s was wishful thinking at best. link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. There is no answer here that will satisfy everyone. But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. But that's not the world we live in. David Lang On Wed, 16 Jul 2014, Lyme Marionette wrote: - Original Message - On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren g...@altermundi.net wrote: Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. There have been many good arguments posted on this subject and to throw my opinion in, it a question of effort and expectations. I think everyone can agree that: -It takes equal effort to turn a firewall on, as it does to turn one off. -It takes equal effort to create a specific block list, as it does to create a specific allow list. -UPnP is not included by default for either the ipv4 or ipv6 stacks. I would also go further to suggest that: -Consistency is good, even if it consistent for superficial reasons. We know that, for NAT reasons, that the ipv4 stack by default blocks incoming connections: -Because it doesn't know by default where to route them. -ipv4 end-points have been traditionally insecure. The two ways to get around this (for gaming, etc): -Through setting firewall rules to route the traffic to an end-point. -Through the use of UPnP (which is used by most games to host, and gaming consoles). With the adoption of ipv6 there is the opportunity to change this behaviour such that instead of incoming traffic being restricted for technical reasons, that incoming traffic is routed to the correct end-point. However, that begs the questions: A) Is that consistent with what people would expect? B) Are ipv6 end-points secure by design? In regards to A, from the mindset of a non-technical user, would wager that the answer is 'no'. Even though there is a change in technology with ipv6, the ipv6 technology fulfills the same role as ipv4 and this could be seen as opposing direction between the two. This would likely catch many end-users by surprize unless they read the small print regarding this. As for B, given my view of software development, applications, networks, etc (I've been in the IT business for over 25 years now) I would wager that 80% of applications are secure, and that the 0ther 20% make the potential change in policy very risky. IMO, which others may disagree with, would be to include UPnP by default which would/should resolve most of the hosting issues. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Implementing DNSSEC
On Tue, 13 May 2014, Erik Rigtorp wrote: Hi, I recently submitted a patch to bump dnsmasq to 2.70. The main new feature in 2.70 is support for DNSSEC. If dnsmasq is updated my next patch is to enable a build flag to build dnsmasq with DNSSEC support. A word of warning here, enabling DNSSEC can actually knock you off the network due to broken ISPs, cerowrt has spent a lot of time over the last couple of months working on this. I would suggest at least reading through the issues they've been having making things work in the real world before enabling this. David Lang Also there is no maintainer listed in the dnsmasq Makefile. Thanks, Erik ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 22/30][ WRT1900AC ] mamba mvebu: support blink Power led when enter FAILSAFE mode
On Fri, 9 May 2014, John Crispin wrote: (maybe i should start to only send the acks for this series, it will save us a lot of time) no, giving the reasons for each nack is valuable. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Making sense of OpenWRT / Linksys WRT1900AC collaboration claims
On Thu, 17 Apr 2014, Gerry Rozema wrote: On 17/04/14 07:54 PM, Matthew Fatheree wrote: I can acknowledge that this process is ongoing, and our engagement with OpenWRT is not yet complete. From the sounds of most of the folks who are OpenWRT, it's not ongoing because it never started. My questions for the list 1) Is OpenWRT a registered trademark ? Was that process ever completed ? 2) If so, who gave permission to Linksys / Belkin to use that trademark in the marketing literature ? well, this just hit slashdot http://beta.slashdot.org/story/201087 so the fireworks are beginning. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How To Remove nf_conntrack
On Fri, 28 Mar 2014, Alan.Hoo wrote: Hello Everyone how can I remove the nf_conntrack kernel module from OpenWRT System ? creating a build config without it is hard, there are a huge number of indirect dependencies that trigger it, and most of them won't show up until you disable some other component. it would be nice if there was a way to run menuconfig where it would show you all the options, even if they are forced as dependencies so you could work up from the one you want to disable instead of having to work down from all the ones that may enable it. I'll try and dig up a copy of the config that I have for a wndr3800 that does this. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
On Tue, 21 Jan 2014, Ben Mulvihill wrote: The nand driver currently in trunk works fine, provided ... what is the current status of nand flash support? I asked about this within the last couple of weeks and was told that supporing devices with nand flash would require major surgery to the squashfs code to allow it to deal with badblocks. has this been done? was I misinformed on what the problem is? or is this still a problem and devices with nand flash can work, but only if they avoid squashfs? David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] HTTPS for binaries
On Thu, 2 Jan 2014, Peter Lawler wrote: On 01/01/14 23:11, Weedy wrote: If this really bothers you, you build from source. And vet the source code before building images. This is what I do for my clients. Someone also mentioned this approach on the trac issue[0], so I'll use same comments here as well. No offence meant by not personalising it :) --- Someone asked me earlier today about how a 'self built' approach alleviates the chicken and egg problem of the compiler[1] why should you trust the compiler used by the project more than the compiler on your system? In any case, don't the people you are trying to defend against have the power to forge SSL certs as well? (by being able to get some CA that your system trusts to sign a cert that they control) so even if you downloaded via HTTPS they could still mitm your download. I would suggest that you turn your concerns closer to home. How do you know they haven't put malware on your hard drive the way that this page shows can be done? http://spritesmods.com/?art=hddhack not to mention the possibility of your smartphone being hacked by it's charger, and then being used to hack the rest of your system. There are so many ways in that modifying the source code you download in a way that will still compile on a project that changes as rapidly as openwrt is a very daunting task, and you should expect that they have far better uses of their time. David Lang At minimum, I'd suggest maybe it'd be a better usage of infrastructure/development time for OpenWRT to consider reproducible/deterministic binaries[2][3] or am I showing my ignorance of current practice of OpenWRT? Cheers, Pete. [0] https://dev.openwrt.org/ticket/13346#comment:6 [1] http://cm.bell-labs.com/who/ken/trust.html [2] https://wiki.debian.org/ReproducibleBuilds [3] https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] exFAT driver
As I understand it, lawyers are looking over the situation with this driver before it gets included in the upstream kernel. David Lang On Fri, 29 Nov 2013, Wojciech Kromer wrote: Date: Fri, 29 Nov 2013 14:34:44 +0100 From: Wojciech Kromer wojciech.kro...@dgt.com.pl Reply-To: OpenWrt Development List openwrt-devel@lists.openwrt.org To: OpenWrt Development List openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [RFC] exFAT driver I'd like to have kernel exfat driver, esspecialy one that compiles with different kernel versions. This one is readonly and seems to be android specific. Just for start, I've tried it on two machines. After some small changes it compiles and: - works with 2.6.32 on debian - crashes with 2.6.38 on ubuntu Best regards. Accidentally found an exFAT driver in a kernel 2.6.34 source: https://github.com/Pivosgroup/buildroot-linux-kernel/tree/develop/fs/exfat The source of the driver inside the mentioned kernel can be downloaded here: http://www.munted.org.uk/programming/exfat.tar.bz2 If the inclusion of this driver is interesting i can test it, send the feedback and write a patch. Personally i'm not interested on it, but surely there are some people interested in this filesystem. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [v3, 1/4] Add kernel support for Sagemcom F@ST2704V2 ADSL router
That doesn't slow down bitrot of the patches, that just works for one person's
systems, for not.
Is there something wrong with this series that is preventing it from being
merged upstream?
do you need people to report that they need it to get it review priority?
do you need reports of it working for people?
do you need someone to sponsor reviews of it?
There are a lot of people out there who would like to run OpenWRT on their ADSL
router (myself included), so I would think that there's interest in adding
support for these sorts of devices.
David Lang
On Fri, 8 Nov 2013, Martijn Zilverschoon wrote:
Well if you need this that badly, you can patch it yourself :)
Checkout the git repository:
git clone git://git.openwrt.org/openwrt.git
download the patches and apply them to the local git repo.
the command for that is: git apply 'example.patch' (make sure that you
are in the openwrt directory)
I think you have to apply 4 patches since this one is 1/4.
Sorry for the earlier message that was incomplete.
-Martijn
2013/11/8 Martijn Zilverschoon thefriedzom...@gmail.com:
Well if you need this that badly, you can patch it yourself :)
git clone git://git.openwrt.org/openwrt.git
2013/11/8 Weedy weedy2...@gmail.com:
Can this pretty please not die to bitrot?
I need this merged so badly ;_;
On Thu, Oct 31, 2013 at 7:33 PM, Marcin Jurkowski marci...@gmail.com
wrote:
This adds kernel support support for Sagemcom F@st 2704 wireless ADSL
router.
It's a BCM6328-based 802.11n wireless router with USB port and ADSL2+
modem equipped with 64 MiB RAM and 8 MiB flash.
---
.../brcm63xx/patches-3.10/536-board_fast2704.patch | 133
+
1 file changed, 133 insertions(+)
create mode 100644
target/linux/brcm63xx/patches-3.10/536-board_fast2704.patch
diff --git a/target/linux/brcm63xx/patches-3.10/536-board_fast2704.patch
b/target/linux/brcm63xx/patches-3.10/536-board_fast2704.patch
new file mode 100644
index 000..db34932
--- /dev/null
+++ b/target/linux/brcm63xx/patches-3.10/536-board_fast2704.patch
@@ -0,0 +1,133 @@
+--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
b/arch/mips/bcm63xx/boards/board_bcm963xx.c
+@@ -1477,6 +1477,122 @@ static struct board_info __initdata boar
+ },
+ };
+
++static struct board_info __initdata board_FAST2704V2 = {
++ .name = F@ST2704V2,
++ .expected_cpu_id= 0x6328,
++
++ .has_uart0 = 1,
++ .has_pci= 1,
++ .has_ohci0 = 1,
++ .has_ehci0 = 1,
++ .has_usbd = 1,
++
++ .has_enetsw = 1,
++
++ .enetsw = {
++ .used_ports = {
++ [0] = {
++ .used = 1,
++ .phy_id = 1,
++ .name = Port 1,
++ },
++ [1] = {
++ .used = 1,
++ .phy_id = 2,
++ .name = Port 2,
++ },
++ [2] = {
++ .used = 1,
++ .phy_id = 3,
++ .name = Port 3,
++ },
++ [3] = {
++ .used = 1,
++ .phy_id = 4,
++ .name = Port 4,
++ },
++ },
++ },
++
++ .leds = {
++ /* front LEDs */
++ {
++ .name =
F@ST2704V2:green:power,
++ .gpio = 4,
++ .active_low = 1,
++ .default_trigger= default-on,
++ },
++ {
++ .name = F@ST2704V2:red:power,
++ .gpio = 5,
++ .active_low = 1,
++ },
++ {
++ .name = F@ST2704V2:red:inet,
++ .gpio = 2,
++ .active_low = 1,
++ },
++ {
++ .name = F@ST2704V2:green:dsl,
++ .gpio = 3,
++ .active_low = 1,
++ },
++ {
++ .name = F@ST2704V2:green:inet,
++ .gpio = 11,
++ .active_low = 1,
++ },
++ {
++ .name = F@ST2704V2:green:usb,
++ .gpio = 1,
++ .active_low = 1
[OpenWrt-Devel] WNDR4300
As far as I can tell the openwrt for the 4300 requires using a initramfs image instead of a squashfs or jffs image. But how do you load the initramfs image on the system? I managed to compile such an image, but I was unable to successfully load it using the standard netgear hold-reset-then-tftp process. I just get timeouts on the tftp. Any suggestions? David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LTS Kernel
On Wed, 3 Apr 2013, Rafa? Mi?ecki wrote: I wanted predefined 6-monthly release cycles for years now, while others think a release should bring something new all the time. I'm not going to reinvent the wheel analyzing how hard it is to say how many features make it worth releasing new version. A lot of big (and actively developed) projects are using cycling releases now (including Linux kernel). And come one, OpenWrt is getting a lot of patches almost daily. I like 6-monthly (of similar) release cycle, it's just a matter of fact of finding some ppl leading that releases. If nothing else, there is support for new hardware all the time. A lot of people get really nervous about installing from a dev tree onto their one and only router. They really should be able to install from a release before the hardware is discontinued. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] problems with preloaded config
I've got a bunch (~50) of openwrt routers (3700/3800) to configure and I'm running into a problem with the wireless configuration. According to the documentation, I should be able to just leave out the MAC entry and on first reboot, openwrt will add it. What's happening instead is that two new radio sections get created, with the MAC address in them, default SSID, and disabled. How can I work around this without having to gather all the MAC addresses ahead of time and putting them in the config files that I push out to the routers? David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] problems with preloaded config
On Sun, 10 Feb 2013, Felix Fietkau wrote: Simply leaving out the MAC address does not work for multiple wifi devices. Makes sense Newer OpenWrt versions put the device path in the wifi sections instead of the MAC address. This is a recent build from Trunk, could you give me an example of what's needed? I'm not seeing it in the autogenerated config. However, a much more reliable way of preconfiguring devices is putting scripts into /etc/uci-defaults that use uci commands to change the existing config files. That way you avoid all these issues entirely. that gets a little messy with lots of networks. I'll look into it though. David Lang - Felix On 2013-02-10 11:25 AM, Mitch Kelly wrote: Hi, Removing option disabled 1 into 'wireless' and adding in the SSID etc before you build should do the trick, You should not need to add the MAC address into the config file, This should be added automatically when the wifi is detected. MK -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of David Lang Sent: Sunday, 10 February 2013 6:20 PM To: OpenWrt Development List Subject: [OpenWrt-Devel] problems with preloaded config I've got a bunch (~50) of openwrt routers (3700/3800) to configure and I'm running into a problem with the wireless configuration. According to the documentation, I should be able to just leave out the MAC entry and on first reboot, openwrt will add it. What's happening instead is that two new radio sections get created, with the MAC address in them, default SSID, and disabled. How can I work around this without having to gather all the MAC addresses ahead of time and putting them in the config files that I push out to the routers? David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] problems with preloaded config
On Sun, 10 Feb 2013, Felix Fietkau wrote: On 2013-02-10 12:05 PM, David Lang wrote: On Sun, 10 Feb 2013, Felix Fietkau wrote: Newer OpenWrt versions put the device path in the wifi sections instead of the MAC address. This is a recent build from Trunk, could you give me an example of what's needed? I'm not seeing it in the autogenerated config. Ah, so you're not using a mac80211 based driver then? WNDR 3800 http://wiki.openwrt.org/toh/netgear/wndr3800 same radios as 3700v2 http://wiki.openwrt.org/toh/netgear/wndr3700 Atheros AR9223 802.11bgn / Atheros AR9220 802.11an David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] wndr3700v4
now that the 3800 is no longer available, it looks as if there isn't a currently sold netgear router that has official openwrt support. Looking at things, it appears as if the 3700v4 may have a lot of potential Per a post an the cerowrt list, the v4 box is: I took a look at their GPL source distribution. And yea! it's openwrt. And boo! it's ancient openwrt, for example dnsmasq is 2.39 (current is 2.64), and their kernel is 2.6.31. I think the cpu and ethernet chips tho look a lot better: Atheros AR9344+ AR9580(5GHz)+AR9344(2.4GHz). It's my hope these do ipv6 better. There is a openwrt forum post at https://forum.openwrt.org/viewtopic.php?id=41094 i connected via jtag - rs232 - usb to the boot console, here some parts from the output: grep 'AR' Booting Atheros AR934x (ToH - o.k.) Atheros on-chip NAND FLash Controller Driver, Version 0.1 (c) 2010 Atheros Communications, Ltd. Ath Nand ID[878555a0]: 2c:f1:80:95:02 ONFI MICRON MT29F1G08ABADAWP Micron NAND 128MiB 3,3V 8-bit [128MB] 12 cmdlinepart partitions found on MTD device ath-nand Creating 12 MTD partitions on ath-nand: 0x-0x0004 : u-boot 0x0004-0x0008 : u-boot-env 0x0008-0x000c : caldata 0x000c-0x0014 : pot 0x0014-0x0034 : language 0x0034-0x003c : config 0x003c-0x006c : traffic_meter 0x006c-0x007e : kernel 0x007e-0x01fc : rootfs What will be the next step ? There is allready an openwrt running on the machine - netgear didn't respond to my quest for making there buldroot available to the community, yet. I have now purchased one to use for testing and trying to get openwrt to load on it. I've been using Linux since the 0.99 kernel days, and so I have a lot of experiance building custom kernels for hardware in the x86 and even Sparc space, and I have built custom openwrt images for the 3700v2 and 3800 in the past, but I am not as familiar as I would need to be with the boot process and firmware signatures needed to get things loaded to move forward with this. If someone can coach me through the process, I would be happy to work on getting this up. David Lang P.S. I also purchased a wndr4300 and wndr4500 to work on if the 4700v4 ends up being a dud. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
