Re: Re: SELinux status report and call to action
OpenWRT uses different commands than other distros for manipulating configs, so those different programs are going to need to be given appropriate permissions. Who is going to do that work? Who is going to field all the issues that will come up because the permissions are not correct for some user's setup (and how many people will be able to figure out that SELinux caused the problem as opposed to "OpenWRT doesn't work") If it's just enabled with a permissive ruleset, what's the advantage of the additional overhead (both from the permission checking, and the logging of the results)? Yes other distros had to go through this same pain, but that doesn't mean that the pain isn't there for OpenWRT as well. David Lang On Wed, 13 Jan 2021, Dac Override wrote: Date: Wed, 13 Jan 2021 17:34:56 +0100 From: Dac Override To: openwrt-devel@lists.openwrt.org Subject: Re: Re: SELinux status report and call to action Hello Alberto, Thanks for you input. I agree that leveraging SELinux is, like for example leveraging Linux netfilter, not trivial. SELinux is however well documenting and with the exception of OpenWrt specifics it might not be productive to yet again document aspects that are already published elsewhere. I have created a document that explains how to build and edit the OpenWrt policy and I have also enclosed a link to the policy language used to write the OpenWrt policy: https://git.defensec.nl/?p=selinux-policy.git;a=summary 1. The CIL used to write OpenWrt policy: https://github.com/SELinuxProject/selinux/blob/master/secilc/docs/README.md 2. OpenWrt policy customization and testing: https://github.com/doverride/openwrt-selinux-policy/blob/master/README.md Generally one should not have to interact with SELinux in OpenWrt but there are some exceptions 1. Some commands might be "targeted" by default and *if* a command cannot operate properly because it is targeted then you can manually run the command "unconfined": For example: you want to use `iw` but SELinux blocks it, then you can run iw from a shell with `runcon -t sys.subj -- iw` to by pass the SELinux restrictions. 2. Some commands might *not* be targeted by default and *if* you want to run that command with "basic" set of restrictions then you can run the command in a "SELinux sandbox". For example you want to run `bmon` with restricted permissions but SELinux does not target it by default then you can run bmon from a shell with `runcon -t sandbox.subj -- bmon` or `runcon -t sandbox.net,subj -- bmon` (you can also execute a restricted shell or tmux session this way (runcon -t sandbox.net.subj -- sh or runcon -t sandbox.net.subj -- tmux) 3. If a file for some reason ends up with a bad label (SELinux associates labels with inodes using the security.selinux security extended attribute) then you can use restorecon command. I have many video's on youtube with casual demonstrations on how to address various SELinux/OpenWrt issues and other case studies: For example: chronyd recently (in november last year) enhanced configuration and packaging, and so I had to adjust the policy so that the changes work. I documented the whole process here: https://www.youtube.com/watch?v=xC-YrlCR7iU Here is a demonstration of the SELinux openwrt sandbox functionality: https://www.youtube.com/watch?v=Ic_k9qknh_Q Filesystem management with SELinux and OpenWrt (zram example with f2fs): https://www.youtube.com/watch?v=R1wyv_poN4U There are various other videos on my channel with casual demo's and ramblings: Here is approx. 3 hours of SELinux with OpenWrt ramble touching on various topic: https://www.youtube.com/watch?v=Q4_SWTAcQSY Maybe we should create a Wiki page on the OpenWrt website where we can bundle these resources. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc3
On Fri, 17 Jul 2015, Cristian Morales Vega wrote: On 17 July 2015 at 16:43, Jonas Gorski wrote: What I don't understand is why there is so much interest in replicating RC3. It makes sense to have a RC3 so there are binaries and more people test it. But if you are going to build it yourself, shouldn't you just use whatever is the latest commit in git://git.openwrt.org/15.05/openwrt.git? That already has the tags for the feeds (http://git.openwrt.org/?p=15.05/openwrt.git;a=blob_plain;f=feeds.conf.default;hb=HEAD). Why to build a RC3 with the bugs that have already been solved and will not be there in RC4/final? if someone is wanting to test specific changes, it's always best to only apply the one change you want to test. Compiling trunk brings in a lot more changes, some of which may introduce bugs (that should be squashed before RC4/Final, but can catch someone in the meantime) David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt-ar71xx GUI
On Wed, 29 Jul 2015, John kerry wrote: I am working on openwrt-ar71xx. After upload the image file the GUI will be access on some IP address. Now I want to change the GUI, Could anyone tell how I can change the GUI, i means to say which file shall I modify. There are a lot of different files, depending on what you are wanting to change. The GUI is named luci, google for that and you will find it's development pages, code repository, etc. But depending on what you are trying to change, it may just be a config file change, but which file will depend on what you are trying to change. if you provide more information about what you are trying to do, we can give better guidence on where to look. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt] 2.4Ghz limited to 50mW in DFS-ETSI
What's more, The regulation is on the signal strength of the radiated signal, not the transmitter power. so if you go to max transmitter power and add a better antenna, you actually exceed the limits. There is apparently an exception to this for point-to-point use. But you still can't use full power + high gain antenna David Lang On Thu, 30 Jul 2015, Ben West wrote: You can look up your respective country's spectrum regulations. It is possible prior versions OpenWRT didn't fully conform to each regulatory domain and were fixed in more recent versions (just as the converse is possible). For example, for the USA, here is a table of power limits for the 2.4GHz and 5GHz bands. Channels 36-48 are limited to 16dBm transmitter power. http://www.air802.com/fcc-rules-and-regulations.html On Thu, Jul 30, 2015 at 3:32 AM, Nicola von Thadden wrote: Hi, I also thought to have used 20dBm or 23dBm in earlier releases (AA). Is there a way to find out to which txpower levels the 5Ghz transceiver is limited? I think the driver reads them out, maybe there is a way to print them on the cmd? But my main problem is the 17dBm on 2.4Ghz when setting DFS-ETSI countries. I don't think that it is a problem of the hardware but of the software parsing the regdom. Maybe there is a fixed limit of 17dBm on non-DFS channels, even when DFS is not required, which is not very useful. Does anyone have an idea where that could be set? My search in the source code had no results until now, where it could be. Thanks Nico On 07/29/2015 06:21 PM, Atanas Vladimirov wrote: https://dev.openwrt.org/ticket/20201 On BB I used 20dBm for both 2.4 and 5GHz on the same router. Sent with AquaMail for Android http://www.aqua-mail.com On 29 юли 2015 г. 18:40:10 Ben West wrote: This is what I observe running Barrier Breaker on UBNT M5 products, too. I believe the 17dBm limit is intentional, i.e. per regulation. The 30dBm tx power limit applies to channels 149 and above, I believe. Also (kind of off-topic): Do you know why 5Ghz channels 36-48 are forced to be 17dBm only on the WNDR3800? I found two possible explanations: either because of the factory calibration On Wed, Jul 29, 2015 at 10:25 AM, Gerald Matzka mailto:mgeral...@yahoo.de>> wrote: Well, it looks like the txpower of your wdnr3800 is limited to 17dBm because of the hardware reg-domain settings. Kind regards, ... sent from my iPhone > Am 29.07.2015 um 10:43 schrieb Nicola von Thadden mailto:n...@vthadden.de>>: > > Hi, > > I have this strange behaviour down below, for which I also opened a > ticket because I think this should not be like that ;) > > Does anyone have an idea where the problem could originate from and how > to fix it? > > Thanks > Nico > >> On 07/29/2015 12:37 AM, OpenWrt wrote: >> #20222: 2.4Ghz limited to 50mW in DFS-ETSI >> --+-- >> Reporter: nicoduck | Owner: developers >> Type: defect| Status: new >> Priority: normal| Milestone: Chaos Calmer (trunk) >> Component: kernel|Version: Trunk >> Keywords: wndr3800 | >> --+-- >> I have got a Netgear WNDR 3800 running with openwrt since quite a while. >> I now upgraded to the latest version (trunk) and wanted to use WLAN within >> the regulations here in Germany but also wanted to max out the output >> power (within the regulations). >> Switching the country to Germany limits the maximum output power to 17dBm, >> although it does show as being limited on 20dBm: >> root@OpenWrt:/# iwinfo wlan0 txpower >>0 dBm ( 1 mW) >>1 dBm ( 1 mW) >>2 dBm ( 1 mW) >>3 dBm ( 1 mW) >>4 dBm ( 2 mW) >>5 dBm ( 3 mW) >>6 dBm ( 3 mW) >>7 dBm ( 5 mW) >>8 dBm ( 6 mW) >>9 dBm ( 7 mW) >> 10 dBm ( 10 mW) >> 11 dBm ( 12 mW) >> 12 dBm ( 15 mW) >> 13 dBm ( 19 mW) >> 14 dBm ( 25 mW) >> 15 dBm ( 31 mW) >> 16 dBm ( 39 mW) >> * 17 dBm ( 50 mW) >> 18 dBm ( 63 mW) >> 19 dBm ( 79 mW) >> 20 dBm ( 100 mW) >> >> What I did: reset the device, flash it with various builts from trunk and >> try to figure out what was going on. >> I now modified my regdb and was able to isolate the source of the problem: >> country DE: DFS-ETSI >> # entries 279004 and 280006 >> (2400 - 2483.5 @ 40), (100 mW) >> # entry 303005 >>
Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings
/etc/config/wireless On Fri, 31 Jul 2015, N.Leiten wrote: Date: Fri, 31 Jul 2015 12:32:14 +0300 From: N.Leiten To: openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings In email dated Пятница - 31 июля 2015 17:08:23 user John kerry wrote: Hi, I am working on Ar71xx openWRT Luci project. By default the Wi-Fi is disabled and SSID is OpenWrt. I need to change the default settings. Could anyone help me to change the default settings. Best Regards, John You can look at mac80211 package, in package/kernel/mac80211/files/lib/wifi/mac80211.sh there's function detect_mac80211() and at the end of file there's block of default wifi parameters. ___ 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] Change OpenWrt Wifi default settings
to make the config be there after a factory reset, you need to put the changes into the image that you build. you already did this for /etc/config/network, do the same thing for /etc/config/wireless David Lang On Sun, 2 Aug 2015, John kerry wrote: Hi Leiten, I have one issue, after upgrading this firmware it will load wireless configuration with this changes, actually it should load when i do factory reset. Thanks, On Sun, Aug 2, 2015 at 3:45 PM, John kerry wrote: Hi Leiten, Thank you so much, Its working :) On Sun, Aug 2, 2015 at 3:12 PM, N.Leiten wrote: Hi, Don't answer to my e-mail only, you need to add openwrt-devel maillist to CC or just answer to CC, in each case I'll receive message but also everyone could see all discussion. In email dated Воскресенье - 02 августа 2015 12:54:32 user John kerry wrote: Hi Leiten, I have added new files under and written below : vi target/linux/ar71xx/base-files/etc/uci-defaults/wireless Use index in prefix of filename to set order of execution, so it'll be like '99-wireless'. #!/bin/sh # # Copyright (c) 2013 The Linux Foundation. All rights reserved. # Copyright (C) 2011 OpenWrt.org # [ -e /etc/config/wireless ] && exit 0 Here is the problem. When uci-defaults invoke scripts there's already preconfiguration done and /etc/config/wireless already exists, so your script just exit at this point. Remove this line. touch /etc/config/wireless uci set wireless.@wifi-device[0].disabled=0; uci set system.@system[0].hostname=test_ap uci set wireless.@wifi-iface[0].mode=ap uci set wireless.@wifi-iface[0].ssid=CD-2.4D uci set wireless.@wifi-iface[0].encryption=none uci set wireless.@wifi-iface[0].wds=1 uci set wireless.radio0.disabled=0 uci commit wireless exit 0 and compile the source code using make V=s but still not changed default settings. Please help me to make it works. Thanks, On Sat, Aug 1, 2015 at 4:38 PM, N.Leiten wrote: You can also use uci-defaults mechanism for your purpose. Just put script in base-files/etc/uci-defaults and set your preferrable parameters with uci and don't forget to 'exit 0' at the end of script, in elsecase it'll be run every time at boot ruining changes. 2015-07-31 12:08 GMT+03:00 John kerry : Hi, I am working on Ar71xx openWRT Luci project. By default the Wi-Fi is disabled and SSID is OpenWrt. I need to change the default settings. Could anyone help me to change the default settings. Best Regards, John ___ 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings
The way to do this is to first forget about the factory reset problem and configure the AP to do what you want (including any encryption) then you can take the resulting file and put it into the build system so that it becomes the 'factory default' settings. Since you are not understanding how to configure the files from the documentation, configure them from the GUI and then look at the resulting files. David Lang On Mon, 3 Aug 2015, John kerry wrote: Hi All, I created separate files directory and added network and wireless files and its working everything but still i am not able to use encryption wpa2. Below is the my script. config wifi-device wifi0 option type qcawifi option channel auto option macaddr 00:03:7f:42:06:61 option hwmode 11ng # REMOVE THIS LINE TO ENABLE WIFI: option disabled 0 config wifi-iface option device wifi0 option network lan option mode ap option ssid CD-1 option encryption psk2 option key CD-1 M I doing anything wrong? Thanks, On Mon, Aug 3, 2015 at 6:40 AM, David Lang wrote: to make the config be there after a factory reset, you need to put the changes into the image that you build. you already did this for /etc/config/network, do the same thing for /etc/config/wireless David Lang On Sun, 2 Aug 2015, John kerry wrote: Hi Leiten, I have one issue, after upgrading this firmware it will load wireless configuration with this changes, actually it should load when i do factory reset. Thanks, On Sun, Aug 2, 2015 at 3:45 PM, John kerry wrote: Hi Leiten, Thank you so much, Its working :) On Sun, Aug 2, 2015 at 3:12 PM, N.Leiten wrote: Hi, Don't answer to my e-mail only, you need to add openwrt-devel maillist to CC or just answer to CC, in each case I'll receive message but also everyone could see all discussion. In email dated Воскресенье - 02 августа 2015 12:54:32 user John kerry wrote: Hi Leiten, I have added new files under and written below : vi target/linux/ar71xx/base-files/etc/uci-defaults/wireless Use index in prefix of filename to set order of execution, so it'll be like '99-wireless'. #!/bin/sh # # Copyright (c) 2013 The Linux Foundation. All rights reserved. # Copyright (C) 2011 OpenWrt.org # [ -e /etc/config/wireless ] && exit 0 Here is the problem. When uci-defaults invoke scripts there's already preconfiguration done and /etc/config/wireless already exists, so your script just exit at this point. Remove this line. touch /etc/config/wireless uci set wireless.@wifi-device[0].disabled=0; uci set system.@system[0].hostname=test_ap uci set wireless.@wifi-iface[0].mode=ap uci set wireless.@wifi-iface[0].ssid=CD-2.4D uci set wireless.@wifi-iface[0].encryption=none uci set wireless.@wifi-iface[0].wds=1 uci set wireless.radio0.disabled=0 uci commit wireless exit 0 and compile the source code using make V=s but still not changed default settings. Please help me to make it works. Thanks, On Sat, Aug 1, 2015 at 4:38 PM, N.Leiten wrote: You can also use uci-defaults mechanism for your purpose. Just put script in base-files/etc/uci-defaults and set your preferrable parameters with uci and don't forget to 'exit 0' at the end of script, in elsecase it'll be run every time at boot ruining changes. 2015-07-31 12:08 GMT+03:00 John kerry : Hi, I am working on Ar71xx openWRT Luci project. By default the Wi-Fi is disabled and SSID is OpenWrt. I need to change the default settings. Could anyone help me to change the default settings. Best Regards, John ___ 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings
can you connect via a wired port? given that you've been changing /etc/config/network and /etc/config/wireless, could you show us what you ended up with there? David Lang On Tue, 4 Aug 2015, John kerry wrote: Hi, I am using ar71xx OpenWrt. I have connected internet connection to WAN port and my PC to LAN. I have enabled the WiFi0. The LAN port static IP i am able to open GUI and even my mobile i connected to Wifi AP and able to open GUI in mobile. But I am not able to access internet on mobile which is connected to wifi0 AP. I have added below script under /etc/firewall.user file. iptables ...flush iptables --table nat --flush iptables --delete-chain iptables --table nat --delete-chain iptables -A FORWARD -j ACCEPT -i br-lan -o eth0.2 -m state --state NEW iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A POSTROUTING -t nat -o eth0.2 -j MASQUERADE echo 1 > /proc/sys/net/ipv4/ip_forward #where br-lan = LAN eth0.2 = WAN Could anyone help me to write the proper NAT rules so that able to access the internet. Thanks, On Mon, Aug 3, 2015 at 11:29 AM, John kerry wrote: Hello Guys, It's working. Thanks a lot to all of you :) On Mon, Aug 3, 2015 at 10:43 AM, David Lang wrote: The way to do this is to first forget about the factory reset problem and configure the AP to do what you want (including any encryption) then you can take the resulting file and put it into the build system so that it becomes the 'factory default' settings. Since you are not understanding how to configure the files from the documentation, configure them from the GUI and then look at the resulting files. David Lang On Mon, 3 Aug 2015, John kerry wrote: Hi All, I created separate files directory and added network and wireless files and its working everything but still i am not able to use encryption wpa2. Below is the my script. config wifi-device wifi0 option type qcawifi option channel auto option macaddr 00:03:7f:42:06:61 option hwmode 11ng # REMOVE THIS LINE TO ENABLE WIFI: option disabled 0 config wifi-iface option device wifi0 option network lan option mode ap option ssid CD-1 option encryption psk2 option key CD-1 M I doing anything wrong? Thanks, On Mon, Aug 3, 2015 at 6:40 AM, David Lang wrote: to make the config be there after a factory reset, you need to put the changes into the image that you build. you already did this for /etc/config/network, do the same thing for /etc/config/wireless David Lang On Sun, 2 Aug 2015, John kerry wrote: Hi Leiten, I have one issue, after upgrading this firmware it will load wireless configuration with this changes, actually it should load when i do factory reset. Thanks, On Sun, Aug 2, 2015 at 3:45 PM, John kerry wrote: Hi Leiten, Thank you so much, Its working :) On Sun, Aug 2, 2015 at 3:12 PM, N.Leiten wrote: Hi, Don't answer to my e-mail only, you need to add openwrt-devel maillist to CC or just answer to CC, in each case I'll receive message but also everyone could see all discussion. In email dated Воскресенье - 02 августа 2015 12:54:32 user John kerry wrote: Hi Leiten, I have added new files under and written below : vi target/linux/ar71xx/base-files/etc/uci-defaults/wireless Use index in prefix of filename to set order of execution, so it'll be like '99-wireless'. #!/bin/sh # # Copyright (c) 2013 The Linux Foundation. All rights reserved. # Copyright (C) 2011 OpenWrt.org # [ -e /etc/config/wireless ] && exit 0 Here is the problem. When uci-defaults invoke scripts there's already preconfiguration done and /etc/config/wireless already exists, so your script just exit at this point. Remove this line. touch /etc/config/wireless uci set wireless.@wifi-device[0].disabled=0; uci set system.@system[0].hostname=test_ap uci set wireless.@wifi-iface[0].mode=ap uci set wireless.@wifi-iface[0].ssid=CD-2.4D uci set wireless.@wifi-iface[0].encryption=none uci set wireless.@wifi-iface[0].wds=1 uci set wireless.radio0.disabled=0 uci commit wireless exit 0 and compile the source code using make V=s but still not changed default settings. Please help me to make it works. Thanks, On Sat, Aug 1, 2015 at 4:38 PM, N.Leiten wrote: You can also use uci-defaults mechanism for your purpose. Just put script in base-files/etc/uci-defaults and set your preferrable parameters with uci and don't forget to 'exit 0' at the end of script, in elsecase it'll be run every time at boot ruining changes. 2015-07-31 12:08 GMT+03:00 John kerry : Hi, I am working on Ar71xx openWRT Luci project. By default the Wi-Fi is disabled and SSID is OpenWrt. I need to change the default settings. Could anyone help me to change the default settings. Best Regards, John ___ openwrt-devel maili
Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings
just changes doesn't help a lot (and it's rather hard to see what's what with the wireless file) but it doesn't look like the wireless interfaces are configured to be part of the LAN interface. David Lang On Tue, 4 Aug 2015, John kerry wrote: Date: Tue, 4 Aug 2015 12:07:38 +0800 From: John kerry To: David Lang Cc: N.Leiten , OpenWrt Development List , Alex Weedy Subject: Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings Hi, below is the /etc/config/network and /etc/config/wireless changes. */etc/config/network:* config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config interface 'lan' option ifname 'eth0.1 eth1' option type 'bridge' option proto 'static' option ipaddr '192.168.1.5' option netmask '255.255.255.0' config interface 'wan' option ifname 'eth0.2' option proto 'dhcp' config switch option name 'eth0' option reset '1' option enable_vlan '1' config switch_vlan option device 'eth0' option vlan '1' option ports '0t 2 3 4 5' config switch_vlan option device 'eth0' option vlan '2' option ports '0t 1' config switch option name 'eth1' option reset '1' option enable_vlan '1' config switch_vlan option device 'eth1' option vlan '1' option ports '0 1 2 3 4 5' */etc/config/wireless:config wifi-device 'wifi0'option type 'qcawifi'option channel 'auto'option macaddr '00:03:7f:42:06:61'option hwmode '11ng'option txpower '19'option htmode 'HT20'config wifi-ifaceoption device 'wifi0'option network 'lan'option mode 'ap'option encryption 'psk2'option ssid 'Test_ap_1'option key * *'Test_ap_1'* *config wifi-device 'wifi1'option type 'qcawifi'option channel 'auto'option macaddr '00:03:7f:42:06:62'option hwmode '11na'option txpower '23'option htmode 'HT20'config wifi-ifaceoption device 'wifi1'option network 'lan' option mode 'ap'option ssid 'Test_ap_2'option encryption 'psk2'option key 'test_ap_2''* *Thanks,* On Tue, Aug 4, 2015 at 11:56 AM, David Lang wrote: can you connect via a wired port? given that you've been changing /etc/config/network and /etc/config/wireless, could you show us what you ended up with there? David Lang On Tue, 4 Aug 2015, John kerry wrote: Hi, I am using ar71xx OpenWrt. I have connected internet connection to WAN port and my PC to LAN. I have enabled the WiFi0. The LAN port static IP i am able to open GUI and even my mobile i connected to Wifi AP and able to open GUI in mobile. But I am not able to access internet on mobile which is connected to wifi0 AP. I have added below script under /etc/firewall.user file. iptables ...flush iptables --table nat --flush iptables --delete-chain iptables --table nat --delete-chain iptables -A FORWARD -j ACCEPT -i br-lan -o eth0.2 -m state --state NEW iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A POSTROUTING -t nat -o eth0.2 -j MASQUERADE echo 1 > /proc/sys/net/ipv4/ip_forward #where br-lan = LAN eth0.2 = WAN Could anyone help me to write the proper NAT rules so that able to access the internet. Thanks, On Mon, Aug 3, 2015 at 11:29 AM, John kerry wrote: Hello Guys, It's working. Thanks a lot to all of you :) On Mon, Aug 3, 2015 at 10:43 AM, David Lang wrote: The way to do this is to first forget about the factory reset problem and configure the AP to do what you want (including any encryption) then you can take the resulting file and put it into the build system so that it becomes the 'factory default' settings. Since you are not understanding how to configure the files from the documentation, configure them from the GUI and then look at the resulting files. David Lang On Mon, 3 Aug 2015, John kerry wrote: Hi All, I created separate files directory and added network and wireless files and its working everything but still i am not able to use encryption wpa2. Below is the my script. config wifi-device wifi0 option type qcawifi option channel auto option macaddr 00:03:7f:42:0
Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings
A given radio can be either an AP or a client, but not both at once. so if you use a radio to connect to another AP, you are making it a client, and in client mode all it can do is connect to that other AP as shows up as the SSID of that other AP. you can do this with one radio, while using the other radio (assuming you have two) to act as an AP for local clients. David Lang On Tue, 4 Aug 2015, John kerry wrote: Hi, Its working, i am able to access internet but there is one problem, When i scan the wireless devices, its gives the list of devices are there nearby, then i connect anyone device, it will connect but my board wifi0 SSID name will change to that router which i connected. I mean LAN side SSID should not change after connecting to WAN SSID. On Tue, Aug 4, 2015 at 12:42 PM, John kerry wrote: Hi This is my firewall file: config defaults option syn_flood '1' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' config zone option name 'lan' option network 'lan' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' config zone option name 'wan' option network 'wan' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT' option masq '1' option mtu_fix '1' config forwarding option src 'lan' option dest 'wan' config rule option name 'Allow-DHCP-Renew' option src 'wan' option proto 'udp' option dest_port '68' option target 'ACCEPT' option family 'ipv4' config rule option name 'Allow-Ping' option src 'wan' option proto 'icmp' option icmp_type 'echo-request' option family 'ipv4' option target 'ACCEPT' config rule option name 'Allow-DHCPv6' option src 'wan' option proto 'udp' option src_ip 'fe80::/10' option src_port '547' option dest_ip 'fe80::/10' option dest_port '546' option family 'ipv6' option target 'ACCEPT' config rule option name 'Allow-ICMPv6-Input' option src 'wan' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable' list icmp_type 'packet-too-big' list icmp_type 'time-exceeded' list icmp_type 'bad-header' list icmp_type 'unknown-header-type' list icmp_type 'router-solicitation' list icmp_type 'neighbour-solicitation' list icmp_type 'router-advertisement' list icmp_type 'neighbour-advertisement' option limit '1000/sec' option family 'ipv6' option target 'ACCEPT' config rule option name 'Allow-ICMPv6-Forward' option src 'wan' option dest '*' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable' list icmp_type 'packet-too-big' list icmp_type 'time-exceeded' list icmp_type 'bad-header' list icmp_type 'unknown-header-type' option limit '1000/sec' option family 'ipv6' option target 'ACCEPT' config include option path '/etc/firewall.user' config include 'miniupnpd' option type 'script' option path '/usr/share/miniupnpd/firewall.include' option family 'IPv4' option reload '1' On Tue, Aug 4, 2015 at 12:38 PM, Weedy wrote: Is there something wrong with the default rules for your use case? Your WiFi interfaces are tagged LAN, things should just work. On 4 Aug 2015 00:07, "John kerry" wrote: Hi, below is the /etc/config/network and /etc/config/wireless changes. */etc/config/network:* config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config interface 'lan' option ifname 'eth0.1 eth1' option type 'bridge' option proto 'static'
Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings
you can't create a new radio with a script, you have to have a second radio in the hardware. wifi0 is one radio, wifi1 is the second. configure one as an AP, the other as a client (you probably want to make the client be part of the wan interface/firewall group if it's your connection to the Internet) As I said before, since you don't understand how the configs work, I'd suggest using the GUI to configure them and then look at what the resulting file looks like. A lot of expertise went into making the GUI set the right config options to make pretty complex things happen. David Lang On Tue, 4 Aug 2015, John kerry wrote: Date: Tue, 4 Aug 2015 14:41:38 +0800 From: John kerry To: David Lang Cc: Weedy , N. Leiten , OpenWrt Development List Subject: Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings Hi, Yes i configured the mode as AP. could you please guide how i can add script for another radio. presently my wireless script is as below: *config wifi-device 'wifi0'option type 'qcawifi'option channel 'auto'option macaddr '00:03:7f:42:06:61'option hwmode '11ng'option txpower '19'option htmode 'HT20'config wifi-ifaceoption device 'wifi0'option network 'lan' option mode 'ap'option encryption 'psk2'option ssid 'Test_ap_1'option key **'Test_ap_1'* *config wifi-device 'wifi1'option type 'qcawifi'option channel 'auto'option macaddr '00:03:7f:42:06:62'option hwmode '11na'option txpower '23'option htmode 'HT20'config wifi-ifaceoption device 'wifi1' option network 'lan' option mode 'ap'option ssid 'Test_ap_2'option encryption 'psk2'option key 'test_ap_2'* *How i can change this to make it work.* *Thanks,* On Tue, Aug 4, 2015 at 2:26 PM, David Lang wrote: A given radio can be either an AP or a client, but not both at once. so if you use a radio to connect to another AP, you are making it a client, and in client mode all it can do is connect to that other AP as shows up as the SSID of that other AP. you can do this with one radio, while using the other radio (assuming you have two) to act as an AP for local clients. David Lang On Tue, 4 Aug 2015, John kerry wrote: Hi, Its working, i am able to access internet but there is one problem, When i scan the wireless devices, its gives the list of devices are there nearby, then i connect anyone device, it will connect but my board wifi0 SSID name will change to that router which i connected. I mean LAN side SSID should not change after connecting to WAN SSID. On Tue, Aug 4, 2015 at 12:42 PM, John kerry wrote: Hi This is my firewall file: config defaults option syn_flood '1' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' config zone option name 'lan' option network 'lan' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' config zone option name 'wan' option network 'wan' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT' option masq '1' option mtu_fix '1' config forwarding option src 'lan' option dest 'wan' config rule option name 'Allow-DHCP-Renew' option src 'wan' option proto 'udp' option dest_port '68' option target 'ACCEPT' option family 'ipv4' config rule option name 'Allow-Ping' option src 'wan' option proto 'icmp' option icmp_type 'echo-request' option family 'ipv4' option target 'ACCEPT' config rule option name 'Allow-DHCPv6' option src 'wan' option proto 'udp' option src_ip 'fe80::/10' option src_port '547' option dest_ip 'fe80::/10' option dest_port '546' option family 'ipv6' option target 'ACCEPT' config rule option name 'Allow-ICMPv6-Input' option src 'wan' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable'
Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings
On Tue, 4 Aug 2015, John kerry wrote: I have one doubts, both should be configured either 2.4GHz or 5GHz but for wifi1 in GUI there is no option to change to 2.4GHz. no, one radio is only able to operate on the 2.4GHz band and the other is only able to operate on the 5GHz band. this isn't a configuration item, this is teh physical/electrical properties of the radios. without some rather complicated (and expensive) setup you can't have two radios on te 2.4GHz band in one AP, when one transmits it would defen (if not actually damage) the other you can use one as a client to a remote AP (say the 5GHz band) and then use the other (the 2.4GHz band) to provide service to nearby equipment. I actually just finished setting up this exact configuration to extend service into a nearby building across a parking lot. David Lang Thanks, On Tue, Aug 4, 2015 at 2:56 PM, David Lang wrote: you can't create a new radio with a script, you have to have a second radio in the hardware. wifi0 is one radio, wifi1 is the second. configure one as an AP, the other as a client (you probably want to make the client be part of the wan interface/firewall group if it's your connection to the Internet) As I said before, since you don't understand how the configs work, I'd suggest using the GUI to configure them and then look at what the resulting file looks like. A lot of expertise went into making the GUI set the right config options to make pretty complex things happen. David Lang On Tue, 4 Aug 2015, John kerry wrote: Date: Tue, 4 Aug 2015 14:41:38 +0800 From: John kerry To: David Lang Cc: Weedy , N. Leiten , OpenWrt Development List Subject: Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings Hi, Yes i configured the mode as AP. could you please guide how i can add script for another radio. presently my wireless script is as below: *config wifi-device 'wifi0'option type 'qcawifi'option channel 'auto'option macaddr '00:03:7f:42:06:61'option hwmode '11ng'option txpower '19'option htmode 'HT20'config wifi-ifaceoption device 'wifi0'option network 'lan' option mode 'ap'option encryption 'psk2'option ssid 'Test_ap_1'option key **'Test_ap_1'* *config wifi-device 'wifi1'option type 'qcawifi'option channel 'auto'option macaddr '00:03:7f:42:06:62'option hwmode '11na'option txpower '23'option htmode 'HT20'config wifi-ifaceoption device 'wifi1'option network 'lan' option mode 'ap'option ssid 'Test_ap_2'option encryption 'psk2'option key 'test_ap_2'* *How i can change this to make it work.* *Thanks,* On Tue, Aug 4, 2015 at 2:26 PM, David Lang wrote: A given radio can be either an AP or a client, but not both at once. so if you use a radio to connect to another AP, you are making it a client, and in client mode all it can do is connect to that other AP as shows up as the SSID of that other AP. you can do this with one radio, while using the other radio (assuming you have two) to act as an AP for local clients. David Lang On Tue, 4 Aug 2015, John kerry wrote: Hi, Its working, i am able to access internet but there is one problem, When i scan the wireless devices, its gives the list of devices are there nearby, then i connect anyone device, it will connect but my board wifi0 SSID name will change to that router which i connected. I mean LAN side SSID should not change after connecting to WAN SSID. On Tue, Aug 4, 2015 at 12:42 PM, John kerry wrote: Hi This is my firewall file: config defaults option syn_flood '1' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' config zone option name 'lan' option network 'lan' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' config zone option name 'wan' option network 'wan' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT' option masq '1' option mtu_fix '1' config forwarding option src 'lan' option dest 'wan' config rule option name 'Allow-DHCP-Renew' option src 'wan' option proto 'udp' option dest_port '68' option target 'ACCEPT' option family 'ipv4' config rul
Re: [OpenWrt-Devel] "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio)
You cannot use both radios on the same channel, or even the same band. One radio will only work on channels 1-11 and the other will only work on channels 36+ pick which band you are going to use to connect to the remote AP and which you are going to use to have your clients connect to it. David Lang On Fri, 7 Aug 2015, John kerry wrote: Hi, I have one and i configured as below: config wifi-device 'wifi0' option type 'qcawifi' option channel 'auto' option macaddr '00:26:75:bd:37:24' option hwmode '11ng' option txpower '16' option htmode 'HT20' config wifi-iface option device 'wifi0' option network 'lan' option mode 'ap' option ssid 'Test_Ap' option encryption 'psk2' option key 'Test_AP' We can configure one radio only to work like that. Something like below: config wifi-device 'radio0' option type 'mac80211' option channel '11' option hwmode '11g' option path 'platform/ar933x_wmac' option htmode 'HT20' option country 'US' option txpower '20' config wifi-iface 'ap1' option device 'radio0' option mode 'ap' option wds '1' option ssid 'my AP' option network 'lan' config wifi-iface 'mesh1' option device 'radio0' option mode 'mesh' option mesh_id 'my mesh' option network 'lan' On Fri, Aug 7, 2015 at 11:31 AM, Weedy wrote: On 6 Aug 2015 23:15, "John kerry" wrote: Hi, Could anyone please help me on this to configure the wireless in such a way that when we connect to wireless WAN the LAN SSID should not change. Thanks, You need 2 physical radios. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio)
you have two radio settings in /etc/config/wireless, one is for 2.4GHz, one is for 5GHz set each of them the way you want them to be (one as a client to the remote AP, the other as a different SSID for your local users to connect to), then add this file to your build process the way you did /etc/config/networks (under files/) David Lang On Sun, 9 Aug 2015, John kerry wrote: Hi, Could anyone Please guide me how i can create 2 separate default settings for 2.4GHz and 5GHz. Thanks, On Sat, Aug 8, 2015 at 8:26 PM, John kerry wrote: Hi, I have to keep 2 default settings for wireless, i means to say i have to configure default settings for 2.4GHz and 5GHz. How i can configure wireless files. mainly i will add switch button in the GUI to switch over 2.4GHz and 5GHz. How i can control this in backend, how i can add file which handle this and configure 2 separate default settings for 2.4GHz and 5GHz. Thanks, On Fri, Aug 7, 2015 at 1:50 PM, David Lang wrote: You cannot use both radios on the same channel, or even the same band. One radio will only work on channels 1-11 and the other will only work on channels 36+ pick which band you are going to use to connect to the remote AP and which you are going to use to have your clients connect to it. David Lang On Fri, 7 Aug 2015, John kerry wrote: Hi, I have one and i configured as below: config wifi-device 'wifi0' option type 'qcawifi' option channel 'auto' option macaddr '00:26:75:bd:37:24' option hwmode '11ng' option txpower '16' option htmode 'HT20' config wifi-iface option device 'wifi0' option network 'lan' option mode 'ap' option ssid 'Test_Ap' option encryption 'psk2' option key 'Test_AP' We can configure one radio only to work like that. Something like below: config wifi-device 'radio0' option type 'mac80211' option channel '11' option hwmode '11g' option path 'platform/ar933x_wmac' option htmode 'HT20' option country 'US' option txpower '20' config wifi-iface 'ap1' option device 'radio0' option mode 'ap' option wds '1' option ssid 'my AP' option network 'lan' config wifi-iface 'mesh1' option device 'radio0' option mode 'mesh' option mesh_id 'my mesh' option network 'lan' On Fri, Aug 7, 2015 at 11:31 AM, Weedy wrote: On 6 Aug 2015 23:15, "John kerry" wrote: Hi, Could anyone please help me on this to configure the wireless in such a way that when we connect to wireless WAN the LAN SSID should not change. Thanks, You need 2 physical radios. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio)
On Sat, 8 Aug 2015, John kerry wrote: Hi, I have to keep 2 default settings for wireless, i means to say i have to configure default settings for 2.4GHz and 5GHz. How i can configure wireless files. mainly i will add switch button in the GUI to switch over 2.4GHz and 5GHz. How i can control this in backend, how i can add file which handle this and configure 2 separate default settings for 2.4GHz and 5GHz. It's not clear what you are asking to do. Please explain in more detail. David Lang Thanks, On Fri, Aug 7, 2015 at 1:50 PM, David Lang wrote: You cannot use both radios on the same channel, or even the same band. One radio will only work on channels 1-11 and the other will only work on channels 36+ pick which band you are going to use to connect to the remote AP and which you are going to use to have your clients connect to it. David Lang On Fri, 7 Aug 2015, John kerry wrote: Hi, I have one and i configured as below: config wifi-device 'wifi0' option type 'qcawifi' option channel 'auto' option macaddr '00:26:75:bd:37:24' option hwmode '11ng' option txpower '16' option htmode 'HT20' config wifi-iface option device 'wifi0' option network 'lan' option mode 'ap' option ssid 'Test_Ap' option encryption 'psk2' option key 'Test_AP' We can configure one radio only to work like that. Something like below: config wifi-device 'radio0' option type 'mac80211' option channel '11' option hwmode '11g' option path 'platform/ar933x_wmac' option htmode 'HT20' option country 'US' option txpower '20' config wifi-iface 'ap1' option device 'radio0' option mode 'ap' option wds '1' option ssid 'my AP' option network 'lan' config wifi-iface 'mesh1' option device 'radio0' option mode 'mesh' option mesh_id 'my mesh' option network 'lan' On Fri, Aug 7, 2015 at 11:31 AM, Weedy wrote: On 6 Aug 2015 23:15, "John kerry" wrote: Hi, Could anyone please help me on this to configure the wireless in such a way that when we connect to wireless WAN the LAN SSID should not change. Thanks, You need 2 physical radios. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio)
Well, if you are going to be modifying the GUI and adding a button to chagne between two configs, where you store the two configs is going to be up to you. When the button is clicked, you need to copy the approriate config to /etc/config/wireless and run the wifi command to restart wifi with the new config (I don't know the exact command to run, do wifi -h and look for a restart option). Or, since the other LUCI stuff writes the file and then restarts things, you can copy that code (which you will be looking at when you modify it to include the new button and related functionality) the files/ process lets you put whatever files you want in place to then use via your change to LUCI. for details of how to change the LUCI code, you should ask on it's development mailing list. David Lang On Sun, 9 Aug 2015, John kerry wrote: Date: Sun, 9 Aug 2015 12:42:49 +0800 From: John kerry To: David Lang Cc: Weedy , OpenWrt Development List , Joshua Judson Rosen Subject: Re: [OpenWrt-Devel] "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio) Hi, Basically i will add one switch in GUI to select either 2.4GHz or 5GHz. So if i select 2.4GHz the settings should be like below, *config wifi-device 'wifi0'* * option type 'qcawifi' option channel 'auto' option macaddr '00:03:7f:42:06:61' option hwmode '11ng' option txpower '19' option htmode 'HT20' config wifi-iface option device 'wifi0' option network 'lan' option mode 'ap' option encryption 'psk2' option ssid 'Test_ap_1' option key 'Test_ap_1'* so if i do factory reset it settings. When i select 5GHz the config load with 5GHz as below: *config wifi-device 'wifi0'* * option type 'qcawifi' option channel 'auto' option macaddr '00:03:7f:42:06:61' option hwmode '11na' option txpower '23' option htmode 'HT20' config wifi-iface option device 'wifi0' option network 'lan' option mode 'ap' option encryption 'psk2' option ssid 'Test_ap_1' option key 'Test_ap_1'* *So basically how i can condition in wireless config file to load the config based on the selection.* *Can i write condition in wireless config file.* *Thanks,* On Sun, Aug 9, 2015 at 7:02 AM, David Lang wrote: On Sat, 8 Aug 2015, John kerry wrote: Hi, I have to keep 2 default settings for wireless, i means to say i have to configure default settings for 2.4GHz and 5GHz. How i can configure wireless files. mainly i will add switch button in the GUI to switch over 2.4GHz and 5GHz. How i can control this in backend, how i can add file which handle this and configure 2 separate default settings for 2.4GHz and 5GHz. It's not clear what you are asking to do. Please explain in more detail. David Lang Thanks, On Fri, Aug 7, 2015 at 1:50 PM, David Lang wrote: You cannot use both radios on the same channel, or even the same band. One radio will only work on channels 1-11 and the other will only work on channels 36+ pick which band you are going to use to connect to the remote AP and which you are going to use to have your clients connect to it. David Lang On Fri, 7 Aug 2015, John kerry wrote: Hi, I have one and i configured as below: config wifi-device 'wifi0' option type 'qcawifi' option channel 'auto' option macaddr '00:26:75:bd:37:24' option hwmode '11ng' option txpower '16' option htmode 'HT20' config wifi-iface option device 'wifi0' option network 'lan' option mode 'ap' option ssid 'Test_Ap' option encryption 'psk2' option key 'Test_AP' We can configure one radio only to work like that. Something like below: config wifi-device 'radio0' option type 'mac80211' option channel '11' option hwmode '11g' option path 'platform/ar933x_wmac' option htmode 'HT20' option country 'US' option txpower '20' config wifi-iface 'ap1' option device 'radio0' option mode 'ap' option wds '1' option ssid 'my AP' option network 'lan' config wifi-iface 'mesh1' option device 'radio0' option mode 'mesh' option mesh_id 'my mesh' option network 'lan' On Fri, Aug 7, 2015 at 11:31 AM, Weedy wrote: On 6 Aug 2015 23:15, "John kerry" wrote: Hi, Could anyone please help me on this to configure the wireless in such a way that when we connect to wireless WAN the LAN SSID should not change. Thanks, You need 2 physical radios. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio)
On Mon, 10 Aug 2015, John kerry wrote: Date: Mon, 10 Aug 2015 18:10:14 +0800 From: John kerry To: Alex Weedy , OpenWrt Development List Subject: [OpenWrt-Devel] Fwd: "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio) Firstly i configure wireless config as below: config wifi-device 'wifi0' option type 'qcawifi' option macaddr '00:01:11:00:01:00' option hwmode '11ng' option txpower '17' option htmode 'HT20' option disabled '0' option channel '1' config wifi-iface option device 'wifi0' option mode 'ap' option ssid 'Testing_ap' option network 'lan' option encryption 'psk2' option key 'Testing_ap' so its SSID was showing and able to connect any device to it. Then i scan the device and connect to one of it. While joining the network i selected Client(WDS) then the wireless config becomes like below: why don't you try following the steps in the video that you posted. first connect as a client, then add an additional interface and make the second interface the AP for things to connect to. the order may make a difference. David Lang config wifi-device 'wifi0' option type 'qcawifi' option macaddr '00:01:11:00:01:00' option hwmode '11ng' option txpower '17' option htmode 'HT20' option disabled '0' option channel '1' config wifi-iface option network 'wwan' option ssid 'D_Link_Router' option encryption 'psk2' option device 'wifi0' option mode 'sta' option key 'Dlink_Router' option wds '1' Then i added one as shown in the video. Now its connected to router also and this add one also showing so i can connect to this also. But i am not getting how to keep this in default wireless config. Because every time we cant add one to configure like this. It should be like default should be in ap mode so any device we can connect, if its connected to another router also that SSID still should be visible and able to connect to this. On Mon, Aug 10, 2015 at 2:57 PM, John kerry wrote: When i try to configure based on video, its shows 2 one as client another one as Master but i am not able to enable it . I mean to say wireless becomes disable. If i enable it using GUI also its not happening. On Mon, Aug 10, 2015 at 2:55 PM, David Lang wrote: What happens when you try to follow the video? Based on your comments, i'm guessing that things don't work when you try and configure the second network and have it with a different SSID than the first network that you put in client mode. Is this correct? David Lang On Mon, 10 Aug 2015, John kerry wrote: Yes, When i am connecting to Another router its changed to Client mode. Can i configure this in repeater mode like its shows in below link: https://www.youtube.com/watch?v=3rbsh2zxPnk ___ 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] Fwd: "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio)
On Mon, 10 Aug 2015, John kerry wrote: I followed the same steps and its working too. But this i want in wireless config file, Because i dont want every time to add using GUI. So When i connect to another router also, no need to add one more. I mean to say it should be in default wireless config file. what do you mean by "default wireless config file" Once you have set it from the GUI, it is in the config files. The next time you boot it will use that config. If you mean that you want it in the factory default config (for when you first flash the router or do a factory reset), then take the /etc/config/wireless and /etc/config/network files and add them to your build under /files David Lang On Mon, Aug 10, 2015 at 6:18 PM, David Lang wrote: On Mon, 10 Aug 2015, John kerry wrote: Date: Mon, 10 Aug 2015 18:10:14 +0800 From: John kerry To: Alex Weedy , OpenWrt Development List Subject: [OpenWrt-Devel] Fwd: "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio) Firstly i configure wireless config as below: config wifi-device 'wifi0' option type 'qcawifi' option macaddr '00:01:11:00:01:00' option hwmode '11ng' option txpower '17' option htmode 'HT20' option disabled '0' option channel '1' config wifi-iface option device 'wifi0' option mode 'ap' option ssid 'Testing_ap' option network 'lan' option encryption 'psk2' option key 'Testing_ap' so its SSID was showing and able to connect any device to it. Then i scan the device and connect to one of it. While joining the network i selected Client(WDS) then the wireless config becomes like below: why don't you try following the steps in the video that you posted. first connect as a client, then add an additional interface and make the second interface the AP for things to connect to. the order may make a difference. David Lang config wifi-device 'wifi0' option type 'qcawifi' option macaddr '00:01:11:00:01:00' option hwmode '11ng' option txpower '17' option htmode 'HT20' option disabled '0' option channel '1' config wifi-iface option network 'wwan' option ssid 'D_Link_Router' option encryption 'psk2' option device 'wifi0' option mode 'sta' option key 'Dlink_Router' option wds '1' Then i added one as shown in the video. Now its connected to router also and this add one also showing so i can connect to this also. But i am not getting how to keep this in default wireless config. Because every time we cant add one to configure like this. It should be like default should be in ap mode so any device we can connect, if its connected to another router also that SSID still should be visible and able to connect to this. On Mon, Aug 10, 2015 at 2:57 PM, John kerry wrote: When i try to configure based on video, its shows 2 one as client another one as Master but i am not able to enable it . I mean to say wireless becomes disable. If i enable it using GUI also its not happening. On Mon, Aug 10, 2015 at 2:55 PM, David Lang wrote: What happens when you try to follow the video? Based on your comments, i'm guessing that things don't work when you try and configure the second network and have it with a different SSID than the first network that you put in client mode. Is this correct? David Lang On Mon, 10 Aug 2015, John kerry wrote: Yes, When i am connecting to Another router its changed to Client mode. Can i configure this in repeater mode like its shows in below link: https://www.youtube.com/watch?v=3rbsh2zxPnk ___ 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] Fwd: "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio)
you have a working config but you want to do something by default what you want to do is different at different times. what is it that you want to be the default? when do you want this default to apply? This isn't clear. David Lang On Tue, 11 Aug 2015, John kerry wrote: Date: Tue, 11 Aug 2015 15:51:38 +0800 From: John kerry To: David Lang Cc: Alex Weedy , OpenWrt Development List Subject: Re: [OpenWrt-Devel] Fwd: "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio) Yes, i can copy the config and build with this configuration, for example now i have connected to some router, another time we can connect to any router. So how i can fix the settings by default. On Tue, Aug 11, 2015 at 12:45 AM, David Lang wrote: On Mon, 10 Aug 2015, John kerry wrote: I followed the same steps and its working too. But this i want in wireless config file, Because i dont want every time to add using GUI. So When i connect to another router also, no need to add one more. I mean to say it should be in default wireless config file. what do you mean by "default wireless config file" Once you have set it from the GUI, it is in the config files. The next time you boot it will use that config. If you mean that you want it in the factory default config (for when you first flash the router or do a factory reset), then take the /etc/config/wireless and /etc/config/network files and add them to your build under /files David Lang On Mon, Aug 10, 2015 at 6:18 PM, David Lang wrote: On Mon, 10 Aug 2015, John kerry wrote: Date: Mon, 10 Aug 2015 18:10:14 +0800 From: John kerry To: Alex Weedy , OpenWrt Development List Subject: [OpenWrt-Devel] Fwd: "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio) Firstly i configure wireless config as below: config wifi-device 'wifi0' option type 'qcawifi' option macaddr '00:01:11:00:01:00' option hwmode '11ng' option txpower '17' option htmode 'HT20' option disabled '0' option channel '1' config wifi-iface option device 'wifi0' option mode 'ap' option ssid 'Testing_ap' option network 'lan' option encryption 'psk2' option key 'Testing_ap' so its SSID was showing and able to connect any device to it. Then i scan the device and connect to one of it. While joining the network i selected Client(WDS) then the wireless config becomes like below: why don't you try following the steps in the video that you posted. first connect as a client, then add an additional interface and make the second interface the AP for things to connect to. the order may make a difference. David Lang config wifi-device 'wifi0' option type 'qcawifi' option macaddr '00:01:11:00:01:00' option hwmode '11ng' option txpower '17' option htmode 'HT20' option disabled '0' option channel '1' config wifi-iface option network 'wwan' option ssid 'D_Link_Router' option encryption 'psk2' option device 'wifi0' option mode 'sta' option key 'Dlink_Router' option wds '1' Then i added one as shown in the video. Now its connected to router also and this add one also showing so i can connect to this also. But i am not getting how to keep this in default wireless config. Because every time we cant add one to configure like this. It should be like default should be in ap mode so any device we can connect, if its connected to another router also that SSID still should be visible and able to connect to this. On Mon, Aug 10, 2015 at 2:57 PM, John kerry wrote: When i try to configure based on video, its shows 2 one as client another one as Master but i am not able to enable it . I mean to say wireless becomes disable. If i enable it using GUI also its not happening. On Mon, Aug 10, 2015 at 2:55 PM, David Lang wrote: What happens when you try to follow the video? Based on your comments, i'm guessing that things don't work when you try and configure the second network and have it with a different SSID than the first network that you put in client mode. Is this correct? David Lang On Mon, 10 Aug 2015, John kerry wrote: Yes, When i am connecting to Another router its changed to Client mode. Can i configure this in repeater mode like its shows in below link: https://www.youtube.com/watch?v=3rbsh2zxPnk ___ 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] Fwd: "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio)
I thought you said a couple posts ago that you were able to configure it through the GUI to work the way you wanted it to, you were just wanting to make something the default. So do you have it working or not? If you have it working, it should keep working after a reboot. What are you meaning when you say that you want to change the default? Are you meaning that you want to create an image that will behave this way when you do a factory reset (or when you first flash it)? If so, then you need to take your working config and make it part of your image via the files/ mechansim. If you are meaning something else, I'm still not understanding what you are trying to do. David Lang On Tue, 11 Aug 2015, John kerry wrote: Date: Tue, 11 Aug 2015 21:20:58 +0800 From: John kerry To: David Lang Cc: Alex Weedy , OpenWrt Development List Subject: Re: [OpenWrt-Devel] Fwd: "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio) Hi, How to config wireless config file for repeater mode. I am not able to config. On Tue, Aug 11, 2015 at 5:34 PM, John kerry wrote: When i load firmware the wireless config will be like below: config wifi-device 'wifi0' option type 'qcawifi' option macaddr '00:26:75:bd:37:24' option hwmode '11ng' option txpower '16' option htmode 'HT20' option disabled '0' option channel '1' config wifi-iface option device 'wifi0' option mode 'ap' option ssid 'Test_ap' option network 'lan' option encryption 'psk2' option key 'Test_ap' option wds '1' so it works as Access point, i can connect to it any devices. When i scan it shows me list of devices then connect to anyone. then the wireless config will becomes like below: config wifi-device 'wifi0' option type 'qcawifi' option macaddr '00:26:75:bd:37:24' option hwmode '11ng' option txpower '16' option htmode 'HT20' option disabled '0' option channel '1' config wifi-iface option network 'wwan' option ssid 'D-link-Router' option encryption 'psk2' option device 'wifi0' option mode 'sta' option key '0010069039' option wds '1' Then i add one more ap mode so wireless config becomes, config wifi-device 'wifi0' option type 'qcawifi' option macaddr '00:26:75:bd:37:24' option hwmode '11ng' option txpower '16' option htmode 'HT20' option disabled '0' option channel '1' config wifi-iface option network 'wwan' option ssid 'D-link-Router' option encryption 'psk2' option device 'wifi0' option mode 'sta' option key '0010069039' option wds '1' config wifi-iface option device 'wifi0' option mode 'ap' option ssid 'Test_ap' option network 'lan' option encryption 'psk2' option key 'Test_ap' option wds '1' This i added manually one ap mode. So if i copy this config file, build and load this firmware, its load what it was there so it shows one client which i was connected last time and one AP which i added. But now i cannot scan anymore and connect to new router instead of old client. This is the problem i am facing. Basically i need to configure the wireless file for repeater mode. So after connecting to another router this SSID still should be there and other device can connect to it. On Tue, Aug 11, 2015 at 4:30 PM, David Lang wrote: you have a working config but you want to do something by default what you want to do is different at different times. what is it that you want to be the default? when do you want this default to apply? This isn't clear. David Lang On Tue, 11 Aug 2015, John kerry wrote: Date: Tue, 11 Aug 2015 15:51:38 +0800 From: John kerry To: David Lang Cc: Alex Weedy , OpenWrt Development List Subject: Re: [OpenWrt-Devel] Fwd: "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio) Yes, i can copy the config and build with this configuration, for example now i have connected to some router, another time we can connect to any router. So how i can fix the settings by default. On Tue, Aug 11, 2015 at 12:45 AM, David Lang wrote: On Mon, 10 Aug 2015, John kerry wrote: I followed the same steps and its working too
Re: [OpenWrt-Devel] Fwd: "3-address Wi-Fi bridging"
On Tue, 11 Aug 2015, Felix Fietkau wrote: On 2015-08-11 11:34, John kerry wrote: This i added manually one ap mode. So if i copy this config file, build and load this firmware, its load what it was there so it shows one client which i was connected last time and one AP which i added. But now i cannot scan anymore and connect to new router instead of old client. This is the problem i am facing. Basically i need to configure the wireless file for repeater mode. You seem to be using a proprietary driver from QCA, probably even a heavily modified version of OpenWrt. We can't help you with that, since the driver and probably other parts of the code that you're running are not made or maintained by the OpenWrt team. - Felix Felix, I don't remember him saying what he's using, how did you spot that? David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio)
On Thu, 13 Aug 2015, John kerry wrote: Hi, i will check whether this is driver issue or Luci, I have to add " disable WPS if this feature is enabled for the WiFi module" this in wireless. How i can handle this. ??? is this something you want to happen? something that happens that you don't want? we can't read your mind. David Lang Thanks, On Thu, Aug 13, 2015 at 2:18 PM, David Lang wrote: On Thu, 13 Aug 2015, John kerry wrote: But i dont think so this driver might be the problem, Because when i am doing using GUI its working so there will be not driver problem. Just i am not getting how to add this in build config. Normally what will be the wireless config for the repeater mode default. the exact file that you create as a result of the GUI is what you would put in the build config. But you say that you don't want that file because you want to connect to different SSIDs on different channels, so you don't _have_ any one file that you want to put in the default. When you use LUCI to scan and attach to a different SSID, you say that it looses the config for the local systems to connect to it. This could be a LUCI problem, or it could be that the driver requires that this be reset afterwords. If it's a LUCI problem, you will have to fix that code (or go to where tehy develop it and convince them to fix it). If it's a driver problem you are out of luck. But we can't tell you a file to put in the build that will connect to any remote system because there isn't one file that will automatically connect to any of several remote systems. David Lang On Thu, Aug 13, 2015 at 11:40 AM, David Lang wrote: If you want to have one config thaqt will talk to many different APs with different names/configs you are asking for magic. You have to change the config to talk to the different destinations. Since you are using a non-mainline driver, we don't know what the driver s able to do. It sounds as if there is a problem that could either be in the driver or in LUCI that makes it loose the rest of the config when you have it scan for networks. you can probably avoid that by just changing the info in the file to be appropriate for the new environment and restarting wifi/rebooting. If you want to do this via the existing GUI you will need to make code changes to LUCI. But at this point you are talking custom stuff. David Lang On Thu, 13 Aug 2015, John kerry wrote: Hi, Still i am not able to configure wireless config file. The problem i am facing, i cannot add fixed router name and password. It should every time scan and connect to any router. If i used GUI one config its fixed to that router which i connected. So with that configuration we are not able to scan again and connect to any other router next time. On Wed, Aug 12, 2015 at 9:29 AM, John kerry wrote: Yes i able to config using GUI, But when i am configuring GUI i scan and connect to one AP and then add one more AP mode to it. So finally i will have wireless configuration. But i cant keep this config in build option because if i load this configuration it will load what i connected last time, so next time i cant scan it anymore it showing the same connected to last AP. On Wed, Aug 12, 2015 at 1:36 AM, David Lang wrote: I thought you said a couple posts ago that you were able to configure it through the GUI to work the way you wanted it to, you were just wanting to make something the default. So do you have it working or not? If you have it working, it should keep working after a reboot. What are you meaning when you say that you want to change the default? Are you meaning that you want to create an image that will behave this way when you do a factory reset (or when you first flash it)? If so, then you need to take your working config and make it part of your image via the files/ mechansim. If you are meaning something else, I'm still not understanding what you are trying to do. David Lang On Tue, 11 Aug 2015, John kerry wrote: Date: Tue, 11 Aug 2015 21:20:58 +0800 From: John kerry To: David Lang Cc: Alex Weedy , OpenWrt Development List Subject: Re: [OpenWrt-Devel] Fwd: "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio) Hi, How to config wireless config file for repeater mode. I am not able to config. On Tue, Aug 11, 2015 at 5:34 PM, John kerry wrote: When i load firmware the wireless config will be like below: config wifi-device 'wifi0' option type 'qcawifi' option macaddr '00:26:75:bd:37:24' option hwmode '11ng' option txpower '16' option htmode 'HT20' option disabled '0' option channel '1' config wifi-iface option device 'wifi0' option mode 'ap' option ssid 'Test_ap' option netwo
Re: [OpenWrt-Devel] AR9344 OpenWrt GUI
On Wed, 9 Sep 2015, John kerry wrote: Hi, We are working on AR9344 OpenWrt, We have configured the wireless as AP mode and broadcasting the SSID so any device can connect to it and even we are able access the GUI on Smartphone after connecting to that AP. Then we do survey the scanning devices, its gives the Scanning result, then we can join Network to anyone from the list. Then blow page will show as shown below: [image: Inline image 1] The we enter the PassPhrase and Click on Submit button. Then next page will show as below [image: Inline image 2] After Clicking the on *Save & Apply button, *The following files /etc/config/network /etc/config/dhcp, /etc/config/qos etc. Because of this files changes Wi-Fi connection is reset the connection. So we are unable to configure above configuration using Smartphone. Well, when you reconfigure the interface you are connected to, it is going to bounce. Which is why it's suggested that you configure the wireless through a wired link. But once the wifi is reset, you should be able to reconnect, login again and continue. Is this not working? If not, what is happening? David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR9344 OpenWrt GUI
On Thu, 10 Sep 2015, John kerry wrote: Yes after reset we are to able to reconnect, I understand using wired connection we can configure but we need to configure using wireless only. Is there anyway that we can avoid the Wi-Fi reset? No, if you tell it to reconfigure wifi and apply the settings, it needs to do what you told it to do, and that involves resetting the radio(s) to make sure they now do everything you told it to do. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] First boot provisioning
catching up on old e-mail On Wed, 9 Dec 2015, Lukáš Macura wrote: Hello, I would want to start some discussion about first boot provisioning and theoretical inclusion of some script into default images. Today, if somebody want some automatic way to autoconfigure OpenWrt boxes, he has to create its own image. But if there is some possibility directly in OpenWrt, how to do some well-documented procedure during first boot, first boot auto configuration could be offloaded from image. I know there are some security issues. But I think that such procedure could be very tiny and efficient. For example, it is very easy to write handler for reset button /etc/rc.button/reset : if [ "$SEEN" -lt 1 ] then echo "REBOOT" > /dev/console sync reboot elif [ "$SEEN" -gt 10 ] then ( echo "PROVISIONING" wget -q -O- http://openwrt-prov/opkg.repo >/etc/opkg/provisioned.conf packages=$(wget -q -O- http://openwrt-prov/default/opkg.install) [ -n "$packages" ] && opkg update && opkg install $packages ) 2>&1 | logger elif [ "$SEEN" -gt 5 ] then echo "FACTORY RESET" > /dev/console jffs2reset -y && reboot & fi so if you press reset button for more than 10 seconds, box will download two files from some server. One which can add some local repositories and second to get package names to install. Next to this, it will do opkg update and install. There are more ways how to trigger first boot procedure. This is only proof of concept. Another way is to include this procedure in uci-defaults and run each time when device is in factory defaults mode. Some questions: - - How to form url? Which url? - - Is it secure to download some external content by default? No, but this will hapen only during first boot. - - Should this procedure be manual? eg. it needs to press button or automaticaly? It all depends on the environment. For he Scale conference last week, I had 120 APs out and they got configured by a combination of the base image (populating /files) and DHCP parameters. That wouldn't work in home systems where the AP is the DHCP. Automating configuation and updates from your own system is a great thing to do. Doing so from someone else's system on the Internet is something else. And taking on the responsibility for holding such configs (and the potential liability if the configs get tampered with and access is granted to lots of peoples systmes) is something else again. It's not something Openwrt is going to want to get involved with. The bigger issue is that the reason why most openwrt devices get updated by flashing a complete image is the shortage of storage on them. By using a pre-compressed, read-only filesystem, the compression ratio is much higher, but it means that anything that gets installed on the device after that point has two versions taking up space, the original, highly compressed version, and a later, less compressed version. You very quickly run out of space updating individual packages and overriding basic configs. But I do like the idea of holding the reset button down to pull from a local system. I'll use that trick in the future :-) David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] use NTP server received via DHCP
Just a side note while you are working in this area. all the documentation for udhcpc (including it's default config settings) says that it uses one default file path, but when it's run that path gets overridden on the command line and a different file is used instead. The default in the config should be changed to what's actually used and the extra copy should be eliminated. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Question about custom script at init on Trunk.-
Since it's just two files that you are wanting to override for your images, go
to the top level directory (where you do your make menuconfig) and create the
directory files and put the files that you want to override in there (in the
appropriate directory, so to override /etc/config/wireless, make the file
files/etc/config/wireless)
much easier than maintaining a different version of the package just to change a
couple files.
David Lang
On Tue, 26 Jan 2016, Guillermo Javier Nardoni wrote:
Date: Tue, 26 Jan 2016 21:19:54 -0300
From: Guillermo Javier Nardoni
To: openwrt-devel@lists.openwrt.org, guille...@geryon.com.ar
Subject: [OpenWrt-Devel] Question about custom script at init on Trunk.-
Hello everyone,
At first, I should say that I?ve been away a long time from openwrt-devel
mailing list.
I was using Barrier Braker 14.07 to build our custom firmware, usually for
TP-Link WR740/741 v3/v4, but recently we have received TP-Link WR740 v5
(a.k.a. 741 v5) so I figured out that Barrier Braker don?t have support for
it, at least not native one.
Googling I found a solution which I?ve flashed it first with a stripped
custom firmware found on Internet and then, via console, do a beautifull
reflash with WR741 v4 firmware (build by us) and everything Works perfect!.
Since I?m not the one who flashes the devices I did a new git from trunk
versión of OpenWrt (CHAOS CALMER (15.05)) because it has native support for
TP-Link TL-WR740N versión 5 but when I looked into the code I?ve figured
out, again, that the code changed a lot since the BB 14.07 and I don?t know
how to adapt the custom configurations.
The reason I changed those 2 files it is because of the users sometimes (i
mean always) press the reset button and it won?t allow us to remotely
recofigure the device and to use one port of the switch to bridge it with
the WAN port to use them just because we have ATAs devices that don?t
support NAT etc etc.
When a user presses the reset button, it resets the device and configure it
with a standard configuration which let the user to have Telephone (VoIP),
Internet, Wifi and we can Access remotely to reconfigure it as I said
before.
On BB 14.07 I?ve just modified 2 files:
./package/base-files/files/lib/functions/uci-defaults.sh
??.
ucidef_add_switch() {
local name=$1
local reset=$2
local enable=$3
uci batch <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] Question about custom script at init on Trunk.-
On Wed, 27 Jan 2016, Karl Palsson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Schultz wrote: Guillermo, It's always best to use a custom package if you can. Modifying upstream leads to problems like this. I don't think you'd need those changes in uci-defaults.sh. Instead, I think you should put your changes in your own uci-default, like 02_network, but your own. Use a number after 02, like 03_custom and put it in /etc/uci-defaults. It should run on first boot. As long as this uci-default script completes successfully, I think the change should occur and the script itself should be deleted so it doesn't run again. Along these lines, I've tried putting in something like 80_mystuff, where I want to set some configurations options for various packages that depend on the hardware they're running on. However, the uci-defaults files are run in alphabetical order, so while 80_mystuff might come after the 01_leds, 02_network stuff from core OpenWrt, the uci-defaults files from packages normally don't seem to have a numerical prefix. This then means that my 80_mystuff script tries to set a config option in a file that doesn't exist yet. Now, yes, I can have my 80_mystuff script go and try and create the package config files it might want to modify, but really, I want "mystuff" to run _last_ or at least, after all the packages have run. Is there any better system for this other than just naming my script z_mystuff instead of 80_mystuff? Is that expected to be "good enough" ? I'm trying this, because I've _been_ trying to use packages instead of modifying upstream, but when I want my package to do different things for different targets, it's seemed easier to hook into the existing target code, rather than trying to copy target detection and config into a package Config.in options typically people use 99stuff and figure that the order of 99s doesn't really matter much the other thing is that I believe that rc.local gets run out of the very last of the numbered items, so you can put stuff there. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Question about custom script at init on Trunk.-
On Wed, 27 Jan 2016, Karl Palsson wrote: Along these lines, I've tried putting in something like 80_mystuff, where I want to set some configurations options for various packages that depend on the hardware they're running on. However, the uci-defaults files are run in alphabetical order, so while 80_mystuff might come after the 01_leds, 02_network stuff from core OpenWrt, the uci-defaults files from packages normally don't seem to have a numerical prefix. This then means that my 80_mystuff script tries to set a config option in a file that doesn't exist yet. Now, yes, I can have my 80_mystuff script go and try and create the package config files it might want to modify, but really, I want "mystuff" to run _last_ or at least, after all the packages have run. Is there any better system for this other than just naming my script z_mystuff instead of 80_mystuff? Is that expected to be "good enough" ? what I do is to flash the base image on a device, and then tweak it until I get things working and then create a new image including that file. If I need different versions for different devices, I work on each one separately and then figure a way to detect the different conditions. Another example from Scale, We use Raspberry Pi computers to run self-service registration stations and to provide digital signs when connected to large TVs. I use a single image that checks to see if it has a mouse attached, if so it's a registration station, otherwise it's a sign and then the appropriate thing gets launched. you can use IP addresses/ranges, DHCP parameters, holding a button, or many other things to detect the different conditions. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Question about custom script at init on Trunk.-
On Wed, 27 Jan 2016, Karl Palsson wrote: David Lang wrote: Now, yes, I can have my 80_mystuff script go and try and create the package config files it might want to modify, but really, I want "mystuff" to run _last_ or at least, after all the packages have run. Is there any better system for this other than just naming my script z_mystuff instead of 80_mystuff? Is that expected to be "good enough" ? I'm trying this, because I've _been_ trying to use packages instead of modifying upstream, but when I want my package to do different things for different targets, it's seemed easier to hook into the existing target code, rather than trying to copy target detection and config into a package Config.in options typically people use 99stuff and figure that the order of 99s doesn't really matter much Well, the thing is, 99 isn't last. that's what I was getting at. $ ls -l build_dir/target-mips_34kc_uClibc-0.9.33.2/root-ar71xx/etc/uci-defaults/ total 140 - -rw-r--r-- 1 karlp karlp 128 Jan 26 13:32 00_uhttpd_ubus - -rwxrwxr-x 1 karlp karlp 17158 Jan 20 17:20 01_leds -rwxrwxr-x 1 karlp karlp 10391 Jan 20 17:22 02_network -rwxrwxr-x 1 karlp karlp 1673 Sep 25 11:01 03_network-switchX-migration -rwxrwxr-x 1 karlp karlp 351 Sep 25 11:01 03_network-vlan-migration -rwxrwxr-x 1 karlp karlp 1244 Sep 25 11:01 04_led_migration -rwxrwxr-x 1 karlp karlp 232 Sep 25 11:01 09_fix-seama-header -rw-rw-r-- 1 karlp karlp 193 Sep 25 11:01 09_fix-trx-header -rw-r--r-- 1 karlp karlp 74 Jan 27 10:56 10-fstab -rw-rw-r-- 1 karlp karlp 418 Sep 25 11:01 10_migrate-shadow -rw-rw-r-- 1 karlp karlp 450 Sep 25 11:01 11_migrate-sysctl -rw-rw-r-- 1 karlp karlp 377 Sep 25 11:01 12_network-generate-ula -rw-rw-r-- 1 karlp karlp 377 Sep 25 11:01 99_stuff_here -rw-rw-r-- 1 karlp karlp 211 Aug 21 12:40 agent_etactica -rwxr-xr-x 1 karlp karlp 83 Jan 11 15:05 luci-i18n-english -rwxr-xr-x 1 karlp karlp 1285 Jan 26 13:33 mosquitto.uci-defaults -rw-rw-r-- 1 karlp karlp 479 Aug 21 12:40 mpacker -rwxrwxr-x 1 karlp karlp 291 Aug 21 12:40 mq_delta_gadget - -rwxrwxr-x 1 karlp karlp 970 Aug 21 12:40 mrelay -rwxr-xr-x 1 karlp karlp 300 Jan 26 13:29 odhcpd.defaults -rwxrwxr-x 1 karlp karlp 224 Sep 24 14:24 snmpd badly wrapped. Here's what you really have in a new image. Putting things in "99_stuff" just won't work very well. All the package provided uci-defaults files, which are the ones I want to extend/augment with my own files have to come later. They are run at /etc/rc.d/S10boot, S99_whatever will run after S10_whatever. The S## files are run at startup, in order and the K## files are run at shutdown in reverse order (since shutdown can sometimes require different ordering than startup. If something is in there with just ## I'm not sure if they are even run. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Question about custom script at init on Trunk.-
On Wed, 27 Jan 2016, Karl Palsson wrote: I think you may have misunderstood. S10_boot runs the files in /etc/uci-defaults/* The files in _/etc/uci-defaults/_ do not all start with a numerical prefix, and are provided by any and all package that has any config it wants to run. So, for a _package_ that wants to do something "late" to do any sort of special target configuration, such as changing serial ports or mount points for an application based on the hardware it's running on, anything like 99-xxx is not going to reliably be late at all. Naming your uci-defaults file something like z999-something will probably work, but it's pretty gross. If you instead try and add your own _init_ script, with a START=99, you now don't even run until the applications whose config you want to adjust have already attempted startup, at whatever START=xx tag they have in their own provided init script. So, /etc/uci-defaults/z999-something works, but is there a better way? why do you have to change the files from something in uci-defaults? can't you just put the corrected configs in the image (most of them are scripts, so you can add the needed smarts to them to have them pull in variables from elsewhere) you can run a S01 script in init.d (or something late enough to work, early enough to run before whatever you need to change) and have it populate the variables that other things will use. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
It's not unusual for developers who disagree with project management issues to fork a project. I am also interested in who is left in OpenWRT and what their viewpoint is. Have the developers who are founding LEDE given up their commit privileges in OpenWRT? or are they going to be workting a bit in both for a while? It will take time to see what effect this is really going to end up having. It could be a permanent fork, it could be a replacement for OpenWRT, it could be a dead end, and it could be something that ends up merging back in later. It's clear that the issues are management, not technical. David Lang On Wed, 4 May 2016, Luiz Angelo Daros de Luca wrote: It is really strange that the decision to create a new project was so opaque when it was motivated to be a more "transparent project". They could've started to be more transparent already with the decision to create a new project. Maybe the answer for the need of an external reboot might be not in the names that jumped into but on those left behind. Maybe it was easier to create a new project than to boot out the problems. My 2 cents, Em qua, 4 de mai de 2016 às 14:50, Roman Yeryomin escreveu: On 4 May 2016 at 19:25, Kathy Giori wrote: On Tue, May 3, 2016 at 10:59 AM, Jo-Philipp Wich wrote: Hi, we'd like to introduce LEDE, a reboot of the OpenWrt community . The project is founded as a spin-off of the OpenWrt project and shares many of the same goals. While I appreciate the enthusiasm, I do not see why you cannot apply these same "principles" of openness and transparency to the OpenWrt project. Makes no sense to me to branch the project. That simply divides the resources in the community into fewer numbers working on each fork. Exactly, tearing down the project and community without any real explanations (and plans to solve the stated issues) is just wrong. Also wearing my hat within the prpl Foundation, which is funded by industry sponsorships that in turn provides financial support for OpenWrt, no one I have spoken to in prpl understands the reason for this spin-off either. It'll cause more confusion and inefficiency in industry. prpl will stick with OpenWrt, and I expect most companies who follow and/or contribute to OpenWrt will stick with it too. kathy ___ 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] Introducing the LEDE project
On Thu, 5 May 2016, Carlos Ferreira wrote: I don't see the end of OpenWRT as a bad thing. If LEDE is basically a fork but without the development bottlenecks that seem to be affecting OpenwRT, then the change can be easily done by the industry segment that uses OpenWRT for their products. In fact, I see it as a good thing because it means that there are developers who care about the future of such embedded development environment. The loss of brand recognition is a bad thing (see LibreOffice vs OpenOffice for example) but that said, this doesn't have to be permanent (see egcs vs gcc for example) David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Calmer heads than mine...
I also think that it is utterly unreasonable to think that the differences are going to be resolved in the next few days/weeks. It took years to get to this point, and there are some very significant differences of opinion. There is going to need to be time for one side or the other to be proven right/wrong on various issues, and that is only going to happen with months/years of producing and maintaining the codebases. The licenses allow both projects to pull from the other, so most of the hard technical work will end up being shared in practice. The infrastructure and organizational work is a duplication of effort, but since that's where there is a lot of disagreement over the best way to do things, I think this is useful duplication, let time show which elements of each team's ideas work well. I think the key thing right now is to keep the split from becoming toxic the way it sometimes has with other projects. If people can calm down enough to let the split become reasonably friendly, then I think a merge in a year or two would be a real possibility, with the resulting organization being stronger for trying the different approaches. I was surprised and bothered by the extent of the posts announcing LEDE on so many different openwrt mailing lists and forum threads, and I was bothered by the OpenWRT response of shutting off the e-mail. The LEDE people still maintain some of the OpenWRT infrastructure and have said that they are willing to keep doing so. So now that both sides have stepped on each other's toes, can everyone take a deep breath and look forward. OpenWRT needs to fill holes left by the departing people, and think about what truth there is in their complaints, and plan how to deal with them while still maintaining progress. LEDE needs to get infrastructure setup, make a release, and show that they can maintain it and respond to bug reports. Let's let everyone get to work rather than defending themselves or lashing out at the other side, and see how things go over the next several months. David Lang On Thu, 5 May 2016, Daniel Dickinson wrote: Hi all, Sorry for sounding off so much yet again. I've been trying to interpret events with a severe lack of information and have unfavourable guesses and impressions that may or may not be accurate. I do know that some of the developers have a history of not getting along, and that has hurt the project. I also know that there are members of both sides who are frustratingly obstinate and/or antagonistic or downright nasty to people they disagree with. Which is why I'm not sure this rift can be healed. I think it would be good if the saner elements (which is not me; I'm not on either side and I'm too impetuous and ready to make noise) who I think are the majority from both sides would communicate and come to an agreement that they imposed on the less reasonable elements of the groups they are currently part of. I think the calmer elements have gotten caught up in or the other of the less reasonable types battles, and that if the calmer elements could get it together it would benefit the community as a whole Regards, Daniel ___ 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] Introducing the LEDE project
You may be right that OpenWRT is doomed, but we have seen time and time again that OpenSource software is not a zero-sum game. Yes, if OpenWRT does nothing, it will struggle, but that's unlikely to be the case. For that matter, even with no new manpower, OpenWRT could just copy everything that LEDE does and still survive for a long time based on brand recognition (after all, people are still downloading OpenOffice, and that hasn't even been pulling improvements from LibreOffice) There's no question that there is going to be disruption and a loss of progress in the short term, but before you count either side out, let them stabilize, and figure out what's really important to them going forward. Revisit the question in 6-9 months and things will probably be much clearer. Remember that the remaining OpenWRT folks haven't has weeks or months to plan what to do at this point. It will take them time for them to figure out what's going to end up happening. In the short term, they have to plug the holes and figure out if anything critical needs to be done to keep the lights on. Only after they are able to get past this short term crisis will they be able to really think about the larger issues and figure out what to do about them. And the LEDE folks have a lot of infrastructure to setup (and there will be a lot of bikeshedding going on while they do this), so they are going to take some time to get everything going and get a release out. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On Mon, 16 May 2016, Roman Yeryomin wrote: On 6 May 2016 at 22:43, Dave Taht wrote: On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin wrote: On 6 May 2016 at 21:43, Roman Yeryomin wrote: On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote: That is too low a limit, also, for normal use. And: for the purpose of this particular UDP test, flows 16 is ok, but not ideal. I played with different combinations, it doesn't make any (significant) difference: 20-30Mbps, not more. What numbers would you propose? How many different flows did you have going at once? I believe that the reason for higher numbers isn't for throughput, but to allow for more flows to be isolated from each other. If you have too few buckets, different flows will end up being combined into one bucket so that one will affect the other more. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On Mon, 16 May 2016, Roman Yeryomin wrote: On 16 May 2016 at 11:12, David Lang wrote: On Mon, 16 May 2016, Roman Yeryomin wrote: On 6 May 2016 at 22:43, Dave Taht wrote: On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin wrote: On 6 May 2016 at 21:43, Roman Yeryomin wrote: On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote: That is too low a limit, also, for normal use. And: for the purpose of this particular UDP test, flows 16 is ok, but not ideal. I played with different combinations, it doesn't make any (significant) difference: 20-30Mbps, not more. What numbers would you propose? How many different flows did you have going at once? I believe that the reason for higher numbers isn't for throughput, but to allow for more flows to be isolated from each other. If you have too few buckets, different flows will end up being combined into one bucket so that one will affect the other more. I'm testing with one flow, I never saw bigger performance with more flows (e.g. -P8 to iperf3). The issue isn't performance, it's isolating a DNS request from a VoIP flow from a streaming video flow from a DVD image download. The question is how many buckets do you need to have to isolate these in practice? it depends how many flows you have. The default was 1024 buckets, but got changed to 128 for low memory devices, and that lower value got made into the default, even for devices with lots of memory. I'm wondering if instead of trying to size this based on device memory, can it be resizable on the fly and grow if too many flows/collisions are detected? David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH] busybox: sysntpd - Support for NTP servers received via DHCP(v6)
On Fri, 20 May 2016, Jo-Philipp Wich wrote: Hi Hans, I wanted to preserve the ntp server behavior and only change the behavior when configured in order to keep backwards compatibility. You favour enabling DHCP ntp server config without explicit config ? Personally I do because thats likely what most users expect, but then trusting foreign NTP server advertisements might be a security sensitive topic - on the other hand one trusts the default gateway and DNS advertisements too, so I don't know. NTP isn't signed. If I can control your DNS, I can probably control your NTP by giving you the wrong IP for the NTP server If I can control your gateway, I can redirect all your NTP queries to someone else (NAT, redirects, etc) so why not trust the NTP server being provided? David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub
On Tue, 24 May 2016, Luka Perkov wrote: Date: Tue, 24 May 2016 16:06:13 +0200 From: Luka Perkov To: openwrt-devel@lists.openwrt.org, openwrt-us...@lists.openwrt.org Subject: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub Dear OpenWrt mailing list readers, as the subject says I'd like to make proposal to move the OpenWrt codebase to Git. This was already discussed before [1] and now when there are no blockers [2] for this change I'd like that we as a community move forward with this switch. Also, I'd like to propose that we move the project to GitHub and here are the reasons why I see this as a good decision: * GitHub will allow people to contribute more easily The bigger amount of contributions has already happened and can be seen on the packages feed which is already hosted on GitHub. With this I'm also hoping to avoid comments regarding invalid patches on the mailing list. For now I am proposing that the current development workflow is also accepted - aka. patches that are sent to the mailing list are also accepted. OpenWRT has already moved to using Git instead of SVN, so why do they need to move from hosting the git repository themselves to having it hosted on github? There can be a mirror of the repo on github (remember that git is a Decentralized VCS) * GitHub and similar services will allow us to integrate more easily with other projects Here specifically I mean integration with modern CI. Here is an example of integration with drone.io [3][4]. At the moment this is only in the POC stage but what I'd like to do down the line is to: - build OpenWrt images for all architectures for every pull request - build OpenWrt package binary for every package pull request for all architectures and make it available for download - build and host OpenWrt qemu and/or Docker image for every pull request the build farm isn't large enough to do this It's also not neccessary to move to github to be able to do this, it just needs more systems in the build farm to be able to build things fast enough. This will allow easy review of the work since flags will be shown in the pull request if the build was sucessful or not. Also, this will allow people to test changes without building the image and thus lowering the time that needs to be spent on maintenance work. If this proposal gets accepted I'll be sending out an email to get access to more build servers so this new build infrastructure can properly support the project in a timely fashion. why should providing more build servers be contingent on moving to a commercial hosting provider vs running things themselves? David Lang Please share your thoughts regarding this proposal. Regards, Luka [1] https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html [2] https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041329.html [3] https://github.com/makkrnic/openwrt-qemu-x86 [4] http://sartura-drone.makkrnic.com/makkrnic/openwrt-qemu-x86/5 ___ 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] [LEDE-DEV] TR-069 for OpenWrt
On Thu, 26 May 2016, Delbar Jos wrote: We are conscious of the fact that together with the proposals made by Felix, Luka and Wojtek we are now looking at many "competing" proposals. As a next step, we recommend to organize a workshop, at a practical location and time, where we put everything on the table and define the most appropriate path forward to the benefit of OpenWrt as a whole. nothing wrong with supporting many different remote management daemons. TR-069 is a complicated remote management system and in order to make this initiative a success, we must ensure that the complexity is handled in an elegant way and with respect for OpenWrt's core architecture. More than on the protocol itself, we believe that we should focus on the architectural enhancements required to support remote management in general. What is it that you think is needed to "support remote management in general"? It's worth pointing out that many people are remotely managing OpenWRT devices, Ansible/Salt/Puppet/Chef/etc are all common tools for the job. now, those are all tools aimed at managing Linux Servers, not networking gear, but OpenWRT is a server. So I'd suggest starting off by creating a daemon that talks and just stores the stuff it's sent in some simple files so that it can return the info when queried. Once you have something that talks the network protocol correctly, modifying it to change the real files, make uci calls, etc for different distros is much easier (just write your daemon with the expectation that the input and output details are going to change, so don't get fancy with them). David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] TR-069 for OpenWrt
On Sat, 28 May 2016, Hauke Mehrtens wrote: On 05/27/2016 12:43 PM, David Lang wrote: On Thu, 26 May 2016, Delbar Jos wrote: We are conscious of the fact that together with the proposals made by Felix, Luka and Wojtek we are now looking at many "competing" proposals. As a next step, we recommend to organize a workshop, at a practical location and time, where we put everything on the table and define the most appropriate path forward to the benefit of OpenWrt as a whole. nothing wrong with supporting many different remote management daemons. TR-069 is a complicated remote management system and in order to make this initiative a success, we must ensure that the complexity is handled in an elegant way and with respect for OpenWrt's core architecture. More than on the protocol itself, we believe that we should focus on the architectural enhancements required to support remote management in general. What is it that you think is needed to "support remote management in general"? It's worth pointing out that many people are remotely managing OpenWRT devices, Ansible/Salt/Puppet/Chef/etc are all common tools for the job. now, those are all tools aimed at managing Linux Servers, not networking gear, but OpenWRT is a server. So I'd suggest starting off by creating a daemon that talks and just stores the stuff it's sent in some simple files so that it can return the info when queried. Once you have something that talks the network protocol correctly, modifying it to change the real files, make uci calls, etc for different distros is much easier (just write your daemon with the expectation that the input and output details are going to change, so don't get fancy with them). David Lang The TR-069 family is currently wildly used by ISPs controlling the (DSL) CPE devices of their customers. There are probably more than 100 million device controlled by standards from the TR-069 family out there. When you get a DSL router from your ISP or buy one in the retail store it is very likely it supports the standards from the TR-069 family, as a vendor in this area you basically need support for this to sell your devices. I wasn't questioning why it's useful to support TR-069. The only part I was questioning was the statement that OpenWRT needed work to make it support remote management. There are already many tools to remotely manage/monitor OpenWRT But that's why I'm saying that it seems like most of the work is in the protocol interface. If there is already a daemon that does the network protocol properly, that should make things very easy. If such a daemon needs to be written, that would be the place I would suggest that they focus. There are a lot of people who can do the plumbing work to make the daemon do the right thing on the system, who are not in a position to work on the network protocol side and make sure that it works properly with the management software. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Response to LEDE proposal/queries/mail?
On Tue, 7 Jun 2016, Eric Schultz wrote: Zoltan, I'm pleased to hear there's been some movement. Does this mean that OpenWrt is going to have releases while LEDE will not? Considering that LEDE folks recently posted a "what's blocking the release" message, this would be extremely unlikely. I am very interested in seeing what OpenWRT is going to be doing next. I hope that it's more than just pulling patches from LEDE. That's a perfectly legitimate thing to do, but would be rather limiting in what value OpenWRT would be providing. And if it is the viewpoint of OpenWRT that LEDE is an experimental testbed (the way that Fedora is seen as a testbed for RHEL), then people should not be told to go away if a lede question is posted on the OpenWRT forums (something I've seen a few times so far) David Lang Eric On Tue, Jun 7, 2016 at 7:42 AM, Zoltan HERPAI wrote: Daniel Dickinson wrote: Hi, I had a few emails on this topic I thought better of sending, but I'm sure I'm not the only one wondering why the remaining OpenWrt devs have not responded to the various LEDE overtures on this mailing list. Is it lack of time, an unwillingness to attempt to have an honest and reasonable dialogue in public, or something else? I admit that for all the furor over the fork, and complaints about LEDE lack of transparency in the fork, I'm seeing a lot more communication from LEDE than from the remaining devs, and am left to guess the reasons why (although with my mechanism to help me avoid bad emails, I don't give voice to my tendency to the less than generous suspicions, now). Hi Daniel, May I ask you to point to which e-mail are you referring to? We are yet to see an official line from LEDE on what they want to see to happen in OpenWrt (setting aside the FUD some LEDE members have shown on the list). The IRC discussion did not happen due to being unable to work out the timezone differences, the conversation on the mailing list did not move forward - this is obviously an issue on our side as well. The official line - which I should have sent out a few days ago - from the OpenWrt team is: Felix's initial comment was LEDE to become a "development environment" for new ideas, and to keep OpenWrt as the standard distro. We have stayed away from committing to OpenWrt trunk to keep a clean sheet according to this, to let LEDE members cleanly and easily merge their changes. (Apologies to all contributors for not pushing their patches so far). Luka - as no objections but only praises were received - plans to do the proposed github move later this week, which will help with the workflow for contributors. What we would like is to: - Ask the LEDE members currently maintaining targets to update their targets, - Ask the LEDE members to tell us about terms and wishes for reunite. Currently there is no official word from LEDE on this, which is quite confusing. We will start merging the pending patches in patchwork this week to get trunk back into a healthy state while discussions are underway. LEDE patches will also be brought in where appropriate. Regards, The OpenWrt team ___ 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] [RFD] Future
having a release every 2-3 years when APs have a life of ~18 months means that nobody is ever going to be able to run a release on something they can buy in the store. even releases every year is too slow. Other than not releasing as frequently, and not updating to current kernels, what other things do you think the Devs should not be doing? and what do you think about the items that the LEDE Devs said were a problem? David Lang On Thu, 30 Jun 2016, Tom Psyborg wrote: Looks like a common problem is when devs get paid well, they are coming up with more and more problems, ideas to solve these and waste too much time on unnecessary things. If you only used the time invested in organizing of all these meet-ups to commit all the patches sent to mailing list that were not applied due to various reasons (from my example they were created manually using diff) it would make the project more easier to handle and easier to focus on important things. You have Chaos Calmer stable release that is not really that stable, trunk on kernel 4.xx containing many bugs, bunch of hardware that is not fully supported yet etc. Instead of forcing "stable" releases every year you should have kept the old way of development, even if it took 2-3 years to accomplish that, but then provide support and updates for this stable release during next few years. Forcing endless kernel updates leaves no room for detailed testing, not to mention usage of the built firmware and from my perspective this makes the overall project lose it's popularity which results in less discovered bugs, sent and especially committed patches, people active on dev board and more spam. On 29 June 2016 at 23:23, Felix Fietkau wrote: On 2016-06-29 17:02, Jo-Philipp Wich wrote: Hi Imre, can you provide a summary of the discussion? Imre's mail is pretty much a summary of the discussion that we had. We got along nicely and decided that to really resolve our issues we do need a proper face to face meeting. IRC/E-Mail just doesn't have the necessary bandwidth for it, and I'm not sure if Google Hangout is a solution either. - Felix ___ 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] SVN to GIT transition
On Mon, 12 Oct 2015, Felix Fietkau wrote: On 2015-10-12 16:11, Roman Yeryomin wrote: On 12 October 2015 at 16:34, Felix Fietkau wrote: On 2015-10-12 15:09, Javier Domingo Cansino wrote: Right now, the revision number (r) is really useful to figure out what particular openwrt version is being used, when people report bugs. The commit hash cannot be used as a replacement, since it might be one that isn't present in the official repo. When using tags as a starting point (via git describe), somebody has to create those tags, which is cumbersome (and would mean adding lots of useless ones). The tags would be the major versions and RCs. I don't believe other tags should be used. Apart from that, I understand that if someone cloned the SVN repo (full svn history), created it's own server, and developed on top of a given revision X, the same problem would arise. I haven't seen a single instance of somebody doing this, and in my opinion it would be kind of stupid anyway :) We don't even advertise the SVN server URL to users anymore for a reason. IMO git describe --dirty would work perfectly. You would see a short hash and if user modified it or not. If the user made a local commit, the short hash becomes useless. if the user does a SVN checkout and then modifies things, the r is also not valid (although it does give you an idea where things branched) David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On Mon, 12 Oct 2015, Jonathan Bennett wrote: His point is that users don't ever do an SVN checkout. Because the r number is baked into the image, it's a really easy and obvious way for an end user to report the revision in a bug report. I can see the advantage in this. If we are to move to git, we would want some way to preserve this feature, that is a super easy way for a user to report the revision. We could bake the short hash into the image, but this would not be useful if any commits were added locally, whereas the r number would still show some useful information. Would it be possible to track the revision number in an automated way even in a git repo? So store the r number, and automatically increment on commits. Not sure if that's an option, but it seems like it might address the problem. It sounds like what you really want to do is to have the nightly build embed the date of the build in the image and have people report that. If someone checks out the source and compiles a new copy (with local modifications), reporting a SVN version is as misleading as a git hash. I know that various projects I work with have the build process embed the date in the package versions, so it should be straightforward to put it into some file in the resulting firmware image. Such a process can also check if it's running on the 'official' tree or in someone else's repo (check repo owner/e-mail) and add the initials of the person compiling it. then something like the -dirty info that was mentioned earlier could also be embedded to show the development since it branched from the main OpenWRT repo. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On Mon, 12 Oct 2015, Felix Fietkau wrote: On 2015-10-12 22:06, David Lang wrote: On Mon, 12 Oct 2015, Jonathan Bennett wrote: His point is that users don't ever do an SVN checkout. Because the r number is baked into the image, it's a really easy and obvious way for an end user to report the revision in a bug report. I can see the advantage in this. If we are to move to git, we would want some way to preserve this feature, that is a super easy way for a user to report the revision. We could bake the short hash into the image, but this would not be useful if any commits were added locally, whereas the r number would still show some useful information. Would it be possible to track the revision number in an automated way even in a git repo? So store the r number, and automatically increment on commits. Not sure if that's an option, but it seems like it might address the problem. It sounds like what you really want to do is to have the nightly build embed the date of the build in the image and have people report that. Many people build from source and don't use nightly builds. If someone checks out the source and compiles a new copy (with local modifications), reporting a SVN version is as misleading as a git hash. It may not always be accurate, but the SVN version is actually useful in most cases, even when modifications are present. I know that various projects I work with have the build process embed the date in the package versions, so it should be straightforward to put it into some file in the resulting firmware image. Such a process can also check if it's running on the 'official' tree or in someone else's repo (check repo owner/e-mail) and add the initials of the person compiling it. What I don't understand is how the script should check if something is the official tree, e.g. in the simple case of somebody having forked the OpenWrt mirror on github, cloned it locally, added and pushed a few commits and then made a build. git config --get user.name git config --get user.email if they are set to the name of the official buildbot, no nothing. If they are set to anything else, take some data (initials or something) and make that part of the version number. It's not checking if it's an unmodified tree, just if it's being built on the OpenWRT infrastructure. If someone is building an unmodified tree, the git hash will work for identifying what tree it is. And someone else posted a process for trackign divergence from the upstream tree if they are modifying it first. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On Mon, 12 Oct 2015, Felix Fietkau wrote: On 2015-10-12 22:02, Javier Domingo Cansino wrote: Would it be possible to track the revision number in an automated way even in a git repo? So store the r number, and automatically increment on commits. Not sure if that's an option, but it seems like it might address the problem. In git you wouldn't need such thing, the way would be to track the forking point comparing the user history with the upstream master history, and describing the path. The oneliner I sent before (which I now realize I split in two), did (or will do) the following. 1) Go back in history and find the latest tag, save it as $tag We currently don't have any tags for mainline trunk, since we usually don't directly release from it. I would put a nightly tag in place (tags are pretty cheap) 2) Find the forking point between upstream and user branch if any, save current commit if not such fork exists as $parent. How does the script know which one is the right upstream? git knows where it was cloned from, so it knows what upstream is for any local branch. 3) count how many commits are from $tag commit to $parent commit, save it as $parent_n 3) If fork exists, count how many commits from $parent to HEAD, save it as $commit_n 4) If tree is dirty, save $dirty='-dirty', else $dirty='' compose the build version info as the following: $tag-$parent_n-$parent-$commit_n-$parent$dirty If I see such a string, how do I look up the last OpenWrt commit from that? With the revision number, I simply start git log and search for @ if you make a nightly/weekly tag it becomes trivial to lookup. you can also use the first 6/8 characters of the git commit and look that up (or git log 12345678..HEAD to show everything between that commit and the current head) David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On Mon, 12 Oct 2015, Felix Fietkau wrote: On 2015-10-12 22:28, David Lang wrote: On Mon, 12 Oct 2015, Felix Fietkau wrote: On 2015-10-12 22:02, Javier Domingo Cansino wrote: Would it be possible to track the revision number in an automated way even in a git repo? So store the r number, and automatically increment on commits. Not sure if that's an option, but it seems like it might address the problem. In git you wouldn't need such thing, the way would be to track the forking point comparing the user history with the upstream master history, and describing the path. The oneliner I sent before (which I now realize I split in two), did (or will do) the following. 1) Go back in history and find the latest tag, save it as $tag We currently don't have any tags for mainline trunk, since we usually don't directly release from it. I would put a nightly tag in place (tags are pretty cheap) Sounds nasty. why? 2) Find the forking point between upstream and user branch if any, save current commit if not such fork exists as $parent. How does the script know which one is the right upstream? git knows where it was cloned from, so it knows what upstream is for any local branch. Yeah, but where it was cloned from might not be OpenWrt upstream. true, but if you work from tags, it can just look for the difference since the most recent tag (or even the most recent tag that matches a specific pattern) 3) count how many commits are from $tag commit to $parent commit, save it as $parent_n 3) If fork exists, count how many commits from $parent to HEAD, save it as $commit_n 4) If tree is dirty, save $dirty='-dirty', else $dirty='' compose the build version info as the following: $tag-$parent_n-$parent-$commit_n-$parent$dirty If I see such a string, how do I look up the last OpenWrt commit from that? With the revision number, I simply start git log and search for @ if you make a nightly/weekly tag it becomes trivial to lookup. you can also use the first 6/8 characters of the git commit and look that up (or git log 12345678..HEAD to show everything between that commit and the current head) The lookup only works if the tags were carried over as well. Not sure if that's the case when somebody does a github fork of the mirror repo. tags are carried over in just about all cases (github does so by default, while there are manual ways to not get them, that will cause people other problems), commit hashes are an intrinsic part of the repo. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On Mon, 12 Oct 2015, Felix Fietkau wrote: If someone checks out the source and compiles a new copy (with local modifications), reporting a SVN version is as misleading as a git hash. It may not always be accurate, but the SVN version is actually useful in most cases, even when modifications are present. I know that various projects I work with have the build process embed the date in the package versions, so it should be straightforward to put it into some file in the resulting firmware image. Such a process can also check if it's running on the 'official' tree or in someone else's repo (check repo owner/e-mail) and add the initials of the person compiling it. What I don't understand is how the script should check if something is the official tree, e.g. in the simple case of somebody having forked the OpenWrt mirror on github, cloned it locally, added and pushed a few commits and then made a build. git config --get user.name git config --get user.email if they are set to the name of the official buildbot, no nothing. If they are set to anything else, take some data (initials or something) and make that part of the version number. It's not checking if it's an unmodified tree, just if it's being built on the OpenWRT infrastructure. If someone is building an unmodified tree, the git hash will work for identifying what tree it is. And someone else posted a process for trackign divergence from the upstream tree if they are modifying it first. I still have doubts about that process. And why should the version info be treated differently if things are built on the official infrastructure? just in the interests of keeping it short. With git all repos are technically equal. It's project convention as to which one is the upstream master. If you have such a convention, why not use it to make the tags that everyone has to deal with shorter then when you are dealing with someone building a branch that needs more description anyway? shrug, it's a nice-to-do, not a requirement. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On Mon, 12 Oct 2015, Felix Fietkau wrote: On 2015-10-12 22:36, David Lang wrote: On Mon, 12 Oct 2015, Felix Fietkau wrote: On 2015-10-12 22:28, David Lang wrote: On Mon, 12 Oct 2015, Felix Fietkau wrote: On 2015-10-12 22:02, Javier Domingo Cansino wrote: Would it be possible to track the revision number in an automated way even in a git repo? So store the r number, and automatically increment on commits. Not sure if that's an option, but it seems like it might address the problem. In git you wouldn't need such thing, the way would be to track the forking point comparing the user history with the upstream master history, and describing the path. The oneliner I sent before (which I now realize I split in two), did (or will do) the following. 1) Go back in history and find the latest tag, save it as $tag We currently don't have any tags for mainline trunk, since we usually don't directly release from it. I would put a nightly tag in place (tags are pretty cheap) Sounds nasty. why? If we want to tag minor releases, the real release tags get hidden behind an ever growing amount of auto-generated tag spam. If you tag weekly there aren't that many tags, and you can give the auto-weekly tags a different format than releases v15.05 release a15.40 weekly tag for week 40 of 2015 these will even sort so the auto tags will scroll off the top and what you care about will be at the end of the list :-) David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On Tue, 13 Oct 2015, Roman Yeryomin wrote: Would it be possible to track the revision number in an automated way even in a git repo? So store the r number, and automatically increment on commits. Not sure if that's an option, but it seems like it might address the problem. If a user is smart enough to commit something locally then he knows what he is doing and is smart enough to report the changes he made. It's so simple. I think the concern is that someone may do this and then make the resulting images available to others to install. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On Wed, 14 Oct 2015, Roman Yeryomin wrote: On 13 October 2015 at 23:08, David Lang wrote: On Tue, 13 Oct 2015, Roman Yeryomin wrote: Would it be possible to track the revision number in an automated way even in a git repo? So store the r number, and automatically increment on commits. Not sure if that's an option, but it seems like it might address the problem. If a user is smart enough to commit something locally then he knows what he is doing and is smart enough to report the changes he made. It's so simple. I think the concern is that someone may do this and then make the resulting images available to others to install. Someone can do this (change the revision) very easily now too (and this is good, because allows using internal revision numbers for custom fw builders), so there is no way you can protect from this (I would even say there is no point in protecting from this). I think it's a good idea to encourage other builders to have a unique id in there. That's why I was talking earlier about adding the initials of the builder to the version string. Even if they are compiling the same code, there are enough different ways to configure things that can cause problems that it's worth knowing if it's a stock build or a custom one. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt Roadmap
On Mon, 12 Nov 2018, Alberto Bursi wrote: I quite frankly don't believe it's worth allocating what limited manpower there is. While I'm not a OpenWrt developer and I don't speak on behalf of the project, I really believe that you are underestimating the effort required behind even a basic LTS release like a "only core packages" or such. I think that if translated into man-hours (and therefore money) it would amount to much higher than just letting devices go EOL and have people replace them. I think it would make far more sense to see if it is possible to define a more minimalistic build that will work on these lower spec devices. Possibly talk to the LUCI project and see if there is a way that you could have LUCI run in a VM on your desktop and access the configs on the router via SSH or something like that so that we can drop off the overhead of the large GUI on the small devices. Trying to backport 'critical fixes' to an old version (especially a version 3+ years old) is just not going to work. Even the "Enterprise" distros do a horrible job with that, and they have very large teams working to do so. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Is there a way I can restore balance to the force?
what happened with the in-person discussions in Berlin between the OpenWRT folks and the LEDE folks? David Lang On Tue, 25 Oct 2016, Sami Olmari wrote: Long time lurker here. I personally wish we'd get things rolling again nicely... I don't know what would be the ultimate doctorine for this, but I'd hate OpenWrt, or whatever the name would be, to die because opinion diffirences and personal argues etc... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Talks between OpenWrt and LEDE
On Wed, 21 Dec 2016, Kathy Giori wrote: From a PR perspective, I strongly suggest keeping the term OpenWrt as part of the branding of the project moving forward. It can just be cosmetic (web site, etc.) but the name has so much history, and positive connotation, that you don't want to lose that brand attached to the development moving forward. I agree, I think this is an obvious choice to make. OpenWRT has a lot of name recognition, it would be foolish to throw that away. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Talks between OpenWrt and LEDE
On Wed, 21 Dec 2016, Dave Taht wrote: On Wed, Dec 21, 2016 at 12:29 PM, David Lang wrote: On Wed, 21 Dec 2016, Kathy Giori wrote: From a PR perspective, I strongly suggest keeping the term OpenWrt as part of the branding of the project moving forward. It can just be cosmetic (web site, etc.) but the name has so much history, and positive connotation, that you don't want to lose that brand attached to the development moving forward. I agree, I think this is an obvious choice to make. OpenWRT has a lot of name recognition, it would be foolish to throw that away. Just to take the other side for rhetorical purposes, a purpose of a re-branding exercise is to show a change in the "product" or organisation behind it. OpenWrt is widely known... as a bleeding edge, sometimes unstable, somewhat hard to use 3rd party firmware. DD-Wrt and Tomato get a lot more press for some reason. So do things like Yocto. If lede were to succeed in meeting its other goals, coherently, preserving "lede" and moving forward as a separate project does make sense. I'll point out OpenOffice vs LibreOffice and the fact that years after development of OO has really stopped, people are still finding it and downloading it instead of LO (it's replacement) there's a lot of stuff out there pointing at OpenWRT, unless you are going to replace all the OpenWRT stuff with pointers to LEDE, you are better off taking advantage of the millions of references to OpenWRT. David Lang Yes, the name is pointing at a product that doesn't exist any longer, but Deb and Ian aren't involved with Debian any longer either. At some point the fact that a name is known matters far more than the historical reasons for the name. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Talks between OpenWrt and LEDE
On Wed, 21 Dec 2016, Stefan Monnier wrote: - While brands have value, you can change a name without losing all the brand recognition. I'm thinking here of cases like XBMC->Kodi or OpenOffice->LibreOffice. I would point at OpenOffice -> LibreOffice as a failure of name changes. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] Talks between OpenWrt and LEDE
On Thu, 22 Dec 2016, John Crispin wrote: Yes, the name is pointing at a product that doesn't exist any longer, but Deb and Ian aren't involved with Debian any longer either. At some point the fact that a name is known matters far more than the historical reasons for the name. a problem that can be solved by a http redirect ... Is that going to break all links in discussions that point at OpenWRT docs and/or forum threads? That's a high cost. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] Talks between OpenWrt and LEDE
On Thu, 22 Dec 2016, John Crispin wrote: On 22/12/2016 09:42, David Lang wrote: On Thu, 22 Dec 2016, John Crispin wrote: Yes, the name is pointing at a product that doesn't exist any longer, but Deb and Ian aren't involved with Debian any longer either. At some point the fact that a name is known matters far more than the historical reasons for the name. a problem that can be solved by a http redirect ... Is that going to break all links in discussions that point at OpenWRT docs and/or forum threads? That's a high cost. David Lang it is something worth considering if the alternative content is available and easy to look up and if we keep archives in ro mode of existing content. claiming that there is only one option and no alternatives is just not constructive and wont lead to a broad discussion during which we can find a consensus. sorry, I did not mean to imply there is only one option. I think there is a lot of value in the OpenWRT name and all the links around the web that refer to it. So there is a huge cost to going with a different name. IMHO, this makes it an easy decision to make, but not the only one possible. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Using kdump... persistent logs, etc. (Syrone Wong)
If you run into problems configuring rsyslog, we have a fairly active mailing list at rsyslog-users , or ask questions here and I'll be happy to answer them. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt and Open Compute Project (OCP)
On Tue, 2 May 2017, tapper wrote: Hi you should look at LEDE: https://lede-project.org/ The LEDE Project (“Linux Embedded Development Environment”) is a Linux operating system based on OpenWrt. It is a complete replacement for the vendor-supplied firmware of a wide range of wireless routers and non-network devices. More than that, all OpenWRT developers have commit access to LEDE and work is ongoing to re-merge the projects using the LEDE codebase (the OpenWRT devs are working to merge anything from the OpenWRT codebase that's missing in the LEDE codebase). Currently LEDE has about a year of development beyond the OpenWRT codebase. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt and lede - remerge proposal
On Thu, 11 May 2017, Martin Tippmann wrote: On Thu, May 11, 2017 at 5:27 PM, tapper wrote: On 11/05/2017 09:30, Matthias Schiffer wrote: The OpenWrt forum design looks a bit better than the landing page, but it still feels too heavy due to the colored backgrounds. Matthias One more thing about the LEDE forum is it is very hard to use with a screen reader where as the OpenWRT one is very good to use. For all blind people could we stick with the Openwrt forum but spruce it up a bit so it looks better for those of us that can see. Hi, the used Discourse Software sadly does not seem to make screen readers a priority :(, but they seem interested in feedback[0] Just an idea: Would NNTP Support help here? There seems to be a maintained plugin[1] and if that works well enough, access via any NNTP client or a simple site / forum like the dlang forum[3] that plays well with linux and screen readers might be an option. The LEDE forum lets you interact with it strictly via e-mail, while the openwrt forum only has 'something is new' notifications via e-mail David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] Remerge logo ideas
the vote on the name was held several months ago, please stop trying to re-do the vote just because it didn't come out the way you wanted it to. k ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Images are too big in LEDE but not in OpenWRT
two years of development means that lots of packages are larger. you will have to see fi there are config options for the packages that you are using that reduce their size I don't know what configuring limits would mean? not produce an image if it's too large? start leaving things out when it hits a limit? David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
I know that IPv6 designers pine for the "good old days" of the Internet when no security was needed. But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. As such, the idea that IPv6 would "restore" the "everyone can connect to everyone on any port" of the early '80s was wishful thinking at best. link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. There is no answer here that will satisfy everyone. But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. But that's not the world we live in. David Lang On Wed, 16 Jul 2014, Lyme Marionette wrote: - Original Message - On Wednesday, July 16, 2014 2:10:53 PM "Gui Iribarren" 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)
On Thu, 17 Jul 2014, Gui Iribarren wrote: On 17/07/14 21:03, David Lang wrote: I know that IPv6 designers pine for the "good old days" of the Internet when no security was needed. But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. As such, the idea that IPv6 would "restore" the "everyone can connect to everyone on any port" of the early '80s was wishful thinking at best. link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. There is no answer here that will satisfy everyone. But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? Hello, thanks for joining the conversation, you might have not spotted this email https://lists.openwrt.org/pipermail/openwrt-devel/2014-July/026813.html as it is now, the situation is actually the opposite of what you're describing, it's more like: "Hey, my VoIP calls are failing, as well as PopcornTime videos, since I installed OpenWRT. They were working just fine with stock TPLink firmware" Have you got any examples of stock firmware that blocks incoming traffic by default? In this discussion I have only seen talk of two that don't. Every IPv4 home router I have seen defaults to 'block all incoming, unless something on the inside opens it' If IPv6 routers end up being wide open, then we are going to start seeing people getting compromized and the analysis being that it was through IPv6 and it will get an (undeserved) reputation of being less secure than IPv4 just because stupid vendors are going to have their stuff exposed. We've seen worms specifically targeting printers in the past, what makes you think we aren't going to see things like that exploiting NAS devices, DNLA servers, thermostats, etc? You would be horrified to see what passes for security in the Internet of Things. A lot of that software makes me think of stuff from the '70s and early '80s. I've seen devices manufactured in 2012 that used 4 bits for the year (with the epoc being Jan 1 2010)!! The horror stories that you have heard about how insecure SCADA and other industrial devices are are not exaggerations, if anything they understate the problems. think about the early Internet protocols (SNMP and tFTP), and think about systems that make them look sane and perfectly reasonable. Exposing these systems to inbound connections from anywhere on the Internet is irresponsible. Now, if these devices make a connection out to phone home, allowing that home to reach back is reasonable, and supporting things like upnp to allow devices to specifically open up inbound connections are reasonable. I'm not saying that it needs to be as hard to configure as getting in through IPv4 NAT, but it should NOT be the 'open end-to-end Internet the way $DIETY intended' look at how easy it is to 'root' phones, where the company involved is at least reasonable competent in writing software. For a lot of the IoT devices, the Internet is a rushed, tacked on addition (they already needed a processor to manage something, so spend a few cents more and now they can advertise this mobile device app). Try using some of these apps and devices and see how horrific the software is. David Lang cheers! Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. But that's not the world we live in. David Lang On Wed, 16 Jul 2014, Lyme Marionette wrote: - Original Message - On Wednesday, July 16, 2014 2:10:53 PM "Gui Iribarren" 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
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
by the way, link local addresses are not going to be used for these devices, because they will all have some 'cloud' feature that will require they have a way to phone home. David Lang On Fri, 18 Jul 2014, David Lang wrote: Every IPv4 home router I have seen defaults to 'block all incoming, unless something on the inside opens it' If IPv6 routers end up being wide open, then we are going to start seeing people getting compromized and the analysis being that it was through IPv6 and it will get an (undeserved) reputation of being less secure than IPv4 just because stupid vendors are going to have their stuff exposed. We've seen worms specifically targeting printers in the past, what makes you think we aren't going to see things like that exploiting NAS devices, DNLA servers, thermostats, etc? You would be horrified to see what passes for security in the Internet of Things. A lot of that software makes me think of stuff from the '70s and early '80s. I've seen devices manufactured in 2012 that used 4 bits for the year (with the epoc being Jan 1 2010)!! The horror stories that you have heard about how insecure SCADA and other industrial devices are are not exaggerations, if anything they understate the problems. think about the early Internet protocols (SNMP and tFTP), and think about systems that make them look sane and perfectly reasonable. Exposing these systems to inbound connections from anywhere on the Internet is irresponsible. Now, if these devices make a connection out to phone home, allowing that home to reach back is reasonable, and supporting things like upnp to allow devices to specifically open up inbound connections are reasonable. I'm not saying that it needs to be as hard to configure as getting in through IPv4 NAT, but it should NOT be the 'open end-to-end Internet the way $DIETY intended' look at how easy it is to 'root' phones, where the company involved is at least reasonable competent in writing software. For a lot of the IoT devices, the Internet is a rushed, tacked on addition (they already needed a processor to manage something, so spend a few cents more and now they can advertise this mobile device app). Try using some of these apps and devices and see how horrific the software is. David Lang cheers! Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. But that's not the world we live in. David Lang On Wed, 16 Jul 2014, Lyme Marionette wrote: - Original Message - On Wednesday, July 16, 2014 2:10:53 PM "Gui Iribarren" 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. ___
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
On Fri, 18 Jul 2014, Benjamin Cama wrote: Le jeudi 17 juillet 2014 à 17:03 -0700, David Lang a écrit : But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. Do you mean, all the hackers and worms we see today despite all these systems being behind blocking firewalls and NATs? Yep, how much worse would they be if more systems were exposed? […] link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. For this, you have ULA. It is available in OpenWRT and recommanded by the RFCs cited earlier. but these low quality devices will not be using local addresses (unless the router implements outbound NAT) because they will need to connect to "the cloud" […] But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? This is nonsense, this will never happen as nobody cares about OpenWRT. so we should just all go home since nobody cares what we do. Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. They are exposed anyway, by other means. there are degrees of exposure, and while I agree that perimeter security by itself is not what we really want, throwing away perimeter security on the theory that every device is going to be secure, or that they are exposed anyway is just begging for trouble. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
On Fri, 18 Jul 2014 10:21:56 -0700, Bill wrote: Gert Doering wrote: On Thu, Jul 17, 2014 at 10:20:09AM +0200, Steven Barth wrote: Regarding firewalling: I understand and support your point for end-to-end connectivity though there are still quite a few people (including myself) who have reservations about the security implications. This discussion here is very much the same discussion as everywhere when the topic pops up. There's basically 3 sides here: - I want a firewall that mimics IPv4 NAT default-closed behaviour - I want IPv6 to be end-to-end so applications can just work and not bother with PCP, firewall traversal, etc. - I want a firewall but one that defaults to open for $somestuff and to close for $otherstuff (swisscom model) I don't think we will be able to agree here any more than on the IETF lists or whatever. But what we (uh, Steven :) ) can do is: provide easily selectable "firewall profiles" that match the 3 "common scenarios". As of today, OpenWRT routers are not "autoconfig" yet, but you need to put in some config anyway (like, the protocol and username/password used to connect to your ISP). If we could have a "basic firewall switch" there that has 4 settings "closed", "fully open", "balanced (swisscom model)" or "customized", this should enable users to get what they want without having to really think about firewall rules, ports, etc. I agree - this is an excellent approach I also agree, this set of basic defaults is good. Of course the question remains "what should the default be", and I'm not sure we can come to an agreement on this. My own thoughts on this are evolving. In real life (whatever that is), I consider myself more a product manager (marketing guy) than a developer, so I'm interested in the customer experience of the final product. Of course, the final product is really a router, and OpenWRT would be a component of that router. In all fairness, as I'm building that router product, I'm going to modify OpenWRT to meet the needs of the market. So, the bottom line is that, whatever the default is in OpenWRT, I'm going to go ahead and set it to what I need it to be in my build, before I blow it on to the router (or whatever) that the customer sees. The end user of the router would be a random customer (let's just say, "someone's mom"), and I am responsible for that customer's experience. Being the experienced (some might say, "cynical") individual I am, I'd want it to be "idiot-friendly" - removing as many opportunities for the end user to get into trouble as possible. So, at least at this point in time, I'm going to close all the ports by default. I'd rather face the prospect of helping the customer open the ports as they need that "end-to-end" connectivity than the prospect of someone saying, "you sold me a router that's unexpectedly wide open to the Internet and everyone in the world is sending all manner of nasty stuff to my printer." However, *I* am actually the end user of OpenWRT - it's reasonable to assume that anyone who is downloading OpenWRT or building it from source is sufficiently advanced in their knowledge (or at least wants to be) that they would expect it to be "expert-friendly," not "idiot-friendly." From that perspective, I still think that having the router block all ports (as is done in v4 "consumer-grade" routers today) is the "idiot-friendly" default, but, after thinking about it more, I think that Gert's "balanced" approach is probably the "expert-friendly" default and the one I would want and expect in the OpenWRT builds. I think the default should be idiot-friendly. Having the easy knob to toggle to make it 'expert-friendly' should be enough. If the 'expert' can't flip that knob, they can't secure their network either. FWIW, Bill P.S. No, my printer is not v6-ready, either, but let's assume there are some that are... that's a real example that has been exploited in the past, especially with the very expensive, high-end printer/copiers sold to businesses. Again from companies that "should know better" David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
On Fri, 18 Jul 2014 11:06:18 +0200, Gert Doering wrote: Hi, On Thu, Jul 17, 2014 at 12:07:57PM -0400, Soren Harward wrote: the worst case scenario is that the user's machine gets compromised. This is an extreme likely case, but it will not happen by a network based attack. It won't happen by a network based attack from the outside in IPv4 because inbound connection from IPv4 are blocked. Compromises these days on end hosts happen due to garbage the users click on (in mail, in web sites, etc.), much less due to network attacks (because client systems have become more robust to these, and they all come with a host firewall by default today). desktop OSs may have become more robust (I think this is debatable), but my point is that the upcoming flood of other devices is not secured against network attacks. So always assume that the compromised host is already *in* your network, and then re-evaluate your router firewall requirements. The thing is that by dropping your perimeter firewall, you make everyone in your area be "in your network" Yes, there will be some attacks that get through and start from the inside, but there are far fewer that get into my network than to get into the network of everyone I share an ISP with. I also don't want these random external users to be eating up my wireless bandwidth hammering uselessly against my devices, even if they will withstand the hammering. go do a tcpdump of your WAN interface some time, look at all the attacks that are going on there (especially with an ISP that's not blocking it for you) If nothing ever got compromised from network attacks, the malware wouldn't bother trying them. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
On Sat, 19 Jul 2014, Gert Doering wrote: On Fri, Jul 18, 2014 at 04:08:02PM -0700, David Lang wrote: go do a tcpdump of your WAN interface some time, look at all the attacks that are going on there (especially with an ISP that's not blocking it for you) I'm well aware of all the bullshit that is knocking on my doors all day. Point is, firewalls on the *routers* are not goint to help the laptop that moves around, attaches to a Wifi Hotspot, is hacked there, gets moved back behind your firewall, and starts hacking others from there. And it doesn't help the desktop PC that neglected to do any updates, gets infected by flash/pdf/word exploit, and starts scanning your network, behind the firewall. The problem here isn't with laptops, it's with TVs, light Bulbs, Thermostats, digital picture frames, etc. These are the types of devices that I'm worried about protecting. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
On Mon, 21 Jul 2014, Gert Doering wrote: Hi, On Sun, Jul 20, 2014 at 03:50:24PM -0700, David Lang wrote: I'm well aware of all the bullshit that is knocking on my doors all day. Point is, firewalls on the *routers* are not goint to help the laptop that moves around, attaches to a Wifi Hotspot, is hacked there, gets moved back behind your firewall, and starts hacking others from there. And it doesn't help the desktop PC that neglected to do any updates, gets infected by flash/pdf/word exploit, and starts scanning your network, behind the firewall. The problem here isn't with laptops, it's with TVs, light Bulbs, Thermostats, digital picture frames, etc. These are the types of devices that I'm worried about protecting. Yes, so how do you protect them from the malware on your PC and Laptop, which both are behind the firewall? A hacker "from the wild" is likely to not even *find* the device if it's using EUI64 IPv6 addressing and not registered in DNS, while an attacker on the same LAN just needs to ping ff02::1 to see them all, wide open... The argument was that laptops are better protected nowdays because they routinely get exposed outside the home network. I agree that they are far better than they used to be, but I am saying that there is this other class of devices that is not benefiting from the attention that the desktop OSs are getting, and these devices are absolutly quality. no, having a default-deny permiter doesn't protect you from a laptop on the inside, but it does protect you from everyone else's laptops outside. While it is nice to say that IPv6 has a large address space and so nobody will ever scan it, I don't believe it. When IPv4 started out, people didn't believe that scanning it was going to be practical either. And since common methods of assigning IPv6 addresses are either sequential (DHCP) or based on MAC addresses (fairly predictable per vendor), I expect that scanning is going to continue. As for the "doing a scan against someone else's IPv6 address space is a DoS against your service", remember that these people aren't doing the scan from _their_ internet connection, they are doing it from botnets, so they are using "free bandwidth" David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
On Mon, 21 Jul 2014, Gert Doering wrote: On Mon, Jul 21, 2014 at 12:18:46AM -0700, David Lang wrote: While it is nice to say that IPv6 has a large address space and so nobody will ever scan it, I don't believe it. Don't believe. Try math. 2^64 is big enough that if you manage to send a few 1000 packets a second, you'll need up to the heat death of the universe to scan a single /64 subnet... (Of course this can be optimized if you're targeting very specific devices and "only" need to scan 2^24 potential EUI64 addresses in a given vendor's MAC range - but that's not your Joe Random attacker. If someone is that determined, he'll just target your PC first, and jump from there to the devices on your LAN. Way easier in general) If someone is targeting you specifically, there are all sorts of other scenarios that come into play. I consider those out of scope for this sort of discussion. We are talking about what is appropriate as the default to defend against the normal Internet Badness, not against targeted threats or the NSA. You are effectivly saying that security by obscurity is good enough. You are assuming that IP address assignments are going to be random enough to make scanning worthless, so no other protection is needed. I just don't buy that. I don't believe that the addresses are really going to end up beng that random. Plus there will need to be some way for devices to be discovered, which will probably be via broadcasts. I don't believe that the devices are going to be secured to the point where these broadcasts will only work from the local network. It doesn't matter how big the per-network address space is if devices respond to the one broadcast address for the network. Also, if the devices intend to be accessible, are they really going to ask people to enter IPv6 IP addresses into configs? or are they going to be publishing themselves to DNS or some other nameserver that will make them easier to find? If you have a SIP phone that you want to "just work", how are the legitimate remote users going to find it? So I'm saying that we still need to block inbound access from random external IP addresses by default. I could see having the firewall look for outbond packets from the devices and opening up inbound rules from those IPs Even if it allowed access on all ports from the entire source network it would still be better than "anyone on the Internet. this would make getting something work between networks not be on by default, but once each side tries to connect to the other, things would be open. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OT] Anyone interested in donating Broadcom development?
On Mon, 28 Jul 2014, John Crispin wrote: On 27/07/2014 23:07, Rafał Miłecki wrote: Note: this is *not* anyhow officially related to the OpenWrt! This is my private request, I use OpenWrt ML just to reach ppl interested in this topic. Also I can't guarantee my development will success and can't guarantee any progress in any reasonable time. if it makes you feel better i can add the official bit, you have done a pile of great work recently :) we would like to officially ask those who think that Rafał's work on brcm is important to help him out by donating the named/requested materials to him ... and as usual his work is on a best effort basis I've had an interest in helping get specific routers supported in the past, but figuring out who to send equipment to ended up defeating me repeatedly. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OT] Anyone interested in donating Broadcom development?
On Mon, 28 Jul 2014, John Crispin wrote: On 28/07/2014 10:41, David Lang wrote: On Mon, 28 Jul 2014, John Crispin wrote: On 27/07/2014 23:07, Rafał Miłecki wrote: Note: this is *not* anyhow officially related to the OpenWrt! This is my private request, I use OpenWrt ML just to reach ppl interested in this topic. Also I can't guarantee my development will success and can't guarantee any progress in any reasonable time. if it makes you feel better i can add the official bit, you have done a pile of great work recently :) we would like to officially ask those who think that Rafał's work on brcm is important to help him out by donating the named/requested materials to him ... and as usual his work is on a best effort basis I've had an interest in helping get specific routers supported in the past, but figuring out who to send equipment to ended up defeating me repeatedly. David Lang hi david. please post the link to the mail you sent on -devel about this. It's been a couple years since my last attempt, given that the topic just came up, I figured I'd try to figure out what the right process is for the next time :-) the most interesting items for me right now are the DSL version on the netgear 3700 and the netgear r6200. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Moving all feeds to OpenWrt GitHub organisation
On Sun, 10 Aug 2014, Florian Fainelli wrote: Hello, Le 10 août 2014 09:44, "Etienne Champetier" a écrit : Le 10 août 2014 18:18, "Stefan Monnier" a écrit : It would be great to have all feeds in one place, on GitHub. I think making oneself dependent upon a commercial company without paying it (i.e. without leverage) would be a mistake. Stefan We use git, the day github closes, or asks for money, or ..., we move. We dont depend on github, we use it while it's there (and free). In the mean time it helps getting the job done Also paying is no leverage, a contract can be but there are always half million clauses, and in the worst case scenario they pay you one month back We already have an infrastructure deployed which is much wider than the services offered by github. Surely we had our own administrative issues with those machines but they have been sorted now and the process is much stronger. At this point, I don't think we would be getting any advantage of using a 3rd party service, but that's just me. I agree about the value of having our own infrastructure, but since git is so powerful, what about making a clone of the feeds on github as well as the current feeds. If the original poster is correct and this will generate more patch submissions from github users, it's a significant win. If not, it doesn't cost any money and only a small amount of time. if git wasn't decentralized enough to allow for multiple instances like this, it would be a much harder decision to make. some projects that have added a presense on github (or moved there entirely) report a significant increase in patches, some report no change. For OpenWRT, I expect that most of the project would see no change, but I wouldn't be surprised to see some areas benefit. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] overcommit memory/ratio
On Wed, 17 Sep 2014, Nikos Mavrogiannopoulos wrote: On Tue, 2014-09-16 at 22:29 +, Karl P wrote: Alternatively, if you know which process it is, set it's oom_adj_score so that it gets killed first. Some other people are kinda used to things behaving as they are, for better or worse. (Turning off overcommit on an openwrt device is no different than turning off overcommit on a desktop as far as I'm concerned. Somethings will be better, lots of things less so) Well being used to something bad, doesn't mean things cannot get better. Routers (to which I have some experience at), rarely have processes running that wouldn't matter if they are randomly killed; on a desktop system you immediately notice an issue, and you can reboot, a router is typically running unattended. Being locked out of such a system because another process had a memory leak, can be an issue. Turning off overcommit so that a program that wants to spawn a child will end up requiring double it's memory (for the time between the fork and the exec) is likely to cause programs to fail when they don't need to. And unlike desktops, you can't just say "allocate a lot of swap" to cover this up. In spite of what some people say, it's far from a clear-cut win to disable overcommit. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] overcommit memory/ratio
On Sat, 20 Sep 2014, Nikos Mavrogiannopoulos wrote: On Fri, 2014-09-19 at 18:39 -0700, David Lang wrote Well being used to something bad, doesn't mean things cannot get better. Routers (to which I have some experience at), rarely have processes running that wouldn't matter if they are randomly killed; on a desktop system you immediately notice an issue, and you can reboot, a router is typically running unattended. Being locked out of such a system because another process had a memory leak, can be an issue. Turning off overcommit so that a program that wants to spawn a child will end up requiring double it's memory (for the time between the fork and the exec) is likely to cause programs to fail when they don't need to. I'd be surprised if fork and exec worked that way. After a fork the two processes share the same physical pages (see the notes on fork() manpage), and overcommit applies to physical ram, not virtual. No, Overcommit says that you can have more virtual RAM than physical RAM + swap. That's what overcommit is. So when you fork a process, it takes double the memory with overcommit off than it does with overcommit on. And unlike desktops, you can't just say "allocate a lot of swap" to cover this up. The same argument works the other way as well. A process using more memory than the available in the router will force some other (arbitrary) process to be killed. Unlike desktops you can't just say "allocate a lot of swap" to cover this up. What you _can_ do, is tell to the process that uses more memory than the existing one, that there is no memory left. But turning overcommit off doesn't tell a process that uses more memory than the existing one that there is no memory left, it tells the first process that tries to allocate memory after it runs out that there is no memory left. This could be the process that's using an unusual amount of memory, or it could be sshd allocating a buffer to use to log. Even if it gets the right process, you are assuming that the programs properly check for errors after anything that allocates memory. This is very commonly not the case, so you still get random failures. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
On Thu, 2 Oct 2014, Alpha Sparc wrote: How good is the throughput on CeroWrt compared to OpenWrt ? The focus of CeroWrt is on reducing latency, not increasing throughput. If you run into really badd bufferbloat problems without these scrips, then these scripts can result more more 'goodput' (useable data as opposed to 'throughput' bits on the wire) getting through, but in the usual case there will be a (slight) reduction in the peak throughput. This is especially so on the inbound side of things because the router is having to work indirectly to throttle the senders so that they don't overload the router at the other end of the connection. I beleive that on the WNDR3800, it's able to work up to about 50Mb with the existing configurations. A faster CPU would do better, a slower one worse. The re-write that Dave is talking about is hoting to improve this. From the pastebin link Dave listed below, they have it up to ~80Mb now David Lang On Oct 2, 2014 9:55 AM, "Dave Taht" wrote: On Wed, Oct 01, 2014 at 12:10:46PM -0400, Weedy wrote: On 30/03/14 06:29 PM, Dave Taht wrote: On Sun, Mar 30, 2014 at 02:24:44PM -0400, Weedy wrote: On Sat, Mar 29, 2014 at 2:56 PM, Dave Täht wrote: From: Dave Taht This adds support for the bufferbloat project's "Smart Queue Management" (SQM) system, which improves over openwrt's qos-scripts in the following ways + Uses HTB with two models for managing traffic a simplest one that merely uses fq_codel, and a three tier one that does some basic and tunable packet prioritization. + Works with ipv6 and ipv4 correctly (unlike qos-scripts) + extensive support for fixing ADSL and PPOe framing problems + Partial support for key diffserv markings + highly tuned fq_codel implementation especially for low bandwidths + Tested heavily on cable modems and on dsl devices It is a disimprovement in that: - There are no built-in tricks for doing l7 classification, or other forms of packet inspection. - We haven't explored hfsc all that much, prefering to rely on the predictable behavior of htb + fq_codel for everything - And there is support for a few qdiscs that are not in the linux kernel mainline that remain experimental. --- net/sqm-scripts/Makefile | 48 +++ net/sqm-scripts/files/etc/config/sqm | 11 + net/sqm-scripts/files/etc/init.d/sqm | 23 ++ net/sqm-scripts/files/usr/lib/sqm/functions.sh | 335 net/sqm-scripts/files/usr/lib/sqm/run.sh | 67 net/sqm-scripts/files/usr/lib/sqm/simple.qos | 187 +++ net/sqm-scripts/files/usr/lib/sqm/simple.qos.help |1 + net/sqm-scripts/files/usr/lib/sqm/simplest.qos | 84 + .../files/usr/lib/sqm/simplest.qos.help|1 + net/sqm-scripts/files/usr/lib/sqm/stop.sh | 22 ++ 10 files changed, 779 insertions(+) create mode 100644 net/sqm-scripts/Makefile create mode 100644 net/sqm-scripts/files/etc/config/sqm create mode 100755 net/sqm-scripts/files/etc/init.d/sqm create mode 100644 net/sqm-scripts/files/usr/lib/sqm/functions.sh create mode 100755 net/sqm-scripts/files/usr/lib/sqm/run.sh create mode 100755 net/sqm-scripts/files/usr/lib/sqm/simple.qos create mode 100644 net/sqm-scripts/files/usr/lib/sqm/simple.qos.help create mode 100755 net/sqm-scripts/files/usr/lib/sqm/simplest.qos create mode 100644 net/sqm-scripts/files/usr/lib/sqm/simplest.qos.help create mode 100755 net/sqm-scripts/files/usr/lib/sqm/stop.sh diff --git a/net/sqm-scripts/files/etc/config/sqm b/net/sqm-scripts/files/etc/config/sqm new file mode 100644 index 000..547d321 --- /dev/null +++ b/net/sqm-scripts/files/etc/config/sqm @@ -0,0 +1,11 @@ + +config queue 'ge00' +option enabled '0' +option interface 'ge00' +option download '2' +option upload '4000' +option qdisc 'fq_codel' +option script 'simple.qos' +option qdisc_advanced '0' +option linklayer 'none' + How hard is this to config from the command line/vim? There are a few more options than this (for DSL compensation, ecn and advanced configuration), the above would work if you changed enabled to '1' and the device from ge00 to your wan device. (not the "wan" firewall rule, presently. ) It does help to have a sane long term and realistic measurement of your network using something like the rrul test rather than the oft-gamed speedtest. http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310 You are right, we should fully document all the variables in this file. Until recently they were kind of in flux. I've never needed or really wanted luci on my box, I just use vim. Going by this patch, there is either nothing to config or no examples
Re: [OpenWrt-Devel] why is 'wan' port missing in luci switch vlan setup page for Netgear WNR2200 ?
On Fri, 3 Oct 2014, Urs Rau (UK) wrote: Hi Jo-Philipp, On 26 Sep 2014, at 09:55, Jo-Philipp Wich mailto:j...@openwrt.org>> wrote: Hi. The wan port is likely a dedicated, non-switch interface (e.g. eth1) on this model. If you want to declare VLANs on it then simply create a new interface using eth1.Y as manual physical ifname where Y denotes the desired VLAN id. ~ Jow yes, I think you are right. eth0 is the yellow wan port and eth1 is the 4 port switch on this hardware but now I have a problem, how do i get tagged VLAN traffic coming in on eth0.96 eth0.128 eth0.144 eth0.160 eth0.168 to ‘connect’ or ‘forward’ to the relevant eth1.VLANID ? on other models the wan port is part of the same switch and I can tick the ‘cpu’ port in luci to ‘transport’ or ‘forward’ the right wan VLAn with the right LAN port 1 - 4. How can I do this on this hardware which has one wan port that is not part of the switch and for lan ports that are part of the switch that luci shows under the ‘switch’ page? or do I have to ‘forget’ about using the ‘wan’ port and work with the lan ports 1 - 4 only? you bridge between the eth0.x and eth1.x interfaces (where x is the VLAN) keep in mind that since this traffic is going through the kernel to get from one side to the other instead of just through the switch, it is going to be slower. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Dual Wifi for OpenWRT
On Sat, 10 Jan 2015, Bruno Randolf wrote: Does anyone know a hardware platform with 2 or more wifi interfaces which can both be used in the 2.4 GHz band? I would not expect to find consumer hardware that had two radios on the 2.4GHz band, the problems that you would run into trying to keep the output of one radio from deafening the other (if not outright popping the receiver amps) would be significant (to say the least). It could be done, but it would take antenna setups that you just don't see mass produced to even get started. Even the "enterprise" grade hardware that has multiple radios tends to have problems with this. It takes having very directional antennas to try and keep as much of the signal away from the other radio to even start. What is it that you are trying to accomplish? David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Dual Wifi for OpenWRT
On Sat, 10 Jan 2015, Bruno Randolf wrote: On 01/10/2015 08:38 PM, David Lang wrote: I would not expect to find consumer hardware that had two radios on the 2.4GHz band, the problems that you would run into trying to keep the output of one radio from deafening the other (if not outright popping the receiver amps) would be significant (to say the least). It could be done, but it would take antenna setups that you just don't see mass produced to even get started. Right, that is a good explanation why no consumer HW with this feature exists. Even the "enterprise" grade hardware that has multiple radios tends to have problems with this. It takes having very directional antennas to try and keep as much of the signal away from the other radio to even start. Hmm... Yes antenna placement is important and difficult, but I know setups where this works quite well. E.g. using RouterStation Pro with 3 MiniPCI cards (ath5k/ath9k). What is it that you are trying to accomplish? For one part I'm trying to find alternatives to that RouterStationPro board which is EOL. But in the current case I actually want to have one or more radios in monitor mode (running "horst", switching thru channels) and another one for connectivity (mesh). In this case the interference problems you mention don't exist, but I admit that this is not a very usual use-case... ;) In that case you re probably best off adding a USB wifi interface to a router. In terms of antennas, try going with high-gain omnidirectional antennas and position them directly above each other (omnidirectional antennas have a 'blind spot' directly above and below the antenna, so if you position them so that each is in the blind spot of the other you have the best chance of it working, and high gain antennas are going to have flatter patterns, making them more forgiving) David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Is Linksys/Belkin lying (again) about being open source (WRT1200AC router) ?
Is the 1200 out yet? The article that was posted earlier did say that they recognized that they had made mistakes with the 1900 and were planning to not do the same thing with the 1200 and have everything ready at the release date. If the release date is not here yet we can't say that they haven't improved. Now, this isn't the same as having the support upstream in openwrt, which is what we all want, but if they do release the full source at the time of the router release, it is better than most. David Lang On Fri, 16 Jan 2015, Fernando Frediani wrote: Hi, Great email Valent, and I fully agree with your comments. We have had this discussion here in the past and nothing much changed from Belkin side (actually it got worse as they disappeared apparently) showing a total failure on product release. I'm not entirely sure of the status of WRT1200AC, but if there is nothing here in OpenWRT and nothing else much can be found on the web they are once again lying. They are publishing intentions as if it was something that was already done and consolidated, ready for any buyer to enjoy. If there is something going on between them and OpenWRT we are not aware, at least not via this list. I personally consider a big slap in the face of consumers Marketing doing what they do in Belkin, like if they didn't care at all. This is not simply 'a mistake' or 'a misunderstanding' , it's complete dishonesty and they are probably fully aware of this but simply don't care at all cause they just want to reach their marketing target. Probably people there might not even have a basic idea about what is open-source. As mentioned Marvel is doing some progress with the Wifi driver, which is great for WRT1900AC owners, but that's Marvel only. What has Belkin done about their share of the work BEFORE they release this new product ? I not sure if much or any. I hope they are able to show me I am wrong on my comments. Regards, Fernando On 14/01/2015 13:05, valent.turko...@gmail.com wrote: Linksys/Belking marketing is again doing one thing and saying another? This time they say that WRT1200AC router is open source: http://www.zdnet.com/article/ces-2015-linksys-1200ac-an-inexpensive-open-source-802-11ac-wi-fi-router/ I have tracked progress with WRT1900AC and saw how they failed to give us open source driver, so I hope that this time they will actually keep their (marketing) promise. I really, really, really hope that this time they have reached out and contacted any of you OpenWrt developers and that we will get truly open source driver from them. So please let us know if any of you have heard anything regarding WRT1200AC router and it's drivers. Cheers, Valent. ___ 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] chance to gather info from a high density deployment
I run the wireless network at the SCaLE conference which is taking place next week. I will be deploying ~50 WNDR3700v2 and WNDR3800 APs running OpenWRT to support ~3k users in the hotel (details available in the presentation/paper I gave at LISA '12 https://www.usenix.org/conference/lisa12/technical-sessions/presentation/lang_david_wireless ) Since such high density environments are fairly rare and hard to get access to, I want to give the OpenWRT project a chance to gather information during the show. I will be building the image for this year in the next couple of days, so I can even patch in additional logging of data if needed. I will be building the firmware images in the next few days. I gather syslogs and normal mrtg stats. I also gather the counts of associations to each ESSID each minute (I use social engineering to steer people to 5GHz by calling that network 'scale' and the 2.4GHz network 'scale-slow') It was suggested that I see if I can gather /sys/kernel/debug/ieee80211/phy*/netdev:*/stations/*/rc_stats and xmit stats frequently (every 10s or so). What else can/should I gather? David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] enabling seccomp by default in kernel
On Sat, 14 Feb 2015, Nikos Mavrogiannopoulos wrote: Hello, I've added libseccomp into packages. That library allows programs to easily restrict the system calls they are allowed to use. In turn that uses the kernel's seccomp filter. That's one of the most reliable ways to restrict/sandbox processes into specific tasks which cannot be overriden even in the event of code injection. I've also enabled the ocserv package to use seccomp if configured to, but in order for that protection to become meaningful for other programs to use as well, it would also need the default kernel option to enable seccomp filter. It needs the kernel support to use the seccomp filter, but why is this so critical that it must be enabled by default? David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] General questions about the direction of switch drivers
On Mon, 16 Feb 2015, Charlie Smurthwaite wrote: I'm writing a driver for a family of 24 port gigabit switches, with a wide array of interesting hardware features. Creating basic VLAN membership and tagging functionality under the swconfig framework has been quite easy, and this framework has been excellent for this. However, I would like to support a lot more of the functionality of this hardware, and see other devices with advanced layer2 and layer3 switching supported in the future, so I wanted some opinion on the direction things are taking. Specifically I am looking for opinion on whether the swconfig framework is suitable for more advanced functionality, or whether there was likely to be a move to any other upstream framework for switch devices, particularly those with more advanced functionality. The types of functionality I am currently interested in supporting are: * VLAN membership an tagging * Packet and byte counters * Security settings and filtering rules * STP * Layer 3 functionality (hardware IPv4 and IPv6 routing tables) * Hardware NAT / firewall Some of this functionality may simply require configuration, where other functions require the active involvement of the CPU. A work-around for many of the items other than the basic VLAN membership and tagging is to force the traffic between the different switch ports to go through the CPU by putting the different ports on different VLANs and then using the kernel bridging/firewalling/etc features. You can't do this between switch ports that are trunked (exposeing the VLAN tags), but other than the cpu load and admin confusion, it works very well to just do this in the kernel. How much of the "functions that requrie active involvement of the CPU" end up being a variation of this? I am curious as to what other switch device frameworks are out there. It's worth noting that the vast majority of OpenWRT devices have a single switch in them, and that switch is typically not the fanciest (although the march of technology mens that every year it's going to be better than it used to be) David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] General questions about the direction of switch drivers
On Mon, 16 Feb 2015, Charlie Smurthwaite wrote: Hi David, On 16/02/15 21:03, David Lang wrote: A work-around for many of the items other than the basic VLAN membership and tagging is to force the traffic between the different switch ports to go through the CPU by putting the different ports on different VLANs and then using the kernel bridging/firewalling/etc features. You can't do this between switch ports that are trunked (exposeing the VLAN tags), but other than the cpu load and admin confusion, it works very well to just do this in the kernel. How much of the "functions that requrie active involvement of the CPU" end up being a variation of this? It can certainly be done this way. In fact with my current driver, I could give every port on the switch a different VLAN, tag them all on the CPU port, and do all the real work in the kernel. However this has one serious drawback: poor throughput. A hardware switch can easily do multiple Gbps, whereas the CPU can probably only handle a couple of hundred Mbps. yep, this is a technique to be pulled out only when needed, but it's worth keeping in mind that you can mix this with the hardware if you don't need to do this between every port, you can group ports into different VLANs and use the CPU between them With regard to "functions that requrie active involvement of the CPU", this is where it gets interesting. There is a huge difference in performance between the kernel managing the switch's MAC address table (telling it which port to send a particular destination MAC address to), or having the CPU manage the STP port status, and caching that for a period of time vs sending all the packets in full through the CPU. how much of this functionality is exposed in the currently common switch chipsets? I'm also wondering if the right answer for some of this could end up being a butchered version of the kernel bridging code that maintains all the configuration/state, but lets the hardware do the packet forwarding. I am curious as to what other switch device frameworks are out there. Specifically, there is the new "switchdev" framework which I was recommended to look at, and looks good, but doesn't seem to be used much yet, and also openvswitch, which is a little different, but may be an option for some purposes. I've seen references to openvswitch, but I was under the impression that it didn't have any relationship with real hardware, it was just a way to configure/manage logical switches for VMs It's worth noting that the vast majority of OpenWRT devices have a single switch in them, and that switch is typically not the fanciest (although the march of technology mens that every year it's going to be better than it used to be) My thought is that the switch chips in devices are quickly improving, with many supporting a lot of functionality that currently goes unused. I understand this is often because it's unnecessary in a home/office router, or a primarily wireless device, but I think OpenWrt is a great platform and a great base to work on these primarily wired devices as well. I think a lot of it is that there just isn't a huge amount of overlap between people who are experienced in dealing with complex wired environments and OpenWRT. I've had a lot of people dismiss the though of using OpenWRT hardware for things that they've traditionally used Cisco/HP switches for, but when desperation has forced them to give it a try, they've been very pleased with the results. I'd love to see someone do a project with a small PC (Raspberry Pi or equivalent) that could take the cheap 8 port switches and unlock the power in the switch chipsets. I saw a post of someone who did this with an arduino, but even that was just pipeing a canned config into it. With something able to run a full software stack, lots of other things would become possible. When you get your stuff working, I'd be very interested in knowing what switch it is you are reprogramming. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] General questions about the direction of switch drivers
On Mon, 16 Feb 2015, Michael Richardson wrote: I have stumbed my toe on 3800 with trying to build tagged switch ports where I have a few ports with explicit VLAN tagging, joined together in the switch, and also exposed to the host. I think it should work, but I mostly just wound up screwing up my CPU port. I have some 3800 with serial consoles now so I should try this out. I've been using tagged and untagged switch ports on the 3800 for a few years now (I use them for the Scale conference and we have a rather complex wired infrastructure), the only problem I ran into was the issue of the ports being numbered backwards on the outside of the box. For the conference, I use one port on the switch as my WAN port (trunked) and then configure the other three ports to specific VLANs. I configure the 'wan' port to be trunked as well, but generally only end up using it to daisy-chain another AP off of. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] General questions about the direction of switch drivers
Having a more abstract way of managing this available is a nice option to have, but I would hate to loose the ability to set things explicitly. Keeping in mind that we are primarily dealing with low-end devices, anything that requires more advanced chipsets just isn't going to happen. The chipsets will progress, but what gets put into the APs is going to be the cheapest swtich chipset that will do the job of a dumb switch. The fact that this cheapest chipset also happens to be able to do a lot more is a very nice bonus for us. Remember that the vendors want to also offer the "Enterprise" APs with the advanced capabilities. David Lang On Mon, 16 Feb 2015, Joel Wirāmu Pauling wrote: I for one would love to see brctl and vconfig disappear completely in favour of ovs-* based standard toolchain for all switch interaction. Certainly in the Bigger iron area, and things like core and cumulus coupled with SDN approaches and Openstack this is fast becoming defacto. I don't see why with a bit of additional abstraction that ovs couldn't become the default stack for mainline and certainly for OpenWRT it offers a lot more versatility than the current brctl and vconfig tools. I guess the biggest issue is getting ovs- offload to switch chipsets rather than CPU bound softswitch. Maybe some sort of flag where unsupported operations/modes which would end up being done on the CPU are flagged/masked?___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][bcm63xx]: Add DGND3700 v1 / DGND3800B support
Is this going to include support for the DSL on these boxes? the Table of
Hardware page still says that the DSL is not and will never be supported. I've
seen enough changes in such things over the years to hope that this is no longer
the case.
David Lang
On Sun, 1 Mar 2015, dani wrote:
Date: Sun, 01 Mar 2015 00:09:59 +0100
From: dani
To: openwrt-devel@lists.openwrt.org, j...@openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH][bcm63xx]: Add DGND3700 v1 / DGND3800B
support
Ok, patch updated with latest changes in trunk, and suggestions.
About SPROM fixups, I misundertsood its purpouse. Deleted since it's not
required.
Signed-off-by: Daniel Gonzalez
diff --git a/target/linux/brcm63xx/base-files/etc/uci-defaults/01_leds
b/target/linux/brcm63xx/base-files/etc/uci-defaults/01_leds
index 854b3b2..69d797e 100644
--- a/target/linux/brcm63xx/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/brcm63xx/base-files/etc/uci-defaults/01_leds
@@ -14,6 +14,14 @@ case "$board_name" in
96328dg2x2)
ucidef_set_led_usbdev "usb" "USB" "A4001N:green:usb" "1-1"
;;
+DGND3700v1_3800B)
+ ucidef_set_led_netdev "lan" "LAN" "DGND3700v1_3800B:green:lan" "eth0.1"
+ ucidef_set_led_netdev "wan" "WAN" "DGND3700v1_3800B:green:inet" "eth0.2"
+ ucidef_set_led_netdev "wlan0" "WIFI2G" "DGND3700v1_3800B:green:wifi2g"
"wlan0"
+ ucidef_set_led_netdev "wlan1" "WIFI5G" "DGND3700v1_3800B:blue:wifi5g"
"wlan1"
+ ucidef_set_led_usbdev "usb1" "USB1" "DGND3700v1_3800B:green:usb-back"
"1-1"
+ ucidef_set_led_usbdev "usb2" "USB2" "DGND3700v1_3800B:green:usb-front"
"1-2"
+ ;;
'F@ST2704V2')
ucidef_set_led_usbdev "usb" "USB" "F@ST2704V2:green:usb" "1-1"
;;
diff --git a/target/linux/brcm63xx/base-files/etc/uci-defaults/02_network
b/target/linux/brcm63xx/base-files/etc/uci-defaults/02_network
index 709a1c8..6b9736a 100644
--- a/target/linux/brcm63xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/brcm63xx/base-files/etc/uci-defaults/02_network
@@ -108,6 +108,13 @@ P870HW-51a_v2)
ucidef_add_switch_vlan "eth0" "2" "4 5t"
;;
+DGND3700v1_3800B)
+ ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
+ ucidef_add_switch "eth0" "1" "1"
+ ucidef_add_switch_vlan "eth0" "1" "1 2 3 4 8t"
+ ucidef_add_switch_vlan "eth0" "2" "0 8t"
+ ;;
+
NB6)
ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
ucidef_add_switch "switch0" "1" "1"
diff --git a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
index 58ce71e..53dd759 100755
--- a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
+++ b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
@@ -111,6 +111,13 @@ brcm63xx_detect() {
brcm63xx_has_reset_button="true"
ifname=eth0
;;
+
+ DGND3700v1_3800B)
+ status_led="DGND3700v1_3800B:green:power"
+ brcm63xx_has_reset_button="true"
+ ifname="eth0"
+ ;;
+
"F@ST2504n")
status_led="fast2504n:green:ok"
brcm63xx_has_reset_button="true"
diff --git a/target/linux/brcm63xx/image/Makefile
b/target/linux/brcm63xx/image/Makefile
index dd16355..3fb9b1c 100755
--- a/target/linux/brcm63xx/image/Makefile
+++ b/target/linux/brcm63xx/image/Makefile
@@ -111,6 +111,12 @@ define Image/Build/HCSDTB
--output_file=$(BIN_DIR)/openwrt-$(2)-$(1).bin
endef
+define Image/Build/ChkDTB
+ # Generate Netgear factory image
+ $(STAGING_DIR_HOST)/bin/mkchkimg -o
$(BIN_DIR)/openwrt-$(2)-$(1)-factory.chk \
+ -k $(BIN_DIR)/openwrt-$(4)-$(1)-cfe.bin -b $(5) -r $(6)
+endef
+
define Build/Clean
$(MAKE) -C lzma-loader clean
endef
@@ -303,6 +309,12 @@ $(eval $(call
ImageDTB,RedBootDTB,Livebox,livebox,livebox-blue-5g))
$(eval $(call ImageDTB,HCSDTB,CVG834G,,cvg834g,a020,0001,0022,vmlinux-cvg834g))
# Netgear DG834GT/PN
$(eval $(call ImageDTB,CFEDTB,DG834GTPN,DG834GT_PN,dg834gtpn,96348GW-10,6348))
+# Netgear DGND3700 v1 / DGND3800B
+$(eval $(call
ImageDTB,CFEDTB,DGND3700v1_3800B,DGND3700v1_3800B,dgnd3700v1,96368MVWG,6368,--image-offset
0x2 --block-size 0x2))
+#Netgear DGND3700 v1 factory firmware
+$(eval $(call
ImageDTB,ChkDTB,DGND3700v1_3800B,DGND3700v1,,DGND3700v1_3800B,U12L144T01_NETGEAR_NEWLED,1))
+#Netgear DGND380
Re: [OpenWrt-Devel] "UCI overlay" proposal
On Thu, 05 Mar 2015 13:36:10 +0100, Matthias Schiffer wrote: Hi, during the development of our Freifunk firmware framework "Gluon" we've come to the conclusion that the current UCI configuration format using static files doesn't always fit our needs. Therefore we propose a new feature we've called "UCI overlays". The basic idea is that we'd like to provide UCI configuration by other means than the static files in /etc/config, for example from a database or generated by scripts on the fly (the latter being our main usecase - we'd like to generate configuration for netifd and fw3 based on meta-configuration data). This should work transparently, without needing changes in the config consumers (applications). The overlay-provided configuration packages should be merged with the config read from /etc/config. We'd like to generate both config sections which may be overruled by corresponding options in /etc/config, and read-only sections which can't be changed by the user through UCI. We see two different ways to implement this: (1) Make the "overlay" an alternative backend which uses the "file" backend to merge generated config with the one from files (2) Introduce overlays as a new concept in libuci While the first option would need less changes in libuci, it doesn't allow stacking different overlays, so we're in favour of option 2. Both ways would need a config file (/etc/uci.conf?) to configure the overlays being used. Our plan is to implement overlays as dlopen-able plugins loaded from somewhere like /lib/uci/overlay so it is possible for other packages to provide overlay implementations. In addition, we'd like to add a new attribute "readonly" to the uci_element structure so changing read-only configuration will fail as soon as someone tries to uci_set it. Does this sound reasonable? We can develop the needed extensions ourselves, but of course we'd like to get this feature upstream to avoid carrying the patches downstream indefinitly, so we're eager to know what you think of this proposal. Should this be built in to uci, or should this be a set of utilities that take /etc/config/wireless.d/* and create /etc/config/wireless when run (which then gets used normally)? You can then have scripts, database tools, config management tools (puppet, chef, etc) drop things in such directories and the utilities can run in cron (or use inotify in an advanced setup) to notice that there was a change and do the appropriate thing to re-read the config. Building it into uci is more elegant, but I worry that having it that integrated will mean that each new way to create config info will end up requiring changes to uci. File based is a little less elegant, but it makes it much easier for people to add new ways to do things. If you are assembling /etc/config/wireless from /etc/config/wireless.d/* you can just say that the resulting file is the combination of all the included files, and it's up to the admin to avoid conflicts between the pieces. If you take /etc/config/wireless and overlay other things on it, you have the question of how do you negate something that was in the base file. I do think that something along these lines should be done. It would be very nice to be able to break up existing config files a little bit (for example, /etc/config/network split raw interfaces from bridge configs from switch configs). And it would be great to be able to have a config management tool be able to just add-on to the base config, replacing part of it, without the config management tool needing to manage everything in the file. Over on the CeroWRT list we are discussing what things are in CeroWRT that have not yet been unstreamed into OpenWRT, and most of them come down to config items. Some of them are 'fairly' small (like renaming interfaces by function, so you have an interface named WAN rather than eth0), while others are very fundamental (routing between each wifi interface and the wired network instead of bridging). An overlay or name.d approach would make it much easier for these different approaches to be presented as packages that can be added to OpenWRT without forcing everyone to change to them. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] "UCI overlay" proposal
changing the format doesn't solve the problem, it just causes churn in all the software. The problem is the lack of standardization and the fact that the way things are configured changes over time. Not everything is configured in UCI (and this will always be the case because it's not worth trying to change every piece of software available) When you try to design a "standardized config space" that will work in the future for equipment and software that nobody has imagined yet, you are either going to go crazy-complicated to try and cover everything and have people going cross-eyed trying to understand the spec, or you are going to lock things down to be so ridged that new things will be working around your config spec. The best that you can do is to setup a framework to keep the configs from stepping on each other and try to converge similar software to use the same terms in the config where it makes sense (remember, the newcomer may have a better way of looking at the problem, so trying to force it to define it's config the way the legacy things did it can cause big problems) I'm all for tools to convert the format to whatever you want to use, and (as I posted earlier), to have tools to assemble/generate the configs, but requiring changes to every piece of software to just change the format requires more than "every langauage can understand JSON" David Lang On Fri, 6 Mar 2015, Zefir Kurtisi wrote: Hello Matthias, can't provide qualified feedback to your proposal, but at least want to post my experience and hope that it is valuable for the discussion. Our company develops highly specialized WLAN products for decades, for a long time based on OpenWRT. The niche market we are in has a strict requirement for long-term availability and compatibility. In the context of configuration, in addition to the default Web-UI configurability, we must support SNMP and stay compatible with MIBs we initially released like 10 years ago. Consequently, for a long time we are following an approach similar to what you are proposing. In the beginning, the config overlay was a simple mapper between backend (uci) and frontend (snmp). Later, when config space and complexity grew, we defined and used a 'meta-config-space' that was generated at runtime from uci to simplify the mapping to snmp. Alas, what looked like a reasonable and clever approach, over time turned into maintenance-hell. We were faced with two moving targets (uci config gradually changing, MIB extensions) that need continuous synchronization and render the approach error-prone and resource-demanding. From that experience, I tend to believe that an overlay- or meta-configuration is only practicable as interim solution during a transition towards a standardized config space. If I had a chance to go back and do things better, this would be my approach: 1) define standardized config space The hardest of all parts - config space must be generic and complete enough to cover each and every potential setup, while at the same time it has to be extensible, backwards-compatible, and well defined. Whoever is familiar with standardization processes knows this will be no picnic. On the good side, with ubus gradually becoming the core framework for OpenWRT, the format for the new config to be JSON is more or less given. As for the structure, in [1] an announcement for a generic network configuration standard in JSON was posted that might well serve as starting point. 2) implement interim overlay Once the config space in 1) is standardized, implement an temporary overlay that provides transparent access to the configuration via legacy uci and new JSON config spaces. From that point on, new applications / packages must not use uci any more. 3) gradually move to new config space Over a defined (and relatively short) transition period, existing packages has to be converted to use the JSON config. At the end of that period, uci should not be used any more. I have developed a few private tools for the overlay-config approach (like conversion from uci to JSON), which are not suitable for upstreaming (C++, proprietary dependencies). From there, my estimate for the implementation workload for the transition (after the config space was standardized) is around 3 man-months. Good Luck, Zefir [1] https://lists.openwrt.org/pipermail/openwrt-devel/2015-January/030422.html On 03/05/2015 01:36 PM, Matthias Schiffer wrote: Hi, during the development of our Freifunk firmware framework "Gluon" we've come to the conclusion that the current UCI configuration format using static files doesn't always fit our needs. Therefore we propose a new feature we've called "UCI overlays". The basic idea is that we'd like to provide UCI configuration by other means than the static files in /etc/config, for example from a database or generated by scripts on the fly (the
Re: [OpenWrt-Devel] "UCI overlay" proposal
One other thought. If there is a desire to change the format, let's pick a format that's already in use for configuring system rather than inventing yet another one. We should survey the tools that are being written for managing software defined datacenters (openstack and similar) and see if we can use one of those config languages (either as-is or with an automated conversion back and forth) David Lang On Fri, 6 Mar 2015, David Lang wrote: changing the format doesn't solve the problem, it just causes churn in all the software. The problem is the lack of standardization and the fact that the way things are configured changes over time. Not everything is configured in UCI (and this will always be the case because it's not worth trying to change every piece of software available) When you try to design a "standardized config space" that will work in the future for equipment and software that nobody has imagined yet, you are either going to go crazy-complicated to try and cover everything and have people going cross-eyed trying to understand the spec, or you are going to lock things down to be so ridged that new things will be working around your config spec. The best that you can do is to setup a framework to keep the configs from stepping on each other and try to converge similar software to use the same terms in the config where it makes sense (remember, the newcomer may have a better way of looking at the problem, so trying to force it to define it's config the way the legacy things did it can cause big problems) I'm all for tools to convert the format to whatever you want to use, and (as I posted earlier), to have tools to assemble/generate the configs, but requiring changes to every piece of software to just change the format requires more than "every langauage can understand JSON" David Lang On Fri, 6 Mar 2015, Zefir Kurtisi wrote: Hello Matthias, can't provide qualified feedback to your proposal, but at least want to post my experience and hope that it is valuable for the discussion. Our company develops highly specialized WLAN products for decades, for a long time based on OpenWRT. The niche market we are in has a strict requirement for long-term availability and compatibility. In the context of configuration, in addition to the default Web-UI configurability, we must support SNMP and stay compatible with MIBs we initially released like 10 years ago. Consequently, for a long time we are following an approach similar to what you are proposing. In the beginning, the config overlay was a simple mapper between backend (uci) and frontend (snmp). Later, when config space and complexity grew, we defined and used a 'meta-config-space' that was generated at runtime from uci to simplify the mapping to snmp. Alas, what looked like a reasonable and clever approach, over time turned into maintenance-hell. We were faced with two moving targets (uci config gradually changing, MIB extensions) that need continuous synchronization and render the approach error-prone and resource-demanding. From that experience, I tend to believe that an overlay- or meta-configuration is only practicable as interim solution during a transition towards a standardized config space. If I had a chance to go back and do things better, this would be my approach: 1) define standardized config space The hardest of all parts - config space must be generic and complete enough to cover each and every potential setup, while at the same time it has to be extensible, backwards-compatible, and well defined. Whoever is familiar with standardization processes knows this will be no picnic. On the good side, with ubus gradually becoming the core framework for OpenWRT, the format for the new config to be JSON is more or less given. As for the structure, in [1] an announcement for a generic network configuration standard in JSON was posted that might well serve as starting point. 2) implement interim overlay Once the config space in 1) is standardized, implement an temporary overlay that provides transparent access to the configuration via legacy uci and new JSON config spaces. From that point on, new applications / packages must not use uci any more. 3) gradually move to new config space Over a defined (and relatively short) transition period, existing packages has to be converted to use the JSON config. At the end of that period, uci should not be used any more. I have developed a few private tools for the overlay-config approach (like conversion from uci to JSON), which are not suitable for upstreaming (C++, proprietary dependencies). From there, my estimate for the implementation workload for the transition (after the config space was standardized) is around 3 man-months. Good Luck, Zefir [1] https://lists.openwrt.org/pipermail/openwrt-devel/2015-January/030422.html On 03/05/2015 01:36 PM, Mat
[OpenWrt-Devel] Re: "UCI overlay" proposal
On Friday, March 6, 2015 11:11:07 PM PDT, Matthias Schiffer wrote: On 03/05/2015 08:25 PM, David Lang wrote: On Thu, 05 Mar 2015 13:36:10 +0100, Matthias Schiffer wrote: ... At the moment we use scripts to edit /etc/config/* to our needs. There are multiple reasons why we'd like to get rid of this: * Changing specific parts of meta-configuration may change large parts of network and firewall configuration. We'd like to avoid writing to the flash more than necessary. the metaconfiguration needs to be stored somewhere, remember that I/O is done in fairly large chunks, it doesn't matter if you write a 5 byte file or a 1k file (possibly even larger), it will generate the same flash usage. besides, how frequently do you expect the configs to change? Even if they change daily, that's not going to cause significant wear on the flash until you start talking about lifetimes on the order of decades. (and hopefully we will have major upgrades being pushed out much more frequently than that) * As long as the UCI config is written to files, admins think they can change them, not anticipating that parts of the config may be rewritten, leading to all kinds of funny misconfigurations. Not actually having the config written out, but generated on the fly, is also an attempt to make the configuration more "fool-proof", by leaving the meta-config as the only way to make changes to the configuraion (in the case of read-only overlays) the typical way to address this is to have your generated files have a header saying that they are generated and that manual edits will disappear. /etc/resolv.conf on my laptop has: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN I can understand your concerns, I'd also like to avoid having to change UCI more than necessary (and more often than necessary). The minimal solution (which is the option 1 I'd proposed) would be just adding support for dlopen-based backend loading and making the default backend configurable (in /etc/uciconf or something like that). I don't like making it so that the admin can't easily see what the config is. Breaking every post on the Internet about troubleshooting and changing settings in OpenWRT is also a problem. Having the config that's in use not show up in the configs will cause these sorts of problems. Option 2 would be nicer in my opinion. I can see other usecases besides ours which would benefit from a way to combine configuration from different sources, so having a generic way to do that in the UCI core could facilitate maintaining such solutions. I agree that we want a good way to combine data from multiple sources, we're just discussing the how. I've also though about just calling this "multi-backend support" instead of "overlays". While that would be very nice and generic for the config consumer, not having a single actual backend would complicate the config write case a lot... with the conf.d approach for each current file, I don't think that the confusion is significant. There will be a little bit, but not much. With a header in /etc/config/wireless telling people not to edit it, but instead make changes in /etc/config/wireless.d the confusion is minimal As to the desire to directly support scripts generating configs. How about extending the normal confd approach so that in addition to combining all files into one, it allowed executables and took whatever was output on stdout and used that as the config text? That would let you put in your scripts to generate the config, but still allow admins to drop in a chunk of text config to override your settings if they wanted to? An admin can trivially see what the script would create by running it (and scripts should have a header giving instructions on how to do this, especially at the start) There is still the question of the granularity of this. The easy way to go is to have it act as if the contents of all the files we combined with cat * and let the normal uci rules for handling duplicates take place (and I'm not sure what those rules are), this would let you override an entire definition, but not override a specific parameter. If we want to have a smarter combination, we will have to define the rules for how the combinations are made (for example, /etc/config/wireless config wifi-iface, how do you tell if a new clause is supposed to override a single parameter on an existing clause vs defining a new interface), and how you "white out" an existing parameter (make it as if it wasn't defined) what granularity were you thinking of? David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
On Mon, 9 Mar 2015, José Vázquez wrote: OpenWRT is a linux distro oriented to networking so the kernel and drivers are important, but you must not forget that the init process (procd and related after AA) is one of the cores of this distro and makes it work. The most relevant packages are oriented to networking, but with the feeds you can make anything that you want, making it very versatile. Also we must take in mind that OpenWRT works with GPL drivers and code (only few are proprietary); I think that one of the main advantages of use them is that anybody can contribute, and IMHO, are easy to maintain. One of the performance penalties come with the network drivers: while proprietary drivers are tightly coupled with the hardware, the drivers developed by OpenWRT guys and collaborators should not be so "complicated" because when the kernel version is changed they can generate a lot of problems and headaches, while more "generic" drivers do not take advantage of all the hardware features, overloading the cpu with tasks that in stock firmwares are managed by specific subsystems that are faster for those specific tasks. there is no reason why the open drivers need to be slower than the proprietary ones. History has shown that with sufficient information, the open drivers end up being as fast, or faster than the proprietary ones. But it does take time and cooperation with the manufacturer to do this with the latest hardware. Open drivers can be modified along with the kernel to take advantage of the newest features in the kernel. Proprietary drivers are either written for one specific kernel, or with a shim layer that limits how well the driver can work with future kernels. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
On Tue, 10 Mar 2015, valent.turko...@gmail.com wrote: Can anyone explain to me how NDAs come into this? Because I remember one discussions with Mikrotik developer who said that they can't release their Atheros driver that they developed as open source because they signed NDA with Atheros? Is Atheros giving some "secret" and proprietary information to companies that sign NDA with them? If this is true then we will never have as fast performance as companies that sign NDAs. Depending on the wording of the NDA, it may be (and frequently has been) possible to write open drivers after signing the NDA. It does limit a bit what you can explain in the comments in the drivers. In some cases (I believe a minority) the NDA prevents you from releasing the driver because the fact that it can get the hardware to do things is deemed 'secret' by the manufacturer. There are a lot of things in Linux that have been developed by developers who have signed NDAs to get access to the detailed specs and access to developers. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
On Wed, 11 Mar 2015, Felix Fietkau wrote: On 2015-03-10 20:22, Zefir Kurtisi wrote: On 03/09/2015 11:28 PM, David Lang wrote: On Mon, 9 Mar 2015, José Vázquez wrote: This gives at least two sources for optimization for the reference driver: 1) save inter-layer processing overhead (passing commands from hostapd directly to HW is cheaper than passing it through 4 layers), and 2) vastly reduce locking when you are in full control of concurrency. The overhead of commands issued by hostapd is pretty much irrelevant. All that matters for driver performance is the actual data path (network stack, mac80211 tx/rx, driver tx/rx). Also, I've not seen any indication in my tests that locking is a measurable cause of performance issues. When it comes to performance issues, guesswork is meaningless, measurements (e.g. profiling results) matter! netperf-wrapper (https://github.com/tohojo/netperf-wrapper) defines a number of tests that we have found extremely useful in measuring bufferbloat (bad latency increases while large transfers are taking place), These tests show upload/download speeds as well as latency measurements. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] "UCI overlay" proposal
On Tue, 10 Mar 2015, Zefir Kurtisi wrote: David, I do not disagree, and in fact I was not proposing a new configuration format. What I tried to point out was a) maintaining a 'meta-configuration' for some config overlay very quickly becomes very challenging and resource consuming It could be, but if you use the conf.d approach I don't see it being either very challenging or resource intensive. b) if the format has to be changed, in OpenWRT JSON should be the obvious choice from a pragmatic point: most of the configuration today already is converted to JSON at runtime to be passed to the various ubus services. If the config format needs to be changed, I wouldn't oppose JSON. I'm just questioning why it would need to change at all. I don't see how it would help, either the overlay problem or the changing config problem. David Lang As for the inherent problem of standardizing a continuously changing configuration, that's what I described as the 'heaviest part'. Considering that there are snmp MIBs released decades ago and (with gradual extensions) still used today, difficult but doable. Anyway, uci is not bad as is generally and does not need a replacement. We have our JSON config overlay and it is doing ok. Alas, it would be a waste of resources if multiple parties were cooking their proprietary overlay system when everybody is trying to reach similar goals. On 03/07/2015 12:00 AM, David Lang wrote: One other thought. If there is a desire to change the format, let's pick a format that's already in use for configuring system rather than inventing yet another one. We should survey the tools that are being written for managing software defined datacenters (openstack and similar) and see if we can use one of those config languages (either as-is or with an automated conversion back and forth) David Lang On Fri, 6 Mar 2015, David Lang wrote: changing the format doesn't solve the problem, it just causes churn in all the software. The problem is the lack of standardization and the fact that the way things are configured changes over time. Not everything is configured in UCI (and this will always be the case because it's not worth trying to change every piece of software available) When you try to design a "standardized config space" that will work in the future for equipment and software that nobody has imagined yet, you are either going to go crazy-complicated to try and cover everything and have people going cross-eyed trying to understand the spec, or you are going to lock things down to be so ridged that new things will be working around your config spec. The best that you can do is to setup a framework to keep the configs from stepping on each other and try to converge similar software to use the same terms in the config where it makes sense (remember, the newcomer may have a better way of looking at the problem, so trying to force it to define it's config the way the legacy things did it can cause big problems) I'm all for tools to convert the format to whatever you want to use, and (as I posted earlier), to have tools to assemble/generate the configs, but requiring changes to every piece of software to just change the format requires more than "every langauage can understand JSON" David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multiple OpenWrt devices collectively managed?
On Sun, 22 Mar 2015, Outback Dingo wrote: On Sun, Mar 22, 2015 at 10:33 AM, valent.turko...@gmail.com < valent.turko...@gmail.com> wrote: On 21 March 2015 at 15:49, Janne Cederberg wrote: Greetings all! Been searching around and found for example OpenWISP but thought I'd ask the list as well: is there some opensource management software for OpenWrt that could control a set of multiple OpenWrt AP's on the same SSID; so basically controlling their channels based on channel use and actively avoiding crowded/DOS'sed channels for example? Best regards, Janne Cederberg Hi Janne, what you are asking for is quite custom piece of software so there is not any open source project with functionality that you ask for. But it is not too difficult to build something like that, try building it yourself and share it with others, or hire somebody to do it for you. Cheers, Valent. Thats actually not true, there are numerous implementations of dashboard management solution for openwrt based routers running mesh, Ive been running a dashboard for well over 6 years now on a large scale wireless deployment. just research openwrt wireless mesh dashboard my understanding of what the OP is asking for is a bit different. Rather than managing mesh systems, the OP is looking for something to manage a bunch of wired infrastructure systems. A large part of this can be done with chef/puppet/ansible/salt/etc, but the specific question is around having something to automatically assign channels amoung the different APs to minimize interference between the APs and between the APs and other things in the area. If there is anyone who has a good program for doing this planning, even if it doesn't manage the configs directly, I'd be very interested in hearing about it. It's not that hard to have each AP report the signal strength of the other APs near it, and then various thigns can be done to create a mapping that will result in the least interference from the other APs in the system (not trivial, but not super hard) but dealing with other APs that aren't part of the network is much harder. It's not enough to know that there is a SSID beaconing on a channel, you have to know how much traffic there is on that channel (airtime usage, not even bits transmitted). On 2.4 GHz you have the added problem that this may be taking place on a channel that overlapps what you are using, so you don't hear the beacon, but you suffer from the interference. I would also be worried about the disruption that would happen as the system decides to shuffle channels and the changes ripple through the system, forcing all clients to reconnect. An AP that is serving clients can't scan other channels to see what conditions are like on those channels. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Building OpenWRT static kernels
On Mon, 23 Mar 2015, Jean-Michel Pouré - GOOZE wrote: Le lundi 23 mars 2015 à 16:21 +0100, Jonas Gorski a écrit : This is currently not easily possible with OpenWrt, as it contains several "out-of-tree" kernel modules, which aren't part of the kernel sources and thus can't be statically linked into the kernel. For example all wifi drivers are build this way, to use newer driver versions with older / "stable" kernel versions. For those build from the kernel sources, you could probably change all CONFIG_FOO to CONFIG_FOO=y in package/kernel/linux/modules/*, which will then make those modules built-in. But this won't work for the out of tree modules. OK. So what kind of security offer OpenWRT to prevent an attacker from loading modules into the kernel? you have to be root to load a module into the kernel, so standard Unix tools for controlling root come into play. Unless you go to extreme lengths, just disabling module loading isn't enough to protect your system from root. root can alter memory (through /dev/kmem and similar), insert breakpoints that change things, and if nothing else, change the kernel image in the flash that will be loaded the next time you boot. I will try a static compilation and report. For information, D-Link routers from the GS-1210 line are compiled with static modules AND GrSec to offer memory randomization and prevent dynamic loading of modules. I don't know how many professional products are compiled with static modules, but my thumbs say "most of them". you would be horrified to look under the covers of most linux based appliances, a lot of them are running a stock redhat/centos install with very little customization outside of the userspace app that they run. Gaping security holes in such appliances are common. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
