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

[Joel Wirāmu Pauling]

Yes that's the update v6 flag I was mentioning.. BUT it won't actually
solve this issue, as you would then need to someone dynamically adjust
inbound stateful forwarding rules in nft/ip6tables dynamically... WHICH ...
am not a fan of doing.



On Tue, 5 May 2020 at 10:23, Fernando Frediani  wrote:

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

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

[Joel Wirāmu Pauling]

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  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  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
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>
>
> ___
> openwrt-devel mailing 
> listopenwrt-devel@lists.openwrt.orghttps://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

[Joel Wirāmu Pauling]

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

Re: [OpenWrt-Devel] Possible security issue

[Joel Wirāmu Pauling]

I'm sorry for wading into this. As with any security related discussion
strawpeople can be made to support any particular thread pulling into
infinity.

Would I love to see namespaces used as part of the base Openwrt
architecture; absolutely. It's been discussed in the past; routing in
particular would benefit immensely from this ; use of different routing
table ID's is a step towards that, but complications like passing device
id's in and out of namespaces however for the switch side of things is
problematic and adds additional overhead as will it introduce issues at the
expense of separation and flexibility.

That potentially could mitigate some of your concerns, but I feel the
preposition for me is openwrt is not multi-user by default OOTB for most
(if not all) targets; and if you want it to be you can.

So fiddling inode bitmasks is not addressing anything IMNSHO because of
that fact.






On Sat, 18 Apr 2020 at 00:50, Wes Turner  wrote:

> From a least privileges perspective:
>
> - chmod o-rwx /var/run/hostapd-phyX.conf
> - chmod o-x uci # setfacl?
>
> Compromise of a service running as a different user should not result in
> disclosure of sensitive keys only necessary for different services.
>
> https://openwrt.org/docs/guide-user/security/security-features mentions
> procd jail / chroot?
>
> AFAIU, LXC is not available in the default kernel builds in any router?
> LXC would be an additional layer of defenses over and above chroot, which
> isn't seccomp
>
> On Fri, Apr 17, 2020, 5:13 AM Joel Wirāmu Pauling 
> wrote:
>
>> No. If you have physical access to the node and/or a valid login as Admin
>> then any form of PSK is vulnerable.
>>
>> If you are concerned about PSK's being exposed then you have the option
>> to run 802.1x auth and issue issues tokens out of radius/IDM that is
>> secured elsewhere than on the AP itself.
>>
>> On Fri, 17 Apr 2020 at 20:16, e9hack  wrote:
>>
>>> Hi,
>>>
>>> the configuration files for hostapd (/var/run/hostapd-phyX.conf) are
>>> readable for everyone. This means everyone can read the wifi passwords. If
>>> a non privileged user calls 'uci show wireless', he will also get all wifi
>>> passwords. This possible e.g. for user nobody and dnsmasq.
>>>
>>> Is this a a security issue?
>>>
>>> Regards,
>>> Hartmut
>>>
>>> ___
>>> 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] Possible security issue

[Joel Wirāmu Pauling]

No. If you have physical access to the node and/or a valid login as Admin
then any form of PSK is vulnerable.

If you are concerned about PSK's being exposed then you have the option to
run 802.1x auth and issue issues tokens out of radius/IDM that is secured
elsewhere than on the AP itself.

On Fri, 17 Apr 2020 at 20:16, e9hack  wrote:

> Hi,
>
> the configuration files for hostapd (/var/run/hostapd-phyX.conf) are
> readable for everyone. This means everyone can read the wifi passwords. If
> a non privileged user calls 'uci show wireless', he will also get all wifi
> passwords. This possible e.g. for user nobody and dnsmasq.
>
> Is this a a security issue?
>
> Regards,
> Hartmut
>
> ___
> 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] x86: use multiple profiles

[Joel Wirāmu Pauling]

Related;

would be nice to have a supported atomic update method (rollforward/back)
and/or adapt sysupgrade/opkg to cope with full sys-upgrade style opperation.

Fedora CoreOS and OSTree may be a possible inspiration point. Either way I
am getting tired of need to have to stand up a new VM - clone config/opkg
update and then switch over from running VM as being the only decent way of
doing sysupgrades on x86 targets.

-Joel

On Thu, 16 Apr 2020 at 10:02, Daniel Golle  wrote:

> On Tue, Apr 14, 2020 at 03:08:09PM -1000, Paul Spooren wrote:
> > Hi all,
> >
> > the x86 been recently reworked (cb007a7bf6) and now it is easily
> possible to
> > define multiple profiles. Currently only a `generic` profile is offered
> which
> > builds mbr and efi grub images with a standard selection of packages
> (common
> > device drivers).
> >
> > I'd suggest to have multiple profiles for common x86 devices, including
> the
> > correct drivers. An example is the APU2 board, which requires additional
> kmods
> > to shine[0].
> >
> > A first split could be to have mbr and efi images separated and the APU2
> board.
>
> +1
> also for splitting EFI and MBR generic images, because EFI image
> should have some different packages (efibootmgr, kmod-fs-efivars, ...)
> installed which are useless when booting from MBR.
>
>
> >
> > Please share your opinions.
> >
> > Best,
> > Paul
> >
> > [0]: https://openwrt.org/toh/pcengines/apu2#kernel_modules
> >
>
> ___
> 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] Configuration management for OpenWrt

[Joel Wirāmu Pauling]

Ansible doesn't require or need python on targets. In fact it's one of it's
biggest selling points and why over a 3rd of modules are network device
centric.

There is a UCI module for openwrt:

https://github.com/lefant/ansible-openwrt-uci

I tend to redeploy images/snapshots to VM's and then run opkg via ansible
or scripts and copy over config files.

-Joel




On Thu, 9 Apr 2020 at 09:08, Paul Spooren  wrote:

> Hi all,
>
> I was wondering if there are some best practices for configuration
> management of OpenWrt devices. I understand that it is fairly easy to
> get/restore a backup of the etc/config folder, but though maybe there
> are some smarter ways.
>
> Ideally a local state (e.g. git repository) would deploy multiple
> devices and automatically update them via a command (or even cron).
>
> Other projects came up with solutions which seem to heavy for common
> WiFi routers. Ansible[0] is great and all, however requires plenty of
> Python to work conveniently. Then cloud-init[1] is Python as well, I
> think even heavier on the client side than Ansible and also doesn't
> seem to be the right use case.
>
> Some time ago I came up with a MAC based init system[2] but that's not
> really to keep things up to date.
>
> Last thing I know of is the approach to convert folders into opkg
> install-able packages[3], so whenever there is a new configuration all
> pre-configured routers would install it via opkg. However this would
> require an opkg cron on client device and building the config-packages
> appear to be quite some overhead. On the other side it handles
> authentication via usign keys.
>
> Anyway, please recommend me a better way which I'm not aware of!
>
> Best,
> Paul
>
> [0]: https://www.ansible.com/
> [1]: https://cloud-init.io/
> [2]: https://github.com/openwrt/packages/pull/6071
> [3]: https://github.com/libremesh/network-profiles-builder
>
>
> ___
> 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] New target IPQ8074 / Asus-ax89x(u)

[Joel Wirāmu Pauling]

So update on the rt-ax89x;

I have successfully managed to compile using the ASUSwrt build chain and
load a usable firmware (well if you can call asuswrt usable; it's horrific
when it comes to how service construct flow is setup, i can't believe the
junk being shipped on otherwise nice platforms...)

I have also figured out the debrick procedure ; uboot on the device DOES
accept tftp in recovery mode. Have added notes to the wiki; reposted here:

Method:

   1. Setup interface on Host PC with ip 192.168.50.75/24 (not the Router
   will ONLY accept tftp put over this IP) ; $ip a a 192.168.50.75/24 dev
   
   2. The HostNIC and recovery is performed ONLY over the 1G WAN port NIC
   (this is the 'blue') NIC port next to the 10G Copper port.
   3. Find valid recovery .trx
   4. Run tftp to 192.168.50.1 ; $tftp 192.168.50.1
   5. Unplug DC barrel jack whilst holding down the reset switch with a
   pointy thing
   6. Leave Power Button Depressed(on)
   7. Replug DC barrel jack whilst still holding reset switch with a pointy
   thing ; release after first LED indication
   8. Power LED will flash slowly
   9. Use TFTP client to put target firmware in bin mode; set trace to show
   progess; $tftp>trace ; $tftp>bin; $tftp>put .trx
   10. Trace will show transfer ; wait for router to reboot.


-Joel

On Sat, 28 Mar 2020 at 00:20, Robert Marko  wrote:

>
>
> On Fri, 27 Mar 2020 at 04:03, Joel Wirāmu Pauling 
> wrote:
>
>> Xiaomi ax3600 has Qualcomm radios right?
>>
> Yeah, its QCA8071A based.
> But I can't find anywhere to get one in EU and there is no GPL released.
> Xiaomi really doesn't care about respecting GPL on their routers.
>
>>
>> On Fri, 27 Mar 2020, 11:21 Robert Marko,  wrote:
>>
>>>
>>>
>>> On Thu, 26 Mar 2020 at 23:11, Joel Wirāmu Pauling 
>>> wrote:
>>>
>>>> Considering that there are a heap of lesser boxes from the likes of
>>>> Cisco/Aruba/Dlink/Asus themselves that are far inferior selling well above
>>>> the 1500$ mark.
>>>>
>>> I dont take Cisco and Aruba prices seriously.
>>>
>>>>
>>>> On Fri, 27 Mar 2020 at 11:09, Joel Wirāmu Pauling 
>>>> wrote:
>>>>
>>>>> It's 800$NZD not sure of what the conversion is.
>>>>>
>>>>> BUT
>>>>>
>>>>> It's got Dual 10Gbit ports ; so if you factor going the DIY route on
>>>>> x86 boxes (which is what I have been forced to do for 10G capable for the
>>>>> last few years), Power consumption, and wifi6 - it's actually not an
>>>>> unreasonable price point for what you get.
>>>>>
>>>> Its roughly 400EUR, a lot for a consumer device.
>>> Its a good device, but for development, it's too expensive since there
>>> is a chance of bricking it.
>>> I am waiting for a cheap(100-ish EUR) IPQ807x board since I don't see
>>> getting a test one at work for a while and I cant afford 300+ EUR myself.
>>>
>>>>
>>>>>
>>>>>
>>>>> On Fri, 27 Mar 2020 at 10:45, Ansuel Smith 
>>>>> wrote:
>>>>>
>>>>>> 400€ for a router... little too much for now... at least the firmware
>>>>>> is openwrt based so ASUS should provide GPL.
>>>>>>
>>>>>> Il giorno gio 26 mar 2020 alle ore 22:42 Robert Marko
>>>>>>  ha scritto:
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Thu, 26 Mar 2020 at 22:39, Joel Wirāmu Pauling <
>>>>>> j...@aenertia.net> wrote:
>>>>>> >>
>>>>>> >> Hi all,
>>>>>> >>
>>>>>> >> I received my ax89x yesterday and have added a stub wiki page for
>>>>>> it here:
>>>>>> >>
>>>>>> >> https://openwrt.org/toh/asus/rt-ax89x
>>>>>> >>
>>>>>> >> There is a published build chain for the device from ASUS - I
>>>>>> haven't tried compiling it.
>>>>>> >> I've done some preliminary poking and opened the case up - dumped
>>>>>> the bootlog.
>>>>>> >>
>>>>>> >> Very interesting device and likely a good target for 10Gbit and
>>>>>> Wifi6 work.
>>>>>> >
>>>>>> >
>>>>>> > Looks great, just that the price tag is painful.
>>>>>> > Its HK01 reference board based, a lot of stuff has been upstreamed
>>>>>> but a whole more is missing for IPQ807x upstream.
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> -Joel
>>>>>> >> ___
>>>>>> >> 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] New target IPQ8074 / Asus-ax89x(u)

[Joel Wirāmu Pauling]

Xiaomi ax3600 has Qualcomm radios right?

On Fri, 27 Mar 2020, 11:21 Robert Marko,  wrote:

>
>
> On Thu, 26 Mar 2020 at 23:11, Joel Wirāmu Pauling 
> wrote:
>
>> Considering that there are a heap of lesser boxes from the likes of
>> Cisco/Aruba/Dlink/Asus themselves that are far inferior selling well above
>> the 1500$ mark.
>>
> I dont take Cisco and Aruba prices seriously.
>
>>
>> On Fri, 27 Mar 2020 at 11:09, Joel Wirāmu Pauling 
>> wrote:
>>
>>> It's 800$NZD not sure of what the conversion is.
>>>
>>> BUT
>>>
>>> It's got Dual 10Gbit ports ; so if you factor going the DIY route on x86
>>> boxes (which is what I have been forced to do for 10G capable for the last
>>> few years), Power consumption, and wifi6 - it's actually not an
>>> unreasonable price point for what you get.
>>>
>> Its roughly 400EUR, a lot for a consumer device.
> Its a good device, but for development, it's too expensive since there is
> a chance of bricking it.
> I am waiting for a cheap(100-ish EUR) IPQ807x board since I don't see
> getting a test one at work for a while and I cant afford 300+ EUR myself.
>
>>
>>>
>>>
>>> On Fri, 27 Mar 2020 at 10:45, Ansuel Smith  wrote:
>>>
>>>> 400€ for a router... little too much for now... at least the firmware
>>>> is openwrt based so ASUS should provide GPL.
>>>>
>>>> Il giorno gio 26 mar 2020 alle ore 22:42 Robert Marko
>>>>  ha scritto:
>>>> >
>>>> >
>>>> >
>>>> > On Thu, 26 Mar 2020 at 22:39, Joel Wirāmu Pauling 
>>>> wrote:
>>>> >>
>>>> >> Hi all,
>>>> >>
>>>> >> I received my ax89x yesterday and have added a stub wiki page for it
>>>> here:
>>>> >>
>>>> >> https://openwrt.org/toh/asus/rt-ax89x
>>>> >>
>>>> >> There is a published build chain for the device from ASUS - I
>>>> haven't tried compiling it.
>>>> >> I've done some preliminary poking and opened the case up - dumped
>>>> the bootlog.
>>>> >>
>>>> >> Very interesting device and likely a good target for 10Gbit and
>>>> Wifi6 work.
>>>> >
>>>> >
>>>> > Looks great, just that the price tag is painful.
>>>> > Its HK01 reference board based, a lot of stuff has been upstreamed
>>>> but a whole more is missing for IPQ807x upstream.
>>>> >>
>>>> >>
>>>> >>
>>>> >> -Joel
>>>> >> ___
>>>> >> 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] New target IPQ8074 / Asus-ax89x(u)

[Joel Wirāmu Pauling]

Considering that there are a heap of lesser boxes from the likes of
Cisco/Aruba/Dlink/Asus themselves that are far inferior selling well above
the 1500$ mark.

On Fri, 27 Mar 2020 at 11:09, Joel Wirāmu Pauling  wrote:

> It's 800$NZD not sure of what the conversion is.
>
> BUT
>
> It's got Dual 10Gbit ports ; so if you factor going the DIY route on x86
> boxes (which is what I have been forced to do for 10G capable for the last
> few years), Power consumption, and wifi6 - it's actually not an
> unreasonable price point for what you get.
>
>
>
> On Fri, 27 Mar 2020 at 10:45, Ansuel Smith  wrote:
>
>> 400€ for a router... little too much for now... at least the firmware
>> is openwrt based so ASUS should provide GPL.
>>
>> Il giorno gio 26 mar 2020 alle ore 22:42 Robert Marko
>>  ha scritto:
>> >
>> >
>> >
>> > On Thu, 26 Mar 2020 at 22:39, Joel Wirāmu Pauling 
>> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I received my ax89x yesterday and have added a stub wiki page for it
>> here:
>> >>
>> >> https://openwrt.org/toh/asus/rt-ax89x
>> >>
>> >> There is a published build chain for the device from ASUS - I haven't
>> tried compiling it.
>> >> I've done some preliminary poking and opened the case up - dumped the
>> bootlog.
>> >>
>> >> Very interesting device and likely a good target for 10Gbit and Wifi6
>> work.
>> >
>> >
>> > Looks great, just that the price tag is painful.
>> > Its HK01 reference board based, a lot of stuff has been upstreamed but
>> a whole more is missing for IPQ807x upstream.
>> >>
>> >>
>> >>
>> >> -Joel
>> >> ___
>> >> 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] New target IPQ8074 / Asus-ax89x(u)

[Joel Wirāmu Pauling]

It's 800$NZD not sure of what the conversion is.

BUT

It's got Dual 10Gbit ports ; so if you factor going the DIY route on x86
boxes (which is what I have been forced to do for 10G capable for the last
few years), Power consumption, and wifi6 - it's actually not an
unreasonable price point for what you get.



On Fri, 27 Mar 2020 at 10:45, Ansuel Smith  wrote:

> 400€ for a router... little too much for now... at least the firmware
> is openwrt based so ASUS should provide GPL.
>
> Il giorno gio 26 mar 2020 alle ore 22:42 Robert Marko
>  ha scritto:
> >
> >
> >
> > On Thu, 26 Mar 2020 at 22:39, Joel Wirāmu Pauling 
> wrote:
> >>
> >> Hi all,
> >>
> >> I received my ax89x yesterday and have added a stub wiki page for it
> here:
> >>
> >> https://openwrt.org/toh/asus/rt-ax89x
> >>
> >> There is a published build chain for the device from ASUS - I haven't
> tried compiling it.
> >> I've done some preliminary poking and opened the case up - dumped the
> bootlog.
> >>
> >> Very interesting device and likely a good target for 10Gbit and Wifi6
> work.
> >
> >
> > Looks great, just that the price tag is painful.
> > Its HK01 reference board based, a lot of stuff has been upstreamed but a
> whole more is missing for IPQ807x upstream.
> >>
> >>
> >>
> >> -Joel
> >> ___
> >> 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] New target IPQ8074 / Asus-ax89x(u)

[Joel Wirāmu Pauling]

Hi all,

I received my ax89x yesterday and have added a stub wiki page for it here:

https://openwrt.org/toh/asus/rt-ax89x

There is a published build chain for the device from ASUS - I haven't tried
compiling it.
I've done some preliminary poking and opened the case up - dumped the
bootlog.

Very interesting device and likely a good target for 10Gbit and Wifi6 work.


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

[OpenWrt-Devel] [Request] Build x86_64 with EFI Images for ext4 combined

[Joel Wirāmu Pauling]

Currently the Auto-generated x86/64 images are all msdos
partition/boot layouts. Which means they are a PITA to run on
increasingly UEFI only hardware.

It would be great to have the release images and snapshots build have
two new variants a combined ext4 efi in particular would be very
useful.

Cheers

-Joel

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

Re: [OpenWrt-Devel] [PATCH] ath79: add support for TP-Link Archer C7 v1

[Joel Wirāmu Pauling]

Just a question on this particular MiniPCIE;

having pulled one of my broken C7's apart (due to shorting 5v on the
MCU) and placed the wireless card (which is oversized) into an x86 dev
board. I notice that atk10k fails due to missing board.bin ; googling
shows that this is some sort of radio tuning and is stored in the ARTS
portion of the mtd of the original device.

What is the correct way to obtain this file for use in this situation?
I Still have a number of working C7's ;

-Joel

On 18 August 2018 at 09:10, Mathias Kresin  wrote:
> 17.08.2018 18:36, Christian Lamparter:
>
>> TP-Link Archer C7 v1 is a dual band router
>> based on Qualcomm/Atheros QCA9558 + QCA9880.
>>
>> Specification:
>>
>>   - 720 MHz CPU
>>   - 128 MB of RAM (Various chips)
>>   - 8 MB of FLASH (Various chips)
>>   - SoC QCA9558 integrated 3T3R 2.4 GHz Wi-Fi
>>   - minipcie slot with 3T3R 5 GHz QCA9880-AR1A (unsupported by ath10k!)
>>   - 5x 10/100/1000 Mbps Ethernet (AR8327N Switch)
>>   - 10x LEDs, 2x software buttons
>>
>> For further informwation on the device, visit the wiki:
>> 
>>
>> Signed-off-by: Christian Lamparter 
>> ---
>>   .../ath79/base-files/etc/board.d/02_network   |  1 +
>>   .../ath79/dts/qca9558_tplink_archer-c7-v1.dts | 46 +++
>>   target/linux/ath79/image/generic-tp-link.mk   |  9 
>>   3 files changed, 56 insertions(+)
>>   create mode 100644
>> target/linux/ath79/dts/qca9558_tplink_archer-c7-v1.dts
>>
>> diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
>> b/target/linux/ath79/base-files/etc/board.d/02_network
>> index 9e31be40f9..0d33549890 100755
>> --- a/target/linux/ath79/base-files/etc/board.d/02_network
>> +++ b/target/linux/ath79/base-files/etc/board.d/02_network
>> @@ -81,6 +81,7 @@ ath79_setup_interfaces()
>> ucidef_add_switch "switch0" \
>> "0@eth0" "3:lan:1" "5:lan:2" "4:wan"
>> ;;
>> +   tplink,archer-c7-v1|\
>> tplink,archer-c7-v2|\
>> tplink,tl-wdr4900-v2)
>> ucidef_add_switch "switch0" \
>> diff --git a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v1.dts
>> b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v1.dts
>> new file mode 100644
>> index 00..3d7713f675
>> --- /dev/null
>> +++ b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v1.dts
>> @@ -0,0 +1,46 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
>> +/dts-v1/;
>> +
>> +#include 
>> +#include 
>> +
>> +#include "qca9558_tplink_archer-c7.dtsi"
>> +
>> +/ {
>> +   compatible = "tplink,archer-c7-v1", "qca,qca9558";
>> +   model = "TP-Link Archer C7 Version 1";
>> +};
>> +
>> +_keys {
>> +   rfkill {
>> +   gpios = < 13 GPIO_ACTIVE_LOW>;
>> +   linux,code = ;
>> +   linux,input-type = ;
>> +   debounce-interval = <60>;
>> +   };
>> +};
>> +
>> +_leds {
>> +   wlan5g {
>> +   label = "tp-link:green:wlan5g";
>> +   gpios = < 17 GPIO_ACTIVE_LOW>;
>> +   default-state = "off";
>> +   linux,default-trigger = "phy0tpt";
>> +   };
>> +};
>> +
>> + {
>> +   uboot: u-boot@0 {
>> +   reg = <0x00 0x02>;
>> +   read-only;
>> +   };
>> +
>> +   firmware@2 {
>> +   reg = <0x02 0x7d>;
>> +   };
>> +
>> +   art: art@ff {
>> +   reg = <0x7f 0x01>;
>
>
> Just to make sure, it's the unit address and not the reg which is wrong?
>
> No need to send a v2, I'll fix it prior to merging the commit.
>
>
> Mathias
>
>
>
> ___
> 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] [PATCH 0/4] Gemini forward-port to kernel v4.14

[Joel Wirāmu Pauling]

It's Cortina but arm7 IIRC; there was a NDA available SDK for it based on
2.6.something - which I started to go through the process of getting access
too a few years ago, but the platform was bought out by Realtek who
scuttled it as it was in competition with their own designs.

The Almond+ has Zwave and Zigbee on PCI bus and Qualcomm AR9880 AC and N
radios, and a USB3 hub. Jtag fully exposed and there is even a Touchscreen
(which I think is I2C based). It would be a nice target to get working with
trunk.

I can post uboot and jtag when I am back in front of it.

-Joel

On 2 May 2018 at 20:04, Linus Walleij <linus.wall...@linaro.org> wrote:

> On Wed, May 2, 2018 at 12:41 AM, Joel Wirāmu Pauling <j...@aenertia.net>
> wrote:
>
> > any chance for support for the
> > Goldengate SoC found in the Almond+. Currently attempting to reuse it
> for a
> > home automation project but it's ancient kernel is terrible and even
> doing
> > basic things like vlans are horribly broken with the Securfi hacked up
> > NutsOS that runs on top of ancient openwrt.
>
> No idea what SoC that is, sorry, even less do I have any development
> board or anything for it... if it is a Cortina or StorLink SoC there is
> chance
> you can reuse some of the drivers for the basic IP blocks but that is
> as much as I can help.
>
> Yours,
> Linus Walleij
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14

[Joel Wirāmu Pauling]

I have been Eyeing your Gemni patches - any chance for support for the
Goldengate SoC found in the Almond+. Currently attempting to reuse it for a
home automation project but it's ancient kernel is terrible and even doing
basic things like vlans are horribly broken with the Securfi hacked up
NutsOS that runs on top of ancient openwrt.

-Joel

On 5 April 2018 at 08:34, Linus Walleij  wrote:

> This patch set forward-ports Gemini to v4.14 with as good
> support as I can get.
>
> I don't know if all or any patches actually make it through
> to the devel list. They are also posted here:
>
> https://dflund.se/~triad/krad/gemini/openwrt/
>
> It would be nice if we could apply this and get a working
> modernized base for the Gemini platforms.
>
> The v4.14 is a bit patchy. With v4.16 we will be looking
> pretty neat.
>
> Linus Walleij (4):
>   firmware-utils: Add the DNS-313 image header tool
>   gemini: Forward-port to v4.14
>   gemini: Add kernel v4.14 patches
>   gemini: Delete kernel 4.4 patches
>
>  target/linux/gemini/Makefile   |   15 +-
>  .../linux/gemini/base-files/etc/board.d/03_hdparm  |   14 +
>  .../base-files/lib/preinit/05_set_ether_mac_gemini |   25 +-
>  target/linux/gemini/config-4.14|  587 
>  target/linux/gemini/config-4.4 |  165 -
>  .../files/arch/arm/mach-gemini/include/mach/gmac.h |   21 -
>  .../linux/gemini/files/arch/arm/mach-gemini/pci.c  |  318 --
>  .../linux/gemini/files/drivers/ata/pata_gemini.c   |  234 --
>  .../files/drivers/net/ethernet/gemini/Kconfig  |   31 -
>  .../files/drivers/net/ethernet/gemini/Makefile |5 -
>  .../files/drivers/net/ethernet/gemini/sl351x.c | 2340 -
>  .../files/drivers/net/ethernet/gemini/sl351x_hw.h  | 1436 
>  .../gemini/files/drivers/usb/host/ehci-fotg2.c |  258 --
>  .../gemini/files/drivers/watchdog/gemini_wdt.c |  378 --
>  target/linux/gemini/image/Makefile |  166 +-
>  target/linux/gemini/image/dns313-header/Makefile   |   34 +
>  .../gemini/image/dns313-header/dns313-header.c |  239 ++
>  target/linux/gemini/image/slask.mk |   56 +
>  .../0001-cache-patch-from-OpenWRT.patch}   |9 +
>  ...0002-pinctrl-gemini-Add-missing-functions.patch |   33 +
>  ...ARM-dts-Add-TVE200-to-the-Gemini-SoC-DTSI.patch |   51 +
>  ...rl-Add-skew-delay-pin-config-and-bindings.patch |   73 +
>  ...0005-pinctrl-gemini-Use-generic-DT-parser.patch |  112 +
>  ...-gemini-Implement-clock-skew-delay-config.patch |  280 ++
>  .../0007-pinctrl-gemini-Fix-GMAC-groups.patch  |  186 +
>  ...nctrl-gemini-Fix-missing-pad-descriptions.patch |   27 +
>  ...inctrl-gemini-Add-two-missing-GPIO-groups.patch |   25 +
>  ...0-pinctrl-gemini-Fix-usage-of-3512-groups.patch |   25 +
>  ...trl-gemini-Support-drive-strength-setting.patch |  198 ++
>  ...d-ethernet-PHYs-to-the-a-bunch-of-Geminis.patch |  113 +
>  ...s-Add-basic-devicetree-for-D-Link-DNS-313.patch |  272 ++
>  ...RM-dts-Flags-D-Link-DIR-685-I2C-bus-gpios.patch |   27 +
>  ...0015-ARM-dts-Add-PCI-to-WBD111-and-WBD222.patch |   74 +
>  ...-Add-TVE-TVC-and-ILI9322-panel-to-DIR-685.patch |  113 +
>  ...tchdog-gemini-ftwdt010-rename-DT-bindings.patch |   88 +
>  ...gemini-ftwdt010-rename-driver-and-symbols.patch |  527 +++
>  ...watchdog-ftwdt010-Make-interrupt-optional.patch |   93 +
>  .../0020-soc-Add-SoC-driver-for-Gemini.patch   |  113 +
>  ...t-Add-DT-bindings-for-the-Gemini-ethernet.patch |  119 +
>  ...t-Add-a-driver-for-Gemini-gigabit-etherne.patch | 3661
> 
>  ...23-ARM-dts-Add-ethernet-to-the-Gemini-SoC.patch |   74 +
>  .../0024-net-gemini-Depend-on-HAS_IOMEM.patch  |   30 +
>  ...-dts-Set-D-Link-DNS-313-SATA-to-muxmode-0.patch |   36 +
>  ...r-gemini-poweroff-Avoid-spurious-poweroff.patch |   80 +
>  ...sb-host-add-DT-bindings-for-faraday-fotg2.patch |   65 +
>  ...28-usb-host-fotg2-add-device-tree-probing.patch |   61 +
>  ...usb-host-fotg2-add-silicon-clock-handling.patch |   99 +
>  ...b-host-fotg2-add-Gemini-specific-handling.patch |  131 +
>  ...RM-dts-Add-the-FOTG210-USB-host-to-Gemini.patch |  178 +
>  .../linux/gemini/patches-4.4/050-gpio-to-irq.patch |   21 -
>  .../110-watchdog-add-gemini_wdt-driver.patch   |   29 -
>  .../111-arm-gemini-add-watchdog-device.patch   |   33 -
>  .../112-arm-gemini-register-watchdog-devices.patch |   40 -
>  .../120-net-add-gemini-gmac-driver.patch   |   20 -
>  .../121-arm-gemini-add-gmac-device.patch   |   85 -
>  .../122-arm-gemini-register-ethernet.patch |  227 --
>  .../130-usb-ehci-add-fot2g-driver.patch|  133 -
>  .../131-arm-gemini-add-usb-device.patch|   77 -
>  .../patches-4.4/132-arm-gemini-register-usb.patch  |   65 -
>  .../140-arm-gemini-add-pci-support.patch   |   66 -
>  .../linux/gemini/patches-4.4/150-gemini-pata.patch |  192 -
>  target/linux/gemini/raidsonic/config-default   |5 -

Re: [OpenWrt-Devel] [openwrt-realtek] Is it possible to add support for rtl8676?

[Joel Wirāmu Pauling]

If it is supported by the Linux kernel the openwrt will work with it. You
may need to compile from source however if it's esoteric.



On 21 April 2017 at 14:57, Pavel Sayekat  wrote:

> Dear team,
> My device is a rtl8676 (may be it has become old :( ) and I like to use
> openwrt firmwire on it if its possible :).
>
> Thanks & Regards,
> Pavel Sayekat
> an rtl8676 user from Bangladesh.
>
> ___
> 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] Giveaway: Linksys WRT3200ACM units

[Joel Wirāmu Pauling]

I am in New Zealand, (also 5 eyes ;) and have not received one.

On 9 February 2017 at 12:04, Hartmut Knaack  wrote:

> Vincent Wiemann schrieb am 08.02.2017 um 22:29:
> > Hi everyone,
> >
> > has anyone received one of the units, yet?
>
> According to the forum, two guys from Canada, one guy from Australia and
> one guy from the UK already got their devices (all 5-eyes countries ;-).
>
> > I wonder how long it takes as my experience with TP-Link (who don't
> > really care about free software :D) is that they send their units with
> > UPS Express and it never took more than a week...
> >
> > On 17.01.2017 20:06, Hartmut Knaack wrote:
> >>
> >> OK, to answer my question: today we received an email from
> Belkin/Linksys,
> >> asking for a shipping address.
> >>
> >
> > Kind regards,
> > CodeFetch
> > ___
> > 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] General questions about the direction of switch drivers

[Joel Wirāmu Pauling]

I for one would love to see brctl and vconfig disappear completely in
favour of ovs-* based standard toolchain for all switch interaction.

Certainly in the Bigger iron area, and things like core and cumulus coupled
with SDN approaches and Openstack this is fast becoming defacto. I don't
see why with a bit of additional abstraction that ovs couldn't become the
default stack for mainline and certainly for OpenWRT it offers a lot more
versatility than the current brctl and vconfig tools.

I guess the biggest issue is getting ovs- offload to switch chipsets rather
than CPU bound softswitch. Maybe some sort of flag where unsupported
operations/modes which would end up being done on the CPU are
flagged/masked?

-Joel

On 16 February 2015 at 16:04, Michael Richardson m...@sandelman.ca wrote:


 First, there are a lot of discussions and papers at netdev01.org about the
 various hardware switch management systems.  I point specifically to a talk
 this morning:
  https://www.netdev01.org/sessions/19

 I have stumbed my toe on 3800 with trying to build tagged switch ports
 where
 I have a few ports with explicit VLAN tagging, joined together in the
 switch,
 and also exposed to the host.  I think it should work, but I mostly just
 wound
 up screwing up my CPU port.  I have some 3800 with serial consoles now so I
 should try this out.

 What would be ideal, and my impression is that this is where the industry
 wants to go, is that one would use brctl and vconfig to build the switch
 configuration that you want, and the drivers below would realize that the
 switch can do that work, and would program things correctly.

 openvswitch is about creating a virtual switch fabric in the CPU, which can
 spread elsewhere --- the trend is though, that this too would be subject to
 hardware offload.

 --
 ]   Never tell me the odds! | ipv6 mesh
 networks [
 ]   Michael Richardson, Sandelman Software Works| network
 architect  [
 ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
 rails[
 ___
 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