Apply the patches to openwrt

19 posts / 0 new

Thu, 08/01/2019 - 04:32

ik6fjn

Is it possible to apply your patches to openwrt standard? If yes how can I proceed?
I would like to use the standard openwrt gui

Thanks .... Franco ik6fjn

Sun, 08/04/2019 - 14:54

AE6XE

The openwrt LUCI UI interface

The openwrt LUCI UI interface is unaware of the mesh standard configuration built into the AREDN UI. While you could install the LUCI interface on top of the AREDN firmware, and use the UI to make changes, it then means you are making raw changes to the configuration and risks:

1) keeping the node compatible with other AREDN nodes.
2) breaking AREDN basic functionality, dependent settings go out of sync.
3) the LUCI interface does not know how to save and keep settings persistent across AREDN firmware upgrades or AREDN UI 'save'.
4) not going to fit on 8Mb flash devices
5) not enough memory to run on 32Mb devices with all the other packages installed with AREDN.

This might be a fun bench test to experiment with, but problematic to join such a node to a greater AREDN mesh.

Joe AE6XE

Wed, 08/07/2019 - 14:03

ik6fjn

Thank you for answering.

Thank you for answering.

I would like to apply your patch on Openwrt and then experiment with the 802.11s protocol which, having a routing protocol at the mac address level, is lighter than olsr.
In this way it would be possible to realize radios even with reduced memory.
Moreover the 802.11s mesh mode is also present on ac devices ... While the ad-hoc mode is not supported by the ac drivers.
If possible I would like a concrete example of how to apply the patches
701-extended-spectrum.patch and 702-enable-country-hx.patch

Franco IK6FJN

Wed, 08/07/2019 - 15:02

(Reply to #3) #4

AE6XE

Franco,

Franco,

You'll need the openwrt source code to start. At the top level of the openwrt source directory structure, a patch is applied:

cat <the openwrt patch file> | patch -p1

ath10k-ct driver in use by OpenWrt does support 802.11ac adhoc mode. There is recent activity working defects in adhoc mode. It's a question if it is ready for prime time or not.

Please post your results with 802.11s. Would be very interested.

Joe AE6XE

Thu, 08/08/2019 - 04:37

(Reply to #4) #5

ik6fjn

Test tp-link 801

Here are some 802.11s screenshots on tp-link with little memory ........
Test performed with 20 mhz of band...

Image Attachments:

Support File Attachments:

Configuration example

Thu, 08/08/2019 - 10:11

(Reply to #5) #6

AE6XE

Franco, this is very

Franco, this is very interesting. I'll have to do some homework to better understand how mesh compares to adhoc mode for the MAC level. Would we expect any performance improvements? If I understand correctly, there would still need to be an olsr or batman at the IP layer 3 if the traffic needs to route beyond the wireless interface, e.g. to another device-band. Conceptually, doesn't seem to be any difference in mesh and adhoc mode -- both do multi-point-to-point with all the stations on the channel at layer 2?

I should have qualified before, the part 97 patches will only work against the 802.11a/b/g/n ath9k driver. There is a note on the wireless site for the 802.11ac ath10k driver, that applying the same regulatory hack needs additional changes -- will crash at present. This is an open issue to get ath10k working with part 97 extended channels. Also, there's no support for 5 and 10MHz channels in ath10k to date.

Joe AE6XE

Thu, 08/08/2019 - 12:32

(Reply to #6) #7

ik6fjn

Hybrid Wireless Mesh Protocol

The 802.11s protocol contains HWMP within it
Which enabled with option mesh_fwding '1' allows multi hop.
Here is the wireless file what it contains:

config wifi-device 'radio0'

option type 'mac80211'

option hwmode '11g'

option path 'pci0000:00/0000:00:00.0'

option country 'IT'

option legacy_rates '1'

option distance 'auto'

option channel '11'

option htmode 'HT20'

config wifi-iface 'default_radio0'

option device 'radio0'

option network 'lan'

option encryption 'none'

option mode 'mesh'

option mesh_id 'Leonardo'

option mesh_fwding '1'

In principle we could do without olsr or batman ......
You can still use olsr or batman by disabling
option mesh_fwding '0'

Franco IK6FJN

Mon, 08/12/2019 - 10:44

ik6fjn

COMPILATION OF PATCH

@Joe AE6XE.

Hi these days I tried to compile these three patches on openwrt:
701-extended-spectrum.patch
702-enable-country-hx.patch
712-auto-distance-settings.patch
Obviously not being an expert I tried to follow the guide that from openwrt regarding quilting and patching but without result.
Can you give me some tips?

Thank you ......
Franco IK6FJN

Mon, 08/12/2019 - 11:09

(Reply to #8) #9

AE6XE

Franco,

Franco,

Before building the openwrt images per the standard instructions, from the top level directory of openwrt, type this command for each of the patch files:

cat <patch file> | patch -p1

This applies these patches to the openwrt code base and branch currently checked out. These patches work on top of openwrt v18.06.2. Checkout this version to guarantee they apply and work -- same as AREDN images. We've built on top of v19.07 branch, but limited testing.

Note, the auto-distance patch is not a full solution--won't fully work with just this code. You would have to write a shell script to detect when a new neighbor has connected on wireless. When this occurs, the auto distance setting needs to be flipped to static and back to auto, so that the driver starts over to figure out which neighbor is the farthest out. This was a hack to substitute as the original code relied on the encryption packets from wpa-supplicant to find a new neighbor. Since ham radio doesn't run this process or encryption, we needed another approach.

Joe AE6XE

Tue, 08/13/2019 - 08:23

(Reply to #9) #10

ik6fjn

COMPILATION OF PATCH

Hi ... It finally worked.
Here are some photos of the result:
git clone https://github.com/openwrt/openwrt.git
cd openwrt
git checkout v18.06.2
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig
cat 701-extended-spectrum.patch | patch -p1
cat 702-enable-country-hx.patch | patch -p1
make -j8 V=s
Thanks Joe

Image Attachments:

Mon, 08/12/2019 - 16:26

#11

K5DLQ

Franco, I would STRONGLY

Franco, I would STRONGLY advise staying on the AREDN branch code because there can be lots of these types of 'gotchas' when trying to re-create it from stratch. Instead, just add to the AREDN branch to try and accomplish what you are after, even if that is installing the LUCI UI interface in addition to the AREDN "perl/lua" based UI.... We review any/all pull requests that are submitted to the project. By going this route, other people may be interested in the changes/features/etc that you may come up with.

Just a suggestion.

BTW, I love the preliminary data on the 802.11s protocol/spec!

Tue, 08/13/2019 - 08:29

(Reply to #11) #12

ik6fjn

AREDN

@ K5DLQ

Hi, it would be the best thing.
I would like to add the ubiquiti loco ac and the litebeam ac 16db 120 ° I have 4 new ones to do tests with us.

Tue, 08/13/2019 - 09:59

(Reply to #12) #13

K5DLQ

yes. The AC wireless driver

yes. The AC wireless driver "ath10k" is on our list to develop/migrate so that it can be used with part 97 channels. Do you have experience with linux driver development? If so, that would be fantastic if you are interested in helping the project! Let us know.

Tue, 08/13/2019 - 11:11

(Reply to #13) #14

ik6fjn

ubiquiti ac loco litebeam ac

Unfortunately I am not a programmer but I am delighted with compilations and it should not be difficult to do it because with openwrt it is possible to compile these devices. A new AREDN branch should be created with an updated version of openwrt.
With the 802.11s protocol there is a parameter to prevent a weak signal from connecting.
Actually it connects but routing will not pass.
In my opinion, this function should also be used with a script that checks the signals every minute and then stops the routing at the station too weak with a command.

Image Attachments:

Tue, 08/13/2019 - 20:32

(Reply to #14) #15

AE6XE

It would be good to

It would be good to understand if 802.11s adds improved routing decisions over 802.11n adhoc with layer 3 routing. 802.11s is still using a great deal of 802.11n (mcs rates, csma, and more). OLSR (and presumably BATMAN, etc.) at layer 3 also will take out a weak signal link as the hello packets measuring link quality drop below a set threshold. It would be interesting to compare how 802.11s measures the quality, e.g. SNR only, packet loss, other? Then compare to the layer 3 routing protocols to see if there is an advantage ether way. OLSR has a plug-in for the 802.11n ath9k driver that feeds the link metrics into the decision process. This is a straight forward option for AREDN to jump to and improve the routing decisions. The question is if 802.11s has any different or more information to add into the routing decisions. Given OLSR has direct access to all metrics in the ath9k RF link with this plug-in, I'd speculate 802.11s is directly comparable, but not better than 802.11n adhoc w/ OLSR.

Joe AE6XE

Thu, 08/15/2019 - 12:43

(Reply to #15) #16

ik6fjn

@Joe AE6XE

Hi Joe, perhaps the only interesting thing in my opinion is that the 802.11s protocol integrates a HWMP Hybrid Wireless Mesh Protocol and is based on AODV Distance On-Demand Distance Vector.
This certainly could make the antennas lighter.

A question ......... Is it possible to get a version of AREDN for i386 32 bit and 64 bit?
If possible I would like to compile a version for i386 to test various USB and PCI wireless devices.

Franco IK6FJN

Thu, 08/15/2019 - 14:32

#17

AE6XE

Take a look at this page:

Take a look at this page: https://openwrt.org/docs/guide-user/network/wifi/mesh/batman

There is a close relationship with BATMAN (an alternative to OLSR) and 802.11s. Specifically, see the batman-adv which is a layer 2 mesh protocol that overlaps with 802.11s somehow -- I've not researched this, but as the BATMAN name suggests, "Better Approach To Mobile Adhoc Networking". This combination is advertised as being better than OLSRv1 at the time it was being created. However, leap frogging may apply, as there is OLSRv2 now.

AREDN images for i386 aren't currently being built. This is equivalent to adding new models to the supported list.

Joe AE6XE

Mon, 03/13/2023 - 18:07

#18

KM6SLF

Joe, is there a place where I

Joe, is there a place where I can monitor progress on ath10k migration? Or do you know if it's finished already?

Mon, 03/13/2023 - 18:38

(Reply to #18) #19

AE6XE

Ath10k is in the snapshot or

Ath10k is in the snapshot or nightly builds already.

Amateur Radio Emergency Data Network

Menu SF

You are here

Apply the patches to openwrt

Amateur Radio Emergency Data Network

Search form

Menu SF

You are here

Apply the patches to openwrt