configuration issue

configuration issue

[Oguzhan Kayhan]

Hello
I am running batman over a openwrt 18.06
default batman config over this firmware is batman-adv 2017.4

I have two systems present..
One board is with 802.11n radio. other is 802.11ac radio
This is the only difference..same image compiled running on both devices..


On 802.11n radio set..
config is as:
batman-adv:
config 'mesh' 'bat0'
        option 'aggregated_ogms'
        option 'ap_isolation'
        option 'bonding'
        option 'fragmentation'
        option 'gw_bandwidth'
        option 'gw_mode'
        option 'gw_sel_class'
        option 'log_level'
        option 'orig_interval'
        option 'vis_mode'
        option 'bridge_loop_avoidance'
        option 'distributed_arp_table'
        option 'multicast_mode'
        option 'network_coding'
        option 'hop_penalty'
        option 'isolation_mark'

wireless :
config wifi-iface
        option device 'radio0'
        option ifname 'mesh0'
        option network 'mesh'
        option mode 'adhoc'
        option ssid 'mesh'
        option bssid '02:CA:FE:CA:CA:40'
        option mcast_rate '18000'


network:
config interface 'lan'
        option type 'bridge'
        option ifname 'eth0 bat0'
        option proto 'static'
....
config interface 'mesh'
        option mtu '1532'
        option proto 'batadv'
        option mesh 'bat0'

config interface 'bat'
        option ifname 'bat0'
        option proto 'static'
        option mtu '1500'
        option ipaddr '172.0.0.10'
        option netmask '255.255.255.0'


This configuration works fine..
But if I run same config on the second node with 802.11ac radio.. it fails..
So I dig around and changed the config as follows.. And it started to work..
batman-adv is same..no difference

wireless:
config wifi-iface 'wmesh'
        option device 'radio0'
        option ifname 'adhoc0'
        option network 'bat0_hardif_wlan'
        option mode 'adhoc'
        option ssid 'mesh'
        option mcast_rate '18000'
        option bssid '02:CA:FE:CA:CA:40'

network:
config interface 'bat0_hardif_wlan'
        option mtu '1532'
        option proto 'batadv'
        option mesh 'bat0'

config interface 'bat0_hardif_eth0'
        option mtu '1532'
        option proto 'batadv'
        option mesh 'bat0'
        option ifname 'eth0'




I have two questions so far..

Why the first config does not work over second system..(Wifi works
fine but. for mesh. i needed to change the config like this)

Second question.. I can live with different config.. Ok..
But I want to use eth0 and eth2 and mesh network as a bridge...
But whenever i add any of this interfaces on bridge.. batman-adv fails..
What am I missing???

Re: configuration issue

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 3925 bytes --]

On Monday, 27 April 2020 14:26:40 CEST Oguzhan Kayhan wrote:
> Hello
> I am running batman over a openwrt 18.06
> default batman config over this firmware is batman-adv 2017.4

This is odd. 18.06 is using batman-adv 2018.1 (2018.1-11 at the moment). 
Sounds like something went wrong with your routing feed.


[...]
> config wifi-iface
>         option device 'radio0'
>         option ifname 'mesh0'
>         option network 'mesh'
>         option mode 'adhoc'
>         option ssid 'mesh'
>         option bssid '02:CA:FE:CA:CA:40'
>         option mcast_rate '18000'
[...]

Please think about switching to meshpoint without forwarding.

    config wifi-iface 'wmesh'
        option device 'radio0'
        option ifname 'mesh0'
        option network 'bat0_hardif_mesh0'
        option mode 'mesh'
        option mesh_id 'mesh'
        option mesh_fwding '0'
        option mesh_ttl '1'
        option 'mcast_rate' '18000'

At least in my experience, the IBSS support in the device firmware is either
not there or starting to rot.


> I have two systems present..
> One board is with 802.11n radio. other is 802.11ac radio
> This is the only difference..same image compiled running on both devices..
[...]
> This configuration works fine..
> But if I run same config on the second node with 802.11ac radio.. it fails..
> So I dig around and changed the config as follows.. And it started to work..
> batman-adv is same..no difference
[...]
> config interface 'bat0_hardif_eth0'
>         option mtu '1532'
>         option proto 'batadv'
>         option mesh 'bat0'
>         option ifname 'eth0'

Hum, where is the ethernet coming from? This is not used in the other 
configuration as slave interface for bat0. And it should also fail if you do 
something like this on the 11n device and don't use a separate interface
section in /etc/config/network for it.

Besides this, what is the change? I don't see one.

And if you just wanted to have eth0 as slave and the wlan interface as slave - 
then yes, you need two different interfaces with proto batadv (batadv_hardif 
in OpenWrt 19.07) in /etc/config/network. It is not possible to have multiple 
slave interfaces in /etc/config/network attached to a single master interface 
using a single (non-"bridge" type) interface section . This is a limitation
of netifd.

> I have two questions so far..
> 
> Why the first config does not work over second system..(Wifi works
> fine but. for mesh. i needed to change the config like this)
> 
> Second question.. I can live with different config.. Ok..
> But I want to use eth0 and eth2 and mesh network as a bridge...

"as a bridge"? Maybe you mean in a bridge? Should work right of the box with eth2:

    config interface 'bat0_hardif_wlan'
            option mtu '1532'
            option proto 'batadv'
            option mesh 'bat0'
    
    config interface 'bat0_hardif_eth0'
            option mtu '1532'
            option proto 'batadv'
            option mesh 'bat0'
            option ifname 'eth0'

    config interface 'lan'
            option type 'bridge'
            option ifname 'eth2 bat0'
            option proto 'static'


If you want to use eth0, eth2 and bat0 in a bridge then it would look like this:

    config interface 'bat0_hardif_wlan'
            option mtu '1532'
            option proto 'batadv'
            option mesh 'bat0'

    config interface 'lan'
            option type 'bridge'
            option ifname 'eth0 eth2 bat0'
            option proto 'static'

> But whenever i add any of this interfaces on bridge.. batman-adv fails..
> What am I missing???

A device just cannot be in a bridge and in batadv at the same time. Just not 
possible because the bridge would steal all the ethernet packets before 
batman-adv would receive them. So it is not even allowed to have two masters 
(batadv interface and a bridge) for a single interface (wlan0, eth0, ...).

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: configuration issue

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 5001 bytes --]

On Monday, 27 April 2020 18:35:29 CEST Oguzhan Kayhan wrote:
[...]
> *I 'm running Gateworks Newport as controller board. And updated from their
> repository Thats the version they had..Actually I tried updating the feeds
> to the latest version but, It threw error on compiling..So , didnt waste
> too much time and stick on the 2017.4 version.But if needed, I will try to
> update versions also.*

Please write them and ask them to adjust their repositories to actually ship 
OpenWrt 18.06 with the up-to-date feeds. We don't support 2017.4 anymore and 
will not provide patch backports for 2017.4-0 from openwrt-routing. But we
have a lot of stable backport patches in 2018.1-11. And 2018.1-11 build likes 
a charm when the main OpenWrt repository is actually an 18.06.

And to me, it looks like Gateworks 18.0x is not even based on OpenWrt 18.06 
but on something which was forked 7 months (1287 commits) before the release 
of 18.06.0 - and we are currently at OpenWrt 18.06.8 on the old stable branch 
and 19.07.2 on the current stable branch.

You don't even have the "newest" (up to 28 month old) security fixes in 
gateworks 18.0x - and there are quite at some security and stability patches 
which you should get integrated.

> > [...]
> > > config wifi-iface
> > >         option device 'radio0'
> > >         option ifname 'mesh0'
> > >         option network 'mesh'
> > >         option mode 'adhoc'
> > >         option ssid 'mesh'
> > >         option bssid '02:CA:FE:CA:CA:40'
> > >         option mcast_rate '18000'
> > [...]
> >
> > Please think about switching to meshpoint without forwarding.
> 
> 
> *I'd be glad if you give more detail what you mean.*

The example configuration was given below. What more details do you need? You 
already noticed yourself that it doesn't support IBSS/adhoc.

> 
> >
> >     config wifi-iface 'wmesh'
> >         option device 'radio0'
> >         option ifname 'mesh0'
> >         option network 'bat0_hardif_mesh0'
> >         option mode 'mesh'
> >         option mesh_id 'mesh'
> >         option mesh_fwding '0'
> >         option mesh_ttl '1'
> >         option 'mcast_rate' '18000'
> >
> > At least in my experience, the IBSS support in the device firmware is
> either
> > not there or starting to rot.
> >
> 
> 
> 
> *That might be the problem.On 802.11ac card, iw phy gives supported
> interface modes as;managed, AP, AP/VLAN,monitor, Meshpoint      but 802.11n
> gives IBSS,managed, AP, AP/VLAN,monitor, Meshpoint, p2p-client, p2p-go
> modes..*
> *So.. does it shows 802.11ac doesnt support batman?

Hu? batman-adv is not IBSS. It can run on all kind of interface types. But it 
makes more sense to run it on meshpoint without forwarding (mesh_fwding 0) or 
IBSS/adhoc.

> or is there any other
> ways to try besides ad-hoc mode? Both cards are DoodleLabs*

Use a meshpoint interface without forwarding. As shown in the example 
configuration in my first mail.


[...]
> > A device just cannot be in a bridge and in batadv at the same time. Just
> not
> > possible because the bridge would steal all the ethernet packets before
> > batman-adv would receive them. So it is not even allowed to have two
> masters
> > (batadv interface and a bridge) for a single interface (wlan0, eth0, ...).
> >
> 
> *So, what is the correct way to do that then..*
> *Any examples for this scenario?*

Don't try to add the ethernet in both bridge and batman-adv as slave. Doesn't 
work - so I cannot give you an example.

If you want to still transport stuff over ethernet which is also used to 
bridge to some other interface, try macvlan or vlan's on top of the ethernet 
interface. The macvlan will create a new ethernet interface which just uses a 
different mac address. A vlan interface on top of the ethernet will just but a 
vlan header between the ethernet header and the next layer. So I am guessing 
you want to first try macvlan (requires kmod-macvlan):

    config interface 'bat0_hardif_wlan'
            option mtu '1532'
            option proto 'batadv'
            option mesh 'bat0'

    config interface 'lan'
            option type 'bridge'
            option ifname 'eth2 eth0 bat0'
            option proto 'static'

    config device 'veth0'
            option name 'veth0'
            option type 'macvlan'
            option ifname 'eth0'

    config interface 'bat0_hardif_eth0'
            option mtu '1532'
            option proto 'batadv'
            option mesh 'bat0'
            option ifname 'veth0'

Or if it is no problem to use VLANs (here 123):

    config interface 'bat0_hardif_wlan'
            option mtu '1532'
            option proto 'batadv'
            option mesh 'bat0'

    config interface 'lan'
            option type 'bridge'
            option ifname 'eth2 eth0 bat0'
            option proto 'static'

    config interface 'bat0_hardif_eth0'
            option mtu '1532'
            option proto 'batadv'
            option mesh 'bat0'
            option ifname 'eth0.123'

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: configuration issue

[Oguzhan Kayhan]

Hello
Yes, changing to 80211s mode seems to work.

Now my config is as follows on both wifi nodes

wireless:
config wifi-iface 'wmesh'
        option device 'radio0'
        option ifname 'mesh0'
        option mode 'mesh'
        option mesh_id 'test'
        option mesh_fwding '0'
        option mesh_ttl '1'
        option mcast_rate '18000'
        option encryption 'none'

network:

config interface 'eth1'
        option ifname 'eth1'
        option proto 'static'
        option mtu '1500'
        option ipaddr '10.1.200.7'
        option netmask '255.255.255.0'
        option gateway '10.1.200.1'

config interface 'bat0_hardif_wlan'
            option mtu '1532'
            option proto 'batadv'
            option mesh 'bat0'

config interface 'bat0_hardif_eth0'
        option mtu '1532'
        option proto 'batadv'
        option mesh 'bat0'
        option ifname 'mesh0'

config interface 'lan'
            option type 'bridge'
            option ifname 'eth2 eth0 bat0'
            option proto 'static'




Now here comes the second part..
How can I make the encryption over mesh?

with ad-hoc there were wpa-2psk encryption on luci interface..
But with 80211s, there is no encryption available on luci, and also
wireless connection can not be establisehd if i manaully write any psk
etc on wifi settings.

Is there a walkthru for this specially for openwrt?

Regards


On Mon, Apr 27, 2020 at 9:18 PM Oguzhan Kayhan <oguzhan@kayhan.name.tr> wrote:
>
> That helps a lot Sven..
> I notified gateworks about it..
> And also I will try the examples you provided.
>
> Best Regards
>
>
>
> On Mon, Apr 27, 2020 at 8:19 PM Sven Eckelmann <sven@narfation.org> wrote:
>>
>> On Monday, 27 April 2020 18:35:29 CEST Oguzhan Kayhan wrote:
>> [...]
>> > *I 'm running Gateworks Newport as controller board. And updated from their
>> > repository Thats the version they had..Actually I tried updating the feeds
>> > to the latest version but, It threw error on compiling..So , didnt waste
>> > too much time and stick on the 2017.4 version.But if needed, I will try to
>> > update versions also.*
>>
>> Please write them and ask them to adjust their repositories to actually ship
>> OpenWrt 18.06 with the up-to-date feeds. We don't support 2017.4 anymore and
>> will not provide patch backports for 2017.4-0 from openwrt-routing. But we
>> have a lot of stable backport patches in 2018.1-11. And 2018.1-11 build likes
>> a charm when the main OpenWrt repository is actually an 18.06.
>>
>> And to me, it looks like Gateworks 18.0x is not even based on OpenWrt 18.06
>> but on something which was forked 7 months (1287 commits) before the release
>> of 18.06.0 - and we are currently at OpenWrt 18.06.8 on the old stable branch
>> and 19.07.2 on the current stable branch.
>>
>> You don't even have the "newest" (up to 28 month old) security fixes in
>> gateworks 18.0x - and there are quite at some security and stability patches
>> which you should get integrated.
>>
>> > > [...]
>> > > > config wifi-iface
>> > > >         option device 'radio0'
>> > > >         option ifname 'mesh0'
>> > > >         option network 'mesh'
>> > > >         option mode 'adhoc'
>> > > >         option ssid 'mesh'
>> > > >         option bssid '02:CA:FE:CA:CA:40'
>> > > >         option mcast_rate '18000'
>> > > [...]
>> > >
>> > > Please think about switching to meshpoint without forwarding.
>> >
>> >
>> > *I'd be glad if you give more detail what you mean.*
>>
>> The example configuration was given below. What more details do you need? You
>> already noticed yourself that it doesn't support IBSS/adhoc.
>>
>> >
>> > >
>> > >     config wifi-iface 'wmesh'
>> > >         option device 'radio0'
>> > >         option ifname 'mesh0'
>> > >         option network 'bat0_hardif_mesh0'
>> > >         option mode 'mesh'
>> > >         option mesh_id 'mesh'
>> > >         option mesh_fwding '0'
>> > >         option mesh_ttl '1'
>> > >         option 'mcast_rate' '18000'
>> > >
>> > > At least in my experience, the IBSS support in the device firmware is
>> > either
>> > > not there or starting to rot.
>> > >
>> >
>> >
>> >
>> > *That might be the problem.On 802.11ac card, iw phy gives supported
>> > interface modes as;managed, AP, AP/VLAN,monitor, Meshpoint      but 802.11n
>> > gives IBSS,managed, AP, AP/VLAN,monitor, Meshpoint, p2p-client, p2p-go
>> > modes..*
>> > *So.. does it shows 802.11ac doesnt support batman?
>>
>> Hu? batman-adv is not IBSS. It can run on all kind of interface types. But it
>> makes more sense to run it on meshpoint without forwarding (mesh_fwding 0) or
>> IBSS/adhoc.
>>
>> > or is there any other
>> > ways to try besides ad-hoc mode? Both cards are DoodleLabs*
>>
>> Use a meshpoint interface without forwarding. As shown in the example
>> configuration in my first mail.
>>
>>
>> [...]
>> > > A device just cannot be in a bridge and in batadv at the same time. Just
>> > not
>> > > possible because the bridge would steal all the ethernet packets before
>> > > batman-adv would receive them. So it is not even allowed to have two
>> > masters
>> > > (batadv interface and a bridge) for a single interface (wlan0, eth0, ...).
>> > >
>> >
>> > *So, what is the correct way to do that then..*
>> > *Any examples for this scenario?*
>>
>> Don't try to add the ethernet in both bridge and batman-adv as slave. Doesn't
>> work - so I cannot give you an example.
>>
>> If you want to still transport stuff over ethernet which is also used to
>> bridge to some other interface, try macvlan or vlan's on top of the ethernet
>> interface. The macvlan will create a new ethernet interface which just uses a
>> different mac address. A vlan interface on top of the ethernet will just but a
>> vlan header between the ethernet header and the next layer. So I am guessing
>> you want to first try macvlan (requires kmod-macvlan):
>>
>>     config interface 'bat0_hardif_wlan'
>>             option mtu '1532'
>>             option proto 'batadv'
>>             option mesh 'bat0'
>>
>>     config interface 'lan'
>>             option type 'bridge'
>>             option ifname 'eth2 eth0 bat0'
>>             option proto 'static'
>>
>>     config device 'veth0'
>>             option name 'veth0'
>>             option type 'macvlan'
>>             option ifname 'eth0'
>>
>>     config interface 'bat0_hardif_eth0'
>>             option mtu '1532'
>>             option proto 'batadv'
>>             option mesh 'bat0'
>>             option ifname 'veth0'
>>
>> Or if it is no problem to use VLANs (here 123):
>>
>>     config interface 'bat0_hardif_wlan'
>>             option mtu '1532'
>>             option proto 'batadv'
>>             option mesh 'bat0'
>>
>>     config interface 'lan'
>>             option type 'bridge'
>>             option ifname 'eth2 eth0 bat0'
>>             option proto 'static'
>>
>>     config interface 'bat0_hardif_eth0'
>>             option mtu '1532'
>>             option proto 'batadv'
>>             option mesh 'bat0'
>>             option ifname 'eth0.123'
>>
>> Kind regards,
>>         Sven

Re: configuration issue

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 2556 bytes --]

On Tuesday, 28 April 2020 11:28:25 CEST Oguzhan Kayhan wrote:
[...]
> Now my config is as follows on both wifi nodes
> 
> wireless:
> config wifi-iface 'wmesh'
>         option device 'radio0'
>         option ifname 'mesh0'
>         option mode 'mesh'
>         option mesh_id 'test'
>         option mesh_fwding '0'
>         option mesh_ttl '1'
>         option mcast_rate '18000'
>         option encryption 'none'
[...]
> Now here comes the second part..
> How can I make the encryption over mesh?

This is not an Gateworks OpenWrt 18.x support mailing list btw.
And the OpenWrt documentation [1,2] explains how to do this.

Anyway, you can enable it on OpenWrt by selecting wpad-mesh-openssl (or
wpad-mesh on older OpenWrt versions). and then using something like:

    config wifi-iface 'wmesh'
         option device 'radio0'
         option ifname 'mesh0'
         option mode 'mesh'
         option mesh_id 'test'
         option mesh_fwding '0'
         option mesh_ttl '1'
         option mcast_rate '18000'
         option encryption 'psk2+ccmp'
         option key 'thisisaverysecretkey'

But as said earlier, the gateworks OpenWrt 18.x is in rather bad shape. So 
expect that there are a lot of important fixes [3,4,5,6,7,8,9,10,11,12,13,..]
missing.

Kind regards,
	Sven


[1] https://openwrt.org/docs/guide-user/network/wifi/mesh/batman
[2] https://openwrt.org/docs/guide-user/network/wifi/mesh/80211s
[3] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=166741240afd396c41b284edaa5180b162232741
[4] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=8f24653184536e1f8259bb43cffdae5673fb593a
[5] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=eba3b028e46dbfe54f1208e9edf47bb0c6f73ac8
[6] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ff8df2b3f9c161edc3ab543bdbeb04a9fb45c959
[7] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=a4322eba2b129adde45e3f7ac6c3805889623dd5
[8] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=3a456683e5da7ed3a26ffb71e1dbbf1d1db0d036
[9] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=6e0fa4a76db667d7f0c1d84a3af5017df26d3fad
[10] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=574e4377fad5137595dea8a281061a3c945187c2
[11] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=547042398afac3ce702adab28c753e7c9ebed452
[12] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ba5ec6b77c94a21bbd78b66c63317a4ff9b62962
[13] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=96f4792fdb036ecf5c8417fce6503412b0b27e5f

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: configuration issue

[Oguzhan Kayhan]

Hello Sven ,
I really appreciate your kind help.
Yes I am sadly aware of the version problem of Gateworks and I already
notified them about an update on repo

It failed when I add
 option encryption 'psk2'
 option key 'thisisaverysecretkey'

but it was working with adhoc.. I will seach for if any needed package
is missing or not.

Regards


On Tue, Apr 28, 2020 at 12:51 PM Sven Eckelmann <sven@narfation.org> wrote:
>
> On Tuesday, 28 April 2020 11:28:25 CEST Oguzhan Kayhan wrote:
> [...]
> > Now my config is as follows on both wifi nodes
> >
> > wireless:
> > config wifi-iface 'wmesh'
> >         option device 'radio0'
> >         option ifname 'mesh0'
> >         option mode 'mesh'
> >         option mesh_id 'test'
> >         option mesh_fwding '0'
> >         option mesh_ttl '1'
> >         option mcast_rate '18000'
> >         option encryption 'none'
> [...]
> > Now here comes the second part..
> > How can I make the encryption over mesh?
>
> This is not an Gateworks OpenWrt 18.x support mailing list btw.
> And the OpenWrt documentation [1,2] explains how to do this.
>
> Anyway, you can enable it on OpenWrt by selecting wpad-mesh-openssl (or
> wpad-mesh on older OpenWrt versions). and then using something like:
>
>     config wifi-iface 'wmesh'
>          option device 'radio0'
>          option ifname 'mesh0'
>          option mode 'mesh'
>          option mesh_id 'test'
>          option mesh_fwding '0'
>          option mesh_ttl '1'
>          option mcast_rate '18000'
>          option encryption 'psk2+ccmp'
>          option key 'thisisaverysecretkey'
>
> But as said earlier, the gateworks OpenWrt 18.x is in rather bad shape. So
> expect that there are a lot of important fixes [3,4,5,6,7,8,9,10,11,12,13,..]
> missing.
>
> Kind regards,
>         Sven
>
>
> [1] https://openwrt.org/docs/guide-user/network/wifi/mesh/batman
> [2] https://openwrt.org/docs/guide-user/network/wifi/mesh/80211s
> [3] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=166741240afd396c41b284edaa5180b162232741
> [4] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=8f24653184536e1f8259bb43cffdae5673fb593a
> [5] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=eba3b028e46dbfe54f1208e9edf47bb0c6f73ac8
> [6] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ff8df2b3f9c161edc3ab543bdbeb04a9fb45c959
> [7] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=a4322eba2b129adde45e3f7ac6c3805889623dd5
> [8] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=3a456683e5da7ed3a26ffb71e1dbbf1d1db0d036
> [9] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=6e0fa4a76db667d7f0c1d84a3af5017df26d3fad
> [10] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=574e4377fad5137595dea8a281061a3c945187c2
> [11] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=547042398afac3ce702adab28c753e7c9ebed452
> [12] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ba5ec6b77c94a21bbd78b66c63317a4ff9b62962
> [13] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=96f4792fdb036ecf5c8417fce6503412b0b27e5f

Re: configuration issue

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

On Tuesday, 28 April 2020 12:36:53 CEST Oguzhan Kayhan wrote:
[...]
> It failed when I add
>  option encryption 'psk2'
>  option key 'thisisaverysecretkey'

Just in case you didn't read in in my previous mail: Make sure that you have 
wpad-mesh(-openssl) installed and check if there is any relevant patch missing 
which prevents wpad-mesh to start up correctly. And no, wpad-full is not good 
enough - it is missing SAE and mesh support.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]