Re: [OpenWrt-Devel] Trac: Custom Query results in Missing or invalid form token.

[Etienne Champetier]

Le 16 juil. 2014 22:39, Rafał Miłecki zaj...@gmail.com a écrit :

 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?

Create an account? (If it's possible)


 --
 Rafał

___
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.

[Yousong Zhou]

Hi,

On 17 July 2014 12:06, Yousong Zhou yszhou4t...@gmail.com wrote:
 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)
 ...


Played with macaddr option in wifi-iface,  looks like the above
failure was caused by duplicate BSSID in the air...  I used a EEPROM
file from a previous thread and extract MAC address from there.

There is another problem though that if I specify option macaddr for
only one of the two wifi-iface sections, hostapd cannot startup
correctly.  Below is the message from netifd/hostapd.

Sun Jul 13 22:29:31 2014 daemon.notice netifd: radio0 (3091):
Configuration file: /var/run/hostapd-phy0.conf
Sun Jul 13 22:29:31 2014 daemon.notice netifd: radio0 (3091): Using
interface wlan0 with hwaddr 02:0c:43:76:20:58 and ssid OpenWrt__T
Sun Jul 13 22:29:31 2014 daemon.notice netifd: radio0 (3091): Failed
to add BSS (BSSID=00:0c:43:76:20:58)
Sun Jul 13 22:29:31 2014 daemon.notice netifd: radio0 (3091):
Interface initialization failed
Sun Jul 13 22:29:31 2014 daemon.notice netifd: radio0 (3091): wlan0:
interface state UNINITIALIZED-DISABLED
Sun Jul 13 22:29:31 2014 daemon.notice netifd: radio0 (3091): wlan0: AP-DISABLED
Sun Jul 13 22:29:31 2014 daemon.notice netifd: radio0 (3091): wlan0:
Unable to setup interface.
Sun Jul 13 22:29:31 2014 daemon.notice netifd: radio0 (3091):
hostapd_free_hapd_data: Interface wlan0-1 wasn't started
Sun Jul 13 22:29:31 2014 daemon.notice netifd: radio0 (3091):
hostapd_free_hapd_data: Interface wlan0 wasn't started
Sun Jul 13 22:29:31 2014 daemon.notice netifd: radio0 (3091): Device
setup failed: HOSTAPD_START_FAILED


Regards.

yousong



 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 

Re: [OpenWrt-Devel] OpenWRT IPv6 firewall

[Dirk Neukirchen]

On 16.07.2014 22:41, Gui Iribarren wrote:
 On 16/07/14 16:21, Bill Moffitt wrote:
 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.
 
 At least Swisscom (according to Baptiste) and TP-Link seem to have
 solved the dilemma by defining expected behaviour = the true
 end-to-end nature of v6 :P hurray!
 

End-to-End communication without firewalls in routers is important for
some users (myself included)

If expected behaviour seems to differ one could check IETF RFCs or drafts

6092: Recommended Simple Security Capabilities in Customer Premises Equipment 
(CPE) for
Providing Residential IPv6 Internet Service: 
http://tools.ietf.org/rfc/rfc6092.txt 

6204: Basic Requirements for IPv6 Customer Edge Routers
http://tools.ietf.org/rfc/rfc6204.txt

Checking OpenWrt against these or against some proposed consumer certifications
like https://www.ipv6ready.org/?page=documentstag=phase-2-cpe
and a testsuite http://interop.ipv6.org.tw/CERouter/

Possibly there were discussions about ipv6 and firewall settings, end-to-end 
on home routers (CPE) on NANOG or other NOG mailing lists


AFAICT OpenWrt does not have some of these sane defaults enabled to quote 
6092:
IPsec transport and tunnel modes are explicitly secured by definition, so
 this document recommends that the DEFAULT operating mode permit IPsec.

Possibly connected with the firewall issues are the state tracking tables.
Bittorrent use case: https://dev.openwrt.org/ticket/16938 requests NOTRACK 
documentation
And IPv6 privacy extensions might increase tracking tables too if a shorter 
lease time is used.


PS: Checking and updating the wiki might be nice regarding IPv6 capabilities 
from RFCs.
I began adding some pages regarding new features mentioned
in the changelog, linking from http://wiki.openwrt.org/doc/barrier.breaker
Some short use cases / commandlines / guide links from people that developed and
tested these features (and list of/if additional hw/software used) would be 
very helpful.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Sysupgrade to Barrier Breaker on au1000 (MTX-1)

[John Crispin]

On 16/07/2014 00:07, Hauke Mehrtens wrote:
 On 07/15/2014 07:06 PM, Bruno Randolf wrote:
 Another problem I noted when upgrading from AA to BB on MTX-1:
 
 # sysupgrade -n
 /tmp/openwrt-au1000-au1500-jffs2-128k-sysupgrade.bin tar:
 openwrt-au1000-au1500-jffs2-128k.fs: not found in archive 
 Invalid image contents Image check 'platform_check_image'
 failed.
 
 I needed to change in /lib/upgrade/platform.sh: 
 ROOTFS_IMG=openwrt-au1000-au1500-root.fs
 
 In AA the ROOTFS image was called differently, the name in BB
 makes more sense, but how could we provide a good upgrade path
 from AA to BB?
 
 bruno

Hi Bruno,

au1000 was not updated for BB and as you see there is some work missing.

feel free to send a patch to fix the sysupgrade issue. Once that is
done and if you volunteert to maintain au1000 for BB, then we culd add
it to the list of targets that we build for rc2

John
___
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

[Steven Barth]

Hi Dirk,

thanks for your help. I'll try to add some more documentation for the 
IPv6 stuff in the near future.


In general the aim is to make stuff comply with RFC 7084 (successor of 
6204) as closely as possible (with only 1 or 2 exceptions on purpose). 
In general I'm not sure if anyone has really done a full interop test to 
check for compliance with RFCs, though it would be nice if someone 
volunteers. My work has been more on a best-effort basis for now. Though 
some of the OpenWrt people work closely together with various ISPs so 
there are some interoperability tests running and some ISPs even have 
provided some information or patches to make OpenWrt work with their 
glitches. That doesn't necessarily aid in RFC compliance though ;)


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. I don't think it makes sense to change the defaults for BB 
at this point, that would be totally unexpected and hastily. And I don't 
really agree with some of the opinions like users will get used to 
end-to-end IPv6 - in my experience users don't even know what IPv6 is 
and does. Nevertheless we should have a discussion about this for CC 
probably and I will try to get some more opinions also in the light of 
IETF 90 being next week.



Cheers,

Steven
___
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

[Ondřej Caletka]

Dne 16.7.2014 22:41, Gui Iribarren napsal(a):
  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.
 What about... at *this* point? :) (i.e. before BB rc2 freeze)
 
 
  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.
 At least Swisscom (according to Baptiste) and TP-Link seem to have
 solved the dilemma by defining expected behaviour = the true
 end-to-end nature of v6 :P hurray!

+1 for having default firewall settings somewhat more open. IMO opening
incoming connections to TCP/UDP ports greater than 1024 as well as all
other protocols that don't use port numbers would be the best compromise
between security and usability.

Blocking ports lower than 1024 should be sufficient to protect legacy
stuff with exploitable telnet, SSH or HTTP/S management interfaces, as
well as it would block unintended file sharing from home NAS-es using
CIFS/NFS/HTTP(S). On the other hand, it would still allow unrestricted
flow of P2P traffic, as well as ad-hoc servers in home network (For
instance, I like to share a file by running an ad-hoc HTTP server and
sharing a link such as http://[2001:db8:123:456::2]:8080/).

I think that reasonable default matters, because sometimes, you are not
able to change the setting of home router (like visiting a friend or on
public hotspot). It would be sad if you had to use some sort of VPN or
IPv6-over-IPv6 tunnelling just to overcome the firewall.

Cheers!
Ondřej Caletka



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

Re: [OpenWrt-Devel] trac/rss-feed has changed?

[Mathias Kresin]

2014-07-16 20:51 GMT+02:00 Bastian Bittorf bitt...@bluebottle.com:
 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

Hi Bastian,

i'm using the rss feed from gitweb
http://git.openwrt.org/?p=openwrt.git;a=atom;opt=--no-merges which
works quite nice.

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

Re: [OpenWrt-Devel] Sysupgrade to Barrier Breaker on au1000 (MTX-1)

[Bruno Randolf]

Hi John and all,

On 07/17/2014 08:14 AM, John Crispin wrote:
 au1000 was not updated for BB and as you see there is some work missing.
 
 feel free to send a patch to fix the sysupgrade issue. Once that is
 done and if you volunteert to maintain au1000 for BB, then we culd add
 it to the list of targets that we build for rc2

I volunteer to maintain au1000. The only devices I have are MTX-1
though, but I believe there are not many other au1000 boards out in the
wild anyways.

I don't know how to fix the sysupgrade issue. Basically the name used in
AA was wrong (ROOTFS_IMG=openwrt-au1000-au1500-jffs2-128k.fs) and this
has been chnaged to something more generic in BB
(ROOTFS_IMG=openwrt-au1000-au1500-root.fs). sysupgrade from BB to BB
works OK, but the problem is upgrade from AA to BB, where the ROOTFS_IMG
names in the tar do not match.

The only solutions I can think of are, none of which I find really good:

1) Keep on using the old (wrong) name for all image types
2) Provide a symlink with the old name for upgrade from AA to BB
3) Add backwards compatibility code to /lib/upgrade/platform.sh

Any other ideas?

What are the other things that are missing for au1000 in BB?

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

Re: [OpenWrt-Devel] [PATCH] ramips: soc wmac eeprom cleanup

[Roman Yeryomin]

On 15 July 2014 19:40, John Crispin j...@phrozen.org wrote:
 Hi,

 lovely, works for me on the 6 boards that i tested. will merge it in a
 sec.

 i will look into the fixme bits.


So, if nothing is wrong, could it be applied?

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

Re: [OpenWrt-Devel] [PATCH] ramips: soc wmac eeprom cleanup

[John Crispin]

On 17/07/2014 12:53, Roman Yeryomin wrote:
 On 15 July 2014 19:40, John Crispin j...@phrozen.org wrote:
 Hi,
 
 lovely, works for me on the 6 boards that i tested. will merge it
 in a sec.
 
 i will look into the fixme bits.
 
 
 So, if nothing is wrong, could it be applied?
 
 Regards, Roman ___ 
 openwrt-devel mailing list openwrt-devel@lists.openwrt.org 
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
 


Thanks, applied in r41680

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

[OpenWrt-Devel] [PATCH v2] ramips: fix mac address partitions on ASL-26555

[Álvaro Fernández Rojas]

ASL-26555 16MB: caldata is present on uboot-env and devdata, but the proper one 
seems to be the devdata, since mac address corresponds to Amper, the real 
manufacturer, meanwhile the caldata on  uboot-env corresponds to D-Link.
ASL-26555 8MB: caldata is only present on uboot-env, but its mac address 
corresponds to Alpha, the real manufacturer.

Signed-off-by: Álvaro Fernández Rojas nolt...@gmail.com
---
diff --git a/target/linux/ramips/dts/ASL26555-16M.dts 
b/target/linux/ramips/dts/ASL26555-16M.dts
index bd45bc3..74163c2 100644
--- a/target/linux/ramips/dts/ASL26555-16M.dts
+++ b/target/linux/ramips/dts/ASL26555-16M.dts
@@ -31,7 +31,7 @@
reg = 0x3 0x1;
read-only;
};
-   factory: partition@4 {
+   partition@4 {
label = factory;
reg = 0x4 0x1;
read-only;
@@ -69,7 +69,7 @@
};
 
ethernet@1010 {
-   mtd-mac-address = factory 0x4004;
+   mtd-mac-address = devdata 0x4004;
};
 
esw@1011 {
diff --git a/target/linux/ramips/dts/ASL26555-8M.dts 
b/target/linux/ramips/dts/ASL26555-8M.dts
index d7e424d..506f147 100644
--- a/target/linux/ramips/dts/ASL26555-8M.dts
+++ b/target/linux/ramips/dts/ASL26555-8M.dts
@@ -26,8 +26,8 @@
reg = 0x0 0x3;
read-only;
};
-   factory: partition@3 {
-   label = factory;
+   ubootenv: partition@3 {
+   label = uboot-env;
reg = 0x3 0x1;
read-only;
};
@@ -64,18 +64,17 @@
};
 
ethernet@1010 {
-   mtd-mac-address = factory 0x4004;
+   mtd-mac-address = ubootenv 0x4004;
};
 
esw@1011 {
ralink,portmap = 0x1e;
};
 
-   /* devdata partition seems to be missing */
-/* wmac@1018 {
-   ralink,mtd-eeprom = devdata 0x4000;
+   wmac@1018 {
+   ralink,mtd-eeprom = ubootenv 0x4000;
};
-*/
+
otg@101c {
status = okay;
};
___
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

[Fernando Frediani]

Hello guys,

This discussion if becoming each day more confusing for something, which 
for me, is very simple assuming the following:


- IPv6 as IPv4 should block *any incoming connection* on the WAN 
interface including those directed to the LAN IPs behind it.
- If a client in the LAN initiates a connection to outsite, the 
return to the this connection will pass through just fine as it already 
does on IPv4 (assume NAT is not in use).
- If a server in the LAN needs incoming connections it will be 
allowed in a per port or per IP basis on the router.
- If one wants to use the OpenWRT router just as a router and not 
as router+firewall he can just disable the firewall role globally (all 
open X all closed) and let all traffic pass to the networks behind it.


What is making it more complicated than this ?

Regards,

Fernando

On 17/07/2014 09:25, Ondr(ej Caletka wrote:

Dne 16.7.2014 22:41, Gui Iribarren napsal(a):

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.

What about... at *this* point? :) (i.e. before BB rc2 freeze)



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.

At least Swisscom (according to Baptiste) and TP-Link seem to have
solved the dilemma by defining expected behaviour = the true
end-to-end nature of v6 :P hurray!

+1 for having default firewall settings somewhat more open. IMO opening
incoming connections to TCP/UDP ports greater than 1024 as well as all
other protocols that don't use port numbers would be the best compromise
between security and usability.

Blocking ports lower than 1024 should be sufficient to protect legacy
stuff with exploitable telnet, SSH or HTTP/S management interfaces, as
well as it would block unintended file sharing from home NAS-es using
CIFS/NFS/HTTP(S). On the other hand, it would still allow unrestricted
flow of P2P traffic, as well as ad-hoc servers in home network (For
instance, I like to share a file by running an ad-hoc HTTP server and
sharing a link such as http://[2001:db8:123:456::2]:8080/).

I think that reasonable default matters, because sometimes, you are not
able to change the setting of home router (like visiting a friend or on
public hotspot). It would be sad if you had to use some sort of VPN or
IPv6-over-IPv6 tunnelling just to overcome the firewall.

Cheers!
Ondr(ej Caletka



___
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

[OpenWrt-Devel] Netifd support for tunnels and address configuration

[Baptiste Jonglez]

Hi,

I am currently adding GRE support for OpenWRT, based on 6in4 support [1]
(since I couldn't find any documentation).

What is the proper way to support address configuration for tunnel
interfaces?  It seems redundant to handle static address configuration for
each tunnel type, especially with the new ip6* options in BB.  We could
even imagine doing DHCP over a tap tunnel (for instance gretap).

My use case is several GRE interfaces, each with a static IPv4/IPv6
configuration.  Currently, I am using proto none, creating tunnels and
assigning addresses in /etc/rc.local, but I'd like to move to native
OpenWRT configuration.

Intuitively, one would like to only define the tunnel parameters in the
proto {gre,6in4,6to4} block (such as remote endpoint, mtu, ttl, etc).
Then, we would use a proto static block, relating to this new interface,
to handle address configuration.

Is it possible?  If not, what is the right way to configure addresses on a
tunnel interface?

Thanks,
Baptiste

[1] http://wiki.openwrt.org/doc/uci/network#protocol.6in4.ipv6-in-ipv4.tunnel


pgpzC94mHr9H0.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] When to use Target Profile or Subtarget

[Claudio Thomas]

Hallo Jow,
thank you for your fast reply.
So far I see there are subtargets needed because each board has another
kernel image (name?).

KERNELNAME:=uImage dtbImage.rb600 dtbImage.rb333


Claudio

On 15.07.2014 15:23, Jo-Philipp Wich wrote:
 Hi.

 Profiles influence image generation and package selection but share all
 a common kernel.

 Subtargets are used if a different kernel is required.

 ~ Jow



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



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT IPv6 firewall

[Baptiste Jonglez]

On Thu, Jul 17, 2014 at 03:21:32PM +0100, Fernando Frediani wrote:
 Hello guys,
 
 This discussion if becoming each day more confusing for something, which for
 me, is very simple assuming the following:
 
 - IPv6 as IPv4 should block *any incoming connection* on the WAN
 interface including those directed to the LAN IPs behind it.

As explained before: this is a mostly unavoidable fact for IPv4, because
of NAT.

Now, if this is avoidable, such as with IPv6, does it have any
justification?  Does your should comes from a RFC?  From common sense?
From a widely accepted practice?  Security comes into mind, but the
proposal is *not* about disabling the firewall completely.

As for the usage, any application that is not purely client/server needs
to be reachable from the outside.  You may want to use peer-to-peer
applications (voice chat, video chat, file sharing, etc) without having to
explicitely configure your firewall.  Btw, this is why protocols such as
UPnP, NAT-PMP, or PCP have been developped.


pgp6zyg1Wy0d7.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] libubus: handle NULL ubus_context in all sync requests by creating a local instance

[Alexandru Ardelean]

This can serve as a convenience for sync requets, since no explicit
ubus_connect() + ubus_free() need to be done.

It can also help in cases where there are async + sync requests,
where one async request is working and sync calls are done.
Seems to create some weird races, probably because of possible
concurrent poll() calls on the same fd.

---
 libubus-obj.c | 42 +-
 libubus-req.c | 33 -
 libubus-sub.c | 15 +--
 libubus.c | 48 ++--
 4 files changed, 112 insertions(+), 26 deletions(-)

diff --git a/libubus-obj.c b/libubus-obj.c
index 47bdb0a..29fe538 100644
--- a/libubus-obj.c
+++ b/libubus-obj.c
@@ -174,7 +174,13 @@ static bool ubus_push_object_type(const struct 
ubus_object_type *type)
 int ubus_add_object(struct ubus_context *ctx, struct ubus_object *obj)
 {
struct ubus_request req;
-   int ret;
+   int ret = UBUS_STATUS_INVALID_ARGUMENT;
+   bool free_ctx = false;
+
+   if (!ctx)
+   free_ctx = (ctx = ubus_connect(NULL)) != NULL;
+   if (!ctx)
+   return -1;
 
blob_buf_init(b, 0);
 
@@ -184,22 +190,24 @@ int ubus_add_object(struct ubus_context *ctx, struct 
ubus_object *obj)
if (obj-type-id)
blob_put_int32(b, UBUS_ATTR_OBJTYPE, obj-type-id);
else if (!ubus_push_object_type(obj-type))
-   return UBUS_STATUS_INVALID_ARGUMENT;
+   goto out;
}
 
if (ubus_start_request(ctx, req, b.head, UBUS_MSG_ADD_OBJECT, 0)  0)
-   return UBUS_STATUS_INVALID_ARGUMENT;
+   goto out;
 
req.raw_data_cb = ubus_add_object_cb;
req.priv = obj;
ret = ubus_complete_request(ctx, req, 0);
if (ret)
-   return ret;
+   goto out;
 
-   if (!obj-id)
-   return UBUS_STATUS_NO_DATA;
+   ret = (!obj-id) ? UBUS_STATUS_NO_DATA : 0;
+out:
+   if (free_ctx)
+   ubus_free(ctx);
 
-   return 0;
+   return ret;
 }
 
 static void ubus_remove_object_cb(struct ubus_request *req, int type, struct 
blob_attr *msg)
@@ -221,22 +229,30 @@ static void ubus_remove_object_cb(struct ubus_request 
*req, int type, struct blo
 int ubus_remove_object(struct ubus_context *ctx, struct ubus_object *obj)
 {
struct ubus_request req;
-   int ret;
+   int ret = UBUS_STATUS_INVALID_ARGUMENT;
+   bool free_ctx = false;
+
+   if (!ctx)
+   free_ctx = (ctx = ubus_connect(NULL)) != NULL;
+   if (!ctx)
+   return -1;
 
blob_buf_init(b, 0);
blob_put_int32(b, UBUS_ATTR_OBJID, obj-id);
 
if (ubus_start_request(ctx, req, b.head, UBUS_MSG_REMOVE_OBJECT, 0)  
0)
-   return UBUS_STATUS_INVALID_ARGUMENT;
+   goto out;
 
req.raw_data_cb = ubus_remove_object_cb;
req.priv = obj;
ret = ubus_complete_request(ctx, req, 0);
if (ret)
-   return ret;
+   goto out;
 
-   if (obj-id)
-   return UBUS_STATUS_NO_DATA;
+   ret = (!obj-id) ? UBUS_STATUS_NO_DATA : 0;
+out:
+   if (free_ctx)
+   ubus_free(ctx);
 
-   return 0;
+   return ret;
 }
diff --git a/libubus-req.c b/libubus-req.c
index 8475dc9..240c2d4 100644
--- a/libubus-req.c
+++ b/libubus-req.c
@@ -225,14 +225,25 @@ int ubus_invoke(struct ubus_context *ctx, uint32_t obj, 
const char *method,
 {
struct ubus_request req;
int rc;
+   bool free_ctx = false;
+
+   if (!ctx)
+   free_ctx = (ctx = ubus_connect(NULL)) != NULL;
+   if (!ctx)
+   return -1;
 
rc = ubus_invoke_async(ctx, obj, method, msg, req);
if (rc)
-   return rc;
+   goto out;
 
req.data_cb = cb;
req.priv = priv;
-   return ubus_complete_request(ctx, req, timeout);
+   rc = ubus_complete_request(ctx, req, timeout);
+out:
+   if (free_ctx)
+   ubus_free(ctx);
+
+   return rc;
 }
 
 static void
@@ -288,17 +299,29 @@ int ubus_notify(struct ubus_context *ctx, struct 
ubus_object *obj,
 {
struct ubus_notify_request req;
int ret;
+   bool free_ctx = false;
+
+   if (!ctx)
+   free_ctx = (ctx = ubus_connect(NULL)) != NULL;
+   if (!ctx)
+   return -1;
 
ret = __ubus_notify_async(ctx, obj, type, msg, req, timeout = 0);
if (ret  0)
-   return ret;
+   goto out;
 
if (timeout  0) {
ubus_abort_request(ctx, req.req);
-   return 0;
+   ret = 0;
+   goto out;
}
 
-   return ubus_complete_request(ctx, req.req, timeout);
+   ret = ubus_complete_request(ctx, req.req, timeout);
+out:
+   if (free_ctx)
+   ubus_free(ctx);
+
+   return ret;
 }
 
 static bool 

Re: [OpenWrt-Devel] [PATCH] libubus: handle NULL ubus_context in all sync requests by creating a local instance

[Alexandru Ardelean]

Forgot to add Github link for easier review.

https://github.com/commodo/ubus/commit/f8942190ea7ff4a243410aa0a9d38eacd41d0b4a


On Thu, Jul 17, 2014 at 6:25 PM, Alexandru Ardelean ardeleana...@gmail.com
wrote:

 This can serve as a convenience for sync requets, since no explicit
 ubus_connect() + ubus_free() need to be done.

 It can also help in cases where there are async + sync requests,
 where one async request is working and sync calls are done.
 Seems to create some weird races, probably because of possible
 concurrent poll() calls on the same fd.

 ---
  libubus-obj.c | 42 +-
  libubus-req.c | 33 -
  libubus-sub.c | 15 +--
  libubus.c | 48 ++--
  4 files changed, 112 insertions(+), 26 deletions(-)

 diff --git a/libubus-obj.c b/libubus-obj.c
 index 47bdb0a..29fe538 100644
 --- a/libubus-obj.c
 +++ b/libubus-obj.c
 @@ -174,7 +174,13 @@ static bool ubus_push_object_type(const struct
 ubus_object_type *type)
  int ubus_add_object(struct ubus_context *ctx, struct ubus_object *obj)
  {
 struct ubus_request req;
 -   int ret;
 +   int ret = UBUS_STATUS_INVALID_ARGUMENT;
 +   bool free_ctx = false;
 +
 +   if (!ctx)
 +   free_ctx = (ctx = ubus_connect(NULL)) != NULL;
 +   if (!ctx)
 +   return -1;

 blob_buf_init(b, 0);

 @@ -184,22 +190,24 @@ int ubus_add_object(struct ubus_context *ctx, struct
 ubus_object *obj)
 if (obj-type-id)
 blob_put_int32(b, UBUS_ATTR_OBJTYPE,
 obj-type-id);
 else if (!ubus_push_object_type(obj-type))
 -   return UBUS_STATUS_INVALID_ARGUMENT;
 +   goto out;
 }

 if (ubus_start_request(ctx, req, b.head, UBUS_MSG_ADD_OBJECT, 0)
  0)
 -   return UBUS_STATUS_INVALID_ARGUMENT;
 +   goto out;

 req.raw_data_cb = ubus_add_object_cb;
 req.priv = obj;
 ret = ubus_complete_request(ctx, req, 0);
 if (ret)
 -   return ret;
 +   goto out;

 -   if (!obj-id)
 -   return UBUS_STATUS_NO_DATA;
 +   ret = (!obj-id) ? UBUS_STATUS_NO_DATA : 0;
 +out:
 +   if (free_ctx)
 +   ubus_free(ctx);

 -   return 0;
 +   return ret;
  }

  static void ubus_remove_object_cb(struct ubus_request *req, int type,
 struct blob_attr *msg)
 @@ -221,22 +229,30 @@ static void ubus_remove_object_cb(struct
 ubus_request *req, int type, struct blo
  int ubus_remove_object(struct ubus_context *ctx, struct ubus_object *obj)
  {
 struct ubus_request req;
 -   int ret;
 +   int ret = UBUS_STATUS_INVALID_ARGUMENT;
 +   bool free_ctx = false;
 +
 +   if (!ctx)
 +   free_ctx = (ctx = ubus_connect(NULL)) != NULL;
 +   if (!ctx)
 +   return -1;

 blob_buf_init(b, 0);
 blob_put_int32(b, UBUS_ATTR_OBJID, obj-id);

 if (ubus_start_request(ctx, req, b.head, UBUS_MSG_REMOVE_OBJECT,
 0)  0)
 -   return UBUS_STATUS_INVALID_ARGUMENT;
 +   goto out;

 req.raw_data_cb = ubus_remove_object_cb;
 req.priv = obj;
 ret = ubus_complete_request(ctx, req, 0);
 if (ret)
 -   return ret;
 +   goto out;

 -   if (obj-id)
 -   return UBUS_STATUS_NO_DATA;
 +   ret = (!obj-id) ? UBUS_STATUS_NO_DATA : 0;
 +out:
 +   if (free_ctx)
 +   ubus_free(ctx);

 -   return 0;
 +   return ret;
  }
 diff --git a/libubus-req.c b/libubus-req.c
 index 8475dc9..240c2d4 100644
 --- a/libubus-req.c
 +++ b/libubus-req.c
 @@ -225,14 +225,25 @@ int ubus_invoke(struct ubus_context *ctx, uint32_t
 obj, const char *method,
  {
 struct ubus_request req;
 int rc;
 +   bool free_ctx = false;
 +
 +   if (!ctx)
 +   free_ctx = (ctx = ubus_connect(NULL)) != NULL;
 +   if (!ctx)
 +   return -1;

 rc = ubus_invoke_async(ctx, obj, method, msg, req);
 if (rc)
 -   return rc;
 +   goto out;

 req.data_cb = cb;
 req.priv = priv;
 -   return ubus_complete_request(ctx, req, timeout);
 +   rc = ubus_complete_request(ctx, req, timeout);
 +out:
 +   if (free_ctx)
 +   ubus_free(ctx);
 +
 +   return rc;
  }

  static void
 @@ -288,17 +299,29 @@ int ubus_notify(struct ubus_context *ctx, struct
 ubus_object *obj,
  {
 struct ubus_notify_request req;
 int ret;
 +   bool free_ctx = false;
 +
 +   if (!ctx)
 +   free_ctx = (ctx = ubus_connect(NULL)) != NULL;
 +   if (!ctx)
 +   return -1;

 ret = __ubus_notify_async(ctx, obj, type, msg, req, timeout = 0);
 if (ret  0)
 -   return ret;
 +   goto out;

 if (timeout  0) {
 

Re: [OpenWrt-Devel] OpenWRT IPv6 firewall

[Soren Harward]

On Thu, Jul 17, 2014 at 11:23 AM, Baptiste Jonglez bjong...@illyse.org wrote:
 ... without having to explicitely configure your firewall.

And this is the opinion that I, and many others, disagree with.

I look at it from the principle of minimizing the worst case scenario.
We could allow all (or some, like ports 1024) incoming traffic by
default; the worst case scenario is that the user's machine gets
compromised.  We could deny all incoming traffic by default; the worst
case scenario is that a peer-to-peer service—which not all users
actually use—doesn't work until the user opens up their firewall,
either manually or by enabling UPnP/NAT-PMP/PCP.  IMO, the latter is
the the much less costly scenario, and follows the best security
practice of deny-by-default, IETF RFCs notwithstanding.

-- 
Soren Harward
___
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

[Fernando Frediani]

Hello Baptiste,

Clarifying my point should I meant From common sense and also From 
Widely accepted practice.


One that may use applications that may need to be reachable from outside 
can adjust the firewall manually to reflect that for the desired ports 
which is not a big deal, or even by UPnP which is even simpler.
I would say more that depending on the environment if a specific user 
prefers, the firewall in the router can allow any traffic to his IP only 
and he can control it locally in his machine.


Therefore there are possibilities and these in my opinion are less 
costly and more secure to have by default.


Best regards,

Fernando

On 17/07/2014 16:23, Baptiste Jonglez wrote:

On Thu, Jul 17, 2014 at 03:21:32PM +0100, Fernando Frediani wrote:

Hello guys,

This discussion if becoming each day more confusing for something, which for
me, is very simple assuming the following:

 - IPv6 as IPv4 should block *any incoming connection* on the WAN
interface including those directed to the LAN IPs behind it.

As explained before: this is a mostly unavoidable fact for IPv4, because
of NAT.

Now, if this is avoidable, such as with IPv6, does it have any
justification?  Does your should comes from a RFC?  From common sense?
 From a widely accepted practice?  Security comes into mind, but the
proposal is *not* about disabling the firewall completely.

As for the usage, any application that is not purely client/server needs
to be reachable from the outside.  You may want to use peer-to-peer
applications (voice chat, video chat, file sharing, etc) without having to
explicitely configure your firewall.  Btw, this is why protocols such as
UPnP, NAT-PMP, or PCP have been developped.


___
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

[OpenWrt-Devel] Netifd support for tunnels and address configuration

[Hans Dedecker]

Hi Baptiste,

I have added GRE support (gre/gretap/grev6/grev6tap) in netifd which I'm 
currenlty testing. The implementation looks the same as for 6rd/dslite tunnel 
interfaces (thus allowing to set mtu/ttl/remote end point); additonally it 
allows to set gre specific parameters (ikey/okey/iseq/oseq/...)
I'm planning to submit the patches in one of the next weeks.

Regards,
Hans

Hi,

I am currently adding GRE support for OpenWRT, based on 6in4 support [1] 
(since I couldn't find any documentation).

What is the proper way to support address configuration for tunnel interfaces? 
 It seems redundant to handle static address configuration for each tunnel 
type, especially with the new ip6* options in BB.  We could even imagine doing 
DHCP over a tap tunnel (for instance gretap).

My use case is several GRE interfaces, each with a static IPv4/IPv6 
configuration.  Currently, I am using proto none, creating tunnels and 
assigning addresses in /etc/rc.local, but I'd like to move to native OpenWRT 
configuration.

Intuitively, one would like to only define the tunnel parameters in the proto 
{gre,6in4,6to4} block (such as remote endpoint, mtu, ttl, etc).
Then, we would use a proto static block, relating to this new interface, to 
handle address configuration.

Is it possible?  If not, what is the right way to configure addresses on a 
tunnel interface?

Thanks,
Baptiste

[1] http://wiki.openwrt.org/doc/uci/network#protocol.6in4.ipv6-in-ipv4.tunnel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] libubus: handle NULL ubus_context in all sync requests by creating a local instance

[Felix Fietkau]

On 2014-07-17 17:25, Alexandru Ardelean wrote:
 This can serve as a convenience for sync requets, since no explicit
 ubus_connect() + ubus_free() need to be done.
 
 It can also help in cases where there are async + sync requests,
 where one async request is working and sync calls are done.
 Seems to create some weird races, probably because of possible
 concurrent poll() calls on the same fd.
I don't like this approach. If you want to avoid races in your code
between async calls and sync calls, just create a separate context for
sync calls.
Also, allowing NULL to be passed as context creates the illusion that it
is generally sane to do so. In the case of adding/removing objects it
makes no sense and is completely misleading: any object that you add
with the internally allocated ubus context gets deleted as soon as the
context is freed.

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

Re: [OpenWrt-Devel] [PATCH] [Resend] [kernel] mtd-partial_eraseblock_erase in all kernels folded into original patch

[Felix Fietkau]

On 2014-07-16 11:43, Maciej Skrzypek wrote:
 mtd: allow partial block erase
 This fixes error erasing partial mtd partition which does not start on
 eraseblock boundary and allows using fconfig to configure redboot on
 devices such as the Gateworks Cambria.
 
 fixed in all kernels and folded in initial mtd-partial_eraseblock_write.patch
 
 Maciej Skrzypek
 Flytronic
 
 Signed-off-by: Maciej Skrzypek maciej.skrzy...@flytronic.pl
The patch is whitespace mangled and does not apply. Please resend.

Thanks,

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

Re: [OpenWrt-Devel] [PATCH v2 00/18] atheros: I/O cleanups

[Felix Fietkau]

On 2014-07-15 15:53, Jonas Gorski wrote:
 On Tue, Jul 15, 2014 at 1:57 AM, Sergey Ryazanov ryazanov@gmail.com 
 wrote:
 Main goals of this series:
  * Simplify interface between arch code and SoC drivers
  * Simplify internal realization of arch code
  * Make code consistent with mainstream kernel rules and practice

 This series extensively tested with FON2202 (ar2315 based) and D-Link
 DWL-2100AP (ar2313 based), but tests are not done with AR2317/8 and
 AR5312, since I have no access to such boards now.

 Changes since v1:
  * Add missed patch 'atheros[ar2315-wdt]: update initialization'

 Sergey Ryazanov (18):
   atheros[ar2315-wdt]: update initialization
   atheros[ar2315-wdt]: rename config symbol
   atheros: use correct address space and pointer type for register
 access
   atheros[ar2315-wdt]: update interrupt handling
   atheros[ar2315-wdt]: update I/O handling
   atheros[ar231x-eth]: update MAC and PHY reset method
   atheros[ar231x-eth]: move driver to atheros subdirectory
   atheros: pass UART IRQ number via function argument
   atheros: move AR2315 misc IRQ dispatching to separate function
   atheros: rename some interrupt control handlers
   atheros: simplify AR2315 misc IRQ (un)masking
   atheros: use irq_set_chained_handler()
   atheros: simplify gpiolib realization
   atheros[ar231x-eth]: pass phys address of I/O memory via platform res
   atheros[ar231x-eth]: pass PHY I/O memory via device resources
   atheros[uart]: use 32-bit aligned I/O
   atheros[uart]: pass only physical I/O mem address to 8250 driver
   atheros: update macroses names
 
 as a nitpick: for the subject, instead of atheros[foo]: it would be
 better to use atheros: foo: for the subject; this is the canonical
 version of providing subsystem tags. Git tends to strip everything in
 brackets, so these can easily get lost.
In this case, it worked. git apparently only strips stuff if the bracket
part is surrounded by whitespace.
But yes, for future submissions it's probably better to avoid that.

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

Re: [OpenWrt-Devel] [PATCH] kernel/3.1{3, 4}: fix AMD USB HDC wakeup quirk disabling

[Felix Fietkau]

On 2014-07-13 16:09, Sergey Ryazanov wrote:
 Declare inline placeholder when usb_hcd_amd_remote_wakeup_quirk() not
 compiled due CONFIG_PCI_DISABLE_COMMON_QUIRKS.
 
 Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
Applied in r41702, thanks.

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

Re: [OpenWrt-Devel] [PATCH v2 00/18] atheros: I/O cleanups

[Felix Fietkau]

On 2014-07-15 01:57, Sergey Ryazanov wrote:
 Main goals of this series:
  * Simplify interface between arch code and SoC drivers
  * Simplify internal realization of arch code
  * Make code consistent with mainstream kernel rules and practice
 
 This series extensively tested with FON2202 (ar2315 based) and D-Link
 DWL-2100AP (ar2313 based), but tests are not done with AR2317/8 and
 AR5312, since I have no access to such boards now.
 
 Changes since v1:
  * Add missed patch 'atheros[ar2315-wdt]: update initialization'
Applied, thanks.

- Felix
___
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)

[Benjamin Cama]

Le mercredi 16 juillet 2014 à 15:58 -0400, Aaron Z a écrit :
 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.

OK, you prefer to have everything firewalled by default, but what about
most people, that will be affected by default settings? (they don't know
how to change it and never will touch it; they may even not be allowed
if they are not on their “own” network, if that even means something to
them) They don't have choice: they _have_ to trust their device/OS. They
have no other choice.

So the choice is on the manufacturer: either you secure your device and
people will trust you, or you build shitty rootable stuff and people
will try not to buy your stuff (you see, they may even not have the
choice to have trust…). But asking them “patch” the security of their
device by mean of some other “magical” device (a firewhat?) is not an
option.

 I would venture to guess that 95% (or more) of the people who install
 OpenWRT are quite capable of opening ports in a firewall.

Yes. But try imagining the impact on the other persons. Now try
imagining that this policy is implemented on 90% of home routers.

 ==
 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

Yes, this kind of UI would be nice.

 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.

“Down the road” being never, as what sets the “standard” is what is
installed in the standard base. Now is time, as this release comes as
“IPv6 fully enabled”.

--
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)

[Benjamin Cama]

Le mercredi 16 juillet 2014 à 21:12 +0200, Sebastian Moeller a écrit :
   What is so wonderful about IPv6? Maleware surely will evolve quickly
 to take advantage of a dropped layer of defense…

“Layer of defense”? To most, it will just translate to a brick wall that
will have to be worked around by some other mean because nobody except
advanced user can configure their firewall.

 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 totally do this for non-experts: non-experts won't ever touch their
default configuration. So, basically, they will have no inbound
connection possible, so manufacturer will find other mean to do whatever
they can to allow for that to happen (as they are doing today with
IPv4). It will just be even less controllable by yourself (custom
protocols, etc). Even if PCP comes: imagine then that device configured
with PCP will be accessible from outside, and… will they be magically
immune to anything this way? They will have to be secured anyway.

 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….

Please, cite me any device today that can be dangerously exposed by an
IPv6 connectivity.

A printer, for example, should be bound (to me) to a link-local address
by default. I don't know any manufacturer who does so (well, they don't
support IPv6 anyway…).

--
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)

[Benjamin Cama]

Le mercredi 16 juillet 2014 à 21:12 +0200, Sebastian Moeller a écrit :
   What is so wonderful about IPv6? Maleware surely will evolve quickly
 to take advantage of a dropped layer of defense…

“Layer of defense”? To most, it will just translate to a brick wall that
will have to be worked around by some other mean because nobody except
advanced user can configure their firewall.

 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 totally do this for non-experts: non-experts won't ever touch their
default configuration. So, basically, they will have no inbound
connection possible, so manufacturer will find other mean to do whatever
they can to allow for that to happen (as they are doing today with
IPv4). It will just be even less controllable by yourself (custom
protocols, etc). Even if PCP comes: imagine then that device configured
with PCP will be accessible from outside, and… will they be magically
immune to anything this way? They will have to be secured anyway.

 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….

Please, cite me any device today that can be dangerously exposed by an
IPv6 connectivity.

A printer, for example, should be bound (to me) to a link-local (or ULA)
address by default. I don't know any manufacturer who does so (well,
they don't support IPv6 anyway…).

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

Re: [OpenWrt-Devel] [PATCH] libubus: handle NULL ubus_context in all sync requests by creating a local instance

[Alexandru Ardelean]

Fair enough.
Will reconsider approach in our code.

If I think about it, there may be an approach (in our code) which
requires fewer changes than this patch, and may even be more elegant.

Thanks and apologies for the noise.


On 7/17/14, Felix Fietkau n...@openwrt.org wrote:
 On 2014-07-17 17:25, Alexandru Ardelean wrote:
 This can serve as a convenience for sync requets, since no explicit
 ubus_connect() + ubus_free() need to be done.

 It can also help in cases where there are async + sync requests,
 where one async request is working and sync calls are done.
 Seems to create some weird races, probably because of possible
 concurrent poll() calls on the same fd.
 I don't like this approach. If you want to avoid races in your code
 between async calls and sync calls, just create a separate context for
 sync calls.
 Also, allowing NULL to be passed as context creates the illusion that it
 is generally sane to do so. In the case of adding/removing objects it
 makes no sense and is completely misleading: any object that you add
 with the internally allocated ubus context gets deleted as soon as the
 context is freed.

 - Felix

___
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

[Benjamin Cama]

Hi Bill,

Le mercredi 16 juillet 2014 à 12:21 -0700, Bill Moffitt a écrit :
 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.

No. Users are used to thing “just working”. They don't know what NAT or
a firewall is. They think they are secured because the vendor of their
devices did his job well.

Their Skype phone work because it uses some kludge that make it look
like a malware from a network security point-of-view. It is kind of
secure because you have allowed only one overlord (Microsoft) to access
your machine and your network. You have to trust Microsoft: no layer of
firewall or anything (apart from cutting yourself completely from the
Internet) will stop your computer from being tied to the Skype network.
So you have to trust them. If you didn't want to be reachable by Skype,
just don't use it, and you won't be reachable, even with no firewall at
all on your router.

Your game console “just work” because it uses a supplementary protocol
(UPnP) that make incoming connections to your console possible. This
doesn't render your console more secure: it would have been the same if
you had global reachability and no firewall. It is just a supplementary
layer that has only one advantage: software not implementing it can't be
globally reachable. So, every software that wants to be reachable has to
do so, or they just die as of yesterday. Every software that does not
just can stay as is; with IPv6, they just could have bound to some
link-local address: the one bound to a global address would have gotten
global reachability “magically”.

[…]
 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)

If the use of such device is meant to be by default “local”, the
manufacturer should somehow restrict its use by default. But printers
may have reason to be globally reachable, if one wants to share it
between several networks. You can configure it (or your firewall) to
restrict its access once you have decided to make it global (as I
suggested, I don't think this would be a good default; I hope the
manufacturers get it…).

 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.

The demande has been their for decades (IP phones for everybody,
anyone?). But I agree that it may be chaotic anyway.

 For that reason, I think that maintaining 
 behavior similar to what consumers see today will be critical in user 
 satisfaction.

The “behavior” casual people are “seeing” today has nothing to do with
their device having global IPv6 reachability or not: they just want
things to work. One way of having IP phones everywhere is to find more
kludges to get through firewalls and praying for nice intermediaries not
to mess with your communications (like MS cited above), the other one is
to have it basically done at the IP level, with IPv6 and global
reachability by default.

 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,

No normal people ask for their firewall to be open by default: only
geeks do.

 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.

“At some point” being too late.

--
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)

[Sebastian Moeller]

Hello Benjamin,

On July 17, 2014 7:45:10 PM CEST, Benjamin Cama ben...@dolka.fr wrote:
Le mercredi 16 juillet 2014 à 21:12 +0200, Sebastian Moeller a écrit :
  What is so wonderful about IPv6? Maleware surely will evolve quickly
 to take advantage of a dropped layer of defense…

“Layer of defense”? To most, it will just translate to a brick wall
that
will have to be worked around by some other mean because nobody except
advanced user can configure their firewall.

  I argue that people unable to change the router settings are better of 
with all unsolicited inbound traffic disabled.


 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 totally do this for non-experts: non-experts won't ever touch their
default configuration. So, basically, they will have no inbound
connection possible, so manufacturer will find other mean to do
whatever
they can to allow for that to happen (as they are doing today with
IPv4). It will just be even less controllable by yourself (custom
protocols, etc). Even if PCP comes: imagine then that device configured
with PCP will be accessible from outside, and… will they be magically
immune to anything this way? They will have to be secured anyway.

 Note that I argue for a per device white list especially since I do not 
think that an automatic port opening method has the security guarantees I hope 
for. But note that with your proposal ALL devices need expert configuration. 
There is no magic immunity by ports closed by default' just a reduced attack 
surface...


 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….

Please, cite me any device today that can be dangerously exposed by an
IPv6 connectivity.

While not from today: http://www.kb.cert.org/vuls/id/986425 looks pretty 
bad... Actually googling for IPv6 cve does seem to find quite a lot. At least 
enough to make port open by default look like a risky proposition. Now you 
could argue that all Linux CVEs will also affect the router... But assuming all 
ipv6 devices will stay safe and secure forever seems a bit to optimistic...


A printer, for example, should be bound (to me) to a link-local address
by default. I don't know any manufacturer who does so (well, they don't
support IPv6 anyway…).

 



--
benjamin

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ar71xx: add RB91x boards to uci-defaults 02_network

[Matthew Reeve]

The default case in 02_network is inappropriate for the MikroTik RouterBOARD 
91x boards because they do not have a WAN port, so don't bother setting the 
non-existent eth1 interface as the WAN port.

Signed-off-by: Matthew Reeve mre...@tenxnetworks.com

--- target/linux/ar71xx/base-files/etc/uci-defaults/02_network  2014-07-17 
21:29:11.794623149 +
+++ target/linux/ar71xx/base-files/etc/uci-defaults/02_network  2014-07-17 
21:29:23.042623159 +
@@ -285,6 +285,10 @@ eap7660d |\
 mr600 |\
 mr600v2 |\
 rb-411 |\
+rb-911g-2hpnd |\
+rb-911g-5hpnd |\
+rb-912uag-2hpnd |\
+rb-912uag-5hpnd |\
 rb-sxt2n |\
 rb-sxt5n |\
 tl-mr10u |\
___
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)

[Karl P]

On 07/17/2014 08:26 PM, Sebastian Moeller wrote:


   I argue that people unable to change the router settings are better of 
with all unsolicited inbound traffic disabled.


I've tried to avoid weighing in on this, but I'd argue that you're wrong :) 
Making sure that people can _never_ have services in the future, just because 
they never had them in the past is a terrible way to live.


Sincerely,
Karl Palsson
___
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)

[David Lang]

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] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)

[Fernando Frediani]

Perfect and well said.

Really don't see why people still think leaving firewalls opened is a 
good idea.
At the end it will bring more problems than solutions for those using 
OpenWRT and play against its good reputation.


As mentioned before adjusting firewall for specific needs or using UPnP 
isn't the end of the world.


Regards,

Fernando

On 18/07/2014 01: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?


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

___
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)

[Gui Iribarren]

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.


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@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] Netifd support for tunnels and address configuration

[Baptiste Jonglez]

On Thu, Jul 17, 2014 at 06:28:09PM +0200, Hans Dedecker wrote:
 Hi Baptiste,
 
 I have added GRE support (gre/gretap/grev6/grev6tap) in netifd which I'm 
 currenlty testing. The implementation looks the same as for 6rd/dslite tunnel 
 interfaces (thus allowing to set mtu/ttl/remote end point); additonally it 
 allows to set gre specific parameters (ikey/okey/iseq/oseq/...)
 I'm planning to submit the patches in one of the next weeks.

Excellent!  Do you have the patches available somewhere to test?  What is
your solution for {v4, v6} address configuration?

One problem I encountered with GRE is broken IPv6 link-local multicast,
for which a workaround could be needed (well, of course, it would be
better to fix it upstream).  Symptoms: ping6 ff02::1%gre-tunnel fails,
but after removing the link-local address and adding a new one, it works.

 Regards,
 Hans

Thanks,
Baptiste


pgp55FS9BPYW6.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)

[Gui Iribarren]

On 17/07/14 21:59, Fernando Frediani wrote:
 Perfect and well said.
 
 Really don't see why people still think leaving firewalls opened is a
 good idea.

leaving *hosts* firewalls opened is a really bad idea. Agreed.

But openwrt doesn't run on hosts, it runs on network equipment
I.e. the building blocks of Internet.
Carriers don't block traffic,
ISP don't block traffic,
and back in the day, CPE equipment didn't block traffic either (think of
dialup, or dumb cablemodems which would simply act as a bridge)
firewall was a software installed in the computer connected to the
cablemodem

Then, with the ever increasing quantity of devices vs the evident
shortage of IPv4, people started to use NAT, or ISPs started to ship
CPEs that would do NAT, which made two-way transparent communication
impossible.
I find it difficult to argue that NAT success was driven by a security
concern, rather than by IP scarcity. :P [1]

Fast-forward a few years, we have a new Internet Protocol being widely
deployed that solves the address scarcity, and thus makes NAT unnecessary.

Now CPEs can work again like transparent devices.

ps. RFCs that argue that NAT resulted in a *reduction in security*...

[0]: http://tools.ietf.org/rfc/rfc6092.txt , january/2011

  Security Considerations
   The IPv6 stateful filtering behavior described in this document is
   intended to be similar in function to the filtering behavior of
   commonly used IPv4/NAT gateways, which have been widely sold as a
   security tool for residential and small-office/home-office networks.
   As noted in the Security Considerations section of [RFC2993], the
   true impact of these tools may be a reduction in security.  It may be
   generally assumed that the impacts discussed in that document related
   to filtering (and not translation) are to be expected with the simple
   IPv6 security mechanisms described here.

   In particular, it is worth noting that stateful filters create the
   illusion of a security barrier, but without the managed intent of a
   firewall.  Appropriate security mechanisms implemented in the end
   nodes, in conjunction with the [RFC4864] local network protection
   methods, function without reliance on network layer hacks and
   transport filters that may change over time.  Also, defined security
   barriers assume that threats originate in the exterior, which may
   lead to practices that result in applications being fully exposed to
   interior attack and which therefore make breaches much easier.

[1]: http://tools.ietf.org/rfc/rfc2993.txt , november/2000,
  11. Summary
  NAT advantages - no item about security


 At the end it will bring more problems than solutions for those using
 OpenWRT and play against its good reputation.
 
 As mentioned before adjusting firewall for specific needs or using UPnP
 isn't the end of the world.
 
 Regards,
 
 Fernando
 
 On 18/07/2014 01: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?

 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 

Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)

[Fernando Frediani]

Hi,

A typical home connection is not an ISP.
Also OpenWRT for the majority of the cases isn't just 'a router', but 
also as a firewall and to protect user's network either on IPv4 or IPv6, 
not just a dummy bridge device.


I guess I see the good intentions of those defending it should be 
opened, but that is taking in consideration only a specific technical 
point of view and thinking only how it should be in an ideal world. 
However the reality that must be taken in consideration are the 
real-world effects of this which will certainly bring more problems than 
solutions.


If a problem must exist, I prefer it to be that the user have to spend 
a minute or two to adjust his router's firewall adding the few 
exceptions that have to be allowed into his network.


Regards,

Fernando Frediani

On 18/07/2014 04:56, Gui Iribarren wrote:

On 17/07/14 21:59, Fernando Frediani wrote:

Perfect and well said.

Really don't see why people still think leaving firewalls opened is a
good idea.

leaving *hosts* firewalls opened is a really bad idea. Agreed.

But openwrt doesn't run on hosts, it runs on network equipment
I.e. the building blocks of Internet.
Carriers don't block traffic,
ISP don't block traffic,
and back in the day, CPE equipment didn't block traffic either (think of
dialup, or dumb cablemodems which would simply act as a bridge)
firewall was a software installed in the computer connected to the
cablemodem

Then, with the ever increasing quantity of devices vs the evident
shortage of IPv4, people started to use NAT, or ISPs started to ship
CPEs that would do NAT, which made two-way transparent communication
impossible.
I find it difficult to argue that NAT success was driven by a security
concern, rather than by IP scarcity. :P [1]

Fast-forward a few years, we have a new Internet Protocol being widely
deployed that solves the address scarcity, and thus makes NAT unnecessary.

Now CPEs can work again like transparent devices.

ps. RFCs that argue that NAT resulted in a *reduction in security*...

[0]: http://tools.ietf.org/rfc/rfc6092.txt , january/2011

   Security Considerations
The IPv6 stateful filtering behavior described in this document is
intended to be similar in function to the filtering behavior of
commonly used IPv4/NAT gateways, which have been widely sold as a
security tool for residential and small-office/home-office networks.
As noted in the Security Considerations section of [RFC2993], the
true impact of these tools may be a reduction in security.  It may be
generally assumed that the impacts discussed in that document related
to filtering (and not translation) are to be expected with the simple
IPv6 security mechanisms described here.

In particular, it is worth noting that stateful filters create the
illusion of a security barrier, but without the managed intent of a
firewall.  Appropriate security mechanisms implemented in the end
nodes, in conjunction with the [RFC4864] local network protection
methods, function without reliance on network layer hacks and
transport filters that may change over time.  Also, defined security
barriers assume that threats originate in the exterior, which may
lead to practices that result in applications being fully exposed to
interior attack and which therefore make breaches much easier.

[1]: http://tools.ietf.org/rfc/rfc2993.txt , november/2000,
   11. Summary
   NAT advantages - no item about security



At the end it will bring more problems than solutions for those using
OpenWRT and play against its good reputation.

As mentioned before adjusting firewall for specific needs or using UPnP
isn't the end of the world.

Regards,

Fernando

On 18/07/2014 01: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?

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 

[OpenWrt-Devel] [PATCH] ar71xx: Add UBNT airGateway support

[Matthew Reeve]

This patch adds support for the Ubiquiti Networks airGateway.

Based in part on code posted by David Hutchison dhutchi...@bluemesh.net on 
openwrt-devel:
  https://lists.openwrt.org/pipermail/openwrt-devel/2013-December/023035.html

Signed-off-by: Matthew Reeve mre...@tenxnetworks.com

--- 
target/linux/ar71xx/patches-3.10/722-MIPS-ath79-add-airGateway-support.patch
2014-07-15 20:26:35.160643008 +
+++ 
target/linux/ar71xx/patches-3.10/722-MIPS-ath79-add-airGateway-support.patch
2014-07-18 03:22:23.326701915 +
@@ -0,0 +1,75 @@
+--- a/arch/mips/ath79/mach-ubnt-xm.c   2014-07-18 02:43:23.110693216 +
 b/arch/mips/ath79/mach-ubnt-xm.c   2014-07-18 03:20:28.542701485 +
+@@ -17,9 +17,11 @@
+ #include linux/etherdevice.h
+ #include linux/ar8216_platform.h
+ 
++#include asm/mach-ath79/ath79.h
+ #include asm/mach-ath79/irq.h
+ #include asm/mach-ath79/ar71xx_regs.h
+ 
++#include common.h
+ #include dev-ap9x-pci.h
+ #include dev-eth.h
+ #include dev-gpio-buttons.h
+@@ -389,3 +391,50 @@ static void __init ubnt_nano_m_xw_setup(
+ 
+ MIPS_MACHINE(ATH79_MACH_UBNT_NANO_M_XW, UBNT-NM-XW, Ubiquiti Nanostation M 
XW,
+ubnt_nano_m_xw_setup);
++
++static struct gpio_led ubnt_airgateway_gpio_leds[] __initdata = {
++  {
++  .name  = ubnt:blue:wlan,
++  .gpio  = 0,
++  }, {
++  .name  = ubnt:white:status,
++  .gpio  = 1,
++  },
++};
++
++static void __init ubnt_airgateway_setup(void)
++{
++  u32 t;
++  u8 *mac0 = (u8 *) KSEG1ADDR(0x1fff);
++  u8 *mac1 = (u8 *) KSEG1ADDR(0x1fff + ETH_ALEN);
++  u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000);
++
++
++  ath79_gpio_function_disable(AR933X_GPIO_FUNC_ETH_SWITCH_LED0_EN |
++   AR933X_GPIO_FUNC_ETH_SWITCH_LED1_EN |
++   AR933X_GPIO_FUNC_ETH_SWITCH_LED2_EN |
++   AR933X_GPIO_FUNC_ETH_SWITCH_LED3_EN |
++   AR933X_GPIO_FUNC_ETH_SWITCH_LED4_EN);
++
++  t = ath79_reset_rr(AR933X_RESET_REG_BOOTSTRAP);
++  t |= AR933X_BOOTSTRAP_MDIO_GPIO_EN;
++  ath79_reset_wr(AR933X_RESET_REG_BOOTSTRAP, t);
++
++  ath79_register_m25p80(NULL);
++  ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_airgateway_gpio_leds),
++   ubnt_airgateway_gpio_leds);
++
++  ath79_init_mac(ath79_eth1_data.mac_addr, mac0, 0);
++  ath79_init_mac(ath79_eth0_data.mac_addr, mac1, 0);
++
++  ath79_register_mdio(0, 0x0);
++
++  ath79_register_eth(1);
++  ath79_register_eth(0);
++
++  ath79_register_wmac(ee, NULL);
++}
++
++MIPS_MACHINE(ATH79_MACH_UBNT_AIRGW, UBNT-AGW, Ubiquiti AirGateway,
++   ubnt_airgateway_setup);
++
+--- a/arch/mips/ath79/machtypes.h  2014-07-18 02:45:30.590693688 +
 b/arch/mips/ath79/machtypes.h  2014-07-18 02:51:02.490694922 +
+@@ -143,6 +143,7 @@ enum ath79_mach_type {
+   ATH79_MACH_TL_WR842N_V2,/* TP-LINK TL-WR842N/ND v2 */
+   ATH79_MACH_TL_WR941ND,  /* TP-LINK TL-WR941ND */
+   ATH79_MACH_TUBE2H,  /* Alfa Network Tube2H */
++  ATH79_MACH_UBNT_AIRGW,  /* Ubiquiti AirGateway */
+   ATH79_MACH_UBNT_AIRROUTER,  /* Ubiquiti AirRouter */
+   ATH79_MACH_UBNT_BULLET_M,   /* Ubiquiti Bullet M */
+   ATH79_MACH_UBNT_LSSR71, /* Ubiquiti LS-SR71 */
--- target/linux/ar71xx/base-files/lib/ar71xx.sh2014-07-18 
03:24:51.146702466 +
+++ target/linux/ar71xx/base-files/lib/ar71xx.sh2014-07-18 
03:25:07.114702524 +
@@ -229,6 +229,9 @@ ar71xx_board_detect() {
*Oolite V1.0)
name=oolite
;;
+   *AirGateway)
+   name=airgateway
+   ;;
*AirRouter)
name=airrouter
;;
--- target/linux/ar71xx/base-files/etc/diag.sh  2014-07-18 03:26:39.290702863 
+
+++ target/linux/ar71xx/base-files/etc/diag.sh  2014-07-18 03:27:18.326703044 
+
@@ -229,6 +229,9 @@ get_status_led() {
uap-pro)
status_led=ubnt:white:dome
;;
+   airgateway)
+   status_led=ubnt:white:status
+   ;;
whr-g301n | \
whr-hp-g300n | \
whr-hp-gn | \
--- target/linux/ar71xx/base-files/lib/upgrade/platform.sh  2014-07-18 
03:36:53.350705163 +
+++ target/linux/ar71xx/base-files/lib/upgrade/platform.sh  2014-07-18 
03:37:27.866705279 +
@@ -186,6 +186,7 @@ platform_check_image() {
tew-712br | \
tew-732br | \
wrt400n | \
+   airgateway | \
airrouter | \
bullet-m | \
nanostation-m | \
--- target/linux/ar71xx/base-files/etc/uci-defaults/01_leds 2014-07-18 
03:43:38.582706657 +
+++ target/linux/ar71xx/base-files/etc/uci-defaults/01_leds 2014-07-18 
03:44:37.774706877 +
@@ -9,6 +9,9 @@
 board=$(ar71xx_board_name)
 
 case $board in
+airgateway)
+ 

Re: [OpenWrt-Devel] New gstreamer packages

[W. Michael Petullo]

 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 ?
 
 to quote Steven Barth who replied to a similar mail:
 
 please note that we are not going to accept patches for the (old) 
 packages feed anymore.
 See: https://forum.openwrt.org/viewtopic.php?id=51078 and the referenced 
 mail for details.
 
 If you like you can adopt this package and maintain it in our new github 
 feed: https://github.com/openwrt/packages though.
 
 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 just pushed the Gstreamer 1.0+ patches to:

https://github.com/MikePetullo/packages/

I am working on getting these and some other packages into the mainstream
package repository.

-- 
Mike

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