Re: OpenWrt One / project update
On Mon, 29 Apr 2024, Michael Richardson wrote: {sorry for the long delay, been unwell} Bjørn Mork wrote: > Maybe it is possible to deploy the system with secure boot and a > protected IDevId key by default, but allowing the user/owner to erase > the key and disable secure boot? This way all use cases could be > supported, including playing with the BL2 code etc. It won't work that way. If someone can easily turn off secure boot, then so can malware. I hope we can go the other way. can you do a hardware lock (jumper, washer under a mounting screw, etc)? David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On Tue, 9 Jan 2024, Paul D wrote: 6GHz seems a starting point nowadays, although I get by with 5GHz. only if all your clients support 6GHz as well, most don't * Packages with cases+PSU are a must for broader acceptance, which explains why the Raspberry Pi bare board is such a failure, right? having a case design available is a good idea, but not shipping it yourself shouldn't be a showstopper. * Having a few H/W variants available provides demand metrics: which variant is more in demand and popular speaks to what people want. at a significant production/inventory cost. A good idea in the long run, but is it really a requirement to start with? David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Terminology
On Tue, 13 Sep 2022, Rich Brown wrote: I am assuming that the code that processes /etc/config/network and /etc/config/wireless is the difficulty. It would be possible to change names on labels in the GUI, and to update the documentation with the new terms. But we need to be able to handle existing configuration files - either to accept them, convert them, or give cogent error messages. I don't see that as the big problem. The big problem I see is all the external documentation (stacktrace for example) that is not under control of the project. 10 years from now you will have people following those instructions, and they need to either work, or give good information about what's going wrong. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Terminology
On Sat, 10 Sep 2022, Arınç ÜNAL wrote: As a start, certain terms have cropped up multiple times in this discussion. Could I ask for definitions for the following terms? Here's my understanding. There is a difference between a physical device that passes bits and the logical interface that communicates with a network range. A given physical devices can have multiple logical interfaces on them, and a logical interface can use multiple physical devices to communicate (i.e. it's not a 1:1 relationship between logical interfaces and physical devices. LUCI is inconsistant and sometimes calls physical devices 'interfaces' and sometimes calls logical interfaces 'interfaces' I would have to go back over this thread to give a better definition for each term, but they are not all names for the same thing as described below (well, they can be in simple configurations, but much more complex configurations are possible, and as people start using the power, the confusion of terms causes problems) David Lang Network: A network represents a group of computers communicating with each other. Interface: Short for network interface. Network Interface: A network interface is the point of interconnection, implemented on the software, between computers. Device: Another term for network interface, used a lot on Linux kernel development. Netdev: A mailing list for all network-related Linux stuff. https://docs.kernel.org/process/maintainer-netdev.html#what-is-netdev Other terms? I think this is inclusive enough. Arınç ___ 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: DSA Mini-tutorial still marked as Work In Progress
On Fri, 9 Sep 2022, Michael Richardson wrote: Jo-Philipp Wich wrote: > Bluntly speaking, DSA is the thing that gives you one Linux network > device per switch port and bridge VLAN filtering is the stuff that > allows you declaring swconfig-esque VLAN port groups on top of an > arbitrary bridge interface. .. > Another conceptual issue I see is that people came to expect a > dedicated "switch" configuration ui which is something that does not > really work with DSA devices anymore since there is no dedicated switch > hardware entity to interact with anymore (DSA takes care of completely > abstracting this away from the user point of view) and that > bridge-vlans just happen to be a configuration detail of a bridge, and > that there happens to be a bridge "br-lan" by default, but a system > could have multiple bridges, or none at all. > So we should also explain why there is no central "switch > configuration" anymore and that this does not translate into a loss of > functionality, but that the former semi opague swconfig switch > configuration entity was dissolved into a bunch of ethernet devices > inside a bridge... +1 One thing that we do need to show is what ethernet devices are on the switch, there is a considerable CPU load to routing traffic through the processor vs through the switch, so when people are deciding what ports to use for different purposes, they need to easily be able to see this info. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
with DSA, do you HAVE to go through the cpu interface and kernel to bridge different ports on the switch? or can you still do vlan routing inside the switch? for the Scale conference, I've done a lot of work using the switch for passing vlan tagged traffic on to other systems while only sending some of it to the CPU (the CPU would be a very significant bottleneck if I tried to send everything though it) David Lang On Wed, 7 Sep 2022, Jo-Philipp Wich wrote: Hi Rich, that tutorial is good ground work imho. One thing I repeatedly noticed (not in the document, but in forum and irc chatter) is that over the time, DSA and bridge VLAN filtering became conflated into one concept while they're actually different pieces; one can do bridge VLAN filtering without DSA and one can utilize DSA without doing bridge VLAN filtering. Bluntly speaking, DSA is the thing that gives you one Linux network device per switch port and bridge VLAN filtering is the stuff that allows you declaring swconfig-esque VLAN port groups on top of an arbitrary bridge interface. I think this is something we should try to better convey in the documentation. For example simple common use cases like: - Making each switch port it's own independent interface with own subnet or - Break out one switch port to turn it into some kind of restricted IoT or guest network access port or - Bridge each ethernet port to another SSID don't require bridge VLAN filtering or touching VLANs in general at all (in contrast to former swconfig). The per-port net devices just have to be taken out of the br-lan bridge and either be put into another bridge or configured as independent network devices. Bridge VLAN filtering on the other hand is only actually needed if you want to deal with VLAN tagged traffic inside the bridge. And even then there's sometimes alternative ways, for example the following two scenarios should be functionally equivalent: - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" - VLAN filtering disabled vs. - Bridge device "br-lan" containing "lan1 lan2 lan3" - VLAN filtering enabled - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as tagged - VLAN device br-lan.10 on top of br-lan In the former case you would put your IP address settings onto the dedicated "br-vlan10" bridge device while in the latter case you would configure the IP addressing on the "br-lan.10" subinterface of the "br-lan" bridge. So maybe it makes sense to focus on the "with DSA, your switch just becomes a linux bridge over a bunch of netdevs" aspect in the mini tutorial and break out any bridge-VLAN related information into a separate advanced VLAN tutorial. Another conceptual issue I see is that people came to expect a dedicated "switch" configuration ui which is something that does not really work with DSA devices anymore since there is no dedicated switch hardware entity to interact with anymore (DSA takes care of completely abstracting this away from the user point of view) and that bridge-vlans just happen to be a configuration detail of a bridge, and that there happens to be a bridge "br-lan" by default, but a system could have multiple bridges, or none at all. So we should also explain why there is no central "switch configuration" anymore and that this does not translate into a loss of functionality, but that the former semi opague swconfig switch configuration entity was dissolved into a bunch of ethernet devices inside a bridge... ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Best VSDL modem-router to target?
Are there any devices out there that support bonded DSL under openwrt? David Lang On Sat, 4 Dec 2021, Andre Heider wrote: Hi, On 03/12/2021 05:28, Andrew Punch wrote: Hi, I live in a small unit, so the usual advice to have a separate VDSL modem, router and ATA isn't great space wise. Is there an all-in-one VDSL modem + router + ATA that would be worth targeting? for DSL on OpenWrt, lantiq is your only option. The default image ships with a DSL firmware, so it's working out of the box. But it's common for users to replace it for better performance, see [0]. There're a few devices which have even the ata working via asterisk, but if you're going asterisk you might as well forget about that analogue crap :P As far as supported devices go, the BT homehub v5a is the only one with 5ghz wifi, which is why it's still a popular device. The next best thing seems to be the fritzbox 7530 (the older model, NOT the ax variant), which is more powerful device. While it's supported, the newer dsl chipset isn't. There's work going on to change that though [1]. The fritzbox 7520 (aka 1&1 homeserver) seems to be the same hardware, it can even be flashed to the vendor 7530 firmware. And that's rather cheap compared to the 7530. That'll be my choice if you don't mind using some not-yet-merged patches. Cheers, Andre [0] https://forum.openwrt.org/t/lantiq-vrx200-xdsl-firmware-recommendation-thread/52937 [1] https://forum.openwrt.org/t/adding-support-for-vrx518-and-maybe-vrx320/55160 I am happy to purchase a spare one for anyone on the mailing list and I'm a software engineer who has done minor kernel fixes. Thanks -Andrew ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 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] 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] 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] [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] 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] 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] 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] [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] [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] 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] 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, 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] 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] [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] 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] [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] [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] [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] [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] [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] [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] 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] 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
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] 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] 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] 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: 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: -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.-
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] [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] 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] 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] 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 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 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: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: 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: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, 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 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] 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] 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] 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] 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)
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" (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)
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)
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] "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] "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)
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)
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] 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] 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
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
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
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
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
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
/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] [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] 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] 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] Dark Destroyer
On Wed, 8 Apr 2015, Peter Lawler wrote: On 08/04/15 05:47, Hartmut Knaack wrote: Give your +1 answer on this mail if you prefer "Dark Destroyer". How does that even work? You're not giving an option to vote for anything else. There are three different subthreads, each looking for answers on that thread ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Designated Driver
+1 On Tue, 7 Apr 2015, Hartmut Knaack wrote: Date: Tue, 07 Apr 2015 21:47:35 +0200 From: Hartmut Knaack To: edgar.sol...@web.de, OpenWrt Development List Subject: Re: [OpenWrt-Devel] Designated Driver That Doodle poll turned out to be spamed/trolled, and everyone could even change or delete other votes. Since this was just communicated over this mailing list, and subscribers are at least basically verified, why not have a good old fashioned poll? Give your +1 answer on this mail if you prefer "Designated Driver". ___ 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] Multiple OpenWrt devices collectively managed?
On Tue, 24 Mar 2015, valent.turko...@gmail.com wrote: After reading comments from all of you I thought of deploying additional devices just as wifi analyzers, as few of you suggested. I have used kismet before, but only as standalone wifi scanner, but there is also an option to deploy kismet-drones and monitor multiple endpoints from central kismet server. That could probably work if you can get alerts from kismet when some channel starts to have lots more traffic than it used to have and then take action if necessary to modify your node's channels. Any thoughts on this approach? The devil is in the details. What does "too much traffic" mean? It could just be the crowd that you are intending to serve using the system, or one person doing a yum update. Then there's the problem of deciding what to do. As I was trying to say in my last, long message, figuring out what channel each AP is on is not a science, it's part art because the system can't know everything (are these APs heavily loaded because this is the keynote and everyone's in one place, or because everyone is in the lobby waiting for the show floor to open in 10 min and will flood in to the area where the APs are idle, etc) I've had cases where vendors on the show floor were demoing video streaming to mobile devices, using their own APs not coordinated with us (and after signing an agreement that they would not do so) where their activity not only clobbered three APs on the show floor, but 6 rooms of APs on the floor above. At some point there's not much you can actually do from a technical point of view other than identifying the problem. Kismit and similar can be useful tools to gather facts, but turning facts into information and figuring out what actions you can take are far from simple. 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 Mon, 23 Mar 2015, Janne Cederberg wrote: I was thinking the same thing David mentioned, namely, that determining channel change criterion is probably not trivial. Are you guys familiar with Cisco Meraki? Thinking about the problem a bit more. First off, I don't believe that this can be completely automated due to the inability to check other channels while providing service, but I do think that the initial setup of such a system can be greatly simplified. first off, the situation that I'm talking about is setting up a multi-AP network with a wired backbone in an area that has some other wifi activity. In my particular focus, this is setting up a conference network where there is already some wifi in place (and they don't turn it off), but if you are setting up a business network and have another company in adjacent offices (or on an adjoining floor) you have the same basic problems. The setup and calibration will take place when things are generally fairly idle. After the APs are deployed and live, scan standard channels for beacons (on 2.4 only bother with 1,6,11,14 the others shouldn't be considered). some of the SSIDs are going to indicate networks that are giong to be busy, some are going to be phones, printers, etc that may have bursts of activity, but are not going to be ongoing major interference sources. It will take a person to categorize these, although a SSID that is seen on multiple channels is probably one to be concerned about. Interference sources on channels may or may not be significant. It's going to be a judgement call. Then put all the APs on the same channel and beacon frequencly for a bit to map out what APs see each other at what strength. Then try to figure out a channel plan that minimizes interference from outside sources and other APs. Include estimates on how low the power can be turned down to reduce AP <-> AP interference. The admin needs the ability to insert modifications (i.e. "I know that a vendor will be using channel X in this area heavily", insert an interference soruce that wasn't detected) Deploy the plan, then designate one or more mobile devices as targets and monitor them closely as they move around the area. This requires an app on the mobile device that can report the signal strength of the AP with each handhake (fancy ping). If any dead areas are found, increase transmission power on the closest APs to provide coverage. sometimes you will need to go back and regenerate a plan. This is a map coloring problem, but you don't know the shape of the vairous areas (because of the shielding/absorbing/reflecting properties of structures), the areas are 3-dimentional, and on 2.4GHz you don't have enough channels to do a non-interference job in any case, so there is no one right answer, or even oen clearly best answer. So different starting points in channel assignment and different orders of walking through the APs to assign channels will result in different plans. Since bodies will affect the range, either a fudge factor will need to be put in, or a walkaround test will need to be doen once crowds form. The entire test will need to be done independently on 2.4GHz vs 5GHz Ideally the software that's doing this lets you take an image and place the APs on that image to then produce a graphical representation of the expected coverage (scale of coverage circles based on the signal strength that the APs hear each other, assume that the picture and AP locations are fairly close to scale accurate. Ideally the mobile app lets the people moving them around the facility tag where they are easily to help show the effects of walls/antennas/etc. If you have "extra" radios (either APs with multiple independent radios per band, or APs that you aren't having users connect to), you may be able to do some scanning while things are live to detect unexpected interference, but generating and testing a plan is disruptive enough that you need to think hard before you try changing things. Since a lot of this is going to depend on where the APs are deployed, and what antennas are put on them (and how the APs/Antennas are positioned), the planning system is not going to be able to fix a bad layout, it can help make it less painful, but there should always be the visualization of what's going on so that an experienced person can look at what the computer decided to do and decide to modify it or throw it out. I've never had the time to go through all of these steps manually when deploying to a location, but they are what I'm thinking of, and I make it a point to see what sort of effect the different types of walls have on the signals when planning for an event. I would love to be able to backstop my educated guesswork with actual measurements to help me find problem spots. David Lang _
Re: [OpenWrt-Devel] Multiple OpenWrt devices collectively managed?
If it's done on a per AP basis, and only happens when nobody is connected, it probably doesn't have much effect. This will work when there aren't a lot of users so the various APs go completely idle on a regular basis. If a client tries to connect right after it has gone idle, they will just end up connecting to a more remote AP (assuming there is one in range) David Lang On Tue, 24 Mar 2015, Janne Cederberg wrote: Oh, sorry Bastian I forgot to comment on your suggestion earlier! Question: how does that "constant" restarting affect network QoS/throughput? -Janne 2015-03-23 23:17 GMT+02:00 Bastian Bittorf : * Janne Cederberg [23.03.2015 22:13]: So there's the auto mode in OpenWrt but that only considers the state of the wifi spectrum at the ifup of the wifi adapter, correct? So if things drastically change later, the AP would stay on the same channel and not switch. what we do in our custom solution: restart the wifi after the last station has left. that triggers often and reshuffles the channels... bye, bastian ___ 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?
Is there any open implementation of this? opencapwap shows no updates in their wiki since 2012 and no files at all on their sourceforge page. I admit to being a bit skeptical about such approaches. They sound good in theory, and work fairly well when there aren't that many users, but I've never seen a commercial system work well when there is really a load on the system (i.e. conference or classroom environments) David Lang On Mon, 23 Mar 2015, xxiao8 wrote: Isn't CAPWAP designed for this? xxiao On 03/23/2015 07:42 PM, openwrt-devel-requ...@lists.openwrt.org wrote: Re: Multiple OpenWrt devices collectively managed? ___ 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] Multiple OpenWrt devices collectively managed?
On Mon, 23 Mar 2015, Bastian Bittorf wrote: * David Lang [23.03.2015 20:19]: 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. we just use hostapd & athXk & acs-survey/channel=auto...why dont you? For one thing I hadn't heard of it before now :-) I would need to test and see what it recommends in real-world conditions. It seems designed for setting up a single AP (although it really shouldn't try every 2.4GHz channel), but when trying to pick channels for a bunch of APs in an area, I see nothing in the documentation that would prevent every AP from picking the same channel because it was marginally better when everything is quiet. Then when you start to see heavy usage, the situaion will have changed drastically and you would have to take time away from servicing clients to scan other channels (during which time you are not transmitting normally, so any other APs doing a survey during the same time would get a faulty view of what the conditions are), and would the system converge to a stable setup, or would it always be shifting traffic. David Lang ___ 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: 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. Yes, I agree with you. For example, DLink DGS-1210 products revision A1 are running a very old 2.6 Linux kernel and it could be very easy to penetrate, especially because no update is done on the firmware. All source code is available, so it is a matter of days before you understand how to break in. You probably only need to look at OpenSSL vulnerability list ... On the converse, we may discuss attack surface : a static kernel can have a very low attack surface. When it includes GrSec, it can become very difficult to penetrate. Hopefully ... DLink appliances are using GrSec. With current OpenWRT configuration, the attack would be Luci => Kernel module. I wonder if specialized companies offer "on the shelf" penetration tools for OpenWRT, but it would not be surprising. IMHO, with current penetration tools, not using GrSec or a static kernel or both is simply too low. the bigger risk is default passwords and non-encrypted management. It doesn't matter if you are using grsecurity, SELinux, etc if your root account is "admin" "password" on every box ever shipped. No matter how secure the box is, if it's never updated, within a few years there will be vulnerabilities known for it. David Lang___ 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
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] "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] 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] 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 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
[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] "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
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
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] [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] 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] 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
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, 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] 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
[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] 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
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] 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] 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