Re: OpenWrt One / project update

[David Lang]

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

[David Lang]

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

[David Lang]

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

[David Lang]

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

[David Lang]

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

[David Lang]

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?

[David Lang]

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

[David Lang]

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

[David Lang]

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

[David Lang]

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

[David Lang]

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 Open Compute Project (OCP)

[David Lang]

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)

[David Lang]

If you run into problems configuring rsyslog, we have a fairly active mailing 
list at rsyslog-users <rsys...@lists.adiscon.com>, 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

[David Lang]

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

[David Lang]

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

[David Lang]

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

[David Lang]

On Wed, 21 Dec 2016, Dave Taht wrote:


On Wed, Dec 21, 2016 at 12:29 PM, David Lang <da...@lang.hm> 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

[David Lang]

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?

[David Lang]

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

[David Lang]

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 <n...@nbd.name> 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?

[David Lang]

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 <wigy...@uid0.hu> 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

[David Lang]

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

[David Lang]

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

[David Lang]

On Tue, 24 May 2016, Luka Perkov wrote:


Date: Tue, 24 May 2016 16:06:13 +0200
From: Luka Perkov <l...@openwrt.org>
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)

[David Lang]

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)

[David Lang]

On Mon, 16 May 2016, Roman Yeryomin wrote:


On 16 May 2016 at 11:12, David Lang <da...@lang.hm> wrote:

On Mon, 16 May 2016, Roman Yeryomin wrote:


On 6 May 2016 at 22:43, Dave Taht <dave.t...@gmail.com> wrote:


On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin <leroi.li...@gmail.com>
wrote:


On 6 May 2016 at 21:43, Roman Yeryomin <leroi.li...@gmail.com> wrote:


On 6 May 2016 at 15:47, Jesper Dangaard Brouer <bro...@redhat.com>
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)

[David Lang]

On Mon, 16 May 2016, Roman Yeryomin wrote:


On 6 May 2016 at 22:43, Dave Taht <dave.t...@gmail.com> wrote:

On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin <leroi.li...@gmail.com> wrote:

On 6 May 2016 at 21:43, Roman Yeryomin <leroi.li...@gmail.com> wrote:

On 6 May 2016 at 15:47, Jesper Dangaard Brouer <bro...@redhat.com> 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

[David Lang]

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

[David Lang]

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

[David Lang]

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

[David Lang]

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 <leroi.li...@gmail.com>
escreveu:


On 4 May 2016 at 19:25, Kathy Giori <kathy.gi...@gmail.com> wrote:

On Tue, May 3, 2016 at 10:59 AM, Jo-Philipp Wich <j...@openwrt.org>

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

[David Lang]

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 <guille...@geryon.com.ar>
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

[David Lang]

Just a side note while you are working in this area.

all the documentation for udhcpc (including it's default config settings) says 
that it uses one default file path, but when it's run that path gets overridden 
on the command line and a different file is used instead.


The default in the config should be changed to what's actually used and the 
extra copy should be eliminated.


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

Re: [OpenWrt-Devel] Question about custom script at init on Trunk.-

[David Lang]

On Wed, 27 Jan 2016, Karl Palsson wrote:


David Lang <da...@lang.hm> 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.-

[David Lang]

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

[David Lang]

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

[David Lang]

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] First boot provisioning

[David Lang]

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

[David Lang]

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

[David Lang]

On Wed, 14 Oct 2015, Roman Yeryomin wrote:


On 13 October 2015 at 23:08, David Lang <da...@lang.hm> 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

[David Lang]

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

[David Lang]

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

[David Lang]

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

[David Lang]

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] AR9344 OpenWrt GUI

[David Lang]

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

[David Lang]

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)

[David Lang]

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 da...@lang.hm 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 da...@lang.hm 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 kerry9...@gmail.com
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 da...@lang.hm 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 kerry9...@gmail.com
To: David Lang da...@lang.hm
Cc: Alex Weedy weedy2...@gmail.com,
OpenWrt Development List openwrt-devel@lists.openwrt.org
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 kerry9...@gmail.com
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

Re: [OpenWrt-Devel] Fwd: 3-address Wi-Fi bridging (was: Multiple Wi-Fi client/AP interfaces on one radio)

[David Lang]

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 kerry9...@gmail.com
To: David Lang da...@lang.hm
Cc: Alex Weedy weedy2...@gmail.com,
OpenWrt Development List openwrt-devel@lists.openwrt.org
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 da...@lang.hm 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 da...@lang.hm wrote:


On Mon, 10 Aug 2015, John kerry wrote:


Date: Mon, 10 Aug 2015 18:10:14 +0800


From: John kerry kerry9...@gmail.com
To: Alex Weedy weedy2...@gmail.com,
OpenWrt Development List openwrt-devel@lists.openwrt.org
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 kerry9...@gmail.com 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 da...@lang.hm 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

Re: [OpenWrt-Devel] Fwd: 3-address Wi-Fi bridging (was: Multiple Wi-Fi client/AP interfaces on one radio)

[David Lang]

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 kerry9...@gmail.com
To: David Lang da...@lang.hm
Cc: Alex Weedy weedy2...@gmail.com,
OpenWrt Development List openwrt-devel@lists.openwrt.org
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 kerry9...@gmail.com 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 da...@lang.hm 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 kerry9...@gmail.com
To: David Lang da...@lang.hm
Cc: Alex Weedy weedy2...@gmail.com,
OpenWrt Development List openwrt-devel@lists.openwrt.org
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 da...@lang.hm 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

Re: [OpenWrt-Devel] Fwd: 3-address Wi-Fi bridging

[David Lang]

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)

[David Lang]

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 da...@lang.hm wrote:


On Mon, 10 Aug 2015, John kerry wrote:

Date: Mon, 10 Aug 2015 18:10:14 +0800

From: John kerry kerry9...@gmail.com
To: Alex Weedy weedy2...@gmail.com,
OpenWrt Development List openwrt-devel@lists.openwrt.org
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 kerry9...@gmail.com 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 da...@lang.hm 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)

[David Lang]

On Mon, 10 Aug 2015, John kerry wrote:


Date: Mon, 10 Aug 2015 18:10:14 +0800
From: John kerry kerry9...@gmail.com
To: Alex Weedy weedy2...@gmail.com,
OpenWrt Development List openwrt-devel@lists.openwrt.org
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 kerry9...@gmail.com 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 da...@lang.hm 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)

[David Lang]

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 kerry9...@gmail.com
To: David Lang da...@lang.hm
Cc: Weedy weedy2...@gmail.com,
OpenWrt Development List openwrt-devel@lists.openwrt.org,
Joshua Judson Rosen jro...@harvestai.com
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 da...@lang.hm 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 da...@lang.hm 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 weedy2...@gmail.com wrote:

On 6 Aug 2015 23:15, John kerry kerry9...@gmail.com 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

Re: [OpenWrt-Devel] 3-address Wi-Fi bridging (was: Multiple Wi-Fi client/AP interfaces on one radio)

[David Lang]

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 kerry9...@gmail.com 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 da...@lang.hm 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 weedy2...@gmail.com wrote:

On 6 Aug 2015 23:15, John kerry kerry9...@gmail.com 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)

[David Lang]

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 da...@lang.hm 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 weedy2...@gmail.com wrote:

On 6 Aug 2015 23:15, John kerry kerry9...@gmail.com 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)

[David Lang]

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 weedy2...@gmail.com wrote:


On 6 Aug 2015 23:15, John kerry kerry9...@gmail.com 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

[David Lang]

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 kerry9...@gmail.com 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 weedy2...@gmail.com 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 kerry9...@gmail.com 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'
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

Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings

[David Lang]

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 kerry9...@gmail.com
To: David Lang da...@lang.hm
Cc: Weedy weedy2...@gmail.com, N. Leiten nicklei...@gmail.com,
OpenWrt Development List openwrt-devel@lists.openwrt.org
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 da...@lang.hm 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 kerry9...@gmail.com 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

Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings

[David Lang]

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 da...@lang.hm 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 kerry9...@gmail.com
To: David Lang da...@lang.hm
Cc: Weedy weedy2...@gmail.com, N. Leiten nicklei...@gmail.com,
OpenWrt Development List openwrt-devel@lists.openwrt.org
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 da...@lang.hm 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 kerry9...@gmail.com
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

Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings

[David Lang]

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 kerry9...@gmail.com
To: David Lang da...@lang.hm
Cc: N.Leiten nicklei...@gmail.com,
OpenWrt Development List openwrt-devel@lists.openwrt.org,
Alex Weedy weedy2...@gmail.com
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 da...@lang.hm 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 kerry9...@gmail.com wrote:

Hello Guys,


It's working. Thanks a lot to all of you :)

On Mon, Aug 3, 2015 at 10:43 AM, David Lang da...@lang.hm 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 da...@lang.hm wrote:

to make the config be there after a factory reset, you need

Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings

[David Lang]

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 kerry9...@gmail.com wrote:


Hello Guys,

It's working. Thanks a lot to all of you :)

On Mon, Aug 3, 2015 at 10:43 AM, David Lang da...@lang.hm 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 da...@lang.hm 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 kerry9...@gmail.com
wrote:

Hi Leiten,



Thank you so much, Its working :)

On Sun, Aug 2, 2015 at 3:12 PM, N.Leiten nicklei...@gmail.com
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 nicklei...@gmail.com
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 kerry9...@gmail.com:

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

Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings

[David Lang]

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 kerry9...@gmail.com wrote:


Hi Leiten,

Thank you so much, Its working :)

On Sun, Aug 2, 2015 at 3:12 PM, N.Leiten nicklei...@gmail.com 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 nicklei...@gmail.com 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 kerry9...@gmail.com:

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

[David Lang]

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 da...@lang.hm 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 kerry9...@gmail.com wrote:

Hi Leiten,


Thank you so much, Its working :)

On Sun, Aug 2, 2015 at 3:12 PM, N.Leiten nicklei...@gmail.com 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 nicklei...@gmail.com 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 kerry9...@gmail.com:


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

[David Lang]

/etc/config/wireless

On Fri, 31 Jul 2015, N.Leiten wrote:


Date: Fri, 31 Jul 2015 12:32:14 +0300
From: N.Leiten nicklei...@gmail.com
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

[David Lang]

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 n...@vthadden.de
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 b...@gowasabi.net 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 mgeral...@yahoo.de
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
n...@vthadden.de 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
(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
# entries 304002 and 305002
(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW
# entries 308002, 309001 and 310003
(5470 - 5725 @ 160), (500 mW), DFS
# 60 gHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
Thas does not work and has

Re: [OpenWrt-Devel] openwrt-ar71xx GUI

[David Lang]

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

[David Lang]

On Fri, 17 Jul 2015, Cristian Morales Vega wrote:


On 17 July 2015 at 16:43, Jonas Gorski j...@openwrt.org 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] Designated Driver

[David Lang]

+1

On Tue, 7 Apr 2015, Hartmut Knaack wrote:


Date: Tue, 07 Apr 2015 21:47:35 +0200
From: Hartmut Knaack knaac...@gmx.de
To: edgar.sol...@web.de,
OpenWrt Development List openwrt-devel@lists.openwrt.org
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] Dark Destroyer

[David Lang]

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] Multiple OpenWrt devices collectively managed?

[David Lang]

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?

[David Lang]

On Mon, 23 Mar 2015, Bastian Bittorf wrote:



* David Lang da...@lang.hm [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

[David Lang]

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?

[David Lang]

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?

[David Lang]

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 bitt...@bluebottle.com:

* Janne Cederberg janne.cederb...@gmail.com [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] Why OpenWrt sucks?

[David Lang]

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?

[David Lang]

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?

[David Lang]

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

[David Lang]

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

[David Lang]

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 latter being our main usecase -
we'd like to generate configuration for netifd and fw3 based on
meta

Re: [OpenWrt-Devel] UCI overlay proposal

[David Lang]

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, Matthias Schiffer wrote:

Hi,
during the development of our Freifunk firmware

Re: [OpenWrt-Devel] UCI overlay proposal

[David Lang]

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

[David Lang]

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 dgcb...@gmail.com
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 dgcb...@gmail.com
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 DGND3800B factory firmware
+$(eval $(call 
ImageDTB,ChkDTB,DGND3700v1_3800B,DGND3800B,,DGND3700v1_3800B,U12L144T11_NETGEAR_NEWLED,1))
# Pirelli Alice Gate VoIP 2 Plus Wi-Fi AGPF-S0
$(eval $(call ImageDTB,CFEDTB,AGPF_S0,AGV2+W,agpf-s0,AGPF-S0,6358,--block-size 
0x2 --image-offset 0x2 --signature2 IMAGE --tag-version 8))
# Pirelli A226G
diff --git a/target/linux/brcm63xx/profiles/netgear.mk 
b/target/linux/brcm63xx/profiles/netgear.mk
index 75ddab5..20224a2 100644
--- a/target/linux/brcm63xx/profiles/netgear.mk
+++ b/target/linux/brcm63xx/profiles/netgear.mk
@@ -12,7 +12,6 @@ endef
define Profile/CVG834G/Description
  Package set optimized for CVG834G.
endef
-
$(eval $(call Profile,CVG834G

Re: [OpenWrt-Devel] General questions about the direction of switch drivers

[David Lang]

On Mon, 16 Feb 2015, Charlie Smurthwaite wrote:


I'm writing a driver for a family of 24 port gigabit switches, with a
wide array of interesting hardware features. Creating basic VLAN
membership and tagging functionality under the swconfig framework has
been quite easy, and this framework has been excellent for this.

However, I would like to support a lot more of the functionality of this
hardware, and see other devices with advanced layer2 and layer3
switching supported in the future, so I wanted some opinion on the
direction things are taking.

Specifically I am looking for opinion on whether the swconfig framework
is suitable for more advanced functionality, or whether there was likely
to be a move to any other upstream framework for switch devices,
particularly those with more advanced functionality. The types of
functionality I am currently interested in supporting are:

* VLAN membership an tagging
* Packet and byte counters
* Security settings and filtering rules
* STP
* Layer 3 functionality (hardware IPv4 and IPv6 routing tables)
* Hardware NAT / firewall

Some of this functionality may simply require configuration, where other
functions require the active involvement of the CPU.


A work-around for many of the items other than the basic VLAN membership and 
tagging is to force the traffic between the different switch ports to go through 
the CPU by putting the different ports on different VLANs and then using the 
kernel bridging/firewalling/etc features. You can't do this between switch ports 
that are trunked (exposeing the VLAN tags), but other than the cpu load and 
admin confusion, it works very well to just do this in the kernel. How much of 
the functions that requrie active involvement of the CPU end up 
being a variation of this?


I am curious as to what other switch device frameworks are out there.

It's worth noting that the vast majority of OpenWRT devices have a single switch 
in them, and that switch is typically not the fanciest (although the march of 
technology mens that every year it's going to be better than it used to be)


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

Re: [OpenWrt-Devel] General questions about the direction of switch drivers

[David Lang]

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

[David Lang]

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

[David Lang]

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] enabling seccomp by default in kernel

[David Lang]

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

[David Lang]

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

[David Lang]

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

[David Lang]

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

[David Lang]

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 ?

[David Lang]

On Fri, 3 Oct 2014, Urs Rau (UK) wrote:


Hi Jo-Philipp,

On 26 Sep 2014, at 09:55, Jo-Philipp Wich 
j...@openwrt.orgmailto:j...@openwrt.org wrote:

Hi.

The wan port is likely a dedicated, non-switch interface (e.g. eth1) on
this model. If you want to declare VLANs on it then simply create a new
interface using eth1.Y as manual physical ifname where Y denotes the
desired VLAN id.

~ Jow

yes, I think you are right.

eth0 is the yellow wan port

and eth1 is the 4 port switch on this hardware

but now I have a problem, how do i get tagged VLAN  traffic coming in on 
eth0.96 eth0.128 eth0.144 eth0.160 eth0.168 to ‘connect’ or ‘forward’ to the 
relevant eth1.VLANID ? on other models the wan port is part of the same switch 
and I can tick the ‘cpu’ port in luci to ‘transport’ or ‘forward’ the right wan 
VLAn with the right LAN port 1 - 4.

How can I do this on this hardware which has one wan port that is not part of 
the switch and for lan ports that are part of the switch that luci shows under 
the ‘switch’ page?

or do I have to ‘forget’ about using the ‘wan’ port and work with the lan ports 
1 - 4 only?


you bridge between the eth0.x and eth1.x interfaces (where x is the VLAN)

keep in mind that since this traffic is going through the kernel to get from one 
side to the other instead of just through the switch, it is going to be slower.


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

Re: [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt

[David Lang]

On Thu, 2 Oct 2014, Alpha Sparc wrote:


How good is the throughput on CeroWrt compared to OpenWrt ?


The focus of CeroWrt is on reducing latency, not increasing throughput. If you 
run into really badd bufferbloat problems without these scrips, then these 
scripts can result more more 'goodput' (useable data as opposed to 'throughput' 
bits on the wire) getting through, but in the usual case there will be a 
(slight) reduction in the peak throughput.


This is especially so on the inbound side of things because the router is having 
to work indirectly to throttle the senders so that they don't overload the 
router at the other end of the connection.


I beleive that on the WNDR3800, it's able to work up to about 50Mb with the 
existing configurations. A faster CPU would do better, a slower one worse. The 
re-write that Dave is talking about is hoting to improve this. From the pastebin 
link Dave listed below, they have it up to ~80Mb now


David Lang


On Oct 2, 2014 9:55 AM, Dave Taht dave.t...@bufferbloat.net wrote:


On Wed, Oct 01, 2014 at 12:10:46PM -0400, Weedy wrote:

On 30/03/14 06:29 PM, Dave Taht wrote:

On Sun, Mar 30, 2014 at 02:24:44PM -0400, Weedy wrote:

On Sat, Mar 29, 2014 at 2:56 PM, Dave Täht dave.t...@bufferbloat.net

wrote:



From: Dave Taht dave.t...@bufferbloat.net

This adds support for the bufferbloat project's Smart Queue

Management

(SQM) system, which improves over openwrt's qos-scripts in the

following

ways

+ Uses HTB with two models for managing traffic
  a simplest one that merely uses fq_codel, and a three tier one

that does

  some basic and tunable packet prioritization.

+ Works with ipv6 and ipv4 correctly (unlike qos-scripts)
+ extensive support for fixing ADSL and PPOe framing problems
+ Partial support for key diffserv markings
+ highly tuned fq_codel implementation especially for low bandwidths
+ Tested heavily on cable modems and on dsl devices

It is a disimprovement in that:

- There are no built-in tricks for doing l7 classification,
or other forms of packet inspection.

- We haven't explored hfsc all that much, prefering to rely
on the predictable behavior of htb + fq_codel for everything

- And there is support for a few qdiscs that are not in the linux
kernel mainline that remain experimental.
---
 net/sqm-scripts/Makefile   |   48 +++
 net/sqm-scripts/files/etc/config/sqm   |   11 +
 net/sqm-scripts/files/etc/init.d/sqm   |   23 ++
 net/sqm-scripts/files/usr/lib/sqm/functions.sh |  335

 net/sqm-scripts/files/usr/lib/sqm/run.sh   |   67 
 net/sqm-scripts/files/usr/lib/sqm/simple.qos   |  187

+++

 net/sqm-scripts/files/usr/lib/sqm/simple.qos.help  |1 +
 net/sqm-scripts/files/usr/lib/sqm/simplest.qos |   84 +
 .../files/usr/lib/sqm/simplest.qos.help|1 +
 net/sqm-scripts/files/usr/lib/sqm/stop.sh  |   22 ++
 10 files changed, 779 insertions(+)
 create mode 100644 net/sqm-scripts/Makefile
 create mode 100644 net/sqm-scripts/files/etc/config/sqm
 create mode 100755 net/sqm-scripts/files/etc/init.d/sqm
 create mode 100644 net/sqm-scripts/files/usr/lib/sqm/functions.sh
 create mode 100755 net/sqm-scripts/files/usr/lib/sqm/run.sh
 create mode 100755 net/sqm-scripts/files/usr/lib/sqm/simple.qos
 create mode 100644 net/sqm-scripts/files/usr/lib/sqm/simple.qos.help
 create mode 100755 net/sqm-scripts/files/usr/lib/sqm/simplest.qos
 create mode 100644

net/sqm-scripts/files/usr/lib/sqm/simplest.qos.help

 create mode 100755 net/sqm-scripts/files/usr/lib/sqm/stop.sh

diff --git a/net/sqm-scripts/files/etc/config/sqm
b/net/sqm-scripts/files/etc/config/sqm
new file mode 100644
index 000..547d321
--- /dev/null
+++ b/net/sqm-scripts/files/etc/config/sqm
@@ -0,0 +1,11 @@
+
+config queue 'ge00'
+option enabled '0'
+option interface 'ge00'
+option download '2'
+option upload '4000'
+option qdisc 'fq_codel'
+option script 'simple.qos'
+option qdisc_advanced '0'
+option linklayer 'none'
+



How hard is this to config from the command line/vim?


There are a few more options than this (for DSL compensation, ecn
and advanced configuration), the above would work if you changed
enabled to '1' and the device from ge00 to your wan device. (not
the wan firewall rule, presently. )

It does help to have a sane long term and realistic measurement of your
network using something like the rrul test rather than the oft-gamed

speedtest.




http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310


You are right, we should fully document all the variables in this file.
Until recently they were kind of in flux.


I've never needed or really wanted luci on my box, I just use vim.

Going by

this patch, there is either nothing to config or no examples. I would

think

shipping a roughly equivalent config to what ships in qos-scripts

would be

a good start

Re: [OpenWrt-Devel] overcommit memory/ratio

[David Lang]

On Sat, 20 Sep 2014, Nikos Mavrogiannopoulos wrote:


On Fri, 2014-09-19 at 18:39 -0700, David Lang wrote


Well being used to something bad, doesn't mean things cannot get better.
Routers (to which I have some experience at), rarely have processes
running that wouldn't matter if they are randomly killed; on a desktop
system you immediately notice an issue, and you can reboot, a router is
typically running unattended. Being locked out of such a system because
another process had a memory leak, can be an issue.


Turning off overcommit so that a program that wants to spawn a child will end up
requiring double it's memory (for the time between the fork and the exec) is
likely to cause programs to fail when they don't need to.


I'd be surprised if fork and exec worked that way. After a fork the two
processes share the same physical pages (see the notes on fork()
manpage), and overcommit applies to physical ram, not virtual.


No, Overcommit says that you can have more virtual RAM than physical RAM + swap. 
That's what overcommit is.


So when you fork a process, it takes double the memory with overcommit off than 
it does with overcommit on.



And unlike desktops, you can't just say allocate a lot of swap to
cover this up.


The same argument works the other way as well. A process using more
memory than the available in the router will force some other
(arbitrary) process to be killed. Unlike desktops you can't just say
allocate a lot of swap to cover this up.

What you _can_ do, is tell to the process that uses more memory than the
existing one, that there is no memory left.


But turning overcommit off doesn't tell a process that uses more memory than the 
existing one that there is no memory left, it tells the first process that tries 
to allocate memory after it runs out that there is no memory left.


This could be the process that's using an unusual amount of memory, or it could 
be sshd allocating a buffer to use to log.


Even if it gets the right process, you are assuming that the programs properly 
check for errors after anything that allocates memory. This is very commonly not 
the case, so you still get random failures.


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

Re: [OpenWrt-Devel] overcommit memory/ratio

[David Lang]

On Wed, 17 Sep 2014, Nikos Mavrogiannopoulos wrote:


On Tue, 2014-09-16 at 22:29 +, Karl P wrote:

Alternatively, if you know which process it is, set it's oom_adj_score so that
it gets killed first.



  Some other people are kinda used to things behaving as
they are, for better or worse.  (Turning off overcommit on an openwrt device is
no different than turning off overcommit on a desktop as far as I'm concerned.
Somethings will be better, lots of things less so)


Well being used to something bad, doesn't mean things cannot get better.
Routers (to which I have some experience at), rarely have processes
running that wouldn't matter if they are randomly killed; on a desktop
system you immediately notice an issue, and you can reboot, a router is
typically running unattended. Being locked out of such a system because
another process had a memory leak, can be an issue.


Turning off overcommit so that a program that wants to spawn a child will end up 
requiring double it's memory (for the time between the fork and the exec) is 
likely to cause programs to fail when they don't need to.


And unlike desktops, you can't just say allocate a lot of swap to cover this 
up.


In spite of what some people say, it's far from a clear-cut win to disable 
overcommit.


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

Re: [OpenWrt-Devel] Moving all feeds to OpenWrt GitHub organisation

[David Lang]

On Sun, 10 Aug 2014, Florian Fainelli wrote:


Hello,

Le 10 août 2014 09:44, Etienne Champetier champetier.etie...@gmail.com
a écrit :



Le 10 août 2014 18:18, Stefan Monnier monn...@iro.umontreal.ca a

écrit :





It would be great to have all feeds in one place, on GitHub.


I think making oneself dependent upon a commercial company
without paying it (i.e. without leverage) would be a mistake.


Stefan


We use git, the day github closes, or asks for money, or ..., we move. We

dont depend on github, we use it while it's there (and free).

In the mean time it helps getting the job done

Also paying is no leverage, a contract can be but there are always half

million clauses, and in the worst case scenario they pay you one month back

We already have an infrastructure deployed which is much wider than the
services offered by github. Surely we had our own administrative issues
with those machines but they have been sorted now and the process is much
stronger.

At this point, I don't think we would be getting any advantage of using a
3rd party service, but that's just me.


I agree about the value of having our own infrastructure, but since git is so 
powerful, what about making a clone of the feeds on github as well as the 
current feeds.


If the original poster is correct and this will generate more patch submissions 
from github users, it's a significant win.


If not, it doesn't cost any money and only a small amount of time.

if git wasn't decentralized enough to allow for multiple instances like this, it 
would be a much harder decision to make.


some projects that have added a presense on github (or moved there entirely) 
report a significant increase in patches, some report no change. For OpenWRT, I 
expect that most of the project would see no change, but I wouldn't be surprised 
to see some areas benefit.


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

Re: [OpenWrt-Devel] [OT] Anyone interested in donating Broadcom development?

[David Lang]

On Mon, 28 Jul 2014, John Crispin wrote:


On 27/07/2014 23:07, Rafał Miłecki wrote:

Note: this is *not* anyhow officially related to the OpenWrt! This
is my private request, I use OpenWrt ML just to reach ppl
interested in this topic. Also I can't guarantee my development
will success and can't guarantee any progress in any reasonable
time.



if it makes you feel better i can add the official bit, you have done
a pile of great work recently :)

official we would like to officially ask those who think that
Rafał's work on brcm is important to help him out by donating the
named/requested materials to him ... and as usual his work is on a best
effort basis /official


I've had an interest in helping get specific routers supported in the past, but 
figuring out who to send equipment to ended up defeating me repeatedly.


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

Re: [OpenWrt-Devel] [OT] Anyone interested in donating Broadcom development?

[David Lang]

On Mon, 28 Jul 2014, John Crispin wrote:


On 28/07/2014 10:41, David Lang wrote:

On Mon, 28 Jul 2014, John Crispin wrote:


On 27/07/2014 23:07, Rafał Miłecki wrote:

Note: this is *not* anyhow officially related to the OpenWrt!
This is my private request, I use OpenWrt ML just to reach ppl
interested in this topic. Also I can't guarantee my
development will success and can't guarantee any progress in
any reasonable time.



if it makes you feel better i can add the official bit, you have
done a pile of great work recently :)

official we would like to officially ask those who think that
Rafał's work on brcm is important to help him out by donating
the named/requested materials to him ... and as usual his work is
on a best effort basis /official


I've had an interest in helping get specific routers supported in
the past, but figuring out who to send equipment to ended up
defeating me repeatedly.

David Lang



hi david.

please post the link to the mail you sent on -devel about this.


It's been a couple years since my last attempt, given that the topic just came 
up, I figured I'd try to figure out what the right process is for the next time 
:-)


the most interesting items for me right now are the DSL version on the netgear 
3700 and the netgear r6200.


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

Re: [OpenWrt-Devel] OpenWRT IPv6 firewall

[David Lang]

On Mon, 21 Jul 2014, Gert Doering wrote:


Hi,

On Sun, Jul 20, 2014 at 03:50:24PM -0700, David Lang wrote:

I'm well aware of all the bullshit that is knocking on my doors all
day.  Point is, firewalls on the *routers* are not goint to help the
laptop that moves around, attaches to a Wifi Hotspot, is hacked there,
gets moved back behind your firewall, and starts hacking others from
there.  And it doesn't help the desktop PC that neglected to do any
updates, gets infected by flash/pdf/word exploit, and starts scanning
your network, behind the firewall.


The problem here isn't with laptops, it's with TVs, light Bulbs,
Thermostats, digital picture frames, etc.

These are the types of devices that I'm worried about protecting.


Yes, so how do you protect them from the malware on your PC and Laptop,
which both are behind the firewall?

A hacker from the wild is likely to not even *find* the device if it's
using EUI64 IPv6 addressing and not registered in DNS, while an attacker
on the same LAN just needs to ping ff02::1 to see them all, wide open...


The argument was that laptops are better protected nowdays because they 
routinely get exposed outside the home network.


I agree that they are far better than they used to be, but I am saying that 
there is this other class of devices that is not benefiting from the attention 
that the desktop OSs are getting, and these devices are absolutly quality.


no, having a default-deny permiter doesn't protect you from a laptop on the 
inside, but it does protect you from everyone else's laptops outside.


While it is nice to say that IPv6 has a large address space and so nobody 
will ever scan it, I don't believe it. When IPv4 started out, people didn't 
believe that scanning it was going to be practical either. And since common 
methods of assigning IPv6 addresses are either sequential (DHCP) or based on MAC 
addresses (fairly predictable per vendor), I expect that scanning is going to 
continue.


As for the doing a scan against someone else's IPv6 address space is a DoS 
against your service, remember that these people aren't doing the scan from 
_their_ internet connection, they are doing it from botnets, so they are using 
free bandwidth


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

Re: [OpenWrt-Devel] OpenWRT IPv6 firewall

[David Lang]

On Mon, 21 Jul 2014, Gert Doering wrote:


On Mon, Jul 21, 2014 at 12:18:46AM -0700, David Lang wrote:

While it is nice to say that IPv6 has a large address space and so nobody
will ever scan it, I don't believe it.


Don't believe.  Try math.  2^64 is big enough that if you manage to send
a few 1000 packets a second, you'll need up to the heat death of the
universe to scan a single /64 subnet...

(Of course this can be optimized if you're targeting very specific
devices and only need to scan 2^24 potential EUI64 addresses in
a given vendor's MAC range - but that's not your Joe Random attacker.
If someone is that determined, he'll just target your PC first, and
jump from there to the devices on your LAN.  Way easier in general)


If someone is targeting you specifically, there are all sorts of other scenarios 
that come into play. I consider those out of scope for this sort of discussion.


We are talking about what is appropriate as the default to defend against the 
normal Internet Badness, not against targeted threats or the NSA.


You are effectivly saying that security by obscurity is good enough. You are 
assuming that IP address assignments are going to be random enough to make 
scanning worthless, so no other protection is needed.


I just don't buy that.

I don't believe that the addresses are really going to end up beng that random.

Plus there will need to be some way for devices to be discovered, which will 
probably be via broadcasts. I don't believe that the devices are going to be 
secured to the point where these broadcasts will only work from the local 
network. It doesn't matter how big the per-network address space is if devices 
respond to the one broadcast address for the network. Also, if the devices 
intend to be accessible, are they really going to ask people to enter IPv6 IP 
addresses into configs? or are they going to be publishing themselves to DNS or 
some other nameserver that will make them easier to find? If you have a SIP 
phone that you want to just work, how are the legitimate remote users going to 
find it?


So I'm saying that we still need to block inbound access from random external IP 
addresses by default.


I could see having the firewall look for outbond packets from the devices and 
opening up inbound rules from those IPs


Even if it allowed access on all ports from the entire source network it would 
still be better than anyone on the Internet. this would make getting something 
work between networks not be on by default, but once each side tries to connect 
to the other, things would be open.


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