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

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

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

ke 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

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

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,

Re: [OpenWrt-Devel] Possible security issue

hroot, 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 expo

Re: [OpenWrt-Devel] Possible security issue

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

Re: [OpenWrt-Devel] [RFC] x86: use multiple profiles

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

Re: [OpenWrt-Devel] Configuration management for OpenWrt

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

Re: [OpenWrt-Devel] New target IPQ8074 / Asus-ax89x(u)

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 Qualcom

Re: [OpenWrt-Devel] New target IPQ8074 / Asus-ax89x(u)

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 th

Re: [OpenWrt-Devel] New target IPQ8074 / Asus-ax89x(u)

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

Re: [OpenWrt-Devel] New target IPQ8074 / Asus-ax89x(u)

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

[OpenWrt-Devel] New target IPQ8074 / Asus-ax89x(u)

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

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

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.

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

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

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

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

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

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

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

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 >

Re: [OpenWrt-Devel] Giveaway: Linksys WRT3200ACM units

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

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

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