[LEDE-DEV] Bringing young people in the community: Google Code-In 2017
Hi everyone, I'm Federico Capoano, some of you may know me for my involvement with Ninux, NetJSON, OpenWISP and contribution to several editions of the Google Summer of Code with Freifunk. OpenWISP has been accepted into the Google Code-In: https://codein.withgoogle.com/organizations/openwisp/ By participating in this program we hope to attract many new young contributors in the world of open source networking, free wifi and similar topics. We aim at proposing easy tasks related to documentation, tutorials, fixing small code issues, UX improvements and so on. We are looking for mentors that share similar goals with us and want to get involved, for those of you that are following the NetJSON development or using some OpenWISP tool, this would be a good time to start contributing! We also would like to invite mentors that want to propose tasks that are related to OpenWRT/LEDE (as indicated to some of you at the last OpenWRT Summit in Prague). Important notes: - we want mentors to take care of the tasks they propose - please read the GCI rules, in particular section 2, 4 and 5: https://developers.google.com/open-source/gci/resources/contest-rules - take a look at the tasks proposals we are working on (we will export this collaborative spreadsheet to CSV) and import it using the GCI API: https://docs.google.com/spreadsheets/d/1nNNN6Db8fS3KtijO9BJB2YHmMzU20OUBoFrXdWk055I/edit#gid=820690942 If interested, please get in touch with us via our support channels (IRC, mailing list, gitter) http://openwisp.org/support.html or reply in private to me (in order to avoid cross-post hell). Thank you for your attention! Best regards Nemesis ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] GSOC 2017 - Implement NetJSON output in ubus (OpenWRT/LEDE)
Hi Arun, welcome to the community! Just to provide more information, we have to thank Freifunk for their help in getting this GSOC slot, here's the abstract that got this project started: https://wiki.freifunk.net/Ideas#Implement_NetJSON_output_in_ubus_.28OpenWRT.2FLEDE.29 Best regards Federico On 05/10/2017 11:24 AM, Arun Kumar wrote: > Hi Developers, > > I am Arunkumar Ravichandran currently admitted for masters program at > University of California, San Diego. My proposal [1] Implement NetJSON > output in ubus (OpenWRT/LEDE) has been accepted to the GSOC 2017 and I > would like to tell more about my proposed project. > > The main aim of this project is to implement parts of the NetJSON[2] > specification in the OpenWRT/LEDE ecosystem. > > Why NetJSON ?? > NetJSON would allow standardization similar to NETCONF. Since NetJSON > uses JSON format, it makes the management of configurations done at a > higher level and larger scale to be automated easily. By using NetJSON > objects to either produce or collect information, in different > vendor’s different hardware, it allows the developers to work on their > ideas faster and in a better way. > > Implementation: > The support for NETJSON is brought in at the interconnect system- > ubus[3]. To add support for a new ubus API which allows retrieving > these two NetJSON object types: DeviceConfiguration[6] and > DeviceMonitoring[7]. The NetJSON objects are filled in using the > plugins available in System Configuration Abstraction Layer(SCAL)[4]. > Full project proposal can be read at [5]. > > I would welcome further suggestions from the LEDE/ OpenWRT community > as that would help in implementing this feature sooner and in a better > way, and also more resilient to multiple data models which are being > used to represent network configurations. > > [1] > https://wiki.freifunk.net/Ideas#Implement_NetJSON_output_in_ubus_.28OpenWRT.2FLEDE.29 > [2] https://github.com/netjson/netjson > [3] https://lede-project.org/docs/guide-developer/ubus > [4] https://github.com/prplfoundation/scal > [5] > https://docs.google.com/document/d/1b6zersOA_GjUqbOjuaXvFd4E40l1MqUXjIyVagLLd08/edit?usp=sharing > [6] http://netjson.org/docs/what.html#deviceconfiguration > [7] http://netjson.org/docs/what.html#devicemonitoring > > Thanks, > Arun > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Test results of OpenWrt 15.05.1 according to BSI test concept for home routers
On 04/26/2017 10:23 PM, Eric Schultz wrote: > On 04/08/2017 11:38 AM, Hauke Mehrtens wrote: > >> The German Bundesamt für Sicherheit in der Informationstechnik (short: >> BSI, English: Federal Office for Information Security) published a >> "Testkonzept für Breitband-Router (DSL-, Kabel-, SOHO-, CE-, CPE-Router, >> IADs)" (English: Test concept for broadband routers). This test concept >> is only available in German and most chapters are published in the >> public by the BSI, chapter 4 and 5 are only available after signing a >> NDA (Traffic Light Protocol) with the BSI: >> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/Themen/Testkonzept-Breitbandrouter.pdf?__blob=publicationFile=5 >> >> Some unnamed organization tested OpenWrt 15.05.1 on a TP-Link TL-WR841N >> V10.0 according to this test concept. Because I commented on the first >> public draft of the test concept and said that I am active in the >> OpenWrt project, the organization contacted me to check if their test >> results are correct and provided me with the full test report under NDA. >> >> >> OpenWrt 15.05.1 failed this test and LEDE will probably also fail this >> test, because we failed on section 4.5.1 "Firewall-Bypass", which is a >> criterion for exclusion (Ausschlusskriterium), see details below. >> >> The test concept focus on "normal" routers and only tests the web GUI >> and also looks mostly on features normal home routers have. We are >> missing some functionality like individual default password, for the web >> GUI and the Wifi, the logging is not very good and so on. The tests >> regarding DNS are interesting and more advanced, if someone wants to >> look into that it would be very nice. >> >> The main problem is in section 4.5.1 "Firewall-Bypass". >> OpenWrt and LEDE implement RFC4890 section 4.3.1: >> --- >> 4.3.1. Traffic That Must Not Be Dropped >> >>Error messages that are essential to the establishment and >>maintenance of communications: >> >>o Destination Unreachable (Type 1) - All codes >>o Packet Too Big (Type 2) >>o Time Exceeded (Type 3) - Code 0 only >>o Parameter Problem (Type 4) - Codes 1 and 2 only >> >>Appendix A.4 suggests some more specific checks that could be >>performed on Parameter Problem messages if a firewall has the >>necessary packet inspection capabilities. >> >>Connectivity checking messages: >> >>o Echo Request (Type 128) >>o Echo Response (Type 129) >> --- >> >> The BSI used RFC6092 (Recommended Simple Security Capabilities in >> Customer Premises Equipment (CPE) for Providing Residential IPv6 >> Internet Service) with this section as the base for the test: >> --- >> 3.2.1. Internet Control and Management >> >>Recommendations for filtering ICMPv6 messages in firewall devices are >>described separately in [RFC4890] and apply to residential gateways, >>with the additional recommendation that incoming "Destination >>Unreachable" and "Packet Too Big" error messages that don't match any >>filtering state should be dropped. >> >>REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination >>Unreachable" and "Packet Too Big" messages containing IP headers that >>do not match generic upper-layer transport state records. >> --- >> >> >> Attached are the results of this test of OpenWrt 15.05.1. The >> information on how the tests from chapter 4 and 5 are done is redacted >> from the document, if you want to work on these problems and would like >> to get more details about the problems from chapter 4 and 5, please >> contact me. I can also help you with translating the problem from German >> to English. ;-) >> >> The "sensitive" informations are under the Traffic Light Protocol >> classification "TLP AMBER", see these German information about the NDA: >> https://mip.bsi.bund.de/Anlage_1_TLP-Merkblatt.pdf >> >> >> I commented on the tests itself, because they are missing many important >> stuff to test, most of the security problem of IoT devices and home >> routers one hears about in the media are not covered here at all. >> >> >> History: >> 20.10.2015: I read this article https://heise.de/-2851354 and wrote some >> comments to the BSI based on the first public draft. In this mail I >> mentioned that I am activate in the OpenWrt project. >> 23.10.2015: The BSI answered me and offered me the full draft when I >> would sign an NDA, I did so and got the full document, but did not >> comment on it again. >> 23.2.2016: I got the full final draft from the BSI >> 22.11.2016: I was told by the unnamed organization that they tested a >> TP-Link device running OpenWrt 15.05.1 and if I could comment on their >> results. I got the results under the NDA and
[LEDE-DEV] Idea: LEDE development sprint
I proposed this idea for the next OpenWRT/LEDE summit which I would like to see come true. I regularly participate to Django (a python web framework) development sprints when I go to international Django conferences. These sprints consist in sitting in a room full of tables, power plugs, developers and many django core developers which offer help to contributors that want to help out fixing bugs, triaging tickets, closing invalid tickets and everything that has to do with bug-fixing and improvement of the project in general. It's really great: it's fun, educational, it builds a stronger community. So why not do this for LEDE too? I'm not a core developer of LEDE, so I need to know what the community and the most active developers think about this idea and if they would be willing to participate. Let me know! It would be exciting!! Federico ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Implement NetJSON output in ubus (OpenWRT/LEDE)
We are looking for students that want to work on this GSoC idea: Implement NetJSON output in ubus (OpenWRT/LEDE): https://wiki.freifunk.net/Ideas#Implement_NetJSON_output_in_ubus_.28OpenWRT.2FLEDE.29 If you are interested, get in touch with Eric Shultz and myself. Thank you Federico ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] OpenWISP Endorses LEDE
Many thanks to the LEDE community and core contributors for the 17.01 release! I just published this news: http://openwisp.org/news/lede.html https://twitter.com/openWISP/status/837731126827495425 We switched our repositories to default to LEDE 17.01: openwisp-config: https://github.com/openwisp/openwisp-config/commit/35067c857da53398060ec63a4437c677b59f2d4b luci-openwisp: https://github.com/openwisp/luci-openwisp/commit/fd00c439997d3442d540cd8b112bccde3447f0b1 image-generator: https://github.com/openwisp/ansible-openwisp2-imagegenerator/commit/51eda4c531b05f1fe6bc96359e7f3f1875145863 These changes were already released in the previous days. This should help LEDE to grow a bit, since OpenWISP has been growing a bit latelly. We are getting new users every day and now these users will start using LEDE too (some enthusiasts already are). Bytheway, OpenWISP is an accepted mentoring organization for the Google Summer of Code 2017, if you work on open source wifi networks, you may want to find out more at: http://openwisp.org/gsoc/ideas-2017.html Freifunk was accepted too: https://wiki.freifunk.net/Ideas Best regards Federico Capoano (core developer of OpenWISP and contributor of Ninux.org) signature.asc Description: OpenPGP digital signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] curl --capath not supported on mbedtls but was supported on polarssl
Hi everyone, I hit something that seems like a regression to me. In a little program named openwisp-config [1], we are using the --capath argument, when switching - as was widely suggested - from polarssl to mbedtls, we noticed curl cannot use the capath argument. There's also a thread in the forum here: https://forum.lede-project.org/t/capath-not-supported-by-libcurl-with-mbedtls-support/947/8 I would like to ask 2 questions 1. is it's desired behaviour or a regression? 2. what's an alternative way to tell curl and or wget to find certificates? Thx in advance Federico [1] https://github.com/openwisp/openwisp-config ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] ImageBuilder ar71xx BIN_DIR issue
Hi everybody, today we started testing lede-17.01 for OpenWISP.org and we noticed a strange issue with the image-generator. We supply a command like: make image PROFILE="Default" BIN_DIR="$BIN_DIR" but the image building fails because something goes to look for binaries in ./bin/targets/ar71xx/generic instead of "$BIN_DIR/targets/ar71xx/generic". If we create manually the dir with: mkdir ./bin/targets/ar71xx/generic The image building procedure completes successfully. Is this desired behaviour or not? Regards Federico ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Status of OpenWrt feeds in LEDE
Hi Michael On 05/08/2016 10:59 PM, W. Michael Petullo wrote: > I am the maintainer of a number of OpenWrt packages, and I am watching > with interest the emargence of the LEDE project. Some time ago, OpenWrt > migrated to GitHub for some of its feeds, including the packages feed. At > that time, many of the packages were deprecated until the maintainter > manually migrated them to GitHub (e.g., gstreamer1). I just finished an > initial review of the LEDE Git repositories, and it seems a number of > packages are missing. Will we go through a period of manual migration > again? What is in store for all of these packages with respect to LEDE? > > Thank you, As far as I understood, we are going to continue using the current package repo on the openwrt github org [1]. Nemesis [1]: https://github.com/openwrt/packages ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
