[OpenWrt-Devel] [PATCH 2/2,v2] ppp: fix o_special option printing
PPPD crashes (SEGV) when the 'dump' or 'dryrun' options are specified and
an option defined internally as o_special with an option flag of
OPT_A2STRVAL is used. The crash occurs because the option value is not
saved when the parameter is processed, but is then referenced when printed.
Additionally, the arg parameter is missing from the call to the printer
utility. This was encountered using xl2tpd and the l2tp_ppp kernel module;
the option PPPD crashes on is pppol2tp 8.
Modify pppd to correctly save the option value, and to call the printer
utility with the correct parameters.
Signed-off-by: Nathan Hintz nlhi...@hotmail.com
---
v2: Address comments from Yousong Zhou
Please apply along with http://patchwork.openwrt.org/patch/5327/
package/network/services/ppp/Makefile | 2 +-
.../services/ppp/patches/501-save-pppol2tp_fd_str.patch | 13 +
.../network/services/ppp/patches/502-fix-printer-args.patch | 11 +++
3 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644
package/network/services/ppp/patches/501-save-pppol2tp_fd_str.patch
create mode 100644
package/network/services/ppp/patches/502-fix-printer-args.patch
diff --git a/package/network/services/ppp/Makefile
b/package/network/services/ppp/Makefile
index 4cee97a..724be30 100644
--- a/package/network/services/ppp/Makefile
+++ b/package/network/services/ppp/Makefile
@@ -10,7 +10,7 @@ include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=ppp
PKG_VERSION:=2.4.6
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=ftp://ftp.samba.org/pub/ppp/
diff --git
a/package/network/services/ppp/patches/501-save-pppol2tp_fd_str.patch
b/package/network/services/ppp/patches/501-save-pppol2tp_fd_str.patch
new file mode 100644
index 000..44d7fc5
--- /dev/null
+++ b/package/network/services/ppp/patches/501-save-pppol2tp_fd_str.patch
@@ -0,0 +1,13 @@
+--- a/pppd/plugins/pppol2tp/pppol2tp.c
b/pppd/plugins/pppol2tp/pppol2tp.c
+@@ -150,6 +150,10 @@ static int setdevname_pppol2tp(char **ar
+ fatal(PPPoL2TP kernel driver not installed);
+ }
+
++ pppol2tp_fd_str = strdup(*argv);
++ if (pppol2tp_fd_str == NULL)
++ novm(PPPoL2TP FD);
++
+ /* Setup option defaults. Compression options are disabled! */
+
+ modem = 0;
diff --git a/package/network/services/ppp/patches/502-fix-printer-args.patch
b/package/network/services/ppp/patches/502-fix-printer-args.patch
new file mode 100644
index 000..e9201f3
--- /dev/null
+++ b/package/network/services/ppp/patches/502-fix-printer-args.patch
@@ -0,0 +1,11 @@
+--- a/pppd/options.c
b/pppd/options.c
+@@ -994,7 +994,7 @@ print_option(opt, mainopt, printer, arg)
+ p = (char *) opt-addr2;
+ if ((opt-flags OPT_STATIC) == 0)
+ p = *(char **)p;
+- printer(%q, p);
++ printer(arg, %q, p);
+ } else if (opt-flags OPT_A2LIST) {
+ struct option_value *ovp;
+
--
1.9.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RESEND] ar71xx: update Carambola2 platform data
Change list:
* Remove button info on GPIO12, there is no button there.
* Remove nvram mtd partition, as it's not used for anything, saves 64k for
user data.
Tested building for carambola2 target.
Signed-off-by: Mantas Pucka man...@8devices.com
---
target/linux/ar71xx/files/arch/mips/ath79/mach-carambola2.c | 9 -
target/linux/ar71xx/image/Makefile | 2 +-
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-carambola2.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-carambola2.c
index e7bc861..babe101 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-carambola2.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-carambola2.c
@@ -25,7 +25,6 @@
#define CARAMBOLA2_GPIO_LED_ETH1 13
#define CARAMBOLA2_GPIO_BTN_JUMPSTART 11
-#define CARAMBOLA2_GPIO_BTN_RESET 12
#define CARAMBOLA2_KEYS_POLL_INTERVAL 20 /* msecs */
#define CARAMBOLA2_KEYS_DEBOUNCE_INTERVAL (3 *
CARAMBOLA2_KEYS_POLL_INTERVAL)
@@ -60,14 +59,6 @@ static struct gpio_keys_button carambola2_gpio_keys[]
__initdata = {
.gpio = CARAMBOLA2_GPIO_BTN_JUMPSTART,
.active_low = 1,
},
- {
- .desc = reset button,
- .type = EV_KEY,
- .code = KEY_RESTART,
- .debounce_interval = CARAMBOLA2_KEYS_DEBOUNCE_INTERVAL,
- .gpio = CARAMBOLA2_GPIO_BTN_RESET,
- .active_low = 1,
- }
};
static void __init carambola2_common_setup(void)
diff --git a/target/linux/ar71xx/image/Makefile
b/target/linux/ar71xx/image/Makefile
index 822f95d..2b88a8f 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -248,7 +248,7 @@
ap96_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(u-boot-env)ro,6144k(rootfs),17
ap113_mtd_layout=mtdparts=spi0.0:64k(u-boot),3008k(rootfs),896k(uImage),64k(NVRAM),64k(ART),3904k@0x1(firmware)
ap121_mtdlayout_2M=mtdparts=spi0.0:64k(u-boot)ro,1216k(rootfs),704k(kernel),64k(art)ro,1920k@0x1(firmware)
ap121_mtdlayout_4M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,2752k(rootfs),896k(kernel),64k(nvram),64k(art)ro,3648k@0x5(firmware)
-carambola2_mtdlayout_16M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,15936k(firmware),64k(nvram),64k(art)ro
+carambola2_mtdlayout_16M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,16000k(firmware),64k(art)ro
ap132_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1408k(kernel),6400k(rootfs),64k(art),7808k@0x5(firmware)
ap135_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,14528k(rootfs),1472k(kernel),64k(art)ro,16000k@0x5(firmware)
ap136_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6336k(rootfs),1408k(kernel),64k(mib0),64k(art)ro,7744k@0x5(firmware)
--
1.8.1.2
___
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)
Le mardi 15 juillet 2014 à 17:43 -0400, Justin Vallon a écrit : I don't think turning off the firewall is a sane default. I don't advise to turn it off for everything. I am trying to find a good compromise. Your arguments based on global addressability are false because IPv4 can be globally addressable, if you want. You can get static ip addresses (or a subnet), turn off NAT, and turn off the firewall - every internal network device will be on the public internet. Yes (even if I don't understand why you are talking about static addressing; it could work with DHCP the same) but you are talking about people who are able to be routed a public IPv4 prefix, which is very few people today, and will be almost nobody in the future because of IPv4 address space depletion. I assume almost every user of OpenWRT is a “home” user and I believe none of them are offered such a possibility by there ISP (well, I happen to have this possibility with my ISP, but it is a very tiny exception, and I don't even use it). You say: A general principle is that a service should not be bound on a globally reachable address if it is not meant to be globally accessible. If my desktop is given an IPv6 address, are all of my services now globally addressable? Yes. If yes, I have opened up all local services (oops). Well, if you didn't want them to be accessible, you have many possibilities: bind it on some non-global address (LL, ULA), restrict it locally (/etc/hosts.deny when appropriate, custom configuration that limit access to some range, etc), use some authentication, configure your firewall appropriately (on the targeted machine or on your router), … The thing here, is to find a _default_: you are imagining a case where every service should be blocked from outside access by default. But I would like my telephony programs, my P2P clients, my local daemons that I run for friends (local git repos, experimental web apps,…), my different servers that listen on different addresses, etc, to be accessible by default. It seems to me that there are far more use cases for allowed access by default than forbidden access. The thing is, these use cases are not very common today because there is no equivalent in IPv4 (practically): you cannot have “accessible by default” in today NATed IPv4. If no, do I need a locally addressable and globally addressable IPv6 space for each device service, so that I can choose which services I consider internal (my printer, my smb share) vs external (my web server)? Yes, this is one possibility. OpenWRT even have by default an ULA prefix configured for delegation on the local network! (BTW, there is a bug that make it configure the /60 on the lan by default, I couldn't trace its origin) Or you could use one of the means I listed. Comprising configuring OpenWRT's firewall. But what should be the default? Is your use case representing what would be globally the right solution? Of course, a lot of people on this ML are thinking in terms of “I can configure my firewall myself”, but this is not the case of the casual users. And I think that in the end, there are far more casual users of OpenWRT that one think if you take into account people that will use your router to access the Internet: these are the ones that will be blocked to run whatever software they want. That is pushing the security problem to the terminal devices. And this is exactly what the end-to-end argument is about! http://en.wikipedia.org/wiki/End-to-end_principle But I don't want to remove the possibility to secure you network at the edge; I just want to say that by default, we could block only a small portion of traffic and let the less security-problematic one flow. Everyone has the possibility to forbid some traffic at the edge by configuring its firewall. By the way, when we talk about restrict the use of some port, we automatically forbid IPsec (RFC 4301 http://tools.ietf.org/html/rfc4301) and Mobile IPv6 (RFC 6275 http://tools.ietf.org/html/rfc6275), which are layer 3 protocols that don't bother about ports. It is a bit sad when we are forbidding some traffic for “security”. I do not understand what the principle of least privilege has to do here. “Forbidden by default” is not about privileges. Privilege here is the right to do something; with respect to networking: open a connection to any host, open a connection to a specific host, allow incoming connections from any host. Principle of least privilege means that you only allow what is required - default is to restrict, not allow. Privileges are granted where necessary, instead of taken away when abused. Why would you immediately talk about abuses? When one is talking about connecting to someone, that means that your correspondent has allowed traffic to flow in. Was your correspondent abused? No, he willingly bound some software to some address, and offered a service. Should this “privilege” be granted only to a few? I don't think so. This is
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
On Tue, Jul 15, 2014 at 11:45:27AM -0400, Aaron Z wrote: As I understand it, if a device on the inside of the network initiates the connection to a device on the outside (say from a VOIP phone to a VOIP server), return connections from the server are allowed. Yes, this is exactly the role of a stateful firewall. I assume your VoIP example is about SIP. This is an interesting example, because actual voice traffic (RTP) will flow *directly* between endpoints, without going through the server. Obviously, this will fail if your firewall blocks all unsolicited inbound traffic. See: http://blog.lithiumblue.com/2007/07/understanding-relationship-between-sip.html What gets blocked are unsolicited connections from the outside which are generally unneeded (and can be a security risk) unless one is running a server (in which case, the users should know how to open ports on their firewall). You have a client/server model in mind. These is not the only kind of applications out there (see my previous examples: voice or video chat, P2P file sharing, network games, etc). This is all about end-to-end reachability, and the end-to-end argument: http://coreinternetvalues.org/?page_id=1415 http://tools.ietf.org/html/rfc3724 http://en.wikipedia.org/wiki/End-to-end_principle End-to-end reachability has been mostly lost with the IPv4 NAT. We have invested tremendous efforts into ugly workarounds for this lack of end-to-end reachability: ICE, TURN, STUN, UPnP, many ALG, etc. So, really, IPv4 should not be the model and these ugly workarounds should not be seen as natural. IPv6 brings back end-to-end reachability, with all its virtues. Now back to practical issues. My favourite use case is video over XMPP (since I ran into this issue). Let's say you want to establish a video conversation with somebody, using XMPP (Jingle). Assume that the stateful firewall of your home router discards all unsolicited inbound traffic, and does not implement any firewall control protocol (for instance, it is running a default installation of OpenWRT). Then, video will just fail: you won't receive any video from your friend, because it is sent directly to you, and your firewall drops it. The same applies if you want to run a game server, use a P2P file sharing system, or more generally any system based on peer-to-peer communication. Note that I'm only talking about IPv6, so NAT is out of scope: in any case, this is really a matter of stateful firewall, not NAT. You have three general classes of solutions to solve the above problem: 1/ Modify the applications to use intermediate servers for communicating between peers. This is very complicated, inefficient network-wise (since you add an extra intermediary instead of sending traffic directly), and completely misses the point: it basically introduces a client-server model where it's neither needed nor desired. 2/ Allow inbound traffic in the home gateway's firewall. In an ideal world, this is the best solution, since it leaves all the intelligence to end nodes (in accordance with the end-to-end principle). In practice, it is generally frowned upon for home networks, as people don't have any control on their own end-devices nowadays. This is quite sad, but that's a different story. Note that it is not a all-or-nothing solution: the initial proposition was to only allow UDP ports 1024 by default, not *any* traffic. 3/ Use a firewall control protocol, so that end devices can request port forwarding. There are several protocols for this: UPnP, NAT-PMP, PCP. This is not ideal from an end-to-end perspective, since a state must be maintained in the home router. If the router reboots, all mappings are lost. Note that PCP deals with this in a mostly reasonable way [1], so it should not matter a lot in practice (not sure about UPnP and NAT-PMP). Additionally, it requires a modification to the applications, but it's not a big modification (we've been doing with IPv4 for years, using UPnP and NAT-PMP). Currently, OpenWRT implements none of these methods (2/ or 3/), since miniupnpd is not included by default. If we want to fix this, I have a personal preference for (a limited version of) 2/, but 3/ is also fine. Note that both approaches are not incompatible, and it could actually be a good idea to do both. Regards, Baptiste [1] http://tools.ietf.org/html/rfc6887#section-14 pgpLxlbzIO2Xs.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)
+1 to all benjamin arguments, default openwrt ipv4 firewall basically does: * deny all unsolicited traffic coming from WAN to the router (i.e. it's own host) * masquerade the LAN hosts behind a single, scarce, ipv4 address, on outgoing traffic. * allow *any possible traffic* that involves LAN hosts (LAN-LAN, LAN-Router, Router-LAN, LAN-WAN) There's *no* way to allow incoming unsolicited traffic coming from WAN to LAN hosts, since they have no public ips that can address them. So there hasn't been a decision or a policy so far regarding inbound traffic for LAN hosts, there was simply no such scenario. now, default openwrt ipv6 firewall basically does: * deny all unsolicited traffic coming from WAN to the router (i.e. it's own host) * allow *some* traffic involving LAN hosts (LAN-LAN, LAN-Router, Router-LAN, LAN-WAN) * in addition, deny all unsolicited traffic coming from WAN to any LAN host (i.e. taking a decision on behalf of other hosts) it is an error to consider this last point/decision in line with the ipv4 policy, since as stated, there's no such scenario in SOHO ipv4 nets in other words, i'd say the principle of least privilege has not been applied so far in ipv4 world to LAN hosts, (they were allowed to do everything they could possibly do) so if there was any principle so far, was something along full trust for LAN hosts. Now LAN hosts gained a new freedom, getting inbound traffic addressed at themselves. Following the full trust principle, why block that? (and worst: while at it, break ipv6 main 'selling point' - end-to-end internet!) cheers! gui On 16/07/14 05:53, Benjamin Cama wrote: Le mardi 15 juillet 2014 à 17:43 -0400, Justin Vallon a écrit : I don't think turning off the firewall is a sane default. I don't advise to turn it off for everything. I am trying to find a good compromise. Your arguments based on global addressability are false because IPv4 can be globally addressable, if you want. You can get static ip addresses (or a subnet), turn off NAT, and turn off the firewall - every internal network device will be on the public internet. Yes (even if I don't understand why you are talking about static addressing; it could work with DHCP the same) but you are talking about people who are able to be routed a public IPv4 prefix, which is very few people today, and will be almost nobody in the future because of IPv4 address space depletion. I assume almost every user of OpenWRT is a “home” user and I believe none of them are offered such a possibility by there ISP (well, I happen to have this possibility with my ISP, but it is a very tiny exception, and I don't even use it). You say: A general principle is that a service should not be bound on a globally reachable address if it is not meant to be globally accessible. If my desktop is given an IPv6 address, are all of my services now globally addressable? Yes. If yes, I have opened up all local services (oops). Well, if you didn't want them to be accessible, you have many possibilities: bind it on some non-global address (LL, ULA), restrict it locally (/etc/hosts.deny when appropriate, custom configuration that limit access to some range, etc), use some authentication, configure your firewall appropriately (on the targeted machine or on your router), … The thing here, is to find a _default_: you are imagining a case where every service should be blocked from outside access by default. But I would like my telephony programs, my P2P clients, my local daemons that I run for friends (local git repos, experimental web apps,…), my different servers that listen on different addresses, etc, to be accessible by default. It seems to me that there are far more use cases for allowed access by default than forbidden access. The thing is, these use cases are not very common today because there is no equivalent in IPv4 (practically): you cannot have “accessible by default” in today NATed IPv4. If no, do I need a locally addressable and globally addressable IPv6 space for each device service, so that I can choose which services I consider internal (my printer, my smb share) vs external (my web server)? Yes, this is one possibility. OpenWRT even have by default an ULA prefix configured for delegation on the local network! (BTW, there is a bug that make it configure the /60 on the lan by default, I couldn't trace its origin) Or you could use one of the means I listed. Comprising configuring OpenWRT's firewall. But what should be the default? Is your use case representing what would be globally the right solution? Of course, a lot of people on this ML are thinking in terms of “I can configure my firewall myself”, but this is not the case of the casual users. And I think that in the end, there are far more casual users of OpenWRT that one think if you take into account people that will use your router to access the Internet: these are the ones that will be blocked to
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
adding more wood to baptiste fire... :) On 16/07/14 06:15, Baptiste Jonglez wrote: 2/ Allow inbound traffic in the home gateway's firewall. In an ideal world, this is the best solution, since it leaves all the intelligence to end nodes (in accordance with the end-to-end principle). In practice, it is generally frowned upon for home networks, as people don't have any control on their own end-devices nowadays. This is quite sad, but that's a different story. Note that it is not a all-or-nothing solution: the initial proposition was to only allow UDP ports 1024 by default, not *any* traffic. What if we put it the other way around: enterprises who built end-devices have neglected investing in security measures, comforted by the fact that all these years the de-facto scenario was that inbound connections were technically impossible unless explicit rules were put in place. (port forwards) then, what happens when those devices are deployed in a myriad of real-world scenarios? hackers rejoice! http://www.networkworld.com/article/2223785/microsoft-subnet/unpatched-trendnet-ip-cameras-still-provide-a-real-time-peeping-tom-paradise.html http://www.forbes.com/sites/kashmirhill/2013/07/26/smart-homes-hack/ if we wanna do something good for the people that don't have any control on their own end-devices, that'd be: leveraging openwrt position to shift the de-facto landscape of SOHO networks, implementing open-by-default ipv6, and thus push the people who *do* have control of those end-devices (manufacturers) implement proper security. 3/ Use a firewall control protocol, so that end devices can request port forwarding. There are several protocols for this: UPnP, NAT-PMP, PCP. This is not ideal from an end-to-end perspective, since a state must be maintained in the home router. If the router reboots, all mappings are lost. Note that PCP deals with this in a mostly reasonable way [1], so it should not matter a lot in practice (not sure about UPnP and NAT-PMP). Additionally, it requires a modification to the applications, but it's not a big modification (we've been doing with IPv4 for years, using UPnP and NAT-PMP). to me, the logic is flawed here: why break existing functionality (free native flow of ipv6 traffic), then implement a control protocol to make it work again on the firewall side, and in the end modify applications to use that protocol? If you're going to modify applications in the first place, then simply bind the services to the correctly scoped ipv6 address. If the concern is about an hypothetic legacy application that assumes the local network is private and trusted, and is suddenly exposed by global ipv6 connectivity... i have yet to find such a case ;) all potentially vulnerable software i come across was a) either written from an ipv4-only perspective and doesn't actually bind to ipv6 addresses at all; or b) evolved to support both protocols but binds to ipv4-only by default ...just my end-2-end-cents, Cheers! gui ___ 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] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Le mercredi 16 juillet 2014 à 10:53 +0200, Benjamin Cama a écrit : Well, if you didn't want them to be accessible, you have many possibilities: bind it on some non-global address (LL, ULA), restrict it locally (/etc/hosts.deny when appropriate, custom configuration that limit access to some range, etc), use some authentication, configure your firewall appropriately (on the targeted machine or on your router), … I will give some example of this kind of protection, as I have been operating an open IPv6 home network for more than four years: * My NFS server has a DNS wildcard rule in /etc/exports to limit who can connect * One of my webserver (running nginx), which is not public (contrary to another one) is restricted with some allow/deny rule (à la Apache); I put my local /56. As I have separated LAN from wireless access (different /64), I could even choose not to authorize from wifi but let Ethernet through. Or VPN. Or whatever. * Same for rsync * Local SMTP who don't have to receive mail from outside are just bound to ::1… * My munin on several hosts also have some filters * My SSH is configured with public key only authentication (no password), but accept connections from everywhere Even then, a lot of these services are below 1024, so they would be “protected” by the proposed compromise. On the other hand, I had to do nothing appart from starting the service to offer web access, SMTP, ssh, imap, pop, XMPP, DNS, bittorrent (to several clients), git server, and I even do mobile IPv6. On several hosts; and every guest in my house can do the same. I wish anyone could try this at home, as this gives really a different feeling of what a real “inter-network” access can be. Of course, on the bad side, you have to adapt to the configuration of every software that you want to restrict access to. I wish more of them offered the tcp-wrappers common restriction ability. If you don't want to adapt, then you can go to your firewall config and do the same here. Well, you could even do everything I told from your firewall configuration if you wanted. I totally want people to be able to do that. But forbidding every inbound flow *by default* is to me a bad idea. The advantage I have over other people, maybe, is that I control all the end points I have (they all run free software), so I may be more confident than others. But this is no real reasons to me: as Gert said, every device should be configured in a way that it must be quite resistant to most attacks. This is how the Internet is going to be anyway; you will always find yourself one day on some network you don't know, and your device should be prepared. If you want to be paranoid and block everything on your own network, fine, do it. But the principle of a remote communication through a network is to be reachable, so better be reachable by default ;-) BTW, if you fear being scanned, the IPv6 address space is so big that host that are not publicly known don't risk much. Of course, we are not immune to absolutely every risk, but so is any device, being protected by a firewall or not. -- benjamin ___ 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 14-07-16 08:09 AM, Gert Doering wrote: Hi, 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... While it may be a good idea for your devices to be designed with this principle in mind, I don't necessarily trust all of the IPv6 enabled widgets on my LAN to have been robustly designed with strong local firewalls and free from bugs that remote attackers could exploit. Furthermore, It is not true that every service which can be put on a network, should be put out on the public internet for all to see (ie: SAMBA/NFS). If someone really wants to expose an NFS share to the internet, then they should have the know-how to configure their firewall to do so. Exposing everyones network shares to the public internet by default is a very bad idea. Cheers, Owen ___ 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 16/07/14 12:09, Gert Doering wrote: 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... Ah, sorry if irony blurred my position: your point, Gert, is exactly my point :) in other words, we're both on the same side: my arguments are in favour of openwrt having an open ipv6 firewall by default, so to put the policy back into end-devices hands (where it always should have been) 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. proprietary-software personal devices are a special case - granted. putting that aside, i think it's insightful to consider that a person that has admin access to all her mobile devices config (which carries every day), so to publish (or restrict) services at her own will, if and only if the network devices upstream (to which might have no control over) have a default-open firewall. in ipv4 world, there was no discussion: a default-open inbound policy in routers that would let end-hosts decide, was simply not possible. why carry that legacy restriction into the wonderful ipv6 world? chee::rs! gui gert ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] trac/rss-feed has changed?
my feedreader was used to fetch https://dev.openwrt.org/log/trunk?limit=100mode=stop_on_copyformat=rss but this stopped working around 13. july 13:00 why? what should i use now? bastian ___ 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 Gui, On Jul 16, 2014, at 20:10 , Gui Iribarren g...@altermundi.net wrote: On 16/07/14 12:09, Gert Doering wrote: 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... Ah, sorry if irony blurred my position: your point, Gert, is exactly my point :) in other words, we're both on the same side: my arguments are in favour of openwrt having an open ipv6 firewall by default, so to put the policy back into end-devices hands (where it always should have been) ??? The part in parenthesis is debatable... 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. My interpretation of his examples is that putting the MAC/IPv6-addresses into a router-managed whitelist would have not significantly increased the amount of work involved... proprietary-software personal devices are a special case - granted. putting that aside, i think it's insightful to consider that a person that has admin access to all her mobile devices config (which carries every day), so to publish (or restrict) services at her own will, if and only if the network devices upstream (to which might have no control over) have a default-open firewall. But in your home you have control over the router’s setting, so explicitly managing the access rights is an easy way deal with the quite common case you just put aside? Or what is your idea about the proprietary-software personal devices. I could envision two “networks” a secured default-closed and on optimistic default-open network managed by the same router (sort of like a guest network with default-open, while the main network is default-closed or vice versa). in ipv4 world, there was no discussion: a default-open inbound policy in routers that would let end-hosts decide, was simply not possible. ? The default could have been to direct everything to one internal host (say lowest MAC or first discovered device). why carry that legacy restriction into the wonderful ipv6 world? What is so wonderful about IPv6? Maleware surely will evolve quickly to take advantage of a dropped layer of defense… For experts as you and Benjamin the default does not really matter that much you can easily change it to your liking; but think about non-experts. I for one would be quite startled if the switch to IPv6 would expose parts of my device zoo that was never configured with that problem in mind…. Best Regards Sebastian chee::rs! gui gert ___ 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] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
- 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. On the other hand, how many devices realistically need to be accessible from the outside by default in a typical setting (ie: in a home/small office)? On a network you have several classes of devices: 1. Devices that frequently need to run an server or peer to peer connection that requires outside access (ie: servers, some computers, tablets, phones, gaming consoles, VOIP phones, etc) 2. Devices which might need to be accessible from the outside in a few cases, but generally speaking have no need to be accessible from the outside (ie: most computers 3. Devices which generally have no need to be accessible from the outside (ie: NAS, network printer, security camera, security system, phone system, etc) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWRT IPv6 firewall
I'd like to chime in to this thread as someone who has spent a fair bit of time supporting end users (primarily home and small office users) setting up and using consumer grade routers. All these routers today, of course, necessarily come NATted, meaning no ports are open to the Internet. Users are accustomed to being able to connect their computers to the router's network and be shielded from unwanted intrusions from outside by the NAT firewall. I believe the default behavior of an IPv6 consumer-grade router should be the same: all ports blocked. Of course, it seems foolish to have global addressing and then have a router that blocks client devices, but here is my reasoning: 1.) In the IPv6 world, the firewall should rightfully migrate from the router to the device, but that transition won't be simultaneous with the availability of v6. For some transitional time, we'll have legacy devices on the network that are v6-capable but not necessarily v6-safe - and consumer-grade users will probably not realize it. At the least, users won't be accustomed to having their printer visible to the whole world and will need time to understand that they need to have strong passwords on their printers, cameras, thermostats, dog feeders, etc. (or explicitly block them) 2.) I believe that the transition to v6 in the U.S. and Europe is not going to be slow and orderly, but will be sudden and chaotic, driven by emergent demand for some service that arises in a manner that necessitates v6 access. For that reason, I think that maintaining behavior similar to what consumers see today will be critical in user satisfaction. I expect that, over time, users will become accustomed to the end-to-end nature of the v6 Internet and may demand that the firewall be open by default, and I would certainly propose that we have a simple checkbox in LUCI that allows the firewall to be changed from all closed except explicitly open ports to all open in one action. At some point we would probably change the default behavior from all closed to all open. However, for the moment, I would argue that the rightness of following expected behavior is greater than the rightness of delivering the true end-to-end nature of v6. FWIW, -Bill Moffitt ___ 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)
Sorry for the earlier email, apparently I accidentally hit send rather than save... - 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. On the other hand, how many devices realistically need to be accessible from the outside by default in a typical setting (ie: in a home/small office)? On a network you have several classes of devices: 1. Devices that frequently need to run an server or peer to peer connection that requires outside access (ie: servers, some computers VOIP phones, etc) 2. Devices which might need to be accessible from the outside in a few cases, but generally speaking have no need to be accessible from the outside (ie: most computers, media players, phones, tablets, gaming consoles, etc) 3. Devices which have no need to be accessible from the outside except in special circumstances and in fact could be a security risk if exposed to the outside world (ie: NAS, network printer, security camera, security system, phone system, etc) On 16/07/14 12:09, Gert Doering wrote: 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. That I think is the point. The open everything above port 1024 model is a good idea for some systems (ie: hotspots, hotel networks, etc) but in the typical home or office setting, the great majority of the devices have no need to be accessible from the outside and in fact, making them available from the outside creates a security risk if there is any kind of security flaw on the device. IMO, it comes down to trust: Do you trust that the people who made your NAS, blueray player, etc will release patches when exploits are found 3 years down the road? I don't. Do you trust that the people who made the firmware for your networked camera didn't leave any back doors in it to be found down the road (ie: a hardcoded root password, poor security on the webpage, etc)? I don't. Do you trust that Microsoft didn't miss any bugs in the Windows 7 firewall and that none of the software on the computer is leaving a port open? I certainly don't. I would venture to guess that 95% (or more) of the people who install OpenWRT are quite capable of opening ports in a firewall. == Perhaps a solution would be to do the following: 1. Have a global setting for the firewall that has three options: 1a. Default open from port 0 on up 1b. Default open from port 1024 on up 1c. Default closed 2. Add/change LUCI interface for opening ports. Add a hyperlink or button next to the list of computers on the network that allows setting the following options (for each computer) in the OpenWRT firewall: 2a. Default to open from port 0 on up 2b. Default open from port 1024 on up 2c. Open port X (or service X) for this computer Factory default could be 1c for the time being (to be consistent with the current IPv4 settings) and it could be re-evaluated down the road as things change. == My $0.02. Aaron Z ___ 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)
- 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
Re: [OpenWrt-Devel] Trac: Custom Query results in Missing or invalid form token.
On 11 July 2014 10:04, Jo-Philipp Wich j...@openwrt.org wrote: Thats due to the varnish cache, it strips all incoming cookies for non-authenticated users. Is there some chance to fix this, please? -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] New gstreamer packages
I created several new gstreamer module packages (v4l2 for example), they update makefiles and add some patches. But now I confused with paths, after update gstreamer was moved to the oldpackages directory. Which path patch should contain ? [...] gstreamer is not available in github packages. It has to be there first to get your patch accepted. There are patches for gst1-...-... that has a newer api than the one available in OpenWrt oldpackages. Most of these build fine see http://patchwork.openwrt.org/patch/4982/ and later or the mailing list archive. I remain very interested in seeing the GStreamer 1.0+ patches accepted into OpenWrt, especially before Barrier Breaker. I currently am reading the notes about the GitHub migration to learn how I can become a package maintainer. Thanks, -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] mac80211: squelch WARN_ON_ONCE() caused by inbalanced set/clear of beacon enable it.
A WARN_ON_ONCE() dump was triggered on a MT7620A based device with
following config. Ticket #17032 can be closed with this patch.
config wifi-iface
option device radio0
option network lan
option mode ap
option ssid OpenWrt__T
option encryption none
config wifi-iface
option device radio0
option network lan
option mode ap
option ssid OpenWrt__TT
option encryption none
The dumped warning message.
[ 23.89] [ cut here ]
[ 23.90] WARNING: at
/home/yousong/trunk-openwrt/build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/linux-ramips_mt7620a/compat-wireless-2014-05-22/drivers/net/wireless/rt2x00/rt2800lib.c:1092
rt2800_conf_tx+0x3c8/0x494 [rt2800lib]()
[ 23.94] Modules linked in: rt2800soc rt2800pci rt2800mmio
rt2800lib pppoe ppp_async iptable_nat rt2x00soc rt2x00pci
rt2x00mmio
rt2x00lib pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4
mac80211
ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string
xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark
xt_mac
xt_limit xt_length xt_hl xt_helper xt_ecn xt_dscp xt_conntrack
xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS
xt_REDIRECT
xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY ts_kmp ts_fsm ts_bm slhc
nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4 nf_conntrack_irc
nf_conntrack_ftp iptable_raw iptable_mangle iptable_filter
ipt_REJECT
ipt_ECN ip_tables crc_itu_t crc_ccitt compat act_connmark
act_skbedit
act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw
sch_hfsc
sch_ingress ledtrig_usbdev ip6t_REJECT ip6table_raw
ip6table_mangle
ip6table_filter ip6_tables x_tables nf_conntrack_ipv6
nf_conntrack
nf_defrag_ipv6 ifb ipv6 eeprom_93cx6 arc4 crypto_blkcipher
leds_gpio
gpio_button_hotplug usbcore nls_base usb_common
[ 24.13] CPU: 0 PID: 1502 Comm: hostapd Not tainted 3.10.44 #17
[ 24.14] Stack : 80322eea
0036 8390f818 83154140
80282f60 802d31fb 05de 80322694 8390f818 83154140
0008 001c
0001 8001f00c 0003 8001ca78 83173bd8 83154140
802847ec 82897794
82897720
...
[ 24.21] Call Trace:
[ 24.22] [800121b4] show_stack+0x48/0x70
[ 24.22] [8001cb74] warn_slowpath_common+0x78/0xa8
[ 24.24] [8001cc2c] warn_slowpath_null+0x18/0x24
[ 24.25] [83164078] rt2800_conf_tx+0x3c8/0x494 [rt2800lib]
[ 24.26]
[ 24.26] ---[ end trace ff7bf97509953be2 ]---
---
.../911-rt2x00-rt2x00lib-fix-beacon-bit-balance.patch | 11 +++
1 file changed, 11 insertions(+)
create mode 100644
package/kernel/mac80211/patches/911-rt2x00-rt2x00lib-fix-beacon-bit-balance.patch
diff --git
a/package/kernel/mac80211/patches/911-rt2x00-rt2x00lib-fix-beacon-bit-balance.patch
b/package/kernel/mac80211/patches/911-rt2x00-rt2x00lib-fix-beacon-bit-balance.patch
new file mode 100644
index 000..9154bda
--- /dev/null
+++
b/package/kernel/mac80211/patches/911-rt2x00-rt2x00lib-fix-beacon-bit-balance.patch
@@ -0,0 +1,11 @@
+--- a/drivers/net/wireless/rt2x00/rt2x00mac.c
b/drivers/net/wireless/rt2x00/rt2x00mac.c
+@@ -651,7 +651,7 @@ void rt2x00mac_bss_info_changed(struct i
+* Upload beacon to the H/W. This is only required on
+* USB devices. PCI devices fetch beacons periodically.
+*/
+- if (rt2x00_is_usb(rt2x00dev))
++ if (!rt2x00_is_pci(rt2x00dev))
+ rt2x00queue_update_beacon(rt2x00dev, vif);
+
+ if (rt2x00dev-intf_beaconing == 1) {
--
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mac80211: squelch WARN_ON_ONCE() caused by inbalanced set/clear of beacon enable it.
Hi,
On 14 July 2014 07:39, Yousong Zhou yszhou4t...@gmail.com wrote:
A WARN_ON_ONCE() dump was triggered on a MT7620A based device with
following config. Ticket #17032 can be closed with this patch.
There are other flaws I'd like to report here. With the same config,
station can see the SSID on the air, but it can only connect to
OpenWrt__TT successfully. When trying to connect to OpenWrt__T, the
following message was read from logread.
Sun Jul 13 23:41:17 2014 daemon.info hostapd: wlan0: STA
38:bc:1a:10:d8:8b IEEE 802.11: authenticated
Sun Jul 13 23:41:17 2014 daemon.info hostapd: wlan0: STA
38:bc:1a:10:d8:8b IEEE 802.11: associated (aid 1)
Sun Jul 13 23:41:19 2014 daemon.info hostapd: wlan0: STA
38:bc:1a:10:d8:8b IEEE 802.11: authenticated
Sun Jul 13 23:41:20 2014 daemon.info hostapd: wlan0: STA
38:bc:1a:10:d8:8b IEEE 802.11: authenticated
Sun Jul 13 23:41:20 2014 daemon.info hostapd: wlan0: STA
38:bc:1a:10:d8:8b IEEE 802.11: associated (aid 1)
Sun Jul 13 23:41:21 2014 daemon.info hostapd: wlan0: STA
38:bc:1a:10:d8:8b IEEE 802.11: authenticated
Sun Jul 13 23:41:21 2014 daemon.info hostapd: wlan0: STA
38:bc:1a:10:d8:8b IEEE 802.11: associated (aid 1)
Sun Jul 13 23:41:21 2014 daemon.info hostapd: wlan0: STA
38:bc:1a:10:d8:8b IEEE 802.11: associated (aid 1)
...
Regards.
yousong
config wifi-iface
option device radio0
option network lan
option mode ap
option ssid OpenWrt__T
option encryption none
config wifi-iface
option device radio0
option network lan
option mode ap
option ssid OpenWrt__TT
option encryption none
The dumped warning message.
[ 23.89] [ cut here ]
[ 23.90] WARNING: at
/home/yousong/trunk-openwrt/build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/linux-ramips_mt7620a/compat-wireless-2014-05-22/drivers/net/wireless/rt2x00/rt2800lib.c:1092
rt2800_conf_tx+0x3c8/0x494 [rt2800lib]()
[ 23.94] Modules linked in: rt2800soc rt2800pci rt2800mmio
rt2800lib pppoe ppp_async iptable_nat rt2x00soc rt2x00pci
rt2x00mmio
rt2x00lib pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4
mac80211
ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string
xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark
xt_mac
xt_limit xt_length xt_hl xt_helper xt_ecn xt_dscp xt_conntrack
xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS
xt_REDIRECT
xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY ts_kmp ts_fsm ts_bm
slhc
nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4 nf_conntrack_irc
nf_conntrack_ftp iptable_raw iptable_mangle iptable_filter
ipt_REJECT
ipt_ECN ip_tables crc_itu_t crc_ccitt compat act_connmark
act_skbedit
act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route
cls_fw sch_hfsc
sch_ingress ledtrig_usbdev ip6t_REJECT ip6table_raw
ip6table_mangle
ip6table_filter ip6_tables x_tables nf_conntrack_ipv6
nf_conntrack
nf_defrag_ipv6 ifb ipv6 eeprom_93cx6 arc4 crypto_blkcipher
leds_gpio
gpio_button_hotplug usbcore nls_base usb_common
[ 24.13] CPU: 0 PID: 1502 Comm: hostapd Not tainted 3.10.44 #17
[ 24.14] Stack : 80322eea
0036 8390f818 83154140
80282f60 802d31fb 05de 80322694 8390f818 83154140
0008 001c
0001 8001f00c 0003 8001ca78 83173bd8 83154140
802847ec 82897794
82897720
...
[ 24.21] Call Trace:
[ 24.22] [800121b4] show_stack+0x48/0x70
[ 24.22] [8001cb74] warn_slowpath_common+0x78/0xa8
[ 24.24] [8001cc2c] warn_slowpath_null+0x18/0x24
[ 24.25] [83164078] rt2800_conf_tx+0x3c8/0x494 [rt2800lib]
[ 24.26]
[ 24.26] ---[ end trace ff7bf97509953be2 ]---
---
.../911-rt2x00-rt2x00lib-fix-beacon-bit-balance.patch | 11
+++
1 file changed, 11 insertions(+)
create mode 100644
package/kernel/mac80211/patches/911-rt2x00-rt2x00lib-fix-beacon-bit-balance.patch
diff --git
a/package/kernel/mac80211/patches/911-rt2x00-rt2x00lib-fix-beacon-bit-balance.patch
b/package/kernel/mac80211/patches/911-rt2x00-rt2x00lib-fix-beacon-bit-balance.patch
new file mode 100644
index 000..9154bda
--- /dev/null
+++
