Re: OpenWrt One / project update

[Fernando Frediani]

Hi Felix
Thanks for the clarification.

Yeah, USB may be Ok, but M.2 isn't for all usages, specially the 
simplest and less costly ones. I see that a SD Card is still quiet 
universal, very cheap for all sorts of projects.
Regarding the the standard for the SD card spec I can't answer that, but 
I would say that whoever uses it should not expect high performance, but 
rather simplicity and cost. Those who may need storage performance may 
well use the M.2.


I see a Winbond 25N01GVZEIG NAND memory in the PCB which seem to be 
128MB of storage. Can I understand that can be used similarly to a SD 
Card for projects which don't require much storage space ?


Thanks
Fernando

On 04/04/2024 13:57, Felix Baumann via openwrt-devel wrote:

Hi Fernando,

the announced specs were

Hardwarespecifications:

* SOC: MediaTek MT7981B
* Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz)
* DRAM: 1 GiB DDR4
* Flash: 128 MiB SPI NAND+ 4 MiB SPI NOR
* Ethernet: 2x RJ45 (2.5 GbE + 1 GbE)
* USB (host): USB 2.0 (Type-A port)
* USB (device, console): Holtek HT42B534-2 UART to USB (USB-C port)
* Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1)
* Buttons: 2x (reset + user)
* Mechanical switch: 1x for boot selection (recovery, regular)
* LEDs: 2x (PWM driven), 2x ETH Led (GPIO driven)
* External hardware watchdog: EM Microelectronic EM6324 (GPIO driven)
* RTC: NXP PCF8563TS (I2C) with battery backup holder(CR1220)
* Power: USB-PD-12V on USB-C port (optional802.3at/afPoE via RT5040 module)
* Expansion slots: mikroBUS
* Certification: FCC/EC/RoHS compliance
* Case: PCB size is compatible to BPi-R4 and the case design can be re-used
* JTAG for main SOC: 10-pin 1.27 mm pitch (ARM JTAG/SWD)
* Antenna connectors: 3x MMCX for easy usage, assembly and durability
* Schematics: these will be publicly available (license TBD)
* GPL compliance: 3b. "Accompany it with a written offer ... to give any third party 
... a complete machine-readable copy of the corresponding source code"
* Price: aiming for below 100$

So yeah: no micro sd card slot.
But you get usb and m.2 for storage which should be fine.
What is it you require one for?

Talking about SD but a bit exaggerated:
The micro SD card spec has gone to shit anyways (who even has devices with 
UHS-III or SD express 7.0 or 8.0? Should the micro SD card slot use UHS-III or 
SD express? both at the same time isn't possible even though the cards look the 
same). The SD card spec can't keep up with CFexpress in the camera sector.

Regards
Felix Baumann


___
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 / project update

[Fernando Frediani]

Hello there

Good work so far.
Did I miss anything, but I couldn't find a SD Card slot. Isn't there one ?

Regards
Fernando

On 04/04/2024 07:00, John Crispin wrote:

Hi,

Just dropping a quick update on the  OpenWrt One project. I've 
received the first batch of three PCBs for testing today. I am in the 
process of testing the hardware to make sure everything works as 
intended.


There are twelve further early prototype boards on standby in case we 
need to tweak anything hardware-wise. You can find some pictures 
showing off the PCB from different angles at these URLs:


http://mirror2.openwrt.org/OpenWrtOne_top.png
http://mirror2.openwrt.org/OpenWrtOne_bottom.png
http://mirror2.openwrt.org/OpenWrtOne_side.png

Work is underway to establish a website where all legal information 
and links to our sources will be provided. Keeping everything 
transparent and accessible is crucial for us.


MediaTek also generously released a substantial amount of programming 
manuals for the SoC used by the OpenWrt One which will be made 
available shortly.


I would like to express my gratitude to the Software Freedom 
Conservancy (SFC), our manufacturer (BPi), the silicon vendor (MTK) 
and fellow developers for their support throughout this journey.


    John


___
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: here we are again: real name 'discussion'

[Fernando Frediani]

Why this insistence on a vote while the discussion is still going on ? 
Why this interest in cut other people's opinion while there is stuff to 
be discussed and may change others idea.
It is not because a certain direction seems to be the way to go that a 
discussion should be abruptly stopped and not let everything that has to 
be discussed happen.



On 27/03/2024 10:53, Paul D wrote:

lets make a vote



So... what's necessary for a vote to start?



___
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 Next Generation Ideas

[Fernando Frediani]

Hello there

I also don't have Notion account so will reply here to all can take note 
and discuss. I have basically 2 notes:


1 - One thing that would be interesting to have it by default regarding 
IPv6 is make the router to find out if it received an IPv6 address in 
the WAN interface but not a Prefix Delegation to be installed in the LAN 
and then make it re-configure itself automatically to use NDP Proxy, so 
the /64 prefix in the WAN can be used in the LAN. This is specially 
useful when users end up connecting a secondary router behind the main 
one who connects to the ISP and receives all IPv6 information instead of 
configuring this secondary router as as Bridge or AP mode disabling DHCP 
Server on it.
There are instructions in the wiki to make it possible, so perhaps it is 
just a question to have it by default to happen automatically on these 
scenarios. This way IPv6 is not broken up on many of these scenarios.


2 - It was mentioned there is some lack of testers for certain 
targets/subtargets. While that may be the case that can be stimulated in 
different ways, starting by adjusting the wiki and related documentation 
with more information on how to test properly feedback it to 
maintainers. There may be many cases where people have the hardware and 
is wiling to put the effort but don't know exactly how.
I guess some people may think the only way to contribute to OpenWrt is 
by writing code and doing PRs and that is definitely not the case. There 
is a fair amount of work to be done to test newer hardware and make it 
100% and that sometimes can be a very lengthy and detailed task. If this 
can be ease up with information in the wiki and other ways this 
ecosystem can certainly be enhanced.


Regards
Fernando

On 31/03/2023 06:44, Arınç ÜNAL wrote:

Hi all,

These are the ideas I've been thinking about for the future of OpenWrt 
for a while. It looks complete enough to share it with all of you.


I'm willing to put a great deal of effort to get as much out-of-tree 
patches on mainline Linux as possible.


You can make a comment on Notion or discuss it here, I'm wondering if 
the ideas are feasible and how well it would benefit the people 
maintaining OpenWrt.


https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb 



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: 24 core buildbot server donation feasible

[Fernando Frediani]

I advise to not to accept this from Equinix for the bad they have been 
doing in the interconnection market in different places.
Sometimes is just better to pay for what you need with donations 
received it rather than accept something from certain companies.


On 21/11/2022 05:39, Petr Štetiar wrote:

Dave Taht  [2022-11-19 06:56:01]:

Hi Dave,


And let me know, and I'll expedite with the manager in charge.

thank you for making us aware, I've just filled that application form.

Cheers,

Petr

___
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: [PATCH] base-files: Don't enable ULA IPv6 addresses by default in new config

[Fernando Frediani]

One of the first things I do when I bring up a new OpenWrt box is to 
disable ULA to the LAN as it has not usage in most scenarios I think.
I basically use the IPv6 connectivity to receive a global prefix 
delegated from my ISP, install it on the LAN and bring global 
connectivity to devices behind it.


I hardly see scenarios where ULA are used - and I know there may be 
legitimate scenarios - but I don't think they are many that justifies to 
have ULA turned on by default.


I see no problem in turning it off and leave it as optional to be 
enabled for those cases


Fernando

On 08/09/2022 14:30, Michael Richardson wrote:

Baptiste Jonglez  writes:

 > ULA IPv6 prefixes (Unique Local Addresses, RFC 4193) are not routable
 > on the Internet.  As such, they have very limited use, and enabling
 > them by default causes more problems than it solves:

 > - if an OpenWrt device already has external IPv6 connectivity with
 > globally routable addresses, then ULA addresses are not useful.

That's just not the case.
ULAs are intended to be the IPv6 version of RFC1918, useable for local
communications.

Please go read RFC7084.
ULAs are required, and OpenWRT has been a leader here.

I strongly object to this proposal.



___
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: [PATCH] build: always set CONFIG_IPV6

[Fernando Frediani]

I find strange any conversation around disabling IPv6 these days, 
regardless the reason. It should be mandatory even if some ISPs don't 
have it enabled yet.


How can one say that IPv6 may be unwanted ? If there is such scenario 
there is something very wrong there.
What should be fixed is the lack of IPv6 in the network or from the ISP, 
not to remove it from any builds, specially in a OpenWrt build.


There is not harm to keep it as is and if there is no IPv6 from the ISP 
nothing bad will happen to the router and everything else will remain 
working as expected in IPv4.


If there was a reason in the past people were removing it was for 
devices with limited amount of flash (4MB generally), but I believe that 
any device with a minimal of 8MB it is already enough to not have to 
remove IPv6 from the build.


Fernando

On 22/08/2022 18:18, Bas Mevissen via openwrt-devel wrote:

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.

___
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: Drop CONFIG_IPV6 ?

[Fernando Frediani]

IPv6 is not a "nice to have" think.
If you are using OpenWrt and consider IPv6 a nice to have thing you 
should do some reading and network understanding as it seems it lacks 
some very fundamental one to you.


I see people often complaining they don't get IPv6 from their ISPs and 
what is the way they expect to do ? Disabling IPv6 on their builds. 
Certainly not.


On 14/03/2022 03:08, Reiner Karlsberg wrote:
Practically always I disable IPv6. First of all, to get rid of stuff, 
which might be "nice to have", but is not required
"to do the job". The less code I have running, the smaller the 
probability to run into bugs.
Second, it is a good method to reduce the requirements on flash, when 
having many non-standard packages installed, i.e. squid or PHP.
Third, I often have to connect via wireless WANs, not supporting IPv6 
at all.


So, pls do _not_ remove CONFIG_IPV6

Cheers,

Reiner


___
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: Drop CONFIG_IPV6 ?

[Fernando Frediani]

How come, at the stage we are, one can be thinking of disabling IPv6 
just because the ISP didn't deploy it yet ?


How one can expect IPv6 to advance (and it has been going farily well), 
if routers at end user have IPv6 disabled ? What when the ISP finishes 
deployment and deliver IPv6 yo users ?


This shouldn't be considered under no other circumstances except for 
personal customized images and quiet older routers.


On 14/03/2022 00:54, Philip Prindeville wrote:

Yeah, I disable CONFIG_IPV6, since most American ISP's have started rolling out 
residential IPv6.  My local pop & pop ILEC hasn't deployed it.  There's not 
even an announced date for it on their roadmap.

I suspect that if everyone had an IPv6 address, which would be both routable 
and non-dynamic, then people could more easily run servers on their networks... 
which might be anethema to the ISP's.




On Mar 13, 2022, at 5:31 PM, Etienne Champetier  
wrote:

Hi All,

We currently have some circular dependencies caused by the usage of
PROVIDES and @IPV6
https://github.com/openwrt/openwrt/issues/9407

One radical way to fix, suggested by Jow, is to completely remove
CONFIG_IPV6 from OpenWrt.
This would also allow to simplify packaging of some core components.

Is anyone disabling CONFIG_IPV6 ?
Do people agree we can drop CONFIG_IPV6 ?
Should we do this before we branch 22.x ?

Best
Etienne


___
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: Automatic LAN Subnet Reassignment

[Fernando Frediani]

Interesting feature.
Another similar thing is when someone connects a OpenWrt WAN port to 
another router LAN port (cascading) which has IPv6 support as the 
upstream router isn't normally able to do Prefix Delegation with its LAN 
prefix the OpenWrt router detects it and re-configure itself with NDP 
Proxy to use the same/64 in the WAN for the LAN therefore not loosing 
the IPv6 connectivity.


People often connect routers in this way by mistake instead in a AP mode 
and breaks IPv6 connectivity so a solution like this would preserve IPv6 
connectivity all the way.


Regards
Fernando

On 21/02/2022 18:38, Rich Brown wrote:

There is a new RFC on the OpenWrt forum proposing "Automatic LAN Subnet 
Reassignment" 
https://forum.openwrt.org/t/rfc-automatic-lan-subnet-reassignment-upon-conflict-with-wan/120938
 The RFC responds to the advice given at last week's OpenWrt-Adm meeting 
(https://etherpad.wikimedia.org/p/ZlZiTcud3wufcSX9-1jD)

The intent of the proposal is for the default configuration to assign a LAN 
subnet that avoids a conflict with the WAN subnet, and provide a mDNS name such 
at OpenWrt.lan for connections.

I have two requests:

1) Please make comments on the technical merits of the proposal on the OpenWrt 
forum at the link above.

2) If the proposal seems to make sense, please consider the process by which we 
would incorporate this into the main release (likely, not for 22.0x, but 
perhaps the next release?)

Thank you.

Rich



___
openwrt-adm mailing list
openwrt-...@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-adm


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

Re: OpenWrt 22.0X release plan

[Fernando Frediani]

Thanks for all the work done towards this.

And thankfully SELinux will not be activated by default.

Regards
Fernando

On 20/02/2022 19:57, Hauke Mehrtens wrote:

Hi,

All the major new features for the next OpenWrt major release are 
mostly merged into master. The kernel 5.10 upgrade for the bcm63xx 
target is still missing.


Paul created a issue to track the remaining tasks:
https://github.com/openwrt/openwrt/issues/9248
This will be extended with new problems.

We plan to do a feature freeze of the master branch on 1. March 2022. 
This means we will not add any big changes any more by that date. 
Minor changes like adding support for new boards or adding a new 
package are still ok, big changes like activating SELinux by default 
would not be oḱ.


Around 20. March 2022 we plan to branch off the next major release and 
would prepare for a first release candidate about 1 week later.


Hauke

___
openwrt-adm mailing list
openwrt-...@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-adm


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

Re: Activate https server support in 21.02 by default

[Fernando Frediani]

Hello Perry

I didn't understand your suggestion fully.

You wish to put some warning to users who are willing to use https about 
the self-signed certificate ou about users using http ?


Regards
Fernando

On 17/09/2021 09:07, Perry wrote:

Hi all,

This issue has come up recently in the Freifunk-Berlin community.  We
have brainstormed a little bit and came up with a suggestion.

Would it be possible to have all the headers in the themes to contain a
link to https (iff the correct packages are installed)?  A bonus would
be a nice mouse-over explaining to the user about the "potential secure
risk ahead" with regards to the certificate.

Greets,
Perry

On 5/17/21 4:48 PM, Fernando Frediani wrote:

Seems good to me.
The main question is: most home users will require it ? I don't think
so. But there may be others that may do, so as long http does not
forward to https seems a good approach so those who want can
deliberately use https.
I think as it stands now forcing https only would be a mistake.

For those who don't want to use may build a custom image it should
really be the other way round since we are talking about something not
essential. But as mentioned if there is not space consumption impact and
not forcibly forward it seems a good approach in my view.

Fernando

On 16/05/2021 10:16, Hauke Mehrtens wrote:


Hi,

Adding CONFIG_PACKAGE_luci-ssl to the image will add less then 10
KBytes to the image, my initramfs image for an ath79 got 2.2 KBytes
bigger. This is about 0.05% of the image. We already include a full
TLS library and use it for WPA3 and HTTPS downloads.
Probably some extra size if used by the X.509 certificate we generate
at first boot and store on flash.

With the current approach we would offer the web page under
http://192.168.1.1 and https://192.168.1.1 by default, the user can
choose what he would like o use. The http version will not forward to
the https version. https is not deactivated by default, but the user
can choose which url he uses in his browser.

The certificates are not signed by a certificate authority, so the
browser will not trust them by default, but this already protects the
users from a attacker passively listening on the connection between
the browser and the OpenWrt device. The comparison with telnet and ssh
is pretty good. For SSH we "waste" a lot more memory.

I am for activating it, if you do not want to use it, you can build a
custom image with the image builder without luci-ssl and px5g-wolfssl.

Hauke


___
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: [RFC] OpenWrt within a Docker container

[Fernando Frediani]

Hello

Certainly run /sbin/init or 'procd' to have *OpenWrt-like experience* is 
a better approach in my view.


Regards
Fernando


On 17/05/2021 15:39, Paul Spooren wrote:

Hello,

after some back and forth I'd like to request some more opinions on 
what kind of Docker containers to offer containing the OpenWrt rootfs. 
This is not about the SDK or ImageBuilder Docker containers.


tl;dr:

Should we ship `slim` containers only, running a OpenWrt shell (ash) 
and nothing more? Whoever wants services to run (e.g. ubus) should run 
additional containers and glue them together via mounts? Or should we 
run /sbin/init or `procd` to have a *OpenWrt-like experience*, with 
LuCI, ubusd and friends.


/tl;dr

Currently the `openwrt/rootfs` container is shipped with minimal 
modifications and starts `/sbin/init` as default action.


Running the container for e.g. LuCI development within a local shell 
results in the following output:


```
user@reactor:~$ docker run -it openwrt/rootfs
Failed to resize receive buffer: Operation not permitted
/etc/preinit: line 5: can't create 
/sys/devices/system/cpu/microcode/reload: Read-only file system

ip: RTNETLINK answers: Operation not permitted
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug 
level

ip: can't send flush request: Operation not permitted
ip: SIOCSIFFLAGS: Operation not permitted
Please press Enter to activate this console.
--- %< ---
root@da3dfbdc5ae4:/#

```

Some init scripts fail due to missing privileges. The console input is 
only possible by using a patched /etc/inittab file and multiple 
services keep failing, most problematic the `network` service since it 
tries and fails in a fast loop to flush some interfaces.


A possible patch is available[1] which disables services obsolete 
within a Docker environment, however this would "flaw" the 
*OpenWrt-like experience*.


Another, probably better approach could be to have *slim-containers* 
which only run `ash` and let the user start whatever is needed, e.g. 
`ubusd && uhttpd` and thereby have access to a LuCI interface to play 
with.


This would follow the experience from other popular containers like 
`alpine` or `debian`. This would also allow us to become an "official" 
container, which would allow to be used as `docker run -it openwrt` 
rather than `docker run -it openwrt/rootfs`. Some efforts were made 
here[2].


I'd prefer the latter option; only offer SDK and ImageBuilder and let 
the rootfs become a "official" Docker container without any running 
services. Whoever needs services can use `FROM openwrt` within a 
Dockerfile  and run whatever is needed.


Best,
Paul

[1]: https://gitlab.com/openwrt/docker/-/merge_requests/47
[2]: https://github.com/docker-library/official-images/pull/7975


___
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: Activate https server support in 21.02 by default

[Fernando Frediani]

Seems good to me.
The main question is: most home users will require it ? I don't think 
so. But there may be others that may do, so as long http does not 
forward to https seems a good approach so those who want can 
deliberately use https.

I think as it stands now forcing https only would be a mistake.

For those who don't want to use may build a custom image it should 
really be the other way round since we are talking about something not 
essential. But as mentioned if there is not space consumption impact and 
not forcibly forward it seems a good approach in my view.


Fernando

On 16/05/2021 10:16, Hauke Mehrtens wrote:


Hi,

Adding CONFIG_PACKAGE_luci-ssl to the image will add less then 10 
KBytes to the image, my initramfs image for an ath79 got 2.2 KBytes 
bigger. This is about 0.05% of the image. We already include a full 
TLS library and use it for WPA3 and HTTPS downloads.
Probably some extra size if used by the X.509 certificate we generate 
at first boot and store on flash.


With the current approach we would offer the web page under 
http://192.168.1.1 and https://192.168.1.1 by default, the user can 
choose what he would like o use. The http version will not forward to 
the https version. https is not deactivated by default, but the user 
can choose which url he uses in his browser.


The certificates are not signed by a certificate authority, so the 
browser will not trust them by default, but this already protects the 
users from a attacker passively listening on the connection between 
the browser and the OpenWrt device. The comparison with telnet and ssh 
is pretty good. For SSH we "waste" a lot more memory.


I am for activating it, if you do not want to use it, you can build a 
custom image with the image builder without luci-ssl and px5g-wolfssl.


Hauke



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

Re: Activate https server support in 21.02 by default

[Fernando Frediani]

On 15/05/2021 18:57, Alberto Bursi wrote:



If HTTPS is still an optional it makes no sense to treat it 
differently from all other optional packages.
The only moment it should be included by default is when it becomes 
mandatory, and the HTTP interface is disabled.


Maybe you are right here.

Fernando


-Alberto

___
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: Activate https server support in 21.02 by default

[Fernando Frediani]

On 15/05/2021 16:59, Alberto Bursi wrote:




I'm personally in the "encrypt all the things" camp. I fully support a 
switch to https only.


But it should be a default, not a "let's add stuff people might want 
to enable later". Either all in or all out.

Perhaps that's the problem.

There has been a movement to blindly "encrypt all the things" even for 
stuff that may not require it ? Why ?
I have no problem with what benefits from it, but if you look certain 
scenarios that's not really something necessary, so in that sense I 
always like the Keep It Simple principle. I don't see that OpenWrt 
really requires HTTPS enabled by default for most usage scenarios 
really, but I would be glad to be convinced the contrary.


Again, I think that if it doesn't impose much extra space consumption 
and it does not come enabled by default it may be a good middle term if 
there are significant cases, although not majority, that may choose to 
enable and use it.


Regards
Fernando



-Alberto

___
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: Activate https server support in 21.02 by default

[Fernando Frediani]

Yeah I understand even if HTTPS wouldn't come enabled by default (and it 
shouldn't), but only available with that and that may seem Ok. My only 
concern has been how much these extras consume on the default image for 
not being something essential.


I understand there has been a movement to have HTTPS everywhere (even 
where it is not necessary), but I understand that in a common LAN this 
is really not necessary by default and when people can freely install 
and use with no problem.
Again concern is space usage for the default image. If that doesn't mean 
anything significant in the context where every byte counts it may be a 
good compromise to have it available but not enabled by default.


Regards
Fernando

On 14/05/2021 11:22, Etienne Champetier wrote:

Hi All,

Le ven. 14 mai 2021 à 05:00, Petr Štetiar  a écrit :

Fernando Frediani  [2021-05-11 20:13:18]:

Hi,


I am no sure https support should still be something by default in the
images as it's not something really essential

to me it's like discussion about telnet versus SSH. (Puting aside, that one
shouldn't be using password at all) If it's fine with you to send your root
password over telnet, then SSH is not essential, I agree.

FYI HTTPS wouldn't be enabled by default, it would be *available* by default,
giving users of default release images choice for management of their devices
over HTTPS, by doing so *explicitly*.

I'm all for HTTPS to be shipped by default
One painfull "bug" that some people might face having both HTTP and HTTPS,
when you login using HTTPS, the sysauth cookie has secure=true,
so you can't login via HTTP anymore because it's trying to modify the
secure=true sysauth cookie :(

Etienne


OpenWrt has quite huge community, so I hope, that having HTTPS available in
default images would bring the currently horrible UX of self-signed
certificates to wider audience which in turn might foster improvements.

-- ynezz


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

Re: Activate https server support in 21.02 by default

[Fernando Frediani]

I am no sure https support should still be something by default in the 
images as it's not something really essential although the storage usage 
increase seems really low based on what you mention.


Fernando

On 11/05/2021 19:55, Hauke Mehrtens wrote:

Hi,

OpenWrt 21.02 currently ships with wolfssl and LuCI for http.

It would be nice to also have https support included in the default 
images.

To add this the following packages have to be added:
* luci-ssl  (969 Bytes ipkg)
* px5g-wolfssl (5216 bytes ipkg)
For me the images increased by 2.2 KBytes when these packages were 
included.


We should *not* activate the automatic forwarding from http to https 
by default. This was deactivated here and should stay like this: 
https://git.openwrt.org/0cf3c5dd7257dff1c87b61c5e53e5b1787ab7015
It would be nice to have this as an option in the default LuCI 
configuration, see here: https://github.com/openwrt/luci/pull/4659


Where are the default packages for the 21.02 releases defined?
I haven't found it here:
https://git.openwrt.org/?p=buildbot.git;a=summary

My proposal:
* Add luci-ssl to the default packages for the 21.02 branch
* merge this: https://github.com/openwrt/luci/pull/4659

@Jow what do you think about this?

Hauke

___
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: Paid support for MT7621 WAN port bugs in 21.02 HEAD/MASTER

[Fernando Frediani]

That's a great initiative. Well done.

Regards mt76 driver if I am not wrong MediaTek had sponsored someone 
from the community a while ago to develop it, but I guess that is not 
the case anymore.

If after this offer someone can take it again that would be great.
These 2 bugs are not the only ones that needs fixing int mt76

Regards
Fernando

On 04/05/2021 00:56, Strontium wrote:

The company I work for is interested in contracting/sponsoring a
knowledgeable developer to resolve the following bug reports in OpenWrt
21.02:

https://bugs.openwrt.org/index.php?do=details_id=3760
https://bugs.openwrt.org/index.php?do=details_id=3762

These problems will negatively effect the entire OpenWrt community of
users with MT7621 based devices if they are not addressed before OpenWrt
21.02 is formally released, so we would like to see them addressed for
everyone's benefit.

If you are interested in helping us, please contact me directly and we
can discuss the details.

Steven


___
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: 20.xx: postponse LuCI HTTPS per default

[Fernando Frediani]

Hi. I don't really see having HTTPS by default as something that make 
such a difference for most common users nor as a major security issue in 
the context it is used at the cost it puts, which may seems not too much 
but I always think of the very minimal for a default image and HTTPS 
isn't something really necessary for I would say most scenarios. Again I 
am not against using HTTPS but rather leaving it as optional for those 
who really want to enable. So not really concerned about the low flash 
devices, but because this will be yet another thing to increase the size 
of the default image.


On 20/11/2020 13:32, Alberto Bursi wrote:



On 20/11/20 17:17, Fernando Frediani wrote:

Hi Alberto

On 20/11/2020 13:09, Alberto Bursi wrote:




The only thing I can accept as a valid complaint against https by 
default is the increased minimum space requirements, everything else 
I really don't understand nor agree with.


It's exactly this I am referring to when I talk about the extras not 
the steps the user will take to enable it. So why I mentioned to 
leave it as optional and easy to do for those who wish (and have 
space) to have it.




Devices with low flash space (and RAM) are already receiving special 
treatment (different compile options, different default packages) to 
lower space footprint.


These devices can (should?) be left out of the "https by default" easily.

But I would be strongly against degrading security for everyone just 
because of these devices.


-Alberto


Regards
Fernando




Yes it is nice to have everything ready and automated to be done 
with a few clicks for those cases that require it. In fact I think 
this would be a better solution for now so it will be possible to 
gather gradually this transition (or not) from HTTP to HTTPS even 
for local/lan applications and see how often people would opt to 
use it.


Still should it end up having HTTPS by default I see self-signed 
certificates are the way to go. Yes there are the warnings and I 
really don't think there is any issue with it.
Those accessing the router Web Interface are not 'normal' Internet 
users and they know what they are doing so the warning from 
self-signed certificates should not be a surprise for them.
And those cases when admins prefer they can always replace the 
self-signed one for Let's Encrypt for example.


Regards
Fernando



-Alberto

___
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


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

Re: 20.xx: postponse LuCI HTTPS per default

[Fernando Frediani]

Hi Alberto

On 20/11/2020 13:09, Alberto Bursi wrote:




The only thing I can accept as a valid complaint against https by 
default is the increased minimum space requirements, everything else I 
really don't understand nor agree with.


It's exactly this I am referring to when I talk about the extras not the 
steps the user will take to enable it. So why I mentioned to leave it as 
optional and easy to do for those who wish (and have space) to have it.


Regards
Fernando




Yes it is nice to have everything ready and automated to be done with 
a few clicks for those cases that require it. In fact I think this 
would be a better solution for now so it will be possible to gather 
gradually this transition (or not) from HTTP to HTTPS even for 
local/lan applications and see how often people would opt to use it.


Still should it end up having HTTPS by default I see self-signed 
certificates are the way to go. Yes there are the warnings and I 
really don't think there is any issue with it.
Those accessing the router Web Interface are not 'normal' Internet 
users and they know what they are doing so the warning from 
self-signed certificates should not be a surprise for them.
And those cases when admins prefer they can always replace the 
self-signed one for Let's Encrypt for example.


Regards
Fernando



-Alberto

___
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: 20.xx: postponse LuCI HTTPS per default

[Fernando Frediani]

The only reason I see to have HTTPS and certificates in OpenWrt in my 
view is to give some layer of security for those accessing the router 
via Wifi or over the Internet for example.


And only admins, who have setup the router or work directly with it will 
access it (not normal users) so they know well what they are doing to 
not find a problem to have a self-signed certificate, or if it's the 
case they may deploy (optionally and later on) a Let's Encrypt 
certificatate which will be in even fewer cases.


Fernando

On 20/11/2020 12:52, W. Michael Petullo wrote:

I think making use of self-signed certificates in production is a bad
idea because (1) it reinforces poor practices, namely electing to trust
a self-signed certificate and (2) it does not authenticate the
server/router, a critical piece of the TLS security model.

My point of view is that we should delay HTTPS-by-default until we have
a scheme for establishing the identity of the router. Until then, we
should be honest and make use of HTTP.



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

Re: 20.xx: postponse LuCI HTTPS per default

[Fernando Frediani]

Yes, exactly it is only an issue when someone have to access the web 
interface via wifi. In a home environment that is a small issue. In a 
more corporate environment there are two options: 1) access is done via 
wired network or 2) enable HTTPS, which make more sense.


Enabling HTTPS by default is still not worth in my view given the extras 
that come with it and I like the idea of keep the default as simple and 
possible. Yes it is nice to have everything ready and automated to be 
done with a few clicks for those cases that require it. In fact I think 
this would be a better solution for now so it will be possible to gather 
gradually this transition (or not) from HTTP to HTTPS even for local/lan 
applications and see how often people would opt to use it.


Still should it end up having HTTPS by default I see self-signed 
certificates are the way to go. Yes there are the warnings and I really 
don't think there is any issue with it.
Those accessing the router Web Interface are not 'normal' Internet users 
and they know what they are doing so the warning from self-signed 
certificates should not be a surprise for them.
And those cases when admins prefer they can always replace the 
self-signed one for Let's Encrypt for example.


Regards
Fernando

On 20/11/2020 11:46, Alberto Bursi wrote:



On 20/11/20 14:22, Fernando Frediani wrote:
I don't see having HTTPS by default in LuCI as something good or even 
necessary ? It's actually an unnecessary complication that could 
always be optional.


One of the main reasons is that in many and probably most cases of a 
new deployed OpenWrt router there is still no Internet connection 
available. Also it doesn't seem to be that people need it since 
access by default is only done via the LAN interfaces.


Not using SSL means anyone in the LAN can snoop the password to access 
the router.


While this is a non-issue for most home wired networks, it is for wifi 
and most people will use wifi on their router.


WPA2 is not going anywhere for a long while still and it is 
susceptible to deauth attacks. After the attacker has captured enough 
handshakes after the deauth they will know the wifi password. It just 
takes a while but there are plenty of automated tools to do that 24/7 
like Pawnagotchi (a raspberry zero running a dedicated application) or 
wifi pineapples or whatever.


Using SSL for web interface means the system is at least 
compartimentalized so in case someone breaks into the wifi/LAN they 
won't also take over the router as well.


If someone for some reason wishes for example to expose the LuCI web 
interface to the internet than fine to have it running on HTTPS and 
that can be enabled by those who wish to operate in such way. As this 
example there are certainly others that justify to have a HTTPS but I 
don't they they are most.


The same way I see as interesting to have an automated way to 
generate SSL Certificates (ex: via Let's Encrypt), but again, that 
should be optional to only those who wish to use HTTPS for their 
specific needs.


Fernando

On 20/11/2020 06:44, Karl Palsson wrote:

"Paul Spooren"  wrote:

Hi,

The current list of release goals for 20.xx states[0] that LuCI
should use HTTPS per default. This works by creating on-device
a self-signed certificate. Self-signed certificates result in
warnings and may cause more harm than good, multiple discussion
are found in the mail archive.

As no clean solution seems in reach while 20.xx seems close,
I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs
`luci`) per default.

This isn't a vote but a request for developer/user opinions.

Very much in favour of leaving this off, self-signed isn't viable
by default

Sincerely,
Karl Palsson

___
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


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

Re: 20.xx: postponse LuCI HTTPS per default

[Fernando Frediani]

I don't see having HTTPS by default in LuCI as something good or even 
necessary ? It's actually an unnecessary complication that could always 
be optional.


One of the main reasons is that in many and probably most cases of a new 
deployed OpenWrt router there is still no Internet connection available. 
Also it doesn't seem to be that people need it since access by default 
is only done via the LAN interfaces. If someone for some reason wishes 
for example to expose the LuCI web interface to the internet than fine 
to have it running on HTTPS and that can be enabled by those who wish to 
operate in such way. As this example there are certainly others that 
justify to have a HTTPS but I don't they they are most.


The same way I see as interesting to have an automated way to generate 
SSL Certificates (ex: via Let's Encrypt), but again, that should be 
optional to only those who wish to use HTTPS for their specific needs.


Fernando

On 20/11/2020 06:44, Karl Palsson wrote:

"Paul Spooren"  wrote:

Hi,

The current list of release goals for 20.xx states[0] that LuCI
should use HTTPS per default. This works by creating on-device
a self-signed certificate. Self-signed certificates result in
warnings and may cause more harm than good, multiple discussion
are found in the mail archive.

As no clean solution seems in reach while 20.xx seems close,
I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs
`luci`) per default.

This isn't a vote but a request for developer/user opinions.

Very much in favour of leaving this off, self-signed isn't viable
by default

Sincerely,
Karl Palsson

___
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: A proposal of https certificate assignment system for luci

[Fernando Frediani]

On 09/10/2020 08:29, Bas Mevissen wrote:

On 2020-10-04 15:48, abnoeh wrote:
.

So I think it is reasonably safe to do the initial setup over HTTP 
(without the "S") at the first boot if there are no certificates 
available from a previous OpenWRT install. Then the user can setup the 
WAN side if needed and upload (from local PC), generate (self-signed) 
or acquire (e.g. Let's Encrypt) the certificates for Luci. After that, 
the connection is switched to HTTPS and HTTP switched off.


Exactly. Only those who really need and want to have a HTTPS certificate 
can to that manually after the router is setup and has Internet connection.


Regards
Fernando





___
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: A proposal of https certificate assignment system for luci

[Fernando Frediani]

I am not sure click though certificate warning is that much of a 
security issue in this context neither OpenWrt should have certificates 
issued by default if I understood it correctly.


Most people accessing OpenWrt LuCI interface knows what it is and would 
not find it strange to have to accept a self-signed certificate.
Also OpenWrt devices mostly are accessible from internal and restricted 
networks and not exposed to the Internet. Still if necessary it is still 
possible to add its own valid certificate to it on those cases where 
necessary.


I think the steps outlined below can be a valid thing, but not to be 
done automatically. As an optional procedure to make the things easier 
for those who have a need to a certificate on certain scenarios.

In such way we keep the things simple as possible.

Regards
Fernando

On 04/10/2020 10:48, abnoeh wrote:

Few months ago there was some debate for how we handle certificate for
luci page: make user to click though certificate warning is not that
great for security so here is a  proposal for autometically assign a
worldwide unique subdomain and how to make valid certificate for it, and
make sure we and connect to the device he is expecting.

Openwrt as project get a CA certificate with name constrained to only
able to sign subdomains of [luci.openwrt.org]. this makes we Technically
Constrained Subordinate CA, (from let's encrypt or digicert), let's call
it the Openwrt CA here (CA ) this makes we don't create too much load to
normal CA like let's encrypt, and as we have complete control of this
zone we can give subdomains as we want like, and don't need full audit
like fully pledged CA and handled like a wildcard cert for them, but the
CA system can be hosted by us and request won't offloaded to upper CA's
server. (except OCSP request, but it can be cashed)

and assignment of a subdomain and it's certificate happens this way :

{everything below will be done on https or otherwise encrypted channel}
1. on first boot, router want to get it's luci certificate send its ssh
host key to Openwrt CA reserve subdomain base32(hash of public
key).luci.openwrt.org (like onion v3 addressed does)
2. Openwrt CA sends nonce to our router
3. router signs nonce+timestamp+[hash of CSR] with sent ssh host key,
and send back to openwrt CA send this signed message with CSR
4. Openwrt CA verify other end controls host key match with hash and
confirmed the CSR, sign the certificate with (key from CSR/SAN with
domain we derived from host key) and sent back to router
5. router now has valid cerfiticate, redirect 192.168.1.1 or openwrt lan
to https version of signed subdomain


now user only have to check :

1. page has valid certificate

2. the subdomain is match with device's ssh host key

and this verify  it's the device we wanted.


--- some consideration
A. how authoritative DNS server reply on public dns lookup those
luci.openwrt.org? act like an dDNS with same verification for DNS
update, or just not answer?
B. router itself need to catches it's on subdomain lookup and answers
it's own address on LAN side.
C. this idea doesn't have real way to ratelimit the certificate request
other them by request ip: I'm not sure that'll be enough

D. Let's encrypt doesn't like to sign such certificate as normal
service, but maybe we can persuade them to sign one (it's one time job
for them)

E. with this now we have another server to manage.


P.S is this too large wall of text?


___
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: ath79: move 8/32 boards to tiny subtarget

[Fernando Frediani]

I have some concern to call tiny the 8/32 boards.
While I understand the 4MB flash devices as phased out the 8/32 are 
still very popular and probably most of the devices still running in 
many and many places and they are not really tiny as of today. Some 
newer low priced are coming with 8/64, but the point is that OpenWrt has 
been the responsible for many devices to keep going for years with 
stability and this no doubt will happen with 8/32 for a while.
Calling tiny means only 8MB flash or both 8MB flash and 32MB ram ? I may 
see a point to call the 8MB devices maybe, but not 32MB ram ones.


Fernando

On 19/09/2020 19:21, Adrian Schmutzler wrote:

Indeed "LOW_MEMORY_FOOTPRINT" seems only to affedt 3 general options
and one option of OpenSSL.

So it might be an option to :
* set LOW_MEM for 8/32 MB devies
* set LOW_MEM and SMALL_FLASH for 4/32 MB devices
* check the CONFIG-options for usefull defaults So the tiny aubtarget can be
defined as "boards with 32MB or less of RAM; some boards also with only
4MB of flash". This definition would essentially match the "4/32 warning" [1].

Actually, this narrows down to a question that struck me several times already:

Now, that 4 MB flash devices are not "supported" anymore, how should we deal with the 
"tiny" subtargets:

1. We keep the tiny subtargets configured for low flash, so people still trying 
to build 4 MB flash devices still can use this. (This will also benefit a few 
devices with kernel size restrictions; however, this is a much smaller set than 
in earlier times; most of these devices have dual-stage bootloaders now or died 
anyway).

2. We convert the tiny targets to low-memory targets; this will improve the 
situation for a few devices (like you mentioned), but will make it much harder 
to still build the 4M flash devices without major changes. Apart from ath79, I 
don't know whether this would make sense for other targets like the old 
subtargets on ramips. This poses the risk of having some targets low-mem and 
some small-flash, which I'd like to avoid. Additionally, we will have to change 
back from low-mem to small-flash again when we start to hit limits with the 8M 
devices.

3. Though not intended by this conversation, the third option is obviously to just ignore 
all 4M or 32M devices from now on (as actually announced by the 4/32 warning), and design 
the tiny targets based on the requirements of the 8M devices that will start to become a 
"problem" soon (either due to kernel size restrictions or because of small 
rootfs). Actually, we already went into this direction by using wpad-basic-wolfssl on 
tiny targets as well.

Best

Adrian


[1] - https://openwrt.org/supported_devices/432_warning

Sven


[0] https://github.com/freifunk-gluon/gluon/issues/2032
[1]
https://github.com/freifunk-

gluon/gluon/commit/7e8af99cf504ca1dc389f28

2a0c9
4f4a911571be






___
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

Fwd: Re: Policy on BUILD_PATENTED

[Fernando Frediani]

On 10/08/2020 06:08, Adrian Schmutzler wrote:


But still, OpenWrt as a project/organization in embedded in an environment it 
has to care about.
And that of course includes caring about the interests of important 
stakeholders (or at least ask them about those), and not make our decisions 
based on how we would like the world to be.

Well said !
+1

I think Bjørn put that in a nutshell nicely.

Best

Adrian


___
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


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

Re: [OpenWrt-Devel] FULL CONE NAT in OpenWrt

[Fernando Frediani]

Not all ISPs allow the user to request static PD. I like the idea of a 
static PD, but it is the ISP choice what they will give the user.
I can understand the issues you are describing but they really need to 
be fixed by other proper means, not by introducing another problem which 
is stimulating users to do NAT66 which is more than ugly thing to have. 
If this has to be used it is because of something else that is not 
working as it should and that is what should be fixed.


Internal sub-nets should be adjusted automatically either via RA or DHCPv6.
I believe there is currently a proposal in IETF to make this scenario 
work as expected when these changes happen and that is the correct way 
in my view to deal with this issue.


Regards
Fernando

On 04/05/2020 19:00, Joel Wirāmu Pauling wrote:
Yup; ok i'm not going to get into a religious war about this. But I 
will fight you on this and I have been around long enough to have been 
on the other side of the fence and am talking from a position of 
understanding it's not a great place we are in to need it. But we do:


There are multiple use-cases for nat66. Here is the one that I have 
now encountered several times, and which I believe likely affects a 
large chunk of users.


Uplink ISP provides /56 PD via /128 PtP link-net using public ranges 
(normal so-far for dhcpv6 setup).

Uplink ISP provides /32 v4 IP via dhcp
End user requests static v4 ; ISP front end systems cope with this.
Despite requesting static addressing the v6 /56 PD does not honor this 
(there is an v6 update flag for this, but it's kind of useless if you 
still have to renumber all your internal sub-subnets when this happens).

--
So every reboot/timeout of the v6 upstream - potentially 1000's of 
endpoints internally all need to update their prefixes (suffixes are 
relatively easy to maintain...)

--
ULA solves this for consistent internal addressing, BUT does not solve 
it for Firewall rules for say things like Video Conference 
bridges/webservers/FIP/OpenStack pools/OpenShift exist routes, etc 
,etc. That may be exposed via port-forwarding and Forwarding rules in 
the Routers/Edge firewall in Openwrt in combination with some 
$othernondhcpv6 aware config.


NAT66 + ULA would solve for the above case. You still have the issue 
of needing to update all the DNS records but that is largely 
accomplishable via the same way DDNS for v4 is.



---
So yup provide me with a better way to cope with the above that does 
not need tunnels or require a provider uplink have static v6 
allocations and I will wholeheartedly agree nat66 is not needed.


-Joel

IPv6 PD /56 is delivered from Uplink RSP (retail service provider); 
MANY ISP's cannot and do-not allow for their PD announcements (via 
dhcpv6) to be statically set, even when their ipv4 addressing


On Tue, 5 May 2020 at 09:02, Fernando Frediani <mailto:fhfredi...@gmail.com>> wrote:


I believe NAT66 should not be stimulated in any sense.
One of the greatest things of IPv6 is to restore end to end
communication.

PDs should only change when there is a re-connection and the CPE
should be able able to handle that correctly updating its LAN
prefixes accordingly.
Stimulating and making that easy for general usage is like a crime
against IPv6. If one really needs to use that "chewing gun" he
must know what he is doing and to manually for that exception case.

Regards
Fernando

On 04/05/2020 17:52, Joel Wirāmu Pauling wrote:

I am all for exposing Cone Nat in UCI / Firewall zones as an
option to the masquerading configuration in a zone.

Also as much as I hate it nat66 for IPv6 needs to be exposed in
the same place - specifically for mapping routable PD which
change often to ULA's.

-Joel

On Tue, 5 May 2020 at 07:25, Gracias Amigou
mailto:puchapap...@gmail.com>> wrote:

Please add this package as official:

*Posts:*

 1. xt_FULLCONENAT -- Implementing RFC 3489 full cone SNAT in
OpenWrt

<https://forum.openwrt.org/t/xt-fullconenat-implementing-rfc-3489-full-cone-snat-in-openwrt/14816>
 2. [12/8更新]OpenWrt 上实现 NAT1 (Full cone NAT) 的方法，无需
DMZ/UPnP - OPENWRT专版
<https://www.right.com.cn/forum/thread-319827-1-1.html>
 3. 从DNAT到netfilter内核子系统，浅谈Linux的Full Cone NAT实现 |
ChionLab
<https://blog.chionlab.moe/2018/02/09/full-cone-nat-with-linux/>

*
*
*Git:*
• GitHub - LGA1150/openwrt-fullconenat: Netfilter and
iptables extension for full cone NAT ported to OpenWrt.
<https://github.com/LGA1150/openwrt-fullconenat>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
<mailto:openwrt-devel@lists.openwrt.org>
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


__

Re: [OpenWrt-Devel] FULL CONE NAT in OpenWrt

[Fernando Frediani]

I believe NAT66 should not be stimulated in any sense.
One of the greatest things of IPv6 is to restore end to end communication.

PDs should only change when there is a re-connection and the CPE should 
be able able to handle that correctly updating its LAN prefixes accordingly.
Stimulating and making that easy for general usage is like a crime 
against IPv6. If one really needs to use that "chewing gun" he must know 
what he is doing and to manually for that exception case.


Regards
Fernando

On 04/05/2020 17:52, Joel Wirāmu Pauling wrote:
I am all for exposing Cone Nat in UCI / Firewall zones as an option to 
the masquerading configuration in a zone.


Also as much as I hate it nat66 for IPv6 needs to be exposed in the 
same place - specifically for mapping routable PD which change often 
to ULA's.


-Joel

On Tue, 5 May 2020 at 07:25, Gracias Amigou > wrote:


Please add this package as official:

*Posts:*

 1. xt_FULLCONENAT -- Implementing RFC 3489 full cone SNAT in
OpenWrt


 2. [12/8更新]OpenWrt 上实现 NAT1 (Full cone NAT) 的方法，无需
DMZ/UPnP - OPENWRT专版

 3. 从DNAT到netfilter内核子系统，浅谈Linux的Full Cone NAT实现 |
ChionLab


*
*
*Git:*
• GitHub - LGA1150/openwrt-fullconenat: Netfilter and iptables
extension for full cone NAT ported to OpenWrt.

___
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

[OpenWrt-Devel] Questions about IPv6 and NDP-Proxy

[Fernando Frediani]

Hello

I have seen on some old OpenWrt documentation 
(https://openwrt.org/docs/guide-user/network/ipv6/start#router_advertisement_dhcpv6) 
that by default when the router cannot receive a IPv6 Prefix Delegation 
(IPv6-PD) but only an IPv6 in the WAN it can automatically detect it and 
act as a NDP-Proxy so the clients in the LAN interface have IPv6 
connectivity.


I have tested it and was unable to observe this behavior without 
changing any configurations. If however I configured both the LAN and 
WAN6 interfaces as DHCPv6, RA and NDP in Relay mode plus WAN6 with 
'option master 1' then it works as expected.


Does anyone know if this automated behavior is expected or if in these 
cases it is always necessary to configured the interfaces in such way to 
make that work ?


This is useful as many people inadvertently connects the LAN port of a 
home router to a WAN port of a second router in order to extend signal 
and by using this technique allows that users connected to the secondary 
routers to keep IPv6 connectivity.


Thanks
Fernando


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

Re: [OpenWrt-Devel] Hamburg 2019 developer meeting details

[Fernando Frediani]

Hello Petr and all
Thanks for the detailed update about the meeting in Hamburg.

I wanted to make a some comments about a few points I consider important
for the project as someone that has been here for a while.

- Release Manager - I fully support it. It is something I suggested a while
ago in the form of an Elected Project Leader similar to Debian, but some
people confused with an autocrat who would assign tasks and ask people all
the time and didn't like at the time (and which my message had nothing to
do with it obviously). I consider not only necessary but essential having
an Release Manager responsible for gather all necessary things together,
organize dates in advance, engage the right people, etc, in order for a new
release to come up in a organized way and within defined deadlines. It is
just that, nothing else. Whenever there is some name already highlighted a
motion should be moved to ratify him/her and move on. While that is still
not possible having 3 people who can create releases is prudent.

- Future Releases every 6 months - Seems a reasonable time to have this
commitment. Even if it happens to be yearly as long there are regular point
releases.

- Number of Releases to be Supported - 2 looks fine to me, but don't think
it should be something 'written on stone'. Depending on the situation it
could be 3 temporarily upon developers decision when it justifies to extend
a previous version due justified circumstances (must think what is most
useful for users in general as well).

- 4/32MB devices - Good to see there was a discussion around it. These
devices are still a reality, quite usable, that can't be ignored and having
them supported for a little while is something good for the whole
ecosystem. Just saying "buy a new 8/64MB device and throw the other away"
isn't something practical and both sides of the coin should be well
reasoned. Good decision.

- New people, Contributions and Voting Access - Agree that commit access
and voting should not be binding as in early days. New rules and roles
should be agreed and vote restricted to those not only with frequent
contributions but also with a proven past history of contribution to the
project and that obviously represents majority of OpenWrt workforce. Having
some way to thank contributions is certainly something positive and welcome.

Forum/Wiki maintainers - Perhaps there can be a kind of committee of
people. I personally fell the Wiki constantly demands some love to be kept
updated and and with the right information for people seeking. These people
could more easily engage developers and contributors in general and to have
any important information about a device or architecture updated as soon at
that it is available in the code. Also getting used to update wiki pages
beforehand or right after a commit is something in my view very positive
and that should be encouraged.

Best regards
Fernando
On 10/07/2019 07:07, Petr Štetiar wrote:

tl;dr: 19.07 was branched, ar71xx is gone, we got some beers & pizzas

Hi all,

I'm writing on the behalf of OpenWrt team members attending the OpenWrt
meeting in Hamburg, which has happened a month ago, so it's about time to
publish some outcome :-)

Most of us met in the late afternoon on Sunday 9th June in a nice local pub
with a great beer selection, together with the Debian folks attending
MiniDebConfHamburg[1].

On Monday 10th June, we started right in the morning in one of the conference
rooms, where we sat down in the circle, introduced ourselves and provided
answers to the "What brings you here?" question. Shortly after this everyone
got marker and paper cards, writing down arbitrary number of topics he would
like to discuss during the following days. Then we put those cards on two
boards, merging similar topics together where applicable.

As you can imagine, this activity has produced a lot of topics, so we needed
to prioritize, so each attendee got five pins, each of those pins represented
one vote, topics with most pins (votes) were discussed first (topics with no
votes were discussed with a soft timer, 6 minutes dedicated to each topic,
where time was extended as needed).

With much discussion, we wrote down all the topics, ideas, TODOs to the
ChaosPad. After the meeting, we cleaned it up, transfered to our wiki[2],
reordered, added some photos and more details.

In the evening we went to some local place with a good pizza, where we
spontaneously decided that it's just right time to branch 19.01 finally (just
about 6 months later, yeah!) and lynxis created that branch as openwrt-19.07
around 21:33 CEST.  You can find a photo of this branching event at the
meeting's wiki[2] page as well.

Then we moved back to Dock Europe[3] venue, where we continued discussing some
of the topics till the early morning.

On Tuesday 11th June we got a visit from h01ger, Debian developer and one of
the developers behind reproducible-builds.org so we've used this opportunity
to talk about improvements in reproducible 

Re: [OpenWrt-Devel] Problem with "base" release repositories

[Fernando Frediani]

+1

Thanks for all Jo.

Fernando

On 26/06/2019 05:50, Bjørn Mork wrote:

Jo-Philipp Wich  writes:


the base repositories have been fully restored and should be safe to use
again.

Thank you for both fast resolution and the continous info updates.
That's pretty impressive, and I just have to wonder how much sleep you
got last night :-)

IMHO, this was a demonstration of professional issue handling with very
limited resources.  OpenWrt is obviously in good hands these days.

A big thanks to you all!




Bjørn

___
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] LEDE 17.01.7 and OpenWrt 18.06.3 deadline on Friday

[Fernando Frediani]

Hello all.
Thanks Jo for the update.

One thing that was discussed here a while ago and unless I am mistaken 
never came to a conclusion was the possibility of extending the life of 
17.01.x a little while due to many cases of 18.06 and its significant 
improvements not being able to run on so many very good or usable 
equipment at all.


I'm not sure what's the best way of finishing that discussion but 
regardless the final result of it I personally think in this case (which 
is slightly different from a normal end-of-life of any version), is 
worth at least discussing the pros and cons. One thing to highlight was 
that the last thing I remember was proposed was not for 17.01.x to keep 
receiving full support for this extra time but only major and security 
fixes.


Let me know your views.

Best regards
Fernando

On 20/06/2019 06:57, Jo-Philipp Wich wrote:

Hi,

please merge any outstanding changes that should be
part of LEDE 17.07.7 and OpenWrt 18.06.3 into the
respective lede-17.01 and openwrt-18.06 branches until
Friday, the 21st of June at 09:00 UTC.

I will tag these branches then and start building
corresponding binary releases shortly after.

The v17.01.7 release will also mark the end-of-life of
the LEDE 17.01 series - we'll decommission the LEDE
17.01 related build resources and repurpose them for
producing 19.07 binaries.

Regards,
Jo


___
openwrt-adm mailing list
openwrt-...@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-adm
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Europe to vote a regulation that may forbidden alternative software on radio devices

[Fernando Frediani]

Hi all

Not sure if this was shared already but European Union is discussing at 
the moment regulations which may make impossible to install a custom 
piece of software on most radio devices, as OpenWrt for example and others.


https://blog.mehl.mx/2019/protect-freedom-on-radio-devices-raise-your-voice-today/
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014L0053

If most are not aware perhaps it's the case to get in touch with the 
Expert Group in order to let them know the impacts of this possible change


http://ec.europa.eu/transparency/regexpert/index.cfm?do=groupDetail.groupDetail=3413

Best regards
Fernando


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

[OpenWrt-Devel] Problems related to High Load on new LuCI

[Fernando Frediani]

Hi all.

I just wanted to let everyone know about this pretty interesting 
discussion on OpenWrt Forum about the ongoing problem of High Load on 
new LuCI interface since 18.01.


https://forum.openwrt.org/t/proposal-and-solution-for-high-load-fix-on-openwrt-luci/29006

Perhaps people and developrs who not follow the forum can give their 
input or find out more about this issue which is happening with several 
people reporting it.
That may not be the final solution but may encourage people to 
contribute or find out more about towards the resolution of the issue.


Regards


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

Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches

[Fernando Frediani]

On 20/12/2018 17:46, James Feeney wrote:


There also seems to be a presumption that a "newbie" is, or should be, running 
luci.  I believe that that is also an inappropriate assumption.
I think that is a pretty reasonable assumption. A newbie does need a web 
interface. I would say more: that is what brings a lot more 
attractiveness to the usage  and to the project itself.


Vast majority of people who use OpenWrt on their routers are not 
developers or very technical and don't think as developers, don't even 
know what SSH or Telnet means but they are pretty comfortable in using a 
intuitive web interface as LuCI is. So in short Web Interface for a 
version that is not custom is kind of vital.


Now, how to treat this issue for 4MB I am not sure yet. Need to give it 
some extra thought and I am not worried about customized versions 
because then the person know what he's doing.


One more thing: I find it horrible in 2018/2019 when people remove IPv6 
support at any conditions in order to save space or memory. This shows a 
very bad example and in my view should not stimulated. Perhaps not have 
other packages in favor of keeping IPv6 but that's another discussion.


Regards


Using some web interface is not necessarily any easier than using a command line interface.  Just because 
Apple or Microsoft teach people to use a Graphical User Interface does not mean that LEDE/OpenWRT should be 
doing the same thing.  "Newbie" is not the same thing as "Dumbed-Down".  Now, if there is 
no text-terminal-based configuration "helper" for LEDE/OpenWRT, again, that is a distinct issue to 
discuss here.

___
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] [RFC] stop accepting 4/32M board patches

[Fernando Frediani]

Sorry about that. I had clicked into Reply to List and for some reason 
it included only one of them.


Then the question may be simpler only about 32MB of RAM if it's the case 
for newer devices or not.


Let's see others opinions. I am not entirely convinced but I see your point.

Fernando

On 05/12/2018 12:18, Mathias Kresin wrote:
Please don't top post and keep all lists as recipients. I added 
openwrt-devel back to the list of recipients.


05/12/2018 14:57, Fernando Frediani:

Hi

Just to make it clear you mean that for the master right ? Not for 
18.06 (when it becomes 19.0x) and LEDE 17.01 (while it's still alive) ?

If so I agree 4MB isn't something much feasible anymore.


You got my mail wrong. It is about not accepting new patches for such 
boards. Dropping support for existing boards wasn't mentioned and 
isn't my intention.


Btw. master will be 19.0x.

Mathias



However for 32MB devices I have serious doubts as mentioned in 
another email there are good devices that may work well with 32MB/8MB 
and I don't think hardly dropping it is a good idea, at least not for 
the current 18.06.
And I am still seeing that some new devices are going to marketed 
with 32MB/8MB so 64MB RAM ones are not majority yet.


Do you have any numbers of how much effort will be put into that to 
perhaps justify this hard drop for 32MB ones and mainly about the 
popularity of these devices from the download website ?


I am not sure a vote would be the best thing to use in this scenario, 
otherwise there would need to be a vote for other things discussed 
and not always that is something ends well. Let's see how this thread 
goes before considering it.


Regards
Fernando

On 05/12/2018 06:56, Mathias Kresin wrote:

Hey all,

I would like to start to reject patches for adding boards with only 
32 MByte of RAM and 4 MByte of flash [0]. These boards barely work 
with todays OpenWrt default builds and require quite some 
modifications to be useful at all [1].


IMHO it doesn't make much sense to waste resources (reviewer time, 
build resources) for boards which will most likely never see an 
official build and/or are more or less unusable with the official 
build.


I prefer to have a joint statement which I can link to, to prevent 
endless discussions or accusations of acting purely arbitrary.


I'm not sure whether the topic qualifies for a formal voting, hence 
the RFC.


Mathias

[0] https://github.com/openwrt/openwrt/pull/1577
[1] https://openwrt.org/supported_devices/432_warning

___
openwrt-adm mailing list
openwrt-...@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-adm


___
openwrt-adm mailing list
openwrt-...@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-adm




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

Re: [OpenWrt-Devel] OpenWrt Roadmap

[Fernando Frediani]

Has this discussion gone anywhere ?

Are we keeping LEDE 17.01 for a little while under these conditions or not ?

Regards
Fernando

On 12/11/2018 18:57, Fernando Frediani wrote:
Totally agree with Luiz. That was the idea behind this proposal and 
you managed to even easier words.


Alberto, the tiny subtarget you mentioned doesn't really seem to run 
well or stably for 18.06 on many of these devices regardless the flash 
size, that's the main point.
As mentioned there are many new devices still coming with 32MB of RAM 
and which can take benefit of OpenWrt for various reasons and usages.


I think for many of us here are completely fine to put some extra cash 
and buy a newer hardware to cope with OpenWrt evolution but the 
reality is that majority of people are not. Another example I wanted 
to put to illustrate is an ISP that has thousands of existing devices 
with similar specs running, being still able to keep using OpenWrt 
more securely while they start to introduce newer hardware to their 
customer base allowing to make a more smooth transition to these more 
powerful hardware.


Regards
Fernando

On 12/11/2018 18:20, Luiz Angelo Daros de Luca wrote:

Hello,

There are a significant amount of devices out there that has 4/32
specs. Even brand new ones.
If there is stability issues with newer OpenWrt versions on those
devices, we should rethink LEDE EOL.

Maintenance burden is directly related to the amount of software to
maintain. At the same time, low specs means they might have no
interest in most packages.
Maybe 15.05 life could be extend with a lower cost by limiting
maintenance to a subset of packages (core? even less?). We could
release LEDE 15.05.(x+1) LTS with feeds configured to use only that
subset of packages. We could also limit the images to those low spec
models.

EOL is not really a big deal until it requires a new HW. Routers are
things that die hard, even after a decade. It just doesn't seem right
to turn old working hw into electronic waste because of software.
Keeping old stuff running is even on of the reasons to use OSS.

Regards,

___
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] PCP and Allow Port Forward for IPv6

[Fernando Frediani]

Hello folks.

I wanted to ask something specific regarding PCP, IPv6 and incoming 
traffic to clients.


If I remember well, a long time ago when full IPv6 support was being 
added to OpenWrt there was a hot discussion if the default firewall 
rules for IPv6 should allow any incoming connections to LAN clients or 
if they should block and the exceptions should be made manually. 
Fortunately, in my view, the decision was to block by default and that's 
how it is know, if I don't miss anything.


But there are cases when incoming connections to LAN clients in IPv6 are 
necessary and most of the time they don't have admin access to the CPE.
Reading some RFCs like 6888 it talks about PCP (RFC 6887 - 
https://tools.ietf.org/html/rfc6887) which disciplines exactly this I am 
talking about on its abstract.
This is also mentioned in RFC 7368 Section 3.6.1 
(https://tools.ietf.org/html/rfc7368#section-3.6.1)


Then looking at the miniupnpd package details 
(https://openwrt.org/packages/pkgdata/miniupnpd) it mentions it has a 
PCP daemon.


Question is: Is it fully implemented including support for IPv6 ? So if 
a modern Operating System makes a request to a CPE which runs this PCP 
Daemon it will be able to add the necessary iptables FORWARD rule to 
allow an incoming connection to that client which requires it ?


Thanks
Regards

Fernando


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

Re: [OpenWrt-Devel] OpenWrt Roadmap

[Fernando Frediani]

Hi.

I think there is a little misunderstanding about this topic.
As many know here for OpenWrt doesn't quiet work as the same for a 
company's project where you may have dedicated people to a project. 
People work in the stuff they get interested and give some attention to 
whatever is agreed by the project guidelines.
I am sure developers will continue to dedicate most of their time to the 
newer and trunk versions and if agreed to extend LEDE 17.01 EOL to it as 
well whenever is strictly necessary.


The idea put is to extend LEDE 17.01 EOL a little while (not forever) 
because it has been reported by a significant amount of people that 
18.06 is not an option anymore for a large amount of older but still 
usable devices due its bigger footprint. Also to minimize the amount of 
attention it may require the idea is not to have new features but only 
critical security and bug fixes. If 18.06 was an option this would not 
be necessary but as there has been significant improvements to this 
version then extending LEDE 17.01 EOL becomes justifiable given the 
number of active devices that still benefit for it.


Best regards
Fernando

On 12/11/2018 20:39, Alberto Bursi wrote:


On 12/11/18 21:57, Fernando Frediani wrote:
Totally agree with Luiz. That was the idea behind this proposal and 
you managed to even easier words.


Alberto, the tiny subtarget you mentioned doesn't really seem to run 
well or stably for 18.06 on many of these devices regardless the 
flash size, that's the main point.
As mentioned there are many new devices still coming with 32MB of RAM 
and which can take benefit of OpenWrt for various reasons and usages. 
I think for many of us here are completely fine to put some extra 
cash and buy a newer hardware to cope with OpenWrt evolution but the 
reality is that majority of people are not. Another example I wanted 
to put to illustrate is an ISP that has thousands of existing devices 
with similar specs running, being still able to keep using OpenWrt 
more securely while they start to introduce newer hardware to their 
customer base allowing to make a more smooth transition to these more 
powerful hardware.



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.


The ISP can pay for someone to do this job if they think really need 
it (but imho it would be better to spend their funds in newer 
hardware, besides they should have planned for hardware obsolescence 
already).


As a point of comparison, even Debian that is far larger than OpenWrt 
only agreed to extend the support period for its old release (which is 
a "mostly core packages" affair too, kernel, basic userspace and 
server software) after some sponsors showed up and paid for it.


-Alberto




Regards
Fernando

On 12/11/2018 18:20, Luiz Angelo Daros de Luca wrote:

Hello,

There are a significant amount of devices out there that has 4/32
specs. Even brand new ones.
If there is stability issues with newer OpenWrt versions on those
devices, we should rethink LEDE EOL.

Maintenance burden is directly related to the amount of software to
maintain. At the same time, low specs means they might have no
interest in most packages.
Maybe 15.05 life could be extend with a lower cost by limiting
maintenance to a subset of packages (core? even less?). We could
release LEDE 15.05.(x+1) LTS with feeds configured to use only that
subset of packages. We could also limit the images to those low spec
models.

EOL is not really a big deal until it requires a new HW. Routers are
things that die hard, even after a decade. It just doesn't seem right
to turn old working hw into electronic waste because of software.
Keeping old stuff running is even on of the reasons to use OSS.

Regards,

___
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


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

Re: [OpenWrt-Devel] OpenWrt Roadmap

[Fernando Frediani]

Totally agree with Luiz. That was the idea behind this proposal and you 
managed to even easier words.


Alberto, the tiny subtarget you mentioned doesn't really seem to run 
well or stably for 18.06 on many of these devices regardless the flash 
size, that's the main point.
As mentioned there are many new devices still coming with 32MB of RAM 
and which can take benefit of OpenWrt for various reasons and usages.


I think for many of us here are completely fine to put some extra cash 
and buy a newer hardware to cope with OpenWrt evolution but the reality 
is that majority of people are not. Another example I wanted to put to 
illustrate is an ISP that has thousands of existing devices with similar 
specs running, being still able to keep using OpenWrt more securely 
while they start to introduce newer hardware to their customer base 
allowing to make a more smooth transition to these more powerful hardware.


Regards
Fernando

On 12/11/2018 18:20, Luiz Angelo Daros de Luca wrote:

Hello,

There are a significant amount of devices out there that has 4/32
specs. Even brand new ones.
If there is stability issues with newer OpenWrt versions on those
devices, we should rethink LEDE EOL.

Maintenance burden is directly related to the amount of software to
maintain. At the same time, low specs means they might have no
interest in most packages.
Maybe 15.05 life could be extend with a lower cost by limiting
maintenance to a subset of packages (core? even less?). We could
release LEDE 15.05.(x+1) LTS with feeds configured to use only that
subset of packages. We could also limit the images to those low spec
models.

EOL is not really a big deal until it requires a new HW. Routers are
things that die hard, even after a decade. It just doesn't seem right
to turn old working hw into electronic waste because of software.
Keeping old stuff running is even on of the reasons to use OSS.

Regards,

___
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

[Fernando Frediani]

Hello.

I want to make a point about LEDE 17.01 branch.

I have seen in the forums and also testing myself the many people are
running LEDE 17.01 pretty stable and with good performance on older
devices. As we know there are 18.06 builds for some of these devices
as well but that have been reports of slowdowns overtime, instability,
higher latency or cases that was necessary to downgrade. On some
discussions people mentioned that this may be due to two main things:
a) newer kernel footprint b) newer LuCI of 18.06.

Even for some devices with 32MB of RAM and 8MB of flash it was
noticeable that 18.06 wasn't as stable as LEDE 17.01. There are also
successful tiny and stable builds for devices with 32MB of RAM and 4MB
of flash and which would be even harder if not impossible to keep the
bare minimal due to the bigger footprint of 18.06 for these cases. I
fully agree 4MB of flash is out of question for 18.06 and going
forward but there are several success cases for 17.01 tiny and custom
builds. And note that as just mentioned there are cases where even
with 8MB of flash 18.06 has not been an option.

We know that OpenWrt has been responsible for given a lot of extra
life to routers due to its newest features. Just to mention one great
example is full IPv6 support to routers where manufacturers stopped to
develop firmware upgrades.

Given that the point I want to put is to perhaps extend 17.01 life
beyond January 2019, at least to receive security patches.
I would normally agree with its retirement as normal part of OpenWrt
life-cycle but I fell that in this case we have a kind of special
situation where it is worth to keep it alive for a little while until
there is a lot of these usable hardware around.

Best regards
Fernando

On 05/11/2018 18:31, Hauke Mehrtens wrote:

Hi all,

We had a discussion about the future OpenWrt Roadmap in July here:
http://lists.infradead.org/pipermail/openwrt-adm/2018-July/000849.html

The outcome from my perspective is the following.

The next release would be done in January 2019 and named 19.01, this
release will probably have code freeze and get branched off in December
2018.
All targets included in 19.01 must use kernel 4.14, kernel 4.9 or older
will not be supported any more, kernel 4.19 will also not yet be
supported in 19.01.
The toolchain will use gcc 7.X, binutils 2.31.1 and musl 1.1.20, it
could be that we upgrade musl to 1.1.21, but gcc will stay on the 7.X
branch.
We already upgraded the wireless drivers to match what is shipped with
kernel 4.19.
OpenSSL should be upgraded to version 1.1.1 before the release.
The rest depends on what people are interested and merge into master
before the branch is created.

The following targets currently use kernel 4.9 and should be upgraded to
kernel 4.14 if they should be in the next release:
* ar7
* ixp4xx
* layerscape
Someone from NXP said they will provide some patches in November.
* brcm2708
I looked at the kernel patches from here:
https://github.com/raspberrypi/linux
* at91
Someone from Microchip already proposed some patches
* orion
* rb532


The next release after 19.01 would be planned for the summer or fall
2019, this release will be based on kernel 4.19, all targets have to be
upgrade to kernel 4.19 by then. This release will probably not contain
ar71xx any more, but only ath79 for these boards.


Support for kernel 4.19 will be added into OpenWrt master soon, but we
will not use it as a default kernel for any target before the 19.01
release is branched off.

Support for kernel 3.18 should be removed soon, we will move the targets
that depend on kernel 3.18 to the unmaintained target feed:
https://github.com/openwrt/targets
If you are interested in one of them, please bring them to kernel 4.14.


The LEDE 17.01 branch will be fully end of life in January 2019, I plan
a final release with the current git status and then it will not even
get fixes for severe security problems any more, currently it only gets
limited security support and all users are already encouraged to upgrade
to OpenWrt 18.06.
OpenWrt 18.06 will get security support till sometime in 2019, we
haven't decided about a date.

If you think we should do something differently please replay to this
mail, we can still change this.

Hauke

___
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] TP-Link Archer C20 v4 and MediaTek MT7628AN and MT7610E

[Fernando Frediani]

Hello folks

I have been trying to make TP-Link Archer C20 v4 to work with OpenWrt. 
It has already a build however both 2.4Ghz and 5Ghz wifi don't work 
properly at present.


For the 2.4 Ghz although it has support it is very unstable and unusable 
as for the MT76 driver used. Has anyone used a different wifi driver ? I 
have seen some Githubs with MT7628AN stuff. Is it somehow different and 
more stable than MT76 ?


For the MT7610E it is said there is not open-source driver available, 
but I have also seen some Githubs with it [1]. Has MediaTek opened its 
code already ? It it stable or usable ? If so can it be added to the 
snapshot ?


I believe this is the main Forum Thread for this router [2], but there 
is no extra information other than some people seem to have made MT7610E 
to work but not with much details about stability.


Thanks
Fernando

[1] - https://github.com/presisco/openwrt-mt7610e
[1] - 
https://github.com/mqmaker/witi-openwrt/tree/master/package/ramips/drivers/mt7610e

[2] - https://forum.openwrt.org/t/tp-link-archer-c20-v4-build/8945


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

Re: [OpenWrt-Devel] [LEDE-DEV] 18.06 Status?

[Fernando Frediani]

I didn't mention forcing people at any point. Just having someone to be 
in charge in order to organize certain things, get people's availability 
and make more thing happen.


With regards schedule the lack of one seems not doing much good, so 
having one has the potential to improve things. And again, having a 
schedule doesn't necessarily mean every single point will get done, but 
certainly will get more attention and commitment from most of people 
around something in common. It will not be a big thing if a feature was 
skipped.


As mentioned in the other reply perhaps Release Coordinator could do 
this job fine without changing much of the whole thing.


Regards
Fernando

On 05/05/2018 15:55, Alberto Bursi wrote:

This isn't a job where you can force people to do anything.

Also, I'm not a fan of half-assing or leaving out things for the sake 
of a schedule.



-Alberto

On 05/05/2018 20:41, Fernando Frediani wrote:
One characteristic from OpenWrt, different from other projects is the 
lack of a leader or a person who can gather others together, make 
some decisions or push for them to happen. If one doesn't like this 
title it can also be "Project Manager" or "Project Coordinator". 
This, in my view, makes a big difference for things to flow in time.


Has anyone heard that saying: "A dog with many owners starves"

Perhaps it is the time to adjust the Rules 
(https://openwrt.org/rules) and add something to make it exist in 
benefit of the project.


Fernando

On 05/05/2018 07:27, Jaap Buurman wrote:

Hi all,

I feel like everybody is just waiting for everybody to agree what
features we want in before coming up with the next step of picking a
date. Obviously this isn't working out very well. Why not turn things
around? Pick a date in a few weeks time on which the Master branch
will be split to a 18.0X branch. If nobody complains before that date
the branch goes on as planned. People can obviously get in the
features they want before said date. If somebody deems a particular
feature very important to be included in this branch, but feels like
it will not be finished before said date, he/she can request a delay
stating:

-What he/she would like to include
-Why this is so important to be included before the branch.
-How much extra time this will need by proposing a new date
-Perhaps a request for help implementing said change

Should this proposal be accepted, we will reschedule the date from
there. If the other people don't think it is important enough to
postpone the release, the old date will stand. This way, we can simply
move forward if nobody complains about a particular date instead of
the waiting around for others that is going on right now. What does
everybody else think of this idea? What seems like a reasonable date?
And who would be willing to take on the task of splitting the branch
at said date to make sure we'll be actually moving forward with the
plan at said date?

Yours sincerely,

Jaap Buurman

On Wed, May 2, 2018 at 4:41 AM, Eric Luehrsen 
<ericluehr...@gmail.com> wrote:

On 05/01/2018 10:47 AM, Hannu Nyman wrote:
I think that the main source tree is in pretty good shape, so 
branching

off the 18.0X rather soon might make sense


I would also think its time to branch 18.[something-soon], and 
rather than

focus on work that needs yet to be completed, look to cut hardware and
packages that are not ready for a release. There is always some 
heart ache
when such decisions are made, but at a point those decisions do 
need to be
made. Without an official release to punctuate both the core team 
and other

packagers hard work, OpenWrt/LEDE could risk losing support from the
community and its limited sponsorship. I imagine this project means
something personally to the core team, so those risks should be 
considered.


- Eric


___
lede-adm mailing list
lede-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-adm

___
lede-adm mailing list
lede-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-adm



___
Lede-dev mailing list
lede-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev



___
Lede-dev mailing list
lede-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

Re: [OpenWrt-Devel] [LEDE-DEV] 18.06 Status?

[Fernando Frediani]

One characteristic from OpenWrt, different from other projects is the 
lack of a leader or a person who can gather others together, make some 
decisions or push for them to happen. If one doesn't like this title it 
can also be "Project Manager" or "Project Coordinator". This, in my 
view, makes a big difference for things to flow in time.


Has anyone heard that saying: "A dog with many owners starves"

Perhaps it is the time to adjust the Rules (https://openwrt.org/rules) 
and add something to make it exist in benefit of the project.


Fernando

On 05/05/2018 07:27, Jaap Buurman wrote:

Hi all,

I feel like everybody is just waiting for everybody to agree what
features we want in before coming up with the next step of picking a
date. Obviously this isn't working out very well. Why not turn things
around? Pick a date in a few weeks time on which the Master branch
will be split to a 18.0X branch. If nobody complains before that date
the branch goes on as planned. People can obviously get in the
features they want before said date. If somebody deems a particular
feature very important to be included in this branch, but feels like
it will not be finished before said date, he/she can request a delay
stating:

-What he/she would like to include
-Why this is so important to be included before the branch.
-How much extra time this will need by proposing a new date
-Perhaps a request for help implementing said change

Should this proposal be accepted, we will reschedule the date from
there. If the other people don't think it is important enough to
postpone the release, the old date will stand. This way, we can simply
move forward if nobody complains about a particular date instead of
the waiting around for others that is going on right now. What does
everybody else think of this idea? What seems like a reasonable date?
And who would be willing to take on the task of splitting the branch
at said date to make sure we'll be actually moving forward with the
plan at said date?

Yours sincerely,

Jaap Buurman

On Wed, May 2, 2018 at 4:41 AM, Eric Luehrsen  wrote:

On 05/01/2018 10:47 AM, Hannu Nyman wrote:

I think that the main source tree is in pretty good shape, so branching
off the 18.0X rather soon might make sense


I would also think its time to branch 18.[something-soon], and rather than
focus on work that needs yet to be completed, look to cut hardware and
packages that are not ready for a release. There is always some heart ache
when such decisions are made, but at a point those decisions do need to be
made. Without an official release to punctuate both the core team and other
packagers hard work, OpenWrt/LEDE could risk losing support from the
community and its limited sponsorship. I imagine this project means
something personally to the core team, so those risks should be considered.

- Eric


___
lede-adm mailing list
lede-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-adm

___
lede-adm mailing list
lede-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-adm

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

Re: [OpenWrt-Devel] Google Summer of Code 2018 - Ideas

[Fernando Frediani]

I tried to add something but couldn't manage to.

The point would be related to implementing TDMA for OpenWrt which seems 
to have been considered many times and some work has been done but never 
concluded. If someone finds it suitable feel free to put it up.


Thanks
Fernando


On 22/01/2018 05:25, Andreas Bräu wrote:

Hi there,

thank you for all your ideas you submitted so far for 
https://projects.freifunk.net/#/projects


Even though we have to finish our application until tomorrow, you can 
still add more ideas via GitHub: 
https://github.com/freifunk/projects.freifunk.net-contents


The whole timeline for GSoC 2018 you can find at 
https://summerofcode.withgoogle.com/how-it-works/#timeline


Please ask if there are any open questions

Thanks

Andi


—
Andreas Bräu

XMPP: andibr...@jabber.weimarnetz.de 
Twitter:@evAltenberga 
Blog:https://blog.andi95.de 
PGP:0xB7E04818



___
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] DPDK APP

[Fernando Frediani]

That would be a awasome feature if possible.

Fernando

On 9 Sep 2017 04:55, "yug...@telincn.com"  wrote:

> Hi all,
> Whether if   there is a way to surpport building DPDK and APP on or for
> openwrt?
>
> Regards,
> Ewan
>
> --
> yug...@telincn.com
>
> ___
> 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] Talks between OpenWrt and LEDE

[Fernando Frediani]

Great achievement. Congratulations to all involved.

On the naming topic have in mind the weight OpenWRT has given its history
in all these years. I personally think this point is the easiest.

Given the agreements continue hopefully there will be a single one great
project again soon with all benefits LEDE has brought in terms of
flexibility, agility and transparency to all contributors.

Thanks
Fernando Frediani

On 21 December 2016 at 16:06, Hauke Mehrtens <ha...@hauke-m.de> wrote:

> We had multiple meetings to find a solution to solve the problems
> between the OpenWrt and the LEDE project and to discuss a possible
> merge. Everyone with commit access to LEDE and all OpenWrt core
> developers were invited to these meetings. We had productive and
> friendly discussions about the problems and our goals.
>
> To be more open and to involve the wider community in these discussions
> we would like to publish the meeting minutes from the meetings.
>
> The first in person meeting took place in Berlin at the OpenWrt Summit
> on 13. October 2016, but no one took any minutes so we do not have
> anything to publish.
> The second meeting was an audio conference on 5. November 2016 and
> Florian took minutes which are attached to this mail.
> At the third audio conference meeting on 3. December 2016 Jow took
> minutes which are also attached to this mail.
> The last meeting took place on 19. December 2016.
> These minutes are representing the current state of the discussions and
> are not PR polished.
>
> We agreed on giving Imre, Zoltan and Luka commit access to the LEDE
> repository so they can migrate changes they care about and which are not
> in LEDE, from the OpenWrt repository to the LEDE repository. We also
> encouraging everyone who sent a patch, which got merged into OpenWrt and
> which is not in LEDE to send it also to LEDE for integration.
>
> It is still not decided that both project will finally merge and we
> haven't decided on the name to use, which parts of the infrastructure
> and many other things. In general we are agreeing on many parts and I am
> looking forward to a good merged ending for all of us.
>
> ___
> 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] Mirroring OpenWRT at MIT

[Fernando Frediani]

Hello Madars,

It´s nice to see that people still get interested in helping OpenWrt
project, but as you may have seen that's one of the main issues of it: that
lack of response, even for people willing to give extra hands and resources.
No wonder why LEDE came up !
Based on things like this it makes me think that a rejoin of OpenWrt and
LEDE becomes something distant.

Fernando

On 17 June 2016 at 21:22, Madars Virza  wrote:

> Dear openwrt-devel,
>
> I'm with MIT SIPB, the student computing club of Massachusetts Institute
> of Technology (https://sipb.mit.edu/). As one of our projects, we
> maintain high-speed mirrors for open source projects --
> http://mirrors.mit.edu/ .
>
> I'm writing you because we'd like to start mirroring OpenWRT.
>
> Is there an official rsync upstream we could use for this?
> downloads.openwrt.org only seems to be accessible over https. If needed
> for your firewalls, we can guarantee a static IP for all of our
> mirroring activity.
>
> Thank you,
>
> Madars Virza
> MIT SIPB
>
> P.S. We previously sent some other emails, but got no responses; please
> let us know if there's a more appropriate list to contact :-)
> ___
> 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 / LEDE

[Fernando Frediani]

Wow. What a great email !!!

OpenWrt core people who have decided to stay with the project think
carefully about it.

In my humble vision reunite with LEDE new ideas and keeping the well
stabilished OpenWrt name is the ideal scenario.
Put aside the diferences and makd an effort for this to happen.

Fernando
On 26 May 2016 08:43, "Jo-Philipp Wich"  wrote:

> Hi all,
>
> I think the status quo has now been described several times and can be
> summarized as:
>
>  - Launching the new LEDE project/fork/reboot without discussing
>matters in advance with the developers not being involved was
>perceived in a hostile action damaging OpenWrt
>
>  - It has been claimed that any changes implemented by LEDE can be
>likewise implemented in OpenWrt as well, obviously not 100%
>identically without prior discussion but at least in a way keeping
>original intents and spirits
>
>  - Both sides expressed the wish to reunite on several occasions
>
> I very much apologize for the huge surprise the LEDE project has been
> to you and I do regret the fact that we didn't discuss it earlier with
> you guys. Some of us got caught in the belief that building a new,
> shiny sandpit according to our liking would be the better course of
> action compared to drastically changing OpenWrt for something not
> guaranteed to work in the long run.
>
> That being said I still think that LEDE already is a success, at least
> in my personal perception. When I mention "we" here I mean all the
> people having participated in LEDE, regardless of affiliation or agenda.
>
> Notable points are:
>
>  - We managed to figure out workflows supporting both mailing-list /
>patchwork-driven development and a more contributor oriented pull
>request model
>
>  - We figured out how to have a linear history without resorting to
>limiting ourselves to svn now (which was the sole argument for
>keeping it btw.)
>
>  - We reworked the buildbots to be more efficient
>
>  - We managed to quickly acquire donations, specifically regarding
>mirror space and build bot capacity
>
>  - We based the web page on a Git repo and mirrored that to Github
>in order to let people contribute
>
>  - We attempted to do everything publically [since the LEDE announcemnt]
>and retroactively published communication regarding the project
>implementation
>
>  - We have between three to four people per server having root access,
>with at least one person not being affiliated with "the cabal"
>
> On the other hand we didn't yet manage to:
>
>  - Clearly communicate our past and future intents upfront and after
>the fact
>
>  - Start a proper discussion with OpenWrt regarding the future direction
>of both projects
>
>  - Untangle the infrastructure (wiki.openwrt.org, dev.openwrt.org,
>git.openwrt.org)
>
>
> The weak effort on both sides in talking about both projects future
> direction paralyzed progress for all of us and in the associated
> communities so I'd very much like to reach at least some agreement or
> definitive decision soon.
>
> In order to underline my honest intention I'd like to give up
> maintenance of the OpenWrt wiki and hand the data / SSH access over to
> you guys so that you can migrate / maintain / rework it as you deem
> fitting.
>
> We're also still in possession of the secret build key for the CC
> release used to sign the package repositories. I'd be glad to throw it
> over the fence and assist you with using my package rebuild scripts to
> push security updates.
>
> Please tell me a contact and I'll provide the person with suitable
> access.
>
> I also still have root access to dev.openwrt.org hosting the Trac,
> though you could reach out to Mirko as well to get access to the system.
>
> Luka mentioned that OpenWrt plans to move to Github, we'd be very happy
> if we could spare you the conversion work - we have a cleanly converted
> repository available at https://git.lede-project.org/openwrt/source.git
> which you could use as starting point for future developments - that
> repository maps the historic SVN and CVS branch/tag structure as good
> as possible to proper Git branches and tags. I also took some care in
> converting svn committer nicknames to proper authors.
>
> We did equivalent conversions for the old packages and old feeds svn
> repositories in https://git.lede-project.org/openwrt/packages.git and
> https://git.lede-project.org/openwrt/feeds.git .
>
> Finally I'd like to hand over my non-root access to the OpenWrt
> buildmaster which I'd hand over to interested OpenWrt people. I took
> over maintenance for some time because Travis has been rather busy with
> real life these days.
>
> If there is truly some interest among the remaining OpenWrt folks to
> reunite while adopting the visions and working modes of LEDE then
> please speak up and tell us about your demands.
>
>
> Best wishes,
> Jo
> ___
> openwrt-devel mailing list
> 

Re: [OpenWrt-Devel] Introducing the LEDE project

[Fernando Frediani]

Thanks Daniel. That explains a lot.
I imagine if some digging is done it would be possible to find the holders
of the critical resources and then re-organize it from scratch within the
OpenWrt Project.
But as the fork has already happened there is no much point in doing that.

Regards,
Fernando

On 4 May 2016 at 21:05, Daniel Dickinson <open...@daniel.thecshore.com>
wrote:

> On 16-05-04 07:59 PM, Fernando Frediani wrote:
> > Just curious to know by the names that signed the announcement of the
> > new project being know OpenWrt Developers why weren't there enough votes
> > inside OpenWrt to do this reboot and reorganize it completely under the
> > LEDE Project ideas ?
>
> I don't know if there is a project charter, but from when I was
> developer (I step aside because I was having personal issues not openwrt
> related) I wasn't aware of an actual voting mechanism or constitution
> that said majority rules.  I'm not sure that there is an actual
> democratic method of decision making in the current framework.
>
> 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

[Fernando Frediani]

Just curious to know by the names that signed the announcement of the new
project being know OpenWrt Developers why weren't there enough votes inside
OpenWrt to do this reboot and reorganize it completely under the LEDE
Project ideas ?

The LEDE ideas are great and the the long time and outstanding issues with
OpenWrt are known to most people here, but I personally suspect if these
changes were done inside the OpenWrt Project, even if there are
disagreements would be more benefits in long term. May be wrong, but it´s
my impression.

Fernando


On 4 May 2016 at 18:40, Daniel Dickinson 
wrote:

> On 16-05-04 12:25 PM, Kathy Giori wrote:
> > 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.
>
> Silly question, but can you outline some specific examples of
> contributions that an outsider like me has somehow missed as being as
> concrete examples of companies contributing back to openwrt, rather than
> just benefiting from it?
>
> 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] [PATCH][ar71xx] Mikrotik Routerboard RB2011 switch fix

[Fernando Frediani]

Out of curiosity. Dp these builds of OpenWrt for Mikrotik RBs make usage 
of any possible hardware off-loads or config customizations are CPU 
affinity possibility made by Mikrotik themselves in their original 
RouterOS ?


Thanks
Fernando

On 15/10/2015 14:48, George Chriss wrote:


On Thu, April 23, 2015 06:16:08 CEST, Toerless Eckert wrote:
> This mail thread seem to have gone dark since december with seemingly
> no conclusion.
>
> I have tried to collect the experiences reported on the wiki page:
>
> wiki.openwrt.org/toh/mikrotik/rb2011uias 


>
> As you can see from the table, for me it only works with 0x6f.
> Chris, for whom both 0x3e and 0x6f work has a rev 2 AR9344. I have
> a rev 3. AR8327 is rev. 4 on both our routerboards. No info what rev 
Matt

> has, he is the other one reporting that only 0x6f works.
>
> I am also observing some amount of increases in switch 0 port 0
> RxBadByte (aka: from CPU to AR8327). It seems to happen for
> all type of traffic sent from CPU to switch, eg: whether i inject it 
from

> WiFi or from a 100 Mbps port, and whether i send it out
> on an untagged port (lan) or tagged one (from CPU, Wan).

I'm under the impression that some of the "OK/Not OK" reports are 
based on ping packet loss which provides limited insight into actual 
throughput.  My results with a RB2011UiAS-IN (no WiFi, empty SFP cage, 
AR9344 Rev. 2, CPU @ 600MHz powered from the DC-in jack) on patched 15.05:


0x0600 (Unpatched)
No TCP/IP 2-way connection [Not OK]

==

0x3e00
(MikroTik Eth1 -> laptop, crossover cable)
/bin/bash -c "dd if=/dev/zero bs=1M count=1000 | netcat 192.168.1.101 
"

1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 1589.44 s, 660 kB/s  [Not OK]

(laptop -> MikroTik Eth1, crossover cable)
dd if=/dev/zero bs=1M count=1000 | nc 192.168.1.121 
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 49.6707 s, 21.1 MB/s  [OK]

==

0x6f00
(MikroTik Eth1 -> laptop, crossover cable)
/bin/bash -c "dd if=/dev/zero bs=1M count=1000 | netcat 192.168.
1.101 "
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 176.224 s, 6.0 MB/s  [OK?]

(laptop -> MikroTik Eth1, crossover cable)
dd if=/dev/zero bs=1M count=1000 | nc 192.168.1.121 
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 50.7454 s, 20.7 MB/s  [OK]


Any word on the bootloader patch?  Happy to test more values as needed.

Sincerely,
George


> I have not really identified any noticeable performance impact from
> this effect through.
>
> Would be nice to hear some logic why 0x6f is the right value.
>
>> From the discussion it looks a bit like trial and error.
>>
>
> Cheers
> Toerless
>
>




___
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] [PATCH][ar71xx] Mikrotik Routerboard RB2011 switch fix

[Fernando Frediani]

Hello George.
No, unfortunatelly it doesn't. I was trying to get a more objective 
reply from perhaps whoever built and maintains this router profile in 
order to understand and compare when using original firmware and OpenWrt 
customized to it. All around the performance X feature list.

As the wiki doesn't mention that I asked it here.

Thanks
Fernando

On 15/10/2015 15:17, George Chriss wrote:
On Thu, Oct 15, 2015 at 2:00 PM, Fernando Frediani 
<fhfredi...@gmail.com <mailto:fhfredi...@gmail.com>> wrote:

>
> Out of curiosity. Dp these builds of OpenWrt for Mikrotik RBs make 
usage of any possible hardware off-loads or config customizations are 
CPU affinity possibility made by Mikrotik themselves in their original 
RouterOS ?


Does this help to answer your question?
http://www.mikrotik.com/download/share/gpl_source.zip 
<http://www.mikrotik.com/download/share/gpl_source.zip>


-George


> Thanks
> Fernando
>
>
> On 15/10/2015 14:48, George Chriss wrote:
>
>
> On Thu, April 23, 2015 06:16:08 CEST, Toerless Eckert wrote:
> > This mail thread seem to have gone dark since december with seemingly
> > no conclusion.
> >
> > I have tried to collect the experiences reported on the wiki page:
> >
> > wiki.openwrt.org/toh/mikrotik/rb2011uias 
<http://wiki.openwrt.org/toh/mikrotik/rb2011uias>

> >
> > As you can see from the table, for me it only works with 0x6f.
> > Chris, for whom both 0x3e and 0x6f work has a rev 2 AR9344. I have
> > a rev 3. AR8327 is rev. 4 on both our routerboards. No info what 
rev Matt

> > has, he is the other one reporting that only 0x6f works.
> >
> > I am also observing some amount of increases in switch 0 port 0
> > RxBadByte (aka: from CPU to AR8327). It seems to happen for
> > all type of traffic sent from CPU to switch, eg: whether i inject 
it from

> > WiFi or from a 100 Mbps port, and whether i send it out
> > on an untagged port (lan) or tagged one (from CPU, Wan).
>
> I'm under the impression that some of the "OK/Not OK" reports are 
based on ping packet loss which provides limited insight into actual 
throughput.  My results with a RB2011UiAS-IN (no WiFi, empty SFP cage, 
AR9344 Rev. 2, CPU @ 600MHz powered from the DC-in jack) on patched 15.05:

>
> 0x0600 (Unpatched)
> No TCP/IP 2-way connection [Not OK]
>
> ==
>
> 0x3e00
> (MikroTik Eth1 -> laptop, crossover cable)
> /bin/bash -c "dd if=/dev/zero bs=1M count=1000 | netcat 
192.168.1.101 "

> 1000+0 records in
> 1000+0 records out
> 1048576000 bytes (1.0 GB) copied, 1589.44 s, 660 kB/s  [Not OK]
>
> (laptop -> MikroTik Eth1, crossover cable)
> dd if=/dev/zero bs=1M count=1000 | nc 192.168.1.121 
> 1000+0 records in
> 1000+0 records out
> 1048576000 bytes (1.0 GB) copied, 49.6707 s, 21.1 MB/s  [OK]
>
> ==
>
> 0x6f00
> (MikroTik Eth1 -> laptop, crossover cable)
> /bin/bash -c "dd if=/dev/zero bs=1M count=1000 | netcat 192.168.
> 1.101 "
> 1000+0 records in
> 1000+0 records out
> 1048576000 bytes (1.0 GB) copied, 176.224 s, 6.0 MB/s  [OK?]
>
> (laptop -> MikroTik Eth1, crossover cable)
> dd if=/dev/zero bs=1M count=1000 | nc 192.168.1.121 
> 1000+0 records in
> 1000+0 records out
> 1048576000 bytes (1.0 GB) copied, 50.7454 s, 20.7 MB/s  [OK]
>
>
> Any word on the bootloader patch?  Happy to test more values as needed.
>
> Sincerely,
> George
>
>
> > I have not really identified any noticeable performance impact from
> > this effect through.
> >
> > Would be nice to hear some logic why 0x6f is the right value.
> >
> >> From the discussion it looks a bit like trial and error.
> >>
> >
> > Cheers
> > Toerless
> >
> >
>
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org <mailto:openwrt-devel@lists.openwrt.org>
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org <mailto: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 "fastpath" - Kernel module for speeding up IP forwarding

[Fernando Frediani]

That would be a really intresting and important feature for many hardware.

Fernando

On 26/09/2015 23:57, Weedy wrote:


Did this die?

On 22 Dec 2014 9:06 am, "Tomer Eliyahu" > wrote:


Hi,

We are software developers, part of Marvell's cellular platform
infrastructure team.

Our team has been working on a project named "fastpath" for speeding
up IP forwarding in embedded systems.
The initial version (fastpath v1) has already been successfully
deployed in our latest pxa1801 (cellular modem) based products.

We are in the final stages of fastpath v2 development, which is
completely hardware independent and requires minimal changes in the
generic networking code (the project consists of a kernel module and a
single kernel patch); despite being hardware independent, fastpath v2
already achieved the same level of performance (as fastpath v1) and
even increased stability.

Our development platform is running openwrt Barrier Breaker (r43694),
so naturally we chose to suggest this to the openwrt development
community first.

You can find a brief description of our fastpath solution below.

We are anxious to hear your thoughts/comments and will gladly
share the code.

Best Regards,

Ram Marzin r...@marvell.com 
Tomer Eliyahu tom...@marvell.com 


Fastpath in a nutshell
--

The basic concept of fastpath is to optimize the data-plane while
keeping the control-plane in the generic networking stack.
This is a known concept in the industry which is commonly used in
embedded systems [1], but so far we couldn't find any open source
implementation for it.

Fast path implements an optimized data-plane, which replaces the
generic data-plane forwarding code for selected connections. The
data-plane implementation includes a straight forward optimized packet
processing engine which handles all the required packet manipulation
for IP forwarding, such as decrement ttl/hop count, checksum
adjustment, MAC header encapsulation and "dummy NAT" (TCP/UDP traffic
which does not carry any L3/L4 information in the packet payload).

As noted above, the control-plane is handled by the generic networking
stack, with the only exception of learning new connections and marking
the valid ones as fastpath - some connections can't participate in
fastpath, such as any "non-dummy NAT" connections (e.g. FTP control
port), local traffic, and any protocol which is not supported (e.g.
IPv6 extensions, IPSec, IPv4 fragmanted packets, etc.).
Needless to say that ALL non-fastpath connections / protocols will
work as is, i.e. they simply won't go through fastpath.

As a rule of thumb, it is safe to assume that in most of the cases,
90% of the data will go through fastpath. In our experiments on
pxa1801, fastpath alone *almost doubled* the performance (both
Throughput and MIPS consumption) for TCP/UDP IPv4/IPv6 forwarding.

References
[1]

http://www.embedded.com/design/operating-systems/4403058/Accelerating-network-packet-processing-in-Linux
___
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] European Commission secretly passes same measure as FCC OpenWRT ban ?

[Fernando Frediani]

I have the impression that this type of fight is the same of in the 
early days of MP3 Audio/Vídeo industry fighting against it. And now Taxi 
companies fighting against Uber. It´s a fight, that even coming from 
government, will never be won.


Fernando

On 03/09/2015 21:07, demos wrote:

i think that is very similar to the FCC thing.
Some ideas how to deal with that may also be there:
https://libreplanet.org/wiki/Save_WiFi

German forum about that: https://forum.freifunk.net/t/6732/19
how these issues touch german legislation:
https://fragdenstaat.de/anfrage/stand-der-umsetzung-der-richtlinie-2014-53-eu/

Cheers
Demos

Caleb James DeLisle:

Seems to be one German newspaper reporting that Directive 2014/53/EU
places an EU ban on flashing devices.

http://www.heise.de/netze/meldung/Funkregulierung-Angriff-auf-alternative-Software-2803189.html

https://translate.google.com/translate?hl=en=auto=en=http%3A%2F%2Fwww.heise.de%2Fnetze%2Fmeldung%2FFunkregulierung-Angriff-auf-alternative-Software-2803189.html


Could not find any other articles about this.
___
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] Change realtime graphs interval

[Fernando Frediani]

Guys,

Have been searching and couldn´t find anything in the configuration.

How can I change the Realtime Graphs update time from 3 seconds to 1 
second ? Do I need to recompile or is it something changeable in the 
configuration ?


Thanks
Fernando
___
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

[Fernando Frediani]

Cool.

Does this Fixed broken IPv6 downstream DHCPv6-PD and onlink-route 
handling fix the issue with loosing the default gateway for IPv6 and 
only fixing when you reboot the router ?


Fernando

On 16/07/2015 11:39, Steven Barth wrote:

The OpenWrt developers are proud to announce the third release candidate of 
OpenWrt Chaos Calmer.

___ __
  |   |.-.-.-.|  |  |  |..|  |_
  |   -   ||  _  |  -__| ||  |  |  ||   _||   _|
  |___||   __|_|__|__||||__|  ||
   |__| W I R E L E S S   F R E E D O M
  -
  CHAOS CALMER (15.05 RC3)
  -
   * 1 1/2 oz GinShake with a glassful
   * 1/4 oz Triple Sec   of broken ice and pour
   * 3/4 oz Lime Juice   unstrained into a goblet.
   * 1 1/2 oz Orange Juice
   * 1 tsp. Grenadine Syrup
  -

  -
http://downloads.openwrt.org/chaos_calmer/15.05-rc3/

** Improvements since RC 2 **
* brcmfmac: support for BCM43602
* mt76: updated version with new firmware support, TX  DMA fixes
* Updated 3.18 to 3.18.18
* Fixed image builder generation
* Various security updates (e.g. openssl, curl)
* Minor fixes

** Improvements since RC 1 **
* Fixed broken ImageBuilders for most targets
* Updated 3.18 to 3.18.14
* Fixed broken IPv6 downstream DHCPv6-PD and onlink-route handling
* Images (special format) for Asus brcm47xx and bcm53xx devices
* Improved stability of sysupgrade on brcm47xx and bcm53xx
* Added HTTPS enforcement option to uhttpd
* Fixed umask issue
* Added support for a few new boards


** Highlights since Barrier Breaker **

* Linux kernel updated to version 3.18
* Improved Security Features
 - Rewritten package signing architecture based on ed25519
 - Added support for jails
 - Added support for hardened builds
* Improved Networking Support
 - Added or improved support for lots of 3G/4G modems (MBIM, QMI, NCM, ...)
 - Added support for 464XLAT (CLAT) [RFC 6877 + RFC 7050]
 - Netfilter performance enhancements (conntrack route cache)
 - Improved support for self-managing networks [draft-ietf-homenet-hncp]
 - Better multi-core support for the network stack
 - Improved support for MAP-E, MAP-T and LW4over6 IPv4 transitioning 
technologies
 [draft-ietf-softwire-map, -map-t, -map-dhcp, -lw4over6]
 - Improved network auto-setup capable of detecting and bootstrapping 
IPv4-only,
   6rd, Dual-Stack, IPv6-only, DS-Lite, LW4over6, MAP-E, MAP-T, 464XLAT
   and combinations without explicit configuration [based on RFC 7084]
 - Added support for Smart Queue Management (SQM) QoS, AQM and Traffic 
Shaping
 - Improved support for DNSSEC
* Platform and Driver Support
 - Added support for feeds of externally maintained targets
 - New mt7621 subtarget for Mediatek 11ac SoC
 - New mt76 mac80211 based wifi driver for MTK 11ac cores.
 - New mwlwifi mac80211 based wifi driver for the Marvell 88W8864
 - New bcm53xx target for Broadcom ARM BCM47xx/53xx devices
 - New mxs target for Freescale i.MX23/28 family and various boards
 - New sunxi target for AllWinner A10/A13/A20 family and various boards
 - brcm2708: support for Raspberry Pi 2
 - brcm63xx: support for BCM6318 and BCM63268 family
 - brcm63xx: improved fallback sprom support with bcma support
 - New ipq806x target for QCA IPQ806x SoC family

* Known Issues
 - KALLSYMS is active causing some devices to fail

And lots and lots of other advancements...
As always a big thank you goes to all our active package maintainers, testers, 
supporters and documenters.


Have fun!
 The OpenWrt developer 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

Re: [OpenWrt-Devel] alternatives to TDMA

[Fernando Frediani]

Hi Bill,

I´m not sure about this. Do you have the source to confirm this ?

Fernando

On 14/07/2015 12:50, Bill Moffitt wrote:
My understanding is that UBNT has an ASIC in their devices to help 
with the timing of the TDMA mode. My suspicion is that, without that 
ASIC, software only TDMA would probably not be precise enough to 
bring benefit.


Does anyone have a better understanding of this?

-Bill
___
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-rc2

[Fernando Frediani]

Anyone ? I am still investigating this issue and trying to figure out if 
it's a Openwrt or ISP problem.


Would that changelog have anything to do with this ?

Fernando

On 13/06/2015 12:43, Fernando Frediani wrote:

Hi folks,

I'm seeing an issue on my Barrier Breaker running on a TP-Link WR842ND 
where it gets an IPv6 /128 to the WAN interface + /64 on the LAN 
interface via DHCPv6 + PD, however it does NOT set the default gateway 
by default, so I have to discover it and set manually using the 
other-side link-local.
Even though eventually while running and after a few Save  Apply it 
mysteriously looses the same default gateway I have set manually 
(I'm guessing due DHCPv6 changing it every in a while to the original 
when it booted - none). And it can't ping it anymore (the other-side 
link local address). By the way, it's a cable connection.


For comparison I have another router running DD-WRT from 22/Nov/2014 
connected to the same ISP in another point of the city and it works 
fine DHCPv6, sets the default gateway by default and never looses it.


By any chance this changelog /Fixed broken IPv6 downstream DHCPv6-PD 
and onlink-route handling/ would perhaps have anything to do with 
that problem observed ?


Thanks
Fernando


On 13/06/2015 11:21, Steven Barth wrote:

The OpenWrt developers are proud to announce the first release candidate
of OpenWrt Chaos Calmer.

___ __
  |   |.-.-.-.|  |  |  |..|  |_
  |   -   ||  _  |  -__| ||  |  |  ||   _||   _|
  |___||   __|_|__|__||||__|  ||
   |__| W I R E L E S S   F R E E D O M
  -
  CHAOS CALMER (15.05 RC2)
  -
   * 1 1/2 oz GinShake with a glassful
   * 1/4 oz Triple Sec   of broken ice and pour
   * 3/4 oz Lime Juice   unstrained into a goblet.
   * 1 1/2 oz Orange Juice
   * 1 tsp. Grenadine Syrup
  -

  -
http://downloads.openwrt.org/chaos_calmer/15.05-rc2/

** Improvements since RC 1 **
* Fixed broken ImageBuilders for most targets
* Updated 3.18 to 3.18.14
* Fixed broken IPv6 downstream DHCPv6-PD and onlink-route handling
* Images (special format) for Asus brcm47xx and bcm53xx devices
* Improved stability of sysupgrade on brcm47xx and bcm53xx
* Added HTTPS enforcement option to uhttpd
* Fixed umask issue
* Added support for a few new boards


** Highlights since Barrier Breaker **

* Linux kernel updated to version 3.18
* Improved Security Features
 - Rewritten package signing architecture based on ed25519
 - Added support for jails
 - Added support for hardened builds
* Improved Networking Support
 - Added or improved support for lots of 3G/4G modems (MBIM, QMI,
NCM, ...)
 - Added support for 464XLAT (CLAT) [RFC 6877 + RFC 7050]
 - Netfilter performance enhancements (conntrack route cache)
 - Improved support for self-managing networks [draft-ietf-homenet-hncp]
 - Better multi-core support for the network stack
 - Improved support for MAP-E, MAP-T and LW4over6 IPv4 transitioning
technologies
 [draft-ietf-softwire-map, -map-t, -map-dhcp, -lw4over6]
 - Improved network auto-setup capable of detecting and bootstrapping
IPv4-only,
   6rd, Dual-Stack, IPv6-only, DS-Lite, LW4over6, MAP-E, MAP-T, 464XLAT
   and combinations without explicit configuration [based on RFC 7084]
 - Added support for Smart Queue Management (SQM) QoS, AQM and
Traffic Shaping
 - Improved support for DNSSEC
* Platform and Driver Support
 - Added support for feeds of externally maintained targets
 - New mt7621 subtarget for Mediatek 11ac SoC
 - New mt76 mac80211 based wifi driver for MTK 11ac cores.
 - New mwlwifi mac80211 based wifi driver for the Marvell 88W8864
 - New bcm53xx target for Broadcom ARM BCM47xx/53xx devices
 - New mxs target for Freescale i.MX23/28 family and various boards
 - New sunxi target for AllWinner A10/A13/A20 family and various boards
 - brcm2708: support for Raspberry Pi 2
 - brcm63xx: support for BCM6318 and BCM63268 family
 - brcm63xx: improved fallback sprom support with bcma support

* Known Issues
 - Sysupgrade on brcm47xx may fail by running out of memory when
using .bin or .chk files. Please use .trx when using rc1 (it was fixed
in rc2).
  - openssl and strongswan are outdated. If you intend to use either
of them please update the packages using the snapshots repository:
https://downloads.openwrt.org/snapshots/trunk/


And lots and lots of other advancements...
As always a big thank you goes to all our active package maintainers,
testers, supporters and documenters.


Have fun!
 The OpenWrt developer team
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org

Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc2

[Fernando Frediani]

Hi folks,

I'm seeing an issue on my Barrier Breaker running on a TP-Link WR842ND 
where it gets an IPv6 /128 to the WAN interface + /64 on the LAN 
interface via DHCPv6 + PD, however it does NOT set the default gateway 
by default, so I have to discover it and set manually using the 
other-side link-local.
Even though eventually while running and after a few Save  Apply it 
mysteriously looses the same default gateway I have set manually (I'm 
guessing due DHCPv6 changing it every in a while to the original when it 
booted - none). And it can't ping it anymore (the other-side link local 
address). By the way, it's a cable connection.


For comparison I have another router running DD-WRT from 22/Nov/2014 
connected to the same ISP in another point of the city and it works fine 
DHCPv6, sets the default gateway by default and never looses it.


By any chance this changelog /Fixed broken IPv6 downstream DHCPv6-PD 
and onlink-route handling/ would perhaps have anything to do with that 
problem observed ?


Thanks
Fernando


On 13/06/2015 11:21, Steven Barth wrote:

The OpenWrt developers are proud to announce the first release candidate
of OpenWrt Chaos Calmer.

___ __
  |   |.-.-.-.|  |  |  |..|  |_
  |   -   ||  _  |  -__| ||  |  |  ||   _||   _|
  |___||   __|_|__|__||||__|  ||
   |__| W I R E L E S S   F R E E D O M
  -
  CHAOS CALMER (15.05 RC2)
  -
   * 1 1/2 oz GinShake with a glassful
   * 1/4 oz Triple Sec   of broken ice and pour
   * 3/4 oz Lime Juice   unstrained into a goblet.
   * 1 1/2 oz Orange Juice
   * 1 tsp. Grenadine Syrup
  -

  -
http://downloads.openwrt.org/chaos_calmer/15.05-rc2/

** Improvements since RC 1 **
* Fixed broken ImageBuilders for most targets
* Updated 3.18 to 3.18.14
* Fixed broken IPv6 downstream DHCPv6-PD and onlink-route handling
* Images (special format) for Asus brcm47xx and bcm53xx devices
* Improved stability of sysupgrade on brcm47xx and bcm53xx
* Added HTTPS enforcement option to uhttpd
* Fixed umask issue
* Added support for a few new boards


** Highlights since Barrier Breaker **

* Linux kernel updated to version 3.18
* Improved Security Features
 - Rewritten package signing architecture based on ed25519
 - Added support for jails
 - Added support for hardened builds
* Improved Networking Support
 - Added or improved support for lots of 3G/4G modems (MBIM, QMI,
NCM, ...)
 - Added support for 464XLAT (CLAT) [RFC 6877 + RFC 7050]
 - Netfilter performance enhancements (conntrack route cache)
 - Improved support for self-managing networks [draft-ietf-homenet-hncp]
 - Better multi-core support for the network stack
 - Improved support for MAP-E, MAP-T and LW4over6 IPv4 transitioning
technologies
 [draft-ietf-softwire-map, -map-t, -map-dhcp, -lw4over6]
 - Improved network auto-setup capable of detecting and bootstrapping
IPv4-only,
   6rd, Dual-Stack, IPv6-only, DS-Lite, LW4over6, MAP-E, MAP-T, 464XLAT
   and combinations without explicit configuration [based on RFC 7084]
 - Added support for Smart Queue Management (SQM) QoS, AQM and
Traffic Shaping
 - Improved support for DNSSEC
* Platform and Driver Support
 - Added support for feeds of externally maintained targets
 - New mt7621 subtarget for Mediatek 11ac SoC
 - New mt76 mac80211 based wifi driver for MTK 11ac cores.
 - New mwlwifi mac80211 based wifi driver for the Marvell 88W8864
 - New bcm53xx target for Broadcom ARM BCM47xx/53xx devices
 - New mxs target for Freescale i.MX23/28 family and various boards
 - New sunxi target for AllWinner A10/A13/A20 family and various boards
 - brcm2708: support for Raspberry Pi 2
 - brcm63xx: support for BCM6318 and BCM63268 family
 - brcm63xx: improved fallback sprom support with bcma support

* Known Issues
 - Sysupgrade on brcm47xx may fail by running out of memory when
using .bin or .chk files. Please use .trx when using rc1 (it was fixed
in rc2).
  - openssl and strongswan are outdated. If you intend to use either
of them please update the packages using the snapshots repository:
https://downloads.openwrt.org/snapshots/trunk/


And lots and lots of other advancements...
As always a big thank you goes to all our active package maintainers,
testers, supporters and documenters.


Have fun!
 The OpenWrt developer 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

Re: [OpenWrt-Devel] Dirty Diamond

[Fernando Frediani]

+1

On 07/04/2015 16:47, Hartmut Knaack wrote:

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 Dirty Diamond.
___
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] Why OpenWrt sucks?

[Fernando Frediani]

Hi Gergely,

I'm just curious to know what makes you be pretty sure that many 
vendors will start doing this in the future and overcome the possible 
legal or political issues they may have to do that ? Marvel was one of 
the worst cases I've ever seen here and I have no much idea what made 
them to release it (a miracle maybe?). Unless you were referring to in 
the future as next century I don't see that happening that soon.


Other than that I fully agree OpenWrt is great, well developed and 
maintained.


Best,

On 10/03/2015 17:26, Gergely Kiss wrote:

Hi Valent,

first of all, I strongly disagree with people claiming that OpenWrt 
sucks because it doesn't. For me it rather looks like a 
well-maintained, rapidly improving project with a great number of 
actively supported hardware and quite a few people contributing to the 
project regularly. I can see dozens of patches published every day not 
only by the core devs but by many contributors which is a great thing 
and indicates that many people are trying to make OpenWrt *even *better.


I must mention you had a point that made me smile - it's about being a 
miracle that openwrt works as good as it does. This reminded me to the 
DNS system. As we all know, it was never developed with a concept of 
creating a complex network service to be used in a worldwide network 
but more like as a simple phonebook for companies, schools and other 
small, autonomous institutions to avoid the need to remember IP 
addresses. Now, DNS is used worldwide by thousands of entities and is 
probably one of the oldest protocols still actively used on the 
internet and it still works pretty good despite its age. Miracles do 
happen sometimes and that's what makes our lives brighter. :)


Anyway, as far as I can see, more and more manufacturers (including 
wireless chip vendors) realize the benefits of open source and release 
their driver codes to the open source community. I clearly remember 
seeing some driver sources posted on this list directly by Marvell and 
I'm pretty sure that many other vendors will start doing so in the 
future. I think the reason why most vendors still haven't published 
their drivers is more like legal issues rather than technical or 
political ones. They have to meet regulatory requirements and 
respect the copyright of other people's work. Even if they would feel 
inclined to release their driver, they can't do so because of 
licensing issues.


For people complaining about OpenWrt, I would simply tell them that 
first of all, it's provided for free for everyone in the world so stop 
complaining. Also, being an open source project, it's always open for 
contributions. Everyone has the possibility to share ideas or 
implement features making OpenWrt a more stable, more robust and more 
versatile piece of software.


My fifty cents was to create a port of Seafile for OpenWrt - I'm using 
it myself at home and I'm very happy to see it running on my router 
with a USB HDD attached rather than running an additional home server 
24/7 consuming more power and taking up more room in my flat. At the 
same time, I'm happy to provide the same ability to other people 
because that's how it's meant to be.


Do you think OpenWrt sucks? Then stop complaining and do something to 
make it better. It's that simple.


Cheers,
Gergely

On 9 March 2015 at 21:02, valent.turko...@gmail.com 
mailto:valent.turko...@gmail.com valent.turko...@gmail.com 
mailto:valent.turko...@gmail.com wrote:


Hi all,
I see this or similar question of forums all the time and I have
answered it few times. I suggest we open a wiki page and contribute an
answer.

Here is how I usually reply to similar questions, please give your
comments in your replies:


Why it OpenWrt slower than stock firmware? I can help by shining a bit
of light onto this subject. I'm developing custom firwmares based on
OpenWrt but I'm not OpenWrt developer, still as I have few years of
experience with OpenWrt I can explain why sometimes performance sucks
or there are some issues and bugs.

OpenWrt has three main parts; linux kernel, software packages and
wireless drivers. OpenWrt developers work on all of them. Consider the
amount of code this is, and consider that all work is done by a
handful of OpenWrt developers. If you work in software industry you
know many people big companies hire to work on much smaller projects.
So be thankful it works as good as it does, it is actually a miracle
that it works as good as it does

Main issue is that wifi chip manufacturers don't offer open source
wifi drivers. If Atheros and Broadcom understood Open source as Intel
does then you would get absolutely top speed and reliability from
OpenWrt wifi drivers. You don't get top notch performance with OpenWrt
because Atheros and Broadcom are choosing not release quality open
source drivers.

Linux, BSDx and OpenWrt developers can only 

Re: [OpenWrt-Devel] Why OpenWrt sucks?

[Fernando Frediani]

Hello Valent,

I think, despite that fact you will get some opposition about some 
points you mentioned here, your email was a good email in my point of view.


First the the most controversial point about how much Atheros contribute 
to the open-source world and to Linux is seems to be that they do a much 
better job than many other vendors. They are probably far ahead than 
many of the known vendors.
However I wanted to leave a question about the performance which in some 
equipment with Atheros chips is in fact slower than with OEM firmware.
Take as example Ubiquiti. They are greatly engineered and as far as I 
know kind of base their firmware AirOS in OpenWRT, but I hear (I said 
heard) that their Atheroes drivers are not the same ones used by 
open-source community (so they have something else from Atheros) and 
they end up getting better speed.


The other points I wanted to mention is about the wiki. That is indeed a 
really good one you raised which could be better updated with more 
information in a more organized way.
In the forums there is plenty of rich information sometimes from the 
main people that is developing that specific architecture, but in many 
cases the same information, findings, issues, etc, take too long (when 
it does) to get to the wiki of that specific board.


I don't think OpenWrt sucks, and quite like it, but I do think it can 
get a lot better if people are engaged in more different and nice ways 
to contribute.


Fernando

On 09/03/2015 17:02, valent.turko...@gmail.com wrote:

Hi all,
I see this or similar question of forums all the time and I have
answered it few times. I suggest we open a wiki page and contribute an
answer.

Here is how I usually reply to similar questions, please give your
comments in your replies:


Why it OpenWrt slower than stock firmware? I can help by shining a bit
of light onto this subject. I'm developing custom firwmares based on
OpenWrt but I'm not OpenWrt developer, still as I have few years of
experience with OpenWrt I can explain why sometimes performance sucks
or there are some issues and bugs.

OpenWrt has three main parts; linux kernel, software packages and
wireless drivers. OpenWrt developers work on all of them. Consider the
amount of code this is, and consider that all work is done by a
handful of OpenWrt developers. If you work in software industry you
know many people big companies hire to work on much smaller projects.
So be thankful it works as good as it does, it is actually a miracle
that it works as good as it does

Main issue is that wifi chip manufacturers don't offer open source
wifi drivers. If Atheros and Broadcom understood Open source as Intel
does then you would get absolutely top speed and reliability from
OpenWrt wifi drivers. You don't get top notch performance with OpenWrt
because Atheros and Broadcom are choosing not release quality open
source drivers.

Linux, BSDx and OpenWrt developers can only use other means to get
wifi devices to work, usually reverse engineering, and without support
from wifi chip companies it is not easy to support all features, get
awesome performance and stability.

This is a long way of saying, that if performance sucks on OpenWrt you
should blame Atheros and Broadcom for not giving you (OpenWrt
community) high quality open source drivers!
___
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] Alternatives do TDMA

[Fernando Frediani]

Hello bkil,

Many thanks for your detailed response.
I would gladly post it to openwrt-users if that worked, which doesn't 
seem to be the case as far as I know.


But also taking the opportunity in this devel list to ask if anyone 
worked of ever saw any work to develop a open TDMA implementation that 
could be merged to OpenWRT. I personally have read a while ago about 
some material that was developed for FreeBSD, but there wasn't much 
information really and no much other than that I could find unfortunately.


Regarding your response I was particularly interested in the RTS/CTS 
configuration and hear about optimal RTS Threshold values.
Also does that AP and Clients have to have exactly same RTS/CTS 
configuration and RTS Threshold values or only the AP is enough ?
This is more common in WISP providers, but would that be also for 
example in internal areas with many clients (e.g: a conference) where 
the clients aren't aware about having to enable the RTS/CTS protection 
and eventually the threshold ?


Regards,
Fernando

On 16/02/2015 19:24, bkil wrote:

Dear Fernando,

You should have posted this question to OpenWrt-User, but I will answer it here.

I haven't personally deployed such a configuration, yet. I don't think
you can do much besides enabling RTS/CTS at every CPE (client). Much
fewer connected clients will be supported compared to a TDMA system.

However, here are some other non-default settings you could test:
* coverage class/distance optimization
* try narrow 5-10MHz channels in case of a crowded neighborhood -
sometimes less is more
* if link speed is already maxed out for the closest nodes, you may
try to reduce their tx power while maintaining the link speed and
error rate, though I wouldn't expect much effect
* after you've measured the link margin and its fading characteristic
at each of your clients, you could consider increasing the mandatory
basic_rate and mcast_rate to reduce airtime a bit more
* you could experiment with increasing the beacon interval, though
each station should already sync and avoid interference with those,
and this could reduce stability
* you may increase dtim_period a bit - again not much effect
* consider blocking most kinds of broadcast/multicast packets if your
network doesn't need it
* compared to AP mode, 802.11s mesh mode has various promising
techniques for precise node coordination and time slot reservation in
the standard which may or may not have been implemented, so you should
have a look
* RTS/CTS should be enough, but another option would be to reduce max
packet size (fragmentation threshold), which will also gravely reduce
your throughput
* you may reduce the number of retries as a last resort and hope for
the upper layers to limit rate (black magic)
...

Hardware considerations:
* use good directional or sector antennas and/or shielding at the base
to reduce noise from the surrounding buildings
* 5GHz is less crowded
* the best solution would be to insert a few intermediary nodes to
form a mesh instead of a star topology - unslotted and uncoordinated
medium access has its limits
* or at least offload the clients to multiple hotspots operated at the
same location, but using different frequencies or polarization

Note that not all options are displayed on Luci, but you could add
them to /etc/config/wireless manually (some could require capability
overrides):
http://wiki.openwrt.org/doc/uci/wireless

An interesting hack come to mind. What if we turned the situation
around? You could operate each CPE in AP mode with a very long beacon
interval. The portal (gateway) itself would operate in multi-STA.
After some u-APSD/PS-POLL tweaking, you could power save on all but
one AP similar to how it's done by default on multi-frequency
multi-STA. The portal would essentially unmute a single CPE at a time
in a round-robin fashion. It sounds a bit quirky and it would surprise
me if the solution scaled beyond a few dozen CPEs, but it would
enforce a kind of TDMA and it might theoretically eliminate collisions
without RTS/CTS if that is your thing. Bandwidth utilization and
latency would leave much to be desired, however.

I'm all into radio propagation, so please do share your views and
findings about this question.

Regards


Hi guys,

What is the best alternative to TDMA when using OpenWRT and Outdoor /
PtMP access ? Any specific configuration to be done in OpenWRT in order
to deal with multiple clients in different ranges ?

Thanks
Fernando

___
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] Alternatives do TDMA

[Fernando Frediani]

Hi guys,

What is the best alternative to TDMA when using OpenWRT and Outdoor / 
PtMP access ? Any specific configuration to be done in OpenWRT in order 
to deal with multiple clients in different ranges ?


Thanks
Fernando
___
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) ?

[Fernando Frediani]

Hi,

Great email Valent, and I fully agree with your comments.
We have had this discussion here in the past and nothing much changed 
from Belkin side (actually it got worse as they disappeared apparently) 
showing a total failure on product release.


I'm not entirely sure of the status of WRT1200AC, but if there is 
nothing here in OpenWRT and nothing else much can be found on the web 
they are once again lying. They are publishing intentions as if it was 
something that was already done and consolidated, ready for any buyer to 
enjoy. If there is something going on between them and OpenWRT we are 
not aware, at least not via this list.


I personally consider a big slap in the face of consumers Marketing 
doing what they do in Belkin, like if they didn't care at all. This is 
not simply 'a mistake' or 'a misunderstanding' , it's complete 
dishonesty and they are probably fully aware of this but simply don't 
care at all cause they just want to reach their marketing target. 
Probably people there might not even have a basic idea about what is 
open-source.


As mentioned Marvel is doing some progress with the Wifi driver, which 
is great for WRT1900AC owners, but that's Marvel only. What has Belkin 
done about their share of the work BEFORE they release this new product 
? I not sure if much or any.

I hope they are able to show me I am wrong on my comments.

Regards,
Fernando

On 14/01/2015 13:05, valent.turko...@gmail.com wrote:

Linksys/Belking marketing is again doing one thing and saying another?

This time they say that WRT1200AC router is open source:
http://www.zdnet.com/article/ces-2015-linksys-1200ac-an-inexpensive-open-source-802-11ac-wi-fi-router/

I have tracked progress with WRT1900AC and saw how they failed to give 
us open source driver, so I hope that this time they will actually 
keep their (marketing) promise.


I really, really, really hope that this time they have reached out and 
contacted any of you OpenWrt developers and that we will get truly 
open source driver from them.


So please let us know if any of you have heard anything regarding 
WRT1200AC router and it's drivers.


Cheers,
Valent.


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


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

[OpenWrt-Devel] WRT1900AC - Available firmwares ?

[Fernando Frediani]

Hi all,

Does anyone here have a Linksys WRT1900AC (that fiasco that suppose to 
be the new generation of WRT54G) ?


I got one a while ago and have been following the firmware development 
for it directly with Belkin people and on the URL - 
https://github.com/wrt1900ac/opensource/tree/master/Barrier-Breaker but 
that showed to be a total failure as they completely abandoned the 
project (GitHub latest update is 6 months old and they don' reply to 
emails anymore).


Many here might have seen all discussions around the subject during the 
initial phase of development especially regarding the open-source 
firmware of their wireless driver, which so far (as far as I know) 
is/was still a binary.


I have been however looking into the OpenWRT Snapshot and can see the 
mvebu folder with similar files than Linksys GitHub - 
http://downloads.openwrt.org/snapshots/trunk/mvebu/
Plus with the information on the wiki - 
http://wiki.openwrt.org/toh/linksys/wrt1900ac that the wireless driver 
has been finally released and the issue 'seems' to be resolved I guess.


Can anyone confirm this one downloaded from OpenWRT works for WRT1900AC 
compared to any of the 3 mentioned on the wiki ?


Thanks
Regards,

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

[OpenWrt-Devel] Kernel 3.15 - zRAM LZ4 Compression

[Fernando Frediani]

Perhaps someone have seen this from 3.15 notes that it now supports LZ4 for
zRAM Compression which increases the performance even more.

Is anyone extensively using it on their BB or CC builds and beleives this
would be significantlly benefitial or not that much ?

A note from the Kernel release:



1.7. zram: LZ4 compression support, improved performance

Zram is a memory compression mechanism added in Linux 3.14 that is used in
Android, Cyanogenmod, Chrome OS, Lubuntu and other projects. In this
release zram brings support for the LZ4 compression algorithm, which is
better than the current available LZO in some cases.

This release also adds performance improvements to concurrent compression
of multiple compression streams, and the ability to switch the compression
algorithm in /sys/block/zram0/comp_algorithm



Best regards,

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

Re: [OpenWrt-Devel] Linksys WRT54G / 16mb / wifi / lowmem / concurrency

[Fernando Frediani]

Hi Bastian,
These are very good news. Well done.

So, should I assume that this result is already using zram ?

Regards,
Fernando

On 17/12/2014 06:41, Bastian Bittorf wrote:

I did some experiments to get our good old Linksys WRT54G
running with recent trunk r43602 / kernel 3.14.26. We are only
using it in adhoc-mode (with olsrd) and it is working OK.

But there is still an issue, but i think it has to do with the
design of the bootup-process:

if wifi is enabled, the box has a lot of (see below [1])

# irq/4-b43: page allocation failure: order:3, mode:0x204020

during bootup and is laggy / unresponsive.
if wifi is disabled and we do after bootup a

uci set wireless.radio0.disabled=0; wifi

there are no problems and even 4000 kb free ram.
I havent opened a ticket on bugtracker, because it
is no bug 8-)

question: will procd fire init-scripts in parallel?
question: hotplug-events are queued and run one after another, right?

bye, bastian.

[1]
[   39.07] irq/4-b43: page allocation failure: order:3, mode:0x204020
[   39.07] CPU: 0 PID: 769 Comm: irq/4-b43 Not tainted 3.14.26 #1
[   39.07] Stack : 0006      
80377432 0036
[   39.07]  80676390  802be7e4 80304dc7 0301 80366080 
80676390 
[   39.07]    802feb2c 8025a53c  801b7f6c 
0006 ff80
[   39.07]  802c1850 80ca9aa4     
 
[   39.07]        
 
[   39.07]  ...
[   39.07] Call Trace:
[   39.07] [801f504c] show_stack+0x48/0x70
[   39.07] [8026b394] warn_alloc_failed+0xf0/0x114
[   39.07] [800259cc] __alloc_pages_nodemask+0x59c/0x708
[   39.07] [8009a564] cache_alloc_refill+0x308/0x614
[   39.07] [8015a22c] kmem_cache_alloc+0x88/0xf4
[   39.07] [806c751c] minstrel_remove_sta_debugfs+0x634/0x1bd8 [mac80211]
[   39.07]
[   39.07] Mem-Info:
[   39.07] Normal per-cpu:
[   39.07] CPU0: hi:0, btch:   1 usd:   0
[   39.07] active_anon:215 inactive_anon:2 isolated_anon:0
[   39.07]  active_file:543 inactive_file:484 isolated_file:3
[   39.07]  unevictable:0 dirty:0 writeback:0 unstable:0
[   39.07]  free:186 slab_reclaimable:233 slab_unreclaimable:840
[   39.07]  mapped:217 shmem:5 pagetables:29 bounce:0
[   39.07]  free_cma:0
[   39.07] Normal free:744kB min:448kB low:560kB high:672kB 
active_anon:860kB inactive_anon:8kB active_file:2172kB inactive_file:1936kB 
unevictable:0kB isolated(anon):0kB isolated(file):12kB
present:16384kB managed:12808kB mlocked:0k
B dirty:0kB writeback:0kB mapped:868kB shmem:20kB slab_reclaimable:932kB 
slab_unreclaimable:3360kB kernel_stack:224kB pagetables:116kB unstable:0kB 
bounce:0kB free_cma:0kB writeback_tmp:0kB
pages_scanned:5 all_unreclaimable? no
[   39.07] lowmem_reserve[]: 0 0
[   39.07] Normal: 52*4kB (UR) 27*8kB (UR) 18*16kB (UR) 1*32kB (R) 0*64kB 
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 744kB
[   39.07] 1034 total pagecache pages
[   39.07] 0 pages in swap cache
[   39.07] Swap cache stats: add 0, delete 0, find 0/0
[   39.07] Free swap  = 0kB
[   39.07] Total swap = 0kB
[   39.07] 4096 pages RAM
[   39.07] 0 pages HighMem/MovableOnly
[   39.07] 894 pages reserved
[   39.07] SLAB: Unable to allocate memory on node 0 (gfp=0x4020)
[   39.07]   cache: kmalloc-32768, object size: 32768, order: 3
[   39.07]   node 0: slabs: 9/9, objs: 9/9, free: 0
[   39.30] irq/4-b43: page allocation failure: order:3, mode:0x204020
[   39.30] CPU: 0 PID: 769 Comm: irq/4-b43 Not tainted 3.14.26 #1
[   39.30] Stack : 0006      
80377432 0036
[   39.30]  80676390  802be7e4 80304dc7 0301 80366080 
80676390 
[   39.30]    802feb2c 8025a53c  801b7f6c 
0006 00014600
[   39.30]  802c1850 80ca9aa4     
 
[   39.30]        
 
[   39.30]  ...
[   39.30] Call Trace:
[   39.30] [801f504c] show_stack+0x48/0x70
[   39.30] [8026b394] warn_alloc_failed+0xf0/0x114
[   39.30] [800259cc] __alloc_pages_nodemask+0x59c/0x708
[   39.30] [8009a564] cache_alloc_refill+0x308/0x614
[   39.30] [8015a22c] kmem_cache_alloc+0x88/0xf4
[   39.30] [806c751c] minstrel_remove_sta_debugfs+0x634/0x1bd8 [mac80211]
[   39.30]
[   39.30] Mem-Info:
[   39.30] Normal per-cpu:
[   39.30] CPU0: hi:0, btch:   1 usd:   0
[   39.30] active_anon:215 inactive_anon:2 isolated_anon:0
[   39.30]  active_file:543 inactive_file:484 isolated_file:3
[   39.30]  unevictable:0 dirty:0 writeback:0 unstable:0
[   39.30]  free:186 

Re: [OpenWrt-Devel] [PATCH] ZRAM: enhacements including /tmp on ZRAM for Barrier Breaker

[Fernando Frediani]

Hi all,

It would be great if someone could port ZRAM to AA so it can be used on 
16MB devices too.
Despite the kernel version doesn't have it, it had several ports that 
work on that version.


By the way. As BB has it natively (I suppose), has anyone used BB with 
ZRAM stably on 16MB devices (e.g: WRT54GL) ?


Thanks
Regards,
Fernando


On 02/12/2014 11:16, John Crispin wrote:

i just pushed a an alternate patch that fixes the problem. please test
it and let me know the results

John

On 22/10/2014 09:20, Tomasz Wasiak wrote:

Devices with less memory are still common so why limit ZRAM usage just to swap
when it could be very useful as for /tmp storage.

This patch changes 3 things:
  - sets default number of ZRAM devices to 2 (1st for /tmp, 2nd for swap)
  - adds ZRAM (default) support to procd's init (TMPFS is used when ZRAM is not
available
  - changes zram-swap so it will use /dev/zram1 for 1st CPU, /dev/zram2 for 2nd
and so on as /dev/zram0 is in use for /tmp.

Signed-off-by: Tomasz Wasiak tjwas...@gmail.com
---
  package/system/procd/patches/procd-support_for_tmp_on_zram.patch   |  
185 ++
  package/system/zram-swap/files/zram.init   |  
 15
  target/linux/generic/patches-3.10/998_zram_make_2_devices_by_default.patch |  
 11
  3 files changed, 203 insertions(+), 8 deletions(-)

--- a/package/system/procd/patches/procd-support_for_tmo_on_zram.patch
+++ b/package/system/procd/patches/procd-support_for_tmp_on_zram.patch
@@ -0,0 +1,185 @@
+--- a/initd/early.c
 b/initd/early.c
+@@ -12,34 +12,130 @@
+  * GNU General Public License for more details.
+  */
+
+-#include sys/mount.h
+-#include sys/types.h
+-#include sys/stat.h
+-
+-#include stdio.h
++#include errno.h
+ #include fcntl.h
+-#include unistd.h
++#include stdio.h
+ #include stdlib.h
++#include string.h
++#include strings.h
++#include unistd.h
++#include sys/mount.h
++#include sys/stat.h
++#include sys/types.h
++#include sys/wait.h
+
+ #include ../log.h
+ #include init.h
+
++static long
++check_ramsize(void)
++{
++  FILE *fp;
++  char line[256];
++  char *key;
++  long val = 0;
++
++  fp = fopen(/proc/meminfo, r);
++  if(fp == NULL)
++  {
++  ERROR(Can't open /proc/meminfo: %s\n, strerror(errno));
++  return errno;
++  }
++
++  while(fgets(line, sizeof(line), fp))
++  {
++  key = strtok(line, :);
++  val = atol(strtok(NULL,  kB\n));
++
++  if (!key || !val)
++  continue;
++
++  if (!strcasecmp(key, MemTotal))
++  break;
++  }
++
++  fclose(fp);
++
++  return val;
++}
++
++static int
++mount_zram_on_tmp(void)
++{
++  FILE *fp;
++  long zramsize = (check_ramsize() / 2);
++  pid_t pid;
++
++  if(!zramsize)
++  {
++  ERROR(Can't read size of RAM. Assuming 16 MB.\n);
++  zramsize = 8192;
++  }
++
++  fp = fopen(/sys/block/zram0/disksize, r+);
++  if(fp == NULL)
++  {
++  ERROR(Can't open /sys/block/zram0/disksize: %s\n, 
strerror(errno));
++  return errno;
++  }
++
++  fprintf(fp, %ld, (zramsize * 1024));
++
++  fclose(fp);
++
++  pid = fork();
++
++  if (!pid)
++  {
++  char *mkfs[] = { /sbin/mke2fs, -b, 4096, -F, -L, TEMP, -m, 
0, /dev/zram0, NULL };
++  int fd = open(/dev/null, O_RDWR);
++
++  if (fd  -1) {
++  dup2(fd, STDIN_FILENO);
++  dup2(fd, STDOUT_FILENO);
++  dup2(fd, STDERR_FILENO);
++  if (fd  STDERR_FILENO)
++  close(fd);
++  }
++
++  execvp(mkfs[0], mkfs);
++  ERROR(Can't exec /sbin/mke2fs\n);
++  exit(-1);
++  }
++
++  if (pid = 0)
++  {
++  ERROR(Can't exec /sbin/mke2fs\n);
++  return -1;
++  } else {
++  waitpid(pid, NULL, 0);
++  }
++
++  if(mount(/dev/zram0, /tmp, ext2, MS_NOSUID | MS_NODEV | MS_NOATIME, 
check=none,errors=continue,noquota)  0)
++  {
++  ERROR(Can't mount /dev/zram0 on /tmp: %s\n, strerror(errno));
++  return errno;
++  }
++
++  LOG(Using up to %ld kB of RAM as ZRAM storage on /mnt\n, zramsize);
++  return 0;
++}
++
+ static void
+-early_mounts(void)
++mount_tmpfs_on_tmp(void)
+ {
+-  mount(proc, /proc, proc, MS_NOATIME, 0);
+-  mount(sysfs, /sys, sysfs, MS_NOATIME, 0);
++  char line[256];
++  long tmpfssize = (check_ramsize() / 2);
+
+-  mount(tmpfs, /tmp, tmpfs, MS_NOSUID | MS_NODEV | MS_NOATIME, 
NULL);
+-  mkdir(/tmp/run, 0777);
+-  mkdir(/tmp/lock, 0777);
+-  mkdir(/tmp/state, 0777);
+-  symlink(/tmp, /var);
++  if(!tmpfssize)
++  {
++  ERROR(Can't read size of RAM. Assuming 16 MB.\n);
++  tmpfssize = 8192;
++  }
+
+-   

Re: [OpenWrt-Devel] [PATCH] ZRAM: enhacements including /tmp on ZRAM for Barrier Breaker

[Fernando Frediani]

By the way. Has anyone compiled and used BB 14.07 for devices with 16MB 
of RAM that went unsupported with AA release because of lack of ZRAM ?


Fernando

On 22/10/2014 08:20, Tomasz Wasiak wrote:

Devices with less memory are still common so why limit ZRAM usage just to swap
when it could be very useful as for /tmp storage.

This patch changes 3 things:
  - sets default number of ZRAM devices to 2 (1st for /tmp, 2nd for swap)
  - adds ZRAM (default) support to procd's init (TMPFS is used when ZRAM is not
available
  - changes zram-swap so it will use /dev/zram1 for 1st CPU, /dev/zram2 for 2nd
and so on as /dev/zram0 is in use for /tmp.

Signed-off-by: Tomasz Wasiak tjwas...@gmail.com
---
  package/system/procd/patches/procd-support_for_tmp_on_zram.patch   |  
185 ++
  package/system/zram-swap/files/zram.init   |  
 15
  target/linux/generic/patches-3.10/998_zram_make_2_devices_by_default.patch |  
 11
  3 files changed, 203 insertions(+), 8 deletions(-)

--- a/package/system/procd/patches/procd-support_for_tmo_on_zram.patch
+++ b/package/system/procd/patches/procd-support_for_tmp_on_zram.patch
@@ -0,0 +1,185 @@
+--- a/initd/early.c
 b/initd/early.c
+@@ -12,34 +12,130 @@
+  * GNU General Public License for more details.
+  */
+
+-#include sys/mount.h
+-#include sys/types.h
+-#include sys/stat.h
+-
+-#include stdio.h
++#include errno.h
+ #include fcntl.h
+-#include unistd.h
++#include stdio.h
+ #include stdlib.h
++#include string.h
++#include strings.h
++#include unistd.h
++#include sys/mount.h
++#include sys/stat.h
++#include sys/types.h
++#include sys/wait.h
+
+ #include ../log.h
+ #include init.h
+
++static long
++check_ramsize(void)
++{
++  FILE *fp;
++  char line[256];
++  char *key;
++  long val = 0;
++
++  fp = fopen(/proc/meminfo, r);
++  if(fp == NULL)
++  {
++  ERROR(Can't open /proc/meminfo: %s\n, strerror(errno));
++  return errno;
++  }
++
++  while(fgets(line, sizeof(line), fp))
++  {
++  key = strtok(line, :);
++  val = atol(strtok(NULL,  kB\n));
++
++  if (!key || !val)
++  continue;
++
++  if (!strcasecmp(key, MemTotal))
++  break;
++  }
++
++  fclose(fp);
++
++  return val;
++}
++
++static int
++mount_zram_on_tmp(void)
++{
++  FILE *fp;
++  long zramsize = (check_ramsize() / 2);
++  pid_t pid;
++
++  if(!zramsize)
++  {
++  ERROR(Can't read size of RAM. Assuming 16 MB.\n);
++  zramsize = 8192;
++  }
++
++  fp = fopen(/sys/block/zram0/disksize, r+);
++  if(fp == NULL)
++  {
++  ERROR(Can't open /sys/block/zram0/disksize: %s\n, 
strerror(errno));
++  return errno;
++  }
++
++  fprintf(fp, %ld, (zramsize * 1024));
++
++  fclose(fp);
++
++  pid = fork();
++
++  if (!pid)
++  {
++  char *mkfs[] = { /sbin/mke2fs, -b, 4096, -F, -L, TEMP, -m, 
0, /dev/zram0, NULL };
++  int fd = open(/dev/null, O_RDWR);
++
++  if (fd  -1) {
++  dup2(fd, STDIN_FILENO);
++  dup2(fd, STDOUT_FILENO);
++  dup2(fd, STDERR_FILENO);
++  if (fd  STDERR_FILENO)
++  close(fd);
++  }
++
++  execvp(mkfs[0], mkfs);
++  ERROR(Can't exec /sbin/mke2fs\n);
++  exit(-1);
++  }
++
++  if (pid = 0)
++  {
++  ERROR(Can't exec /sbin/mke2fs\n);
++  return -1;
++  } else {
++  waitpid(pid, NULL, 0);
++  }
++
++  if(mount(/dev/zram0, /tmp, ext2, MS_NOSUID | MS_NODEV | MS_NOATIME, 
check=none,errors=continue,noquota)  0)
++  {
++  ERROR(Can't mount /dev/zram0 on /tmp: %s\n, strerror(errno));
++  return errno;
++  }
++
++  LOG(Using up to %ld kB of RAM as ZRAM storage on /mnt\n, zramsize);
++  return 0;
++}
++
+ static void
+-early_mounts(void)
++mount_tmpfs_on_tmp(void)
+ {
+-  mount(proc, /proc, proc, MS_NOATIME, 0);
+-  mount(sysfs, /sys, sysfs, MS_NOATIME, 0);
++  char line[256];
++  long tmpfssize = (check_ramsize() / 2);
+
+-  mount(tmpfs, /tmp, tmpfs, MS_NOSUID | MS_NODEV | MS_NOATIME, 
NULL);
+-  mkdir(/tmp/run, 0777);
+-  mkdir(/tmp/lock, 0777);
+-  mkdir(/tmp/state, 0777);
+-  symlink(/tmp, /var);
++  if(!tmpfssize)
++  {
++  ERROR(Can't read size of RAM. Assuming 16 MB.\n);
++  tmpfssize = 8192;
++  }
+
+-  mount(tmpfs, /dev, tmpfs, MS_NOATIME, mode=0755,size=512K);
+-  mkdir(/dev/shm, 0755);
+-  mkdir(/dev/pts, 0755);
+-  mount(devpts, /dev/pts, devpts, MS_NOATIME, mode=600);
++  snprintf(line, 256, size=%ldk, tmpfssize);
++  mount(tmpfs, /tmp, tmpfs, MS_NOSUID | MS_NODEV | MS_NOATIME, 
line);
++  LOG(Using up to %ld 

[OpenWrt-Devel] Linksys / Belkin - WRT1900AC

[Fernando Frediani]

Is anyone using/working on this router so far ? There has been a lot of 
discussion on the list in the past about it as the promised successor of 
famous WRT54G.


I got one of these a while ago and since them I have been in contact 
several times with some people Linksys/Belkin team who was responsible 
for the Product including an ex Product Director (and which apparently 
has left the company afterwards).


After much discussion in the OpenWRT-Devel list they have committed 
repair all the major mess they have done around the product release 
promising it would support OpenWRT but in fact it never did properly. 
Sometime later they have set this GitHub below where they have been 
doing some development and they also have done some contribution to 
OpenWRT code.

https://github.com/wrt1900ac/opensource/
https://github.com/jimmychungbelkin/Mamba

Their contributions were criticized by different people and they 
promised to fix it, along with opening the source of the wireless driver 
which at the moment is still a binary unfortunately.
Also there are fundamental issues with their version available at GitHub 
where both 2.4 and 5 Ghz frequencies disconnects under some significant 
traffic and information dos now show up correctly in the WebUI.


I have tried to contact them several times to ask about the status, as 
in the GitHub it shows the last update more than 3 months old. They have 
replied to some emails, saying every time someone else was working on 
the project, showing again a total mess to handle things. Ultimately 
they have been ignoring any emails and don't seem very concerned about 
the product itself.


Does anyone have the a different view of me or any have information I'm 
not aware about about the development of OpenWRT for this product ?


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

[OpenWrt-Devel] Set which antenna to be used

[Fernando Frediani]

Hi all,

I have just tested BB Final on a 1043ND-v1 to observe a possible issue 
I've seen a while ago.
This device has 3 antennae but I want to use only one port (a Sector 
antenna) so I set the following on my /etc/config/wireless which means 
only the first antenna port (4 = 100 in binary).


option rxantenna '0x4'
option txantenna '0x4'

However when doing a: iw phy phy0 info | grep -i ant
I get the following output:
Available Antennas: TX 0x7 RX 0x7
Configured Antennas: TX 0x7 RX 0x7

Would it be something to do with ath9k or anywhere else to look at?
Thanks
Regards,

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

Re: [OpenWrt-Devel] VXLAN support

[Fernando Frediani]

Hi,
This would be a really useful and nice feature to add. May be use for 
example for connecting an office to DC based infra-structure that makes 
use of VXLAN.
Open vSwitch (which runs on OpenWRT), as far as I know supports VXLAN 
but it doesn't seem to achieve very good performance on most OpenWRT 
devices.


Regards,
Fernando

On 31/08/2014 19:51, Jiri Pirko wrote:

Hi all.

I did not find any movement in support of VXLAN. Are there any plans to
support it? Or is anyone working on that?

I can try to add VXLAN support to netifd. Any comments, ideas, hints
appreciated.

Thanks.

Jiri
___
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] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment

[Fernando Frediani]

Well done guys. These type of findings that makes significant different 
on embedded systems.


Fernando

On 30/08/2014 20:33, Felix Fietkau wrote:

On 2014-08-30 21:27, Nikos Mavrogiannopoulos wrote:

On Sat, 2014-08-30 at 20:10 +0200, Felix Fietkau wrote:


This could be a problem caused by mips16. We use that in BB to create
smaller binaries. but Jonas saw a performance problem in some
applications, mostly stuff doing crypto (big integer calculations).
Can you try to build the BB toolchain without the mips16 feature in
target/linux/ar71xx/Makefile and try your application again.

There's no need to disable it for the target, since it can be disabled
for individual packages.

So should all packages that contain performance critical code have that
flag? 35% performance penalty is too high for such systems.

Some kinds of code may be more affected than others. For crypto code we
should definitely disable mips16, as it seems to be most affected.

- 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

[OpenWrt-Devel] zram in Barrier Breaker for 16MB devices

[Fernando Frediani]

Hi all,

With the release of Attitude Adjustment last year devices with 16MB of 
less went unsupported.
Now with the release of Barrier Breaker which has support to zram are 
there any plans to support them again ? Has anyone been using it with 
such devices without any issues ? Not sure if a BB build for them even 
with zram working would need any specific features removed to run smoothly ?


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

[OpenWrt-Devel] Antenna selection not working as expected

[Fernando Frediani]

Hello,

I have a TL-WR1043ND v1 running Barrier Breaker 14.07-rc2 and have a 
Sector Antenna connected to the first antenna port. On the other two I 
have removed the original Omni antennas.
In order to tell the router that I want to work only with the Sector 
antenna (first port) I have added the following option on 
/etc/config/wireless radio configuration

*option rxantenna '0x4'**
**option txantenna '0x4'*

Where 4 means 100 in binary which is equivalent to the first antenna On 
only.

However the router doesn't seem to obey it.
If I run:*
iw phy phy0 info | grep -i ant *
I get the following:
 Available Antennas: TX 0x7 RX 0x7
Configured Antennas: TX 0x7 RX 0x7
While I would expect to see the Configured Antennas with different values.

Does anyone have any idea if this is not working as expected or if it's 
something to do with the ath9k driver or if I can try a different 
driver, etc ?
Previously I was running the snapshot version before RC2 and getting the 
same result.

If anyone has any clue would be greatly appreciated.

Thanks
Best regards,

Fernando

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

Re: [OpenWrt-Devel] OpenWRT IPv6 firewall

[Fernando Frediani]

Hello guys,

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


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


What is making it more complicated than this ?

Regards,

Fernando

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

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

I expect that, over time, users will become accustomed to the
end-to-end nature of the v6 Internet and may demand that the firewall
be open by default, and I would certainly propose that we have a
simple checkbox in LUCI that allows the firewall to be changed from all
closed except explicitly open ports to all open in one action. At
some point we would probably change the default behavior from all
closed to all open.

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



However, for the moment, I would argue that the rightness of following
expected behavior is greater than the rightness of delivering the true
end-to-end nature of v6.

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

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

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

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

Cheers!
Ondr(ej Caletka



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


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

Re: [OpenWrt-Devel] OpenWRT IPv6 firewall

[Fernando Frediani]

Hello Baptiste,

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


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


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


Best regards,

Fernando

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

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

Hello guys,

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

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

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

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

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


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


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

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

[Fernando Frediani]

Perfect and well said.

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


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


Regards,

Fernando

On 18/07/2014 01:03, David Lang wrote:
I know that IPv6 designers pine for the good old days of the 
Internet when no security was needed.


But the reality is that hackers and worms have shown that leaving 
systems exposed to the Internet is just a Bad Idea.


As such, the idea that IPv6 would restore the everyone can connect 
to everyone on any port of the early '80s was wishful thinking at best.


link-local addressing isn't a good idea, because the average home will 
have three separate links (wired plus two bands of wireless), these 
can get bridged together, but that causes problems as well.


There is no answer here that will satisfy everyone.

But do you really want to see the news stories about how anyone 
running openwrt is vulnerable to $lastest_windows_exploit but people 
running stock firmware aren't?


Yes, it would be ideal if every host was locked down so that it was 
safe for them to be exposed.


But that's not the world we live in.

David Lang

On Wed, 16 Jul 2014, Lyme Marionette wrote:


- Original Message -
On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren 
g...@altermundi.net wrote:

Benjamin is giving some great examples of real-world scenarios where
an
default-open firewall simplifies administration,
and where a default-closed firewall would be not only unnecessary
(provides no benefits), but would indeed complicate setting up
things.


There have been many good arguments posted on this subject and to 
throw my opinion in, it a question of effort and expectations.


I think everyone can agree that:
-It takes equal effort to turn a firewall on, as it does to turn one 
off.
-It takes equal effort to create a specific block list, as it does to 
create a specific allow list.

-UPnP is not included by default for either the ipv4 or ipv6 stacks.

I would also go further to suggest that:
-Consistency is good, even if it consistent for superficial reasons.

We know that, for NAT reasons, that the ipv4 stack by default blocks 
incoming connections:

-Because it doesn't know by default where to route them.
-ipv4 end-points have been traditionally insecure.

The two ways to get around this (for gaming, etc):
-Through setting firewall rules to route the traffic to an end-point.
-Through the use of UPnP (which is used by most games to host, and 
gaming consoles).


With the adoption of ipv6 there is the opportunity to change this 
behaviour such that instead of incoming traffic being restricted for 
technical reasons, that incoming traffic is routed to the correct 
end-point.

However, that begs the questions:
A) Is that consistent with what people would expect?
B) Are ipv6 end-points secure by design?

In regards to A, from the mindset of a non-technical user, would 
wager that the answer is 'no'. Even though there is a change in 
technology with ipv6, the ipv6 technology fulfills the same role as 
ipv4 and this could be seen as opposing direction between the two. 
This would likely catch many end-users by surprize unless they read 
the small print regarding this.


As for B, given my view of software development, applications, 
networks, etc (I've been in the IT business for over 25 years now) I 
would wager that 80% of applications are secure, and that the 0ther 
20% make the potential change in policy very risky.


IMO, which others may disagree with, would be to include UPnP by 
default which would/should resolve most of the hosting issues.


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


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

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

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

[Fernando Frediani]

Hi,

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


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


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


Regards,

Fernando Frediani

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

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

Perfect and well said.

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

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

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

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

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

Now CPEs can work again like transparent devices.

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

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

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

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

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



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

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

Regards,

Fernando

On 18/07/2014 01:03, David Lang wrote:

I know that IPv6 designers pine for the good old days of the
Internet when no security was needed.

But the reality is that hackers and worms have shown that leaving
systems exposed to the Internet is just a Bad Idea.

As such, the idea that IPv6 would restore the everyone can connect
to everyone on any port of the early '80s was wishful thinking at best.

link-local addressing isn't a good idea, because the average home will
have three separate links (wired plus two bands of wireless), these
can get bridged together, but that causes problems as well.

There is no answer here that will satisfy everyone.

But do you really want to see the news stories about how anyone
running openwrt is vulnerable to $lastest_windows_exploit but people
running stock firmware aren't?

Yes, it would be ideal if every host was locked down so that it was
safe for them to be exposed.

But that's not the world we live in.

David Lang

On Wed, 16 Jul 2014, Lyme Marionette wrote:


- Original Message -
On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren
g...@altermundi.net wrote:

Benjamin is giving some great examples of real-world scenarios where
an
default-open firewall simplifies administration,
and where

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

[Fernando Frediani]

Fully agree with Aaron's comments below.

Regards,

Fernando

On 15/07/2014 16:45, Aaron Z wrote:

- Original Message -
On Monday, July 14, 2014 5:36:09 PM Benjamin Cama ben...@dolka.fr wrote:

Hi everyone,

Le lundi 14 juillet 2014 à 22:17 +0900, Baptiste Jonglez a écrit :

On Mon, Jul 14, 2014 at 02:38:16PM +0200, Steven Barth wrote:

Hi Baptiste,

in general our current firewalling approach is to keep defaults
for IPv4 and
IPv6 relatively close (not considering NAT here of course).

Could you detail the reasoning behind this approach?  Don't
confuse the user?

I'd rather have Don't bother the user: things should generally
just
work, without having to configure anything (in this case, port
forwarding).  But there is an obvious tradeoff with security.

I agree with Baptiste here. There is no equivalent in IPv4 of “global
reachability” by default with the NATs we have today, so we can't
have
the same defaults. Global reachability is how IP in general was meant
to
be; please, do not make it broken again.

As I understand it, this is NOT adding NAT, but (by default) blocking 
unsolicited incoming connections from the outside world to devices on the 
internal network (which dont necessarily need to be accessible from the outside 
world). That is the whole point in using a firewall is it not? To keep people 
out of where they shouldn't be.



Opening up the IPv6 firewall by default would be unexpected and I
don't
really like the approach for that matter and honestly I don't
trust
client devices that much.

At least opening UDP ports  1024 seems pretty reasonable, and
covers most
use-cases regarding VoIP and video.  But it does indeed depart from
the
IPv4 case (not sure if it is such a bad idea though).

This looks like a good compromise to me. Knowledgeable users can
disable
the firewall for needed hosts, while for others this “just work”. PCP
may be coming one day, but it's still not there yet, so we need not
to
break the default configuration while waiting for it.

Opening access from the outside to the inside as a default rule goes against the 
principle of least privilege on which firewall rules are generally predicated.
As I understand it, if a device on the inside of the network initiates the 
connection to a device on the outside (say from a VOIP phone to a VOIP server), 
return connections from the server are allowed. What gets blocked are 
unsolicited connections from the outside which are generally unneeded (and can 
be a security risk) unless one is running a server (in which case, the users 
should know how to open ports on their firewall).

Aaron Z
___
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] IEEE 802.11 TDMA mode support in OpenWRT

[Fernando Frediani]

Hi Ben,

TDMA doesn't require synchronization between the radios. This would be 
Ubiquiti's AirSync technology and that's for another usage. When you 
have two or mode radios colocated in a tower receiving and transmitting 
at the same time so it avoids them do it at the same time and 
synchronizes Receive and Transmit.


TDMA is more to be used in PtMP environments where you have multiple 
customers talking to the AP and they don't see each other, so the AP is 
able to organize more correctlly the time each one sends data. That's 
probably why it was only implements on proprietary systems usede by 
WISPs with different names.


Regards,

Fernando

On 03/07/2014 19:59, Ben West wrote:
In an old thread on the Battlemesh listserv about strategies for 
dealing with a mix of strong / weak clients for PtMP, someone offered 
this pointer for JaldMAC, an open 802.11 polling implementation in ath9k:


http://matthias.vallentin.net/papers/nsdr10.pdf
https://github.com/shaddi/jaldimac/commits/master

Unfortunately, that repo has sat idle for over 2 years, and I believe 
it it was more a proof of concept rather than a usable implementation.


Also, i believe TDMA requires very tight synchronization between all 
radios, hence the inclusion of GPS modules on proprietary implementations.




On Thu, Jul 3, 2014 at 11:02 AM, Fernando Frediani 
fhfredi...@gmail.com mailto:fhfredi...@gmail.com wrote:


Hi all,

Is anyone aware of any implementation of TDMA mode support in
OpenWRT (similar to Ubiquiti's AirMAX, Deliberant's iPoll or
MikroTik's NV2, etc)

Would that have to be implemented having in mind the radio driver
or could it possible also be implemented in any router ?
This is certanlly something significant for more throughput
demanding and crowded environments.

Best regards,

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




--
Ben West
http://gowasabi.net
b...@gowasabi.net mailto:b...@gowasabi.net
314-246-9434


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

[OpenWrt-Devel] IEEE 802.11 TDMA mode support in OpenWRT

[Fernando Frediani]

Hi all,

Is anyone aware of any implementation of TDMA mode support in OpenWRT 
(similar to Ubiquiti's AirMAX, Deliberant's iPoll or MikroTik's NV2, etc)


Would that have to be implemented having in mind the radio driver or 
could it possible also be implemented in any router ?
This is certanlly something significant for more throughput demanding 
and crowded environments.


Best regards,

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

Re: [OpenWrt-Devel] ideal battery for solar nodes?

[Fernando Frediani]

Can you specify the usage(in Watts) of these equipment you mentioned and 
voltage ?
A 50W solar panel looks Ok, but you need to calculate the usage in Amps 
so you can find out how long the battery of that capacity can run 
without sun and you need the Watts and Voltage for that.


Fernando


On 23/05/2014 09:58, valent.turko...@gmail.com wrote:
How do you calculate ideal battery for solar nodes? I know that it 
depends on how much routers there are planned. But for example let's 
use solar node that has one nanostation nanobridge for unplink and 
picostation for AP.


I guess that 50W solar panel should be enough, right? But how big 
should the battery be?


Is 7Ah enough?

At my company we use 92Ah batteries for powering ADSL DSLAMs, and are 
replacing then now with new ones. Using a too big battery is also not 
advised because then you need much bigger solar panels because lead 
battery also looses lots of power due it's internal resistance.


So 92Ah is much too big, but is 7Ah too small? Does anybody have 
experience with batteries and solar power?



___
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] ideal battery for solar nodes?

[Fernando Frediani]

 Well, without the Watts or Current consumed it's impossible to make 
any estimations. Just a rough guess based on other people's usage as you 
mentioned below.


Fernando

On 23/05/2014 12:47, heini66 wrote:
the wr741 is running with 5v dc. i talked to the user and he toled me, 
it is possible to opperate the mobile ap for 5-6h, belonging how much 
trafic is running on it. sorry, i can't tell somthing about the 
current.( don't own one to get a messurement ) but when he is able to 
work with 4 aa mignon for 5-6h, it can't be that much.



2014-05-23 12:40 GMT+02:00 Fernando Frediani fhfredi...@gmail.com 
mailto:fhfredi...@gmail.com:


Can you specify the usage(in Watts) of these equipment you
mentioned and voltage ?
A 50W solar panel looks Ok, but you need to calculate the usage in
Amps so you can find out how long the battery of that capacity can
run without sun and you need the Watts and Voltage for that.

Fernando



On 23/05/2014 09:58, valent.turko...@gmail.com
mailto:valent.turko...@gmail.com wrote:

How do you calculate ideal battery for solar nodes? I know that
it depends on how much routers there are planned. But for example
let's use solar node that has one nanostation nanobridge for
unplink and picostation for AP.

I guess that 50W solar panel should be enough, right? But how big
should the battery be?

Is 7Ah enough?

At my company we use 92Ah batteries for powering ADSL DSLAMs, and
are replacing then now with new ones. Using a too big battery is
also not advised because then you need much bigger solar panels
because lead battery also looses lots of power due it's internal
resistance.

So 92Ah is much too big, but is 7Ah too small? Does anybody have
experience with batteries and solar power?


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



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
mailto: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-Users] Tplink wr1043nd internal/external antenna configuration and detection

[Fernando Frediani]

Hi Csmv,
Thanks for the reply.

The behavior that you are describing is exactly what I get here. 
Sometimes I get one result at the setup time and sometimes while running 
(or at reboot) I get another wihtout any change on the configuration. 
Also same thing about the sensitiveness and output power which seems to 
vary.
I wouldn't think this is a hardware issue, but a software issue. For me 
it seems that it simply doesn't obey the commands, or it changes the 
antenna settings by itself for some unknown reason.


Answering your question antenna 7 are all three antennas. The number 
you see in front of Available and Configured Antennas is the translation 
to a binary number. So for example 7 = 111 (all three antenas up) , 4 = 
100 (the first antenna in the left) , 1 = 001 (the third antenna), and 
so on.


Would someone be able to confirm they have similar results with their 
units and where to look for a possible fix ?


Thanks
Best regards,

Fernando

On 20/05/2014 04:38, cmsv wrote:

Hello


On 03/11/2014 08:54 PM, Fernando Frediani wrote:

Hi folks,

Hopefully this is a easy one for you.

I've got a TL-1043ND running Barrier Breaker (r39440). This router has 3
detachable antennas and I have removed all of them in order to be able
to use an external Sectorial antenna to reach a few other points in a
mid-range distance.
I have connected this Sectorial antenna to one of the RP-SMA connectors
and left the other two without.

On the /etc/config/wireless I'm using the following relevant lines:

 option diversity '0'
 option rxantenna '0x1'
 option txantenna '0x1'

Which supposedly means it will only use that antenna port. Or if I want
to use the use the 3rd antenna port '0x4'.

I have one one these routers and at some point i had a similar problem
that i thought i had solved.

system type : Atheros AR9132 rev 2
machine : TP-LINK TL-WR1043ND

For the longest time and with AA r39154 i was only able to get 4 or 5
results when scanning for ssid's using a 15 dbi omni antenna.

Since the router was and is in a very far remote location i was only
able to play with the physical setup about 3 months ago.

While playing with the configuration and having the router physically
using the omni antenna with rp-sma connector number 2 (middle one) i did
not get better results. I tried to change to connector 3 and also no
better results until i moved it to connector 1 (counting from the left
when you have the router front facing you).

While setting it with connector number 1 and adjusting the configuration
i was able to get 22 SSID's and so i though the problem was solved.
About less than 2 months and without any other changes; the router went
by itself to the previous bad performance and was detecting only about 4
or 5 ssid's.

At the time the setup was :
Configured Antennas: TX 0x1 RX 0x1

While:
Available Antennas: TX 0x7 RX 0x7


Strangely it did work quite well for a while even tho it showed that the
available antenna was not the one configured.

However it did not last long and i have been trying to figure out why it
stopped being able to detect those 22 ssdi's and why i don't see it
working as well as before when it gave me 22 ssid scan results.

According to:
~# iw phy phy0 info | grep -i ant
Available Antennas: TX 0x7 RX 0x7
Configured Antennas: TX 0x7 RX 0x7

0x7 is the same as wireless.radio0.txantenna=7 which is not 1, 2 or 3.
or am i wrong ? Where exactly is antenna 7 ?

My first question is: which antenna is this one ? Any of the 3 rp-sma
connectors ?

Changing wireless.radio0.diversity on and off also does not seem to help
or change anything.

Recently i updated the firmware to r40757 and there was no improvement.

I also find it very odd that a nearby access point is able to detect
this AP with SNR of 40 dbm while from the 1043nd side i only detect the
other access point with 5 ~ 9 dbm SNR.

To me this tells me that TX and RX is not working well for the 1043nd

Can someone shed some light into this from their own experience or are
these builds broken ?



Is it the correct way of using external antennas on these types of
routers ? Does using it in this way make sure there is no loss of signal
via the other ports ?
Or must the other two ports have some type of antenna even if it's a
different type like the original Omnis ?
Anyone had a similar experience and can help clarifying it ?

Thanks and best regards,
Fernando
___
openwrt-users mailing list
openwrt-us...@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-users



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


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

Re: [OpenWrt-Devel] [PATCH 16/30][ WRT1900AC ] mamba mvebu: sysupgrade support for mamba + dual boot

[Fernando Frediani]

Probably because most routers so far don't have enough flash memory to 
hold two partitions. I have seen this used on some Professional NAS systems.

Pretty useful though !

The information I have from Belkin about this feature how it works is: 
If the new flashed partition has some problem (e.g: Kernel Panic) U-Boot 
will try 3 times and if it still fails it will automatically revert back 
to boot from the previous working partition.


Regards,
Fernando

On 09/05/2014 12:16, Karl Palsson wrote:

Are there any existing docs on sysupgrade dual boot support like this?  It's a 
nice feature,
and I'd love to use existing functionality for this, but I haven't seen it, or 
heard about it
before.

Cheers,
Karl P

On Fri, May 09, 2014 at 11:48:23AM +0200, John Crispin wrote:

nack,

wrong folder duplicates functionality ..

John

On 08/05/2014 23:07, Matthew Fatheree wrote:

 From dea780ba779104cd1460efe3815c16990f5db959 Mon Sep 17 00:00:00
2001 From: Matthew Fatheree matthew.fathe...@belkin.com Date:
Sun, 4 May 2014 19:10:18 +0700 Subject: [PATCH 16/30] mamba mvebu:
sysupgrade support for mamba + dual boot is supportted

Add platform specific support for sysupgrade. Mamba supports dual
boot implementation. The firmware can be flashed to Primary Boot
partition or Alternative Boot partition. The sysupgrade has the
ping-pong effect:

.
___
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] high load without reason

[Fernando Frediani]

Ahh, recentlly I deployed Barrier Breaker on a friend's exactlly same 
router model and he has said it was getting very similar behavior (high 
loads without any apparently reason). We tried to revert back to AA 
which I am not sure if clear the issues (I guess it would if it's a 
kernel issue).


Fernando

On 24/04/2014 10:25, Bastian Bittorf wrote:

* Bastian Bittorf bitt...@bluebottle.com [24.04.2014 09:07]:

thank you 'Luiz Angelo Daros de Luca',
the reason was khubd / a USB-issue. i did nothing, just waited
and it was repaired automatically. according to dmesg, there
was something USB-related, but without user-action:

http://www.intercity-vpn.de/files/openwrt/high_load_with_unkown_reason_dmesg.txt

so in fact a kernel-issue 8-(

bye, bastian
___
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] Making sense of OpenWRT / Linksys WRT1900AC collaboration claims

[Fernando Frediani]

Couldn't agree more. Very good email.

On 23/04/2014 18:33, cmsv wrote:

Although it would be good to have this hardware supported aren't we all
forgetting something such as BETTER alternatives without extra work and
headaches ?

I have seen this router costing from $279  to a typical price of $352
and more which ends up for being close to 400 bucks after taxes
(sometimes more). For this amount of money we could pick up two
minnowboards or, 7 raspberry pi's with wifi or 10 normal home wifi
routers or for example or even much better hardware like eeepc's.

One of my network servers is an eeepc 1015  4 core Intel(R) Atom(TM) CPU
N550 @ 1.50GHz with 2gb of ram and 250gb of hd. Cost me $200 brand new
(153 Euros in 02/04/2012) and has been active for 2 years. Power
consumption is 4w minium, 5W average, 8W maximum with a 12v PSU and size
is not much bigger than these type of routers. Much better hardware in
every single way, for way less money, less trouble, less headaches, much
more functionality.

A have 4 of them. One has been working for 2 years now non stop. These
can easily be found online used or new and are much better options in
every way possible rather than a router which Belkin/Linksys purposely
have used openwrt as an excuse to try to sell it under the supposed
opensource support (which fully lacks of) and slowly have been releasing
more source code just because it got caught trying to sell a cat for a
tiger and putting lipstick on a pig.

I think openwrt devs have better things to do at the moment and other
things to improve that not only need the improvement as well as are
easier to deal with, rather than WASTING time helping belkin selling
this hardware.

These corporate giants will give a sausage to who gives them a truck
full of pigs and hope that we do all the work for them.

I think openwrt should ditch the support for now. Let belkin bend over
and do what they should have done a while go and have them understanding
the lesson. After all they were the ones that advertised it the way they
did.

At this stage there are MUCH BETTER alternatives by far.

On 04/23/2014 10:13 AM, José Vázquez wrote:

2014-04-23 14:27 GMT+02:00, Zoltan HERPAI wigy...@uid0.hu:

I don't know if any of the OpenWRT developers or contributors have
this router. If yes, my opinion is to add support for the board using
the patches sent by Matthew Fatheree as base, reworking them and drop
wireless support for now until they (Marvell or Belkin) develop a
cfg80211 or mac80211 compatible wireless driver. In other
circumstances maybe would be a good idea to spend time developing a
driver for the Avastar family but i think that if they say that the
WRT1900ac has support for OpenWRT, DD-WRT, DebWRT or any other it
should be their job.

Correction: if nobody have this router another option  could be take
Matthew's patches

(without the binary blob), correct them, test if can be compiled without
problems, include
them and add initial support marking @BROKEN.
Of course this is my own opinion and i don't have all the information,
so, if this is the case my apologies to OpenWRT developers, Matthew
Fatheree and Belkin International,Inc

Note that while having the wireless driver source released (or partially
released), is a big win, I don't see any uboot source in the package.

Regards,
-w-


Yes, it is a big win, but as Felix noted before the driver needs to be
rewrote and it doesn't use the standard Linux Wireless API.
This means that work on supporting this device can theoretically
continue, although I expect it to take quite a bit of time. As I
anticipated, the code quality of the driver source code is abysmal.
This looks like rewrite (not cleanup) material, ugly enough to cause eye
cancer or frighten small children ;)

There are also still some pieces missing: Since this driver does not use
standard Linux Wireless APIs, it can only properly function with custom
hostapd/wpa_supplicant hacks. I don't see those in the release.

I think that is too much job and efforts for a single and not very
popular, as far i know, wireless family chips. I repeat that it is my
not totally informed opinion because i don't know a lot of details.

Off topic: for me are more interesting the ath9k and ath10k drivers.

José
___
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] Making sense of OpenWRT / Linksys WRT1900AC collaboration claims

[Fernando Frediani]

I'm glad these emails threads remain recorded in the archives so they 
will be useful in the future for people cheated by Linksys/Belkin 
marketing department if this doesn't get resolved with the same energy 
that was spent to announce the product.


Fernando

On 22/04/2014 20:34, Stefan Monnier wrote:

I'm not sure if I can adequately address all of your concerns, but I
may be able to clear up some confusion.

It seems that there was no confusion at all.  The problem is that
Belkin/Linksys lied about its involvement with the OpenWRT community and
what you're saying confirms it.

The reaction here is rather hostile for that reason.  The OpenWRT
community would actually be thrilled to help along, if Linksys gave it
the opportunity.  But marketing lies compounded with wording that makes
it sound like the problem is all on OpenWRT's side doesn't help with
the collaboration.

Of course, the hostile reaction here doesn't help with that
collaboration either, but it's due in large part to the disappointment.

So I suggest to start over: have the marketing department fix those
lies, then send some patches over here in manageable chunks, and send
some sample units to some of the key developers, maybe make a public Git
branch for the ongoing not yet integrated effort.

On the other side, the OpenWRT can then show its pleasure by
incorporating some of those patches, and maybe publicize the
collaboration on its home page.


 Stefan
___
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] Making sense of OpenWRT / Linksys WRT1900AC collaboration claims

[Fernando Frediani]

From the product review in Amazon:
---
Linksys says:
Hi Mat,
Hopefully we can clear up some of your concerns.
*Flashing your WRT1900AC will NOT void your warranty. We are making sure 
our support staff are clear on this*. Thanks for letting us know that 
you were given bad information.
*OpenWRT firmware is coming but is not being developed by Linksys.* *We 
are working with the OpenWRT team to give them whatever support they 
need for their release*. We do not have any time frame for OpenWRT to 
release firmware for the WRT1900AC but it is in progress and will be 
available at some point in the near future. We suspect that they will 
announce it as soon as it is available.
About the web UI crashing issue, please email us your case number from 
support and link to this review at linksysca...@linksys.com so we can 
further investigate.

Thanks,
Linksys Supporthttp://support.linksys.com
---

Not being developed by Linksys ? By who then ?
With regards giving the OpenWRT team whatever support they need, giving 
the source of the wireless driver would be a good start. Then a couple 
of units to developers is another way to work with the OpenWRT team I 
guess.


Fernando

On 18/04/2014 07:44, Andrew Johnson wrote:

(See below)
On Thu, Apr 17, 2014 at 7:54 PM, Matthew Fatheree 
matthew.fathe...@belkin.com mailto:matthew.fathe...@belkin.com wrote:


On Thu, 2014-04-17 at 19:27 -0700, Andrew Johnson wrote:
 As already pointed out by Felix, your patches do not contain the
 necessary wireless driver, so OpenWRT users are not actually able to
 create a working firmware for the WRT1900AC with those patches. So
 your statement that users are able to access those [patches], and
 create a firmware image while the approval process completes. isn't
 true, because said firmware image wouldn't actually work.

The firmware can be built with what we have provided, and will run on
the WRT1900AC successfully.  It is true that it would lack wireless
support, but that would not stop the firmware from actually
working.  We
are actively working on the package to support the wireless hardware,
this will not be overlooked.


Oh. I had figured this goes without saying, but I guess I was wrong --
For all intents and purposes, lack of wireless functionality in a 
wireless router firmware means the firmware doesn't work. Nobody in 
their right mind is going to pay $250 USD for an 802.11ac 
wireless**router that purports OpenWRT support in order to use it with 
OpenWRT as a wired-only router. No one.
So with that being said, I would submit to you that making statements 
like It is true that it would lack wireless support, but that would 
not stop the firmware from actually working does more damage than 
good in conversations like this. The lack of the wireless support is 
indeed the very thing that is stopping the firmware from working. It'd 
be nice to avoid things like that moving forward if at all possible -- 
as the saying goes, don't pee on my boots and tell me it's raining.


I apologize for the confusion.  I am optimistic, that things will be
cleared up soon.

I appreciate your enthusiasm.


I'm still willing to wait and see what happens. But so far, I feel 
this is a horrible start on the OpenWRT support front -- especially 
marketing wise. Again, here's a review from someone that bought this 
product expecting OpenWRT support based on the marketing materials and 
was quite disappointed - http://amzn.to/1f0z4p8

Regards,

Andrew


___
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] Making sense of OpenWRT / Linksys WRT1900AC collaboration claims

[Fernando Frediani]

I think Belkin marketing responsible person should be fired straight 
away because they lied. My opinion !
Sometimes, in my organizations, sales and marketing people seems that 
just because they wear a suit and a tie they can lie without the risk of 
any penalty so they don't measure a bit of their public statements.


Fernando

On 17/04/2014 05:18, Andrew Johnson wrote:

Hello,

Now that this router is available at retailers [4] and we're seeing 
all kinds of reviews pop up, if possible I'd like to get some 
clarification on the nature of the collaboration between Linksys and 
the OpenWRT developers on the WRT1900AC.


Linksys has been making claims in their marketing materials that the 
WRT1900AC is OpenWRT Ready [1]:

OpenWRT Ready
Over the past months Linksys and the OpenWRT project have been 
collaborating to ensure open source readiness and continued 
development for the new WRT.


I've seen at least one account from a person that has this router in 
their hands, but it doesn't seem to be OpenWRT ready for them [2]. 
Indeed, I believe this reviewer is right -- correct me if I'm wrong, 
but one cannot download and flash a readily available OpenWRT image 
that would actually function.
Moreover, this reviewer [2] claims that a Linksys support technician 
stated that flashing OpenWRT would void the warranty, which is 
interesting, if true.


The press release [1] also mentions collaborating with the OpenWRT 
project over the past months, but the oldest communication  to 
openwrt-devel seems to be 13 days ago -- Apr 3, 2014 from Matthew 
Fatheree when a patch was submitted [3].


Linksys is also using purported quotes from an OpenWRT representative 
in their marketing materials [1]:
The history of OpenWrt goes back more than a decade when it all began 
with a project to hack and modify the Linksys WRT54G. A lot has 
changed since then, said Gregers Petersen, relationship manager at 
OpenWrt. Today OpenWrt is a complete embedded Linux distribution that 
enables users to be innovative and create new solutions and functions. 
Other key elements of OpenWrt are source code transparency, security 
and extensive package repositories. We see it as a very positive 
development to have collaborated directly with the Linksys engineering 
team on the new WRT1900AC router. As a result of that consumers will 
have the freedom of choice between the Linksys default firmware and 
OpenWrt. The OpenWrt developers recognize the potential of the 
collaboration with Linksys, and the opportunities it brings for more 
devices and solutions.


Something doesn't seem to jive here. Can anyone fill in the blanks?
In particular, some transparency Real Soon Now from someone at Linksys 
as well as Gregers Petersen with OpenWRT would be much appreciated, 
especially in light of how much the OpenWRT name is being used in the 
Linksys press releases and marketing materials as outlined above.


1. 
http://www.businesswire.com/news/home/20140410005397/en/Linksys-Starts-Shipping-WRT1900AC-Successor-Legendary-WRT#.U09GUvldVyV
2. 
http://www.amazon.com/review/R15JCQ96X8Z3WY/ref=cm_cr_dp_title?ie=UTF8ASIN=B00IGL3L2Echannel=detail-glancenodeID=541966store=pc
3. 
https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg22849.html

4. http://goo.gl/4bgh8b (Best Buy WRT1900AC page)


___
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] is anybody working on supporting Linksys WRT1900ac ?

[Fernando Frediani]

NDA = $$$ = Quiet

I just don't understand what is the problem, if it's really true, to 
tell the most interested people (developers) that you are working on 
something directly related to the project, even without giving any 
further details due the NDA.



On 06/04/2014 11:17, Hartmut Knaack wrote:

Gerry Rozema schrieb:

On 28/03/14 01:58 PM, Peter Lawler wrote:

Hi Pete! We are working with one of the OpenWRT founders and his
team. We'll be sharing more details later... Stay tuned! :)

https://dev.openwrt.org/wiki/people

Two listed there as founders, and I'm one of the two.

Isn't me, so it must be Mike

Mike, are you still alive and on the list?

___
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] is anybody working on supporting Linksys WRT1900ac ?

[Fernando Frediani]

That is very interesting.

Does anyone know if the source code of the .ko module was finally 
provided by Belkin/Linksys ?


Jose-Vasquez - Regarding your other email why there is so much interest 
on the WRT1900ac,, I think first because it was announced as a successor 
of the famous WRT54G, which  needless to say the importance of this in 
the start of the project. Also despite the fact other hardwares like 
TL-WDR7500 are very interesting indeed, this one has its merits on the 
upcoming ac era and if Belkin/Linksys is truly interested to work 
with OpenWRT developers means, in theory, an always welcome 
contribution back to the project.


Best regards,

Fernando


On 07/04/2014 14:32, Toke Høiland-Jørgensen wrote:

There was a patch posted from linksys last week:

http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/23500

-Toke

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

Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?

[Fernando Frediani]

Reading all this discussion around WRT1900ac makes me wonder of something:

- When Belkin acquired Linksys and announced WRT1900ac they made a big 
noise (marketing) about OpenWRT compatibility so they are using the 
project's name for their financial benefit, make people believe in that 
to buy the hardware (nothing that stops them to do that really).
- Anyone here would then expect they engage with developers and submit 
patches for the work they are doing. They kind of showed up but very 
briefly and submmited a non-acceptable patch so far.
- Therefore they are subscribed to this email list seeing all this 
discussion around their product and either:

- They watch it silently, laugh and ignore it (which is not good).
- They are not even aware or following this discussion (which is 
not good too).


Therefore I get confused of what the next steps will be around it and 
the output of this discussion will end.


Regards,

Fernando

On 07/04/2014 23:03, Peter Lawler wrote:

On 08/04/14 00:50, José Vázquez wrote:

There is something that still don't understand: why is there so much
interest in the WRT1900ac? A Wandboard quad + i.e. TL-WDR7500 is a
more exciting, more powerful and more versatile combo.


As we've seen from elsewhere in this thread, they've already submitted 
some patches[1] in a non-standard format and had them knocked back. 
The 'quality' of the submission does kinda make me wonder whether the 
folks designing the box never in their wildest dreams expected to get 
approval from Linksys's new owners to go the FLOSS path. I actually 
kinda have the feeling that the Linksys engis have had an OpenWRT 
capable box in their office for some time and it's the new owners that 
have allowed them to productise. But I digress...


Now that I'm actually convinced that they are working on having 
OpenWRT, I've started to re-read their product announcements [2]. 
Whilst originally I (and maybe others) expected it to have been ready 
with OWRT out of the box it's pretty clear to me now that they never 
intended it to be OWRT ready on launch day but at some time after 
launch. This is probably why Bastian never got a response to his 
request for a bunch of dev boxes[3]. Which kinda dovetails in to... 
Given the quality of the patch submitted in [1], I'm expecting it'll 
be OpenWRT ready and production stable say June at the earliest.


As for the TL-WDR7500, the one obvious thing the 1900ac has that it 
doesn't is eSATA. Also, at the time of initial 1900ac announcement, 
there was no working 5GHz on the WDR7500 [4] so interest for me to a 
very large degree is in the performance in that spectrum.


Anyway, enough from me for first in the morning emails before my 
coffee. Good luck to both 'teams' working on 5GHz stuff for OpenWRT. 
Having a choice in hardware can only benefit everyone.



Pete.

1 http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/23500
2 
http://store.linksys.com/Linksys-WRT1900AC-Open-Source-Wireless-Router_stcVVproductId158014980VVcatId551966VVviewprod.htm 
[Apparently they're still supporting WinXP as a host PC platform, 
popcorn!]

3 http://article.gmane.org/gmane.comp.embedded.openwrt.devel/23513
4 
https://lists.openwrt.org/pipermail/openwrt-devel/2014-March/024459.html

___
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] is anybody working on supporting Linksys WRT1900ac ?

[Fernando Frediani]

Then the obvious question is: Mike, if it's really you according to 
Linksys and Gerry statements, why don't you say a word about it in the 
list ? Did you sign a non-disclosure agreement ?


On 28/03/2014 21:57, Gerry Rozema wrote:

On 28/03/14 01:58 PM, Peter Lawler wrote:


Hi Pete! We are working with one of the OpenWRT founders and his 
team. We'll be sharing more details later... Stay tuned! :)


https://dev.openwrt.org/wiki/people

Two listed there as founders, and I'm one of the two.

Isn't me, so it must be Mike
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] UCI support for IEEE 802.1ad ?

[Fernando Frediani]

Hello,

This doesn't answer your question, but I want to share what I have done 
to overcome that lack of vlan tagging on certain enviroments using 
OpenWRT/DD-WRT.


I simply use openvpn tunnels with tap interfaces(layer 2) and bridge 
them with either a VAP interface or a separated Ethernet port. It's not 
an ideal solution and adds up a little extra latency and CPU processing 
but it's not a big deal and works fine and does the propose for when 
other options don't work. Depending where this tunnels is passing 
through (e.g: an already encrypted WPA2 link) I don't even bother to use 
encryption on the openvpn configuration reducing the needed extra CPU).


Hope it helps.

In time: I like Guifi.net and often read your website for ideas. Please 
put more content in either English or Spanish not in bloody Catalan !


Regards,

Fernando

On 17/02/2014 13:34, al wrote:

Hello, I'm Ál Cano Santana, from Guifi.net free network in Catalunya. We're 
making some parts of our mesh network with good and cheap router TP-Link 
WDR3500 with OpenWrt. That router has a AR934X built-in switch that is not so 
good and drop vlan tagged packets on switch, but it drops only in 802.1q, not 
in IEEE 802.1ad.

So if we can implement UCI support for 802.1ad we can solve this problem.

Now mac-vlan is implemented in uci and works so fine, but as I saw only 
supports 802.1q, and we have the problem that our switch drop 802.1q, but we 
test with 802.1ad vlan packets and they aren't dropped.

Can you help us to implement this feature?

Sorry if I didn't explain it well, I can try to do it again if you need it.

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

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