GithubHelp home page GithubHelp logo

nqminds / edgesec Goto Github PK

View Code? Open in Web Editor NEW
5.0 4.0 1.0 29.25 MB

Secure router - reference implementation

Home Page: https://edgesec.info

License: MIT License

CMake 6.90% C 91.79% Shell 1.13% Makefile 0.18%
iot wifi ap security subnets radius hostapd cmake dnsmasq gateway

edgesec's People

Contributors

aloisklink avatar dependabot[bot] avatar mcr avatar mereacre avatar nallott avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

Forkers

mcr

edgesec's Issues

Failing CI builds due to automake version mismatch

Describe the bug

GitHub Actions CI occasionally fails with:

configure.ac:13: error: version mismatch.  This is Automake 1.16.1,
configure.ac:13: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:13: comes from Automake 1.16.5.  You should recreate
configure.ac:13: aclocal.m4 with aclocal and run automake again.
configure.ac:13: warning: user variable 'ETAGS' defined here ...

The issue seems to be with GitHub Actions runners, some of their runners seem to be using an older automake version. Restarting the CI action usually means that the CI job will be rerun on a working runner.

grpc automatic tests

If grpc is integrating into the edgesec cmake system it also integrates the test. So, when running make test it also runs the grpc tests, which take a long time to run.

Enable `codespell` to automatically check for spelling mistakes

Is your feature request related to a problem? Please describe.

We're occasionally making typos in the edgesec documentation. Having an automated spellchecker would help fix this.

Discussed in #504 (comment)

Describe the solution you'd like

It may be worth enabling something like codespell. It easily integrates with `pre-commit, so it should be pretty easy to run. The only issue is fixing all the false positives.

Describe alternatives you've considered

cspell is pretty popular in the Node.JS eco-system. However, because it requires Node.JS (which is pretty massive), it's not a great fit for our project.

codespell uses Python, which is already something we need, due to our dependency on pre-commit.

Additional context

It may not be worth enabling, as it may cause a bunch of false positives. Another thing that might help is enabling Doxygen warnings, since I'm sure that some of our docs might not be rendering properly.

dockerfile

Create/move dockerfile for crosscompile at root of repo.

Enable GitHub PR Merge Queues for this project.

Is your feature request related to a problem? Please describe.

The edgesec GitHub repo enforces that all PRs must be up-to-date when merging a PR. However, this makes merging multiple PRs in succession quite tedious, as we need to manually update each PR, wait for CI to pass, then merge them.

Describe the solution you'd like

On 2023-02-08, GitHub announced that the PR Merge Queue beta is now public for any open-source repo to join, see https://github.blog/changelog/2023-02-08-pull-request-merge-queue-public-beta/

image

Basically, when we do try to merge, it will automatically try multiple PRs at once, so it should speed up merging by quite a bit. If a PR has a failed required check, it should automatically be pulled from the queue.

Describe alternatives you've considered

N/A

Additional context

We'd probably also want to make a bunch more CI checks required, e.g. pretty-much everything except the code-coverage and Code scanning results / CodeQL should be required IMO.

Any thoughts?

Wifi Dongle support: TL-WN823N

This is: https://www.amazon.ca/gp/product/B0088TKTY2

It uses driver: https://github.com/Mange/rtl8192eu-linux-driver

Bus 001 Device 007: ID 2357:0109 TP-Link TL-WN823N v2/v3 [Realtek RTL8192EU]

wlx6c5ab04ac3a5: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 6c:5a:b0:4a:c3:a5  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

but it does not support VLAN:

2022-01-14 22:00:02.966  TRACE iw.c:199: phy1 -> P2P-GO
2022-01-14 22:00:02.966  TRACE iw.c:377: WiFi interface wlx6c5ab04ac3a5 doesn't suport vlan tagging
2022-01-14 22:00:02.966  DEBUG engine.c:338: interface wlx6c5ab04ac3a5 not VLAN capable

src/ap/ap_service.c code-coverage is inconsistent

Describe the bug

Code-coverage for the src/ap/ap_service.c file is inconsistent.

For example, see #391 (comment).
This PR doesn't change anything with our code, but somehow src/ap/ap_service.c had a code-coverage change. This is consistently happening with our PRs, which is a bit annoying, since we sometimes get a false-positive โŒ saying that the codecoverage got worse, but it turns out it's just src/ap/ap_service.c

Expected behavior

src/ap/ap_service.c always returns the same code-coverage.

Additional context

My gut feeling is that this means that there may be some sort of race-condition in https://github.com/nqminds/edgesec/blob/main/tests/ap/test_ap_service.c

However, Code coverage does have a guide on what to look into for Unexpected Coverage Changes

I checked the output of https://app.codecov.io/gh/nqminds/edgesec/commit/2fbaccfb91aebca7879676ce3744f81587372825 and https://app.codecov.io/gh/nqminds/edgesec/commit/072e3d8bca338ac5d834bd180bd2690dcf5d5e97 and it looks like the following lines are different:

--- 072e3d8bca338ac5d834bd180bd2690dcf5d5e97-code-cov	2023-01-27 12:30:08.577755316 +0000
+++ 2fbaccfb91aebca7879676ce3744f81587372825-code-cov	2023-01-27 12:30:29.421877663 +0000
@@ -8,20 +8,20 @@
 FN:168,find_ap_status
 FN:207,ap_sock_handler
 FN:248,register_ap_event
 FN:275,run_ap
 FN:316,close_ap
-FNDA:6,disconnect_ap_command
 FNDA:17,run_ap
-FNDA:6,check_sta_ap_command
 FNDA:12,denyacl_del_ap_command
-FNDA:17,close_ap
-FNDA:17,ping_ap_command
+FNDA:6,disconnect_ap_command
+FNDA:6,check_sta_ap_command
 FNDA:24,denyacl_ap_command
-FNDA:0,find_ap_status
 FNDA:17,register_ap_event
+FNDA:17,close_ap
+FNDA:0,find_ap_status
 FNDA:0,ap_sock_handler
+FNDA:17,ping_ap_command
 FNDA:12,denyacl_add_ap_command
 FNF:11
 FNH:9
 DA:34,17
 DA:35,17

They both seem to be calling the same functions to me, just in a different order, but I don't really know enough about the GCC code-coverage format to be sure.

capsrv filter error

When starting capsrv from edgesec with a non empty filter, the capture deosn't capture any packets.

General Repo Improvements

  • Simplify CMake build options
    • Ideally we should have an option called "BUILD_TARGET" that we can put in raspbian/openwrt/ubuntu, and it will automatically set every other option automatically.
    • cmake --preset linux option added in #126
  • Split CMake project up into
  • Compile dependencies during compile step (cmake --build)
    • Currently, we compile dependencies during the configure step (cmake),
      which isn't great, since we don't have a lot of control there.
    • Done in:
  • Move GRPC dependency only into EDGESec Servers
    • Currently sync_client.cc still relies on GRPC, so it should be refactored out.
    • Removed. In the future, GRPC will be written in Rust in the nqminds/d3engine repo
  • Docs refactor
  • Replace log_trace() to log errors with a new function called log_error()
    log_err() right now is only used for system errors, as it looks at errno.
  • Change libpcap compilation so that it never uses netlink
    May be fixed by #110

`os_get_reltime` returns actual time, not relative time

Describe the bug

The current implementation of os_get_reltime returns the actual time, instead of the relative time.

To Reproduce

  1. Call os_get_reltime().
  2. Change the date/time on your PC (e.g. using leap seconds)
  3. Notice that the result of os_get_reltime() may go backwards.

Expected behavior

Every call to os_get_reltime() shows the actual relative time compared to when the program
started running.

Additionally, the result of os_get_reltime() should never be lower than previous calls.

Additional context

It's one of the falsehoods programmers believe about time ๐Ÿ˜†

[...]

  • Timestamps always advance monotonically.

Taken from https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca

man gettimeofday(2) also recommends using clock_gettime().

Notes

The time returned by gettimeofday() is affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the system time). If you need a monotonically increasing clock, see clock_gettime(2).

Copied from man gettimeofday(2) under the Linux-man-pages-copyleft license

hostapd also has a better implementation that we can use, (see https://w1.fi/cgit/hostap/commit/?id=594516b4c28a94ca686b17f1e463dfd6712b75a7) but it might be Linux specific and not work on FreeBSD/CheriBSD.

`cmake --preset openwrt/mvebu/cortexa9` no longer works

Running cmake --preset openwrt/mvebu/cortexa9 causes an error:

CMake Error at CMakeLists.txt:3 (project):
  The CMAKE_C_COMPILER:

    /home/alois/Documents/EDGESec/build/openwrt/mvebu/cortexa9/_deps/openwrt_sdk_mvebu_cortexa9-src/staging_dir/toolchain-arm_cortex-a9+vfpv3-d16_gcc-7.5.0_musl_eabi/bin/arm-openwrt-linux-muslgnueabi-gcc

  is not a full path to an existing compiler tool.

  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
  the compiler, or to the compiler name if it is in the PATH.

Last known working commit: c527013
Earliest known broken commit: 78ed0dc

git bisect start 78ed0dcadc80891ffb008d8354ecd5ac86ae3e4a c527013cb7a4ceb438adb2ba4e1a4f54a7a0bb79
# deletes build folder, except for `*.tar.*`-ish, then tries configure
git bisect run sh -c "find ./build/ -type f -name '*.tar.*' -delete; /snap/bin/cmake --preset openwrt/mvebu/cortexa9"
git bisect reset

EDIT: It looks like the issue is due to 49e3000

For some reason, the ExternalProject_Add PREFIX option works fine only the first time you run cmake (hence why GitHub Actions is happy to run this code).
The second time you run cmake, something breaks.

Wifi Dongle support: WT-AC1686

This is device: https://www.amazon.ca/gp/product/B07X11SCSD

It is discovered by driver 88x2bu, from:
https://github.com/cilynx/rtl88x2BU_WiFi_linux_v5.3.1_27678.20180430_COEX20180427-5959

lsusb: Bus 001 Device 005: ID 0bda:b812 Realtek Semiconductor Corp. RTL88x2bu [AC1200 Techkey]
wlxe84e06947b0f: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether e8:4e:06:94:7b:0f  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

This device can not be used with EDGEsec:

 2022-01-15 22:15:44.021  TRACE iw.c:377: WiFi interface wlxe84e06947b0f doesn't suport vlan tagging

edgesec binary produced for TARGET=aarch64-linux-musl fails to run

Describe the bug

edgesec binary produced for TARGET=aarch64-linux-musl fails to run on target platform OpenWrt 21.02.1, r16325-88151b8303 on RPi 3B+

This is related to build process referenced in issue #209

To Reproduce
Steps to reproduce the behavior follow from those listed in #209

  1. With the correct compiler information build the system:
# docker run --rm --volume "$PWD":/opt/EDGESec --workdir /opt/EDGESec openwrt cmake --build --preset openwrt/default -j4

This produces --

user@linux /home/user/edgesec/build/openwrt/default/src# ls -ltr
total 7208
-rw-r--r-- 1 root root   12310 Jul 28 12:03 Makefile
-rw-r--r-- 1 root root     408 Jul 28 12:03 CTestTestfile.cmake
-rw-r--r-- 1 root root    2623 Jul 28 12:03 cmake_install.cmake
drwxr-xr-x 7 root root    4096 Jul 28 12:03 CMakeFiles
drwxr-xr-x 3 root root    4096 Jul 28 12:05 dhcp
drwxr-xr-x 3 root root    4096 Jul 28 12:05 firewall
drwxr-xr-x 3 root root    4096 Jul 28 12:05 radius
drwxr-xr-x 3 root root    4096 Jul 28 12:05 utils
-rwxr-xr-x 1 root root  156256 Jul 28 12:05 libsqlhook.so
drwxr-xr-x 3 root root    4096 Jul 28 12:05 ap
-rw-r--r-- 1 root root   34906 Jul 28 12:05 libconfig.a
drwxr-xr-x 4 root root    4096 Jul 28 12:05 capture
drwxr-xr-x 3 root root    4096 Jul 28 12:05 supervisor
drwxr-xr-x 3 root root    4096 Jul 28 12:05 dns
-rw-r--r-- 1 root root   25092 Jul 28 12:05 librunctl.a
-rwxr-xr-x 1 root root 7033360 Jul 28 12:05 edgesec

  1. copy edgesec to targert system (scp)

  2. Run it

root@OpenWrt:~/ManySecured# ./edgesec
./edgesec: line 1: syntax error: unexpected ")"
  1. See error

  2. Check ldd

root@OpenWrt:~/ManySecured# ldd ./edgesec 
	/lib64/ld-linux-x86-64.so.2 (0x7fb318a000)
	libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fb318a000)
	libuci.so => /lib/libuci.so (0x7fb2f87000)
	libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fb318a000)
Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by ./edgesec)
	libubox.so.20210516 => /lib/libubox.so.20210516 (0x7fb2f69000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7fb2f46000)
Error relocating ./edgesec: unsupported relocation type 7
  : repeated many times
Error relocating ./edgesec: __fprintf_chk: symbol not found
Error relocating ./edgesec: unsupported relocation type 7
  : repeated many times
Error relocating ./edgesec: __memcpy_chk: symbol not found
Error relocating ./edgesec: unsupported relocation type 7
  : repeated many times
Error relocating ./edgesec: getnetbyname_r: symbol not found
Error relocating ./edgesec: unsupported relocation type 7
  : repeated many times
Error relocating ./edgesec: __memset_chk: symbol not found
Error relocating ./edgesec: unsupported relocation type 7
  : repeated many times
Error relocating ./edgesec: getprotobyname_r: symbol not found
Error relocating ./edgesec: unsupported relocation type 7
  : repeated many times
Error relocating ./edgesec: unsupported relocation type 8
  : repeated many times
Error relocating ./edgesec: unsupported relocation type 6
  : repeated many times
Error relocating ./edgesec: unsupported relocation type 1
  : repeated many times
Error relocating ./edgesec: fcntl64: symbol not found
Error relocating ./edgesec: unsupported relocation type 1
  : repeated many times
Error relocating ./edgesec: unsupported relocation type 5
  : repeated many times
root@OpenWrt:~/ManySecured# 

Expected behaviour

edgesec should do something.

Host System

OpenWRT on a RPi 3B+.

BusyBox v1.33.1 (2021-10-24 09:01:35 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 21.02.1, r16325-88151b8303
 -----------------------------------------------------
root@OpenWrt:~/ManySecured# uname --a
Linux OpenWrt 5.4.154 #0 SMP Sun Oct 24 09:01:35 2021 aarch64 GNU/Linux



Running `ctest` in parallel may cause `test_dnsmasq` to fail due to SIGHUP

Describe the bug

Running tests with ctest only works when using a single process.

Running ctest with multiple threads (e.g. ctest -j16), has a high chance of causing test_dnsmasq to be killed via SIGHUP.

To Reproduce
Steps to reproduce the behavior:

  1. First compile tests

    git checkout ba237fdcc13c9313be9aed6fdff60eba996115cf # current main
    cmake --preset "linux"
    cmake --build --preset "linux" -j=16
  2. Run ctest with multiple threads:

    me@me:~/edgesec$ ctest --preset "linux" --output-on-failure -j=16 # often fails!
    ...
    15/45 Test #36: test_hostapd .....................   Passed    0.01 sec
          Start 44: test_reflection_list
    16/45 Test #39: test_dnsmasq .....................SIGHUP***Exception:   0.02 sec
    [==========] tests: Running 7 test(s).
    [ RUN      ] test_define_dhcp_interface_name
    2023-02-17 18:25:53.745  ERROR dnsmasq.c:72: dconf param is NULL
    2023-02-17 18:25:53.745  ERROR dnsmasq.c:77: ifname param is NULL
    2023-02-17 18:25:53.745  ERROR dnsmasq.c:111: define_dhcp_interface_name: snprintf error.
    [       OK ] test_define_dhcp_interface_name
    [ RUN      ] test_generate_dnsmasq_conf
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:171: Number of substrings=5
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:178: vlanid=0
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:188: ip_addr_low=10.0.0.2
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:195: ip_addr_upp=10.0.0.254
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:202: subnet_mask=255.255.255.0
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:209: lease_time=24h
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:171: Number of substrings=5
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:178: vlanid=1
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:188: ip_addr_low=10.0.1.2
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:195: ip_addr_upp=10.0.1.254
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:202: subnet_mask=255.255.255.0
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:209: lease_time=24h
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:171: Number of substrings=5
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:178: vlanid=2
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:188: ip_addr_low=10.0.2.2
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:195: ip_addr_upp=10.0.2.254
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:202: subnet_mask=255.255.255.0
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:209: lease_time=24h
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:171: Number of substrings=5
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:178: vlanid=3
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:188: ip_addr_low=10.0.3.2
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:195: ip_addr_upp=10.0.3.254
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:202: subnet_mask=255.255.255.0
    2023-02-17 18:25:53.745  TRACE test_dnsmasq.c:209: lease_time=24h
    2023-02-17 18:25:53.745  DEBUG dnsmasq.c:217: Writing into /tmp/dnsmasq-test.conf
    2023-02-17 18:25:53.745  DEBUG dnsmasq.c:217: Writing into /tmp/dnsmasq-test.conf
    [       OK ] test_generate_dnsmasq_conf
    [ RUN      ] test_generate_dnsmasq_script
    2023-02-17 18:25:53.746  DEBUG dnsmasq.c:252: Writing into /tmp/dnsmasq_exec-test.sh
    [       OK ] test_generate_dnsmasq_script
    [ RUN      ] test_run_dhcp_process
    2023-02-17 18:25:53.746  DEBUG dnsmasq.c:386: Checking dnsmasq proc running...
    
          Start 18: test_hashmap
    17/45 Test #22: test_log_thread_safe .............   Passed    0.02 sec
          Start 10: test_iface_mapper
    ...
    98% tests passed, 1 tests failed out of 45
    
    Total Test time (real) =   1.01 sec
    
    The following tests FAILED:
    	 39 - test_dnsmasq (SIGHUP)
    Errors while running CTest

Expected behavior
CMake tests have the appropriate RESOURCE_LOCK (or other CMake test properties) flags to avoid race conditions.

why does WLAN need VLAN tagging, or why doesn't RPI support that?

When running edgesec on an RPI4, I am getting:

2021-12-16 19:09:42.843  TRACE iw.c:199: phy0 -> P2P-device
2021-12-16 19:09:42.843  TRACE iw.c:377: WiFi interface wlan0 doesn't suport vlan tagging
2021-12-16 19:09:42.843  DEBUG engine.c:338: interface wlan0 not VLAN capable
2021-12-16 19:09:42.843  TRACE generic_hsm_driver.c:69: context param is NULL
Failed to start edgesec engine.

This is with mcr@fennrau:~/EDGESec/build $ uname -a
Linux fennrau 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux

Perhaps I am running too old a kernel.

Memory leak in `uci_lookup_section_ref()` function

It looks like the uci_lookup_section_ref() function has a memory leak.

ti is allocated with calloc(), but it's never free()-ed in the function, and as far as I'm aware, the pointer to ti is never passed out of this function.

if ((ti = os_calloc(1, sizeof(struct uci_type_list))) == NULL) {
log_errno("os_calloc");
return NULL;
}
ti->next = list;
list = ti;
ti->name = s->type;

grpc compilation error

I get this when compiling:
[ 0%] Generating reverse_access.pb.cc, reverse_access.pb.h, reverse_access.grpc.pb.cc, reverse_access.grpc.pb.h
Scanning dependencies of target reverse_grpc_proto
[ 1%] Building CXX object CMakeFiles/reverse_grpc_proto.dir/reverse_access.grpc.pb.cc.o
In file included from /usr/include/google/protobuf/arenastring.h:38,
from /home/alex/Projects/EDGESec/build/reverse_access.pb.h:24,
from /home/alex/Projects/EDGESec/build/reverse_access.grpc.pb.cc:5:
/usr/local/include/google/protobuf/stubs/fastmem.h:54:10: fatal error: google/protobuf/port_def.inc: No such file or directory
54 | #include <google/protobuf/port_def.inc>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/reverse_grpc_proto.dir/build.make:78: CMakeFiles/reverse_grpc_proto.dir/reverse_access.grpc.pb.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:823: CMakeFiles/reverse_grpc_proto.dir/all] Error 2
make: *** [Makefile:163: all] Error 2

$ protoc --version
libprotoc 3.6.1

Packet hash function

Currently we use md5 for packet hash function. Need to replace or reconsider calculating for every packet.

`tests/test_edgesec.c` code-coverage is inconsistent

Describe the bug

tests/test_edgesec.c code-coverage is inconsistent.

As an example, see #434 (comment).

This PR doesn't change anything in tests/test_edgesec.c, but somehow tests/test_edgesec.c had a code-coverage change. This is consistently happening with our PRs, which is a bit annoying, since we sometimes get a false-positive โŒ saying that the code-coverage got worse, but it turns out it's just tests/test_edgesec.c

Expected behavior

tests/test_edgesec.c code-coverage is consistent.

Screenshots

image

Additional context

It looks like the issue is this line:

I'm guessing maybe some of the CI compilers might be using a different version of gcc that uses different optimisation? I have a WIP commit that will test this branch, which should fix this issue, see 80e1ee7

Convert `uint64_t` time types to `time_t`

Instead of declaring the type of variables that store seconds since the unix spoch as uint64_t, e.g. in
https://github.com/nqminds/EDGESec/blob/acc80a447578c15baa3026e4cc2d377c862e3c7f/src/capture/capture_cleaner.c#L53-L55

They should probably instead by declared as type time_t (C-standard in time.h) or os_time_t (used by wpa_supplicant and our src/utils/os.h file):

https://github.com/nqminds/EDGESec/blob/97be6093287897eb1a6f52c4e1131c9bfaf62792/src/utils/os.h#L116

Wifi Dongle support: Archer T2U Nano

This is device: https://www.amazon.ca/gp/product/B07PB1X4CN

This was able to use the driver https://github.com/gnab/rtl8812au.git

Bus 001 Device 006: ID 2357:011e TP-Link AC600 wireless Realtek RTL8811AU [Archer T2U Nano]
enx60a4b722c9eb: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 60:a4:b7:22:c9:eb  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

It is unclear if this device supported WiFi VLANs, as it says "Fail"

2022-01-14 22:02:25.667  TRACE iw.c:240: wlan0 -> wiphy=0
2022-01-14 22:02:25.667  DEBUG engine.c:341: is_iw_vlan fail
2022-01-14 22:02:25.667  INFO  engine.c:359: Found wifi interface enx60a4b722c9eb

but EDGEsec continued. It did not start hostapd properly, and it is unclear why at this point.

cmake config error

I get this error when buildign on a Pi from a bare repo clone:

$ cmake -B build/ -S .
Adding RPATH $ORIGIN relative path to: ../lib/edgesec
CMake Error at CMakeLists.txt:110 (message):
  CMake target_autoconf_triple=armv7l-linux-gnu, not the same as
  CMAKE_LIBRARY_ARCHITECTURE=arm-linux-gnueabihf


-- Configuring incomplete, errors occurred!
See also "/home/pi/EDGESec/build/CMakeFiles/CMakeOutput.log".

I'm a bit confused about the purpose of CMakeLists.txt:110

Intermittent failing CI due to `Failed to execute statement: disk I/O error`

Describe the bug

GitHub Actions CI tests are failing intermittently due to:

 5/35 Test  #4: test_sqlite_header ...............***Failed    0.01 sec
[==========] Running 1 test(s).
[ RUN      ] test_init_sqlite_header_db
2022-09-05 08:31:12.358  ERROR sqliteu.c:23: Failed to execute statement: disk I/O error
2022-09-05 08:31:12.358  ERROR sqlite_header.c:614: execute_sqlite_query fail: CREATE TABLE IF NOT EXISTS eth (timestamp INTEGER NOT NULL, id TEXT NOT NULL, caplen INTEGER, length INTEGER, ifname TEXT, ether_dhost TEXT, ether_shost TEXT, ether_type INTEGER, PRIMARY KEY (timestamp, id));

Interestingly, our CI runs tests twice. Once for testing, and once for code coverage. This bug seems to only have on the 2nd run, so I'm guessing there may be some kind of race condition (or maybe GitHub Actions has an unusual file-system)

My gut feeling is that a sleep 5s between tests runs should prevent it.

To Reproduce

Intermittent, so we can't easily reproduce.

Expected behavior

CI tests should be consistent.

Documentation missing a preset for TARGET=aarch64-linux-musl

Describe the bug

Cross compiler settings as documented were not correct.

The objective was to compile the system for a RasberryPi Model 3B+, following the documentation
here: https://github.com/nqminds/edgesec/blob/main/README.md

To Reproduce
Steps to reproduce the behavior:

  1. Edit /edgesec/config.mak to contain
# Raspberry Pi target
TARGET=aarch64-linux-musl

OUTPUT=/usr/local
MUSL_VER = 1.1.24
  1. docker build
# docker build -t openwrt .
  1. docker run
# docker run --rm --volume "$PWD":/opt/EDGESec --workdir /opt/EDGESec openwrt cmake --preset openwrt/default

Produces errors. E.g.:

 The CMAKE_C_COMPILER:

    /usr/local/bin/arm-linux-musleabihf-gcc

  is not a full path to an existing compiler tool.
CMake Error at CMakeLists.txt:5 (project):
  The CMAKE_CXX_COMPILER:

    /usr/local/bin/arm-linux-musleabihf-g++

  is not a full path to an existing compiler tool.
  1. Edit .cmake file
    https://github.com/nqminds/edgesec/blob/main/CMakeModules/CMakeToolchains/arm-linux.cmake#L7

Comment out line 7 (missing from the docs). It should look like this:

# set(CROSS_COMPILE_PREFIX /usr/local/bin/arm-linux-musleabihf-)
  1. docker run command executes as expected

Expected behaviour

docker run --rm --volume "$PWD":/opt/EDGESec --workdir /opt/EDGESec openwrt cmake --preset openwrt/default

Should not produce errors relating to the cross compiler.

`test_dhcp_service` fails when building with `-DCMAKE_BUILD_TYPE=MinSizeRel`

test_dhcp_service occasionally fails when building with -DCMAKE_BUILD_TYPE=MinSizeRel (this sets -Os, aka optimize for size).

Steps to reproduce

Using:

  • commit c527013
  • gcc 11.2.0-19ubuntu1 (Ubuntu 22.04)
  • cmake 3.22.1
  • Host architecture: x86_64
  • Build architecture: x86_64
cmake --preset linux -DCMAKE_BUILD_TYPE=MinSizeRel
cmake --build -j4 --preset linux
ctest --preset linux --output-on-failure

The error output is occasionally (not consistent):

EDGESec $ ctest --preset linux --output-on-failure
[...some lines removed...]
27/33 Test #27: test_dnsmasq .....................   Passed    2.01 sec
      Start 28: test_dhcp_service
28/33 Test #28: test_dhcp_service ................***Failed    0.00 sec
[==========] Running 3 test(s).
[ RUN      ] test_run_dhcp
2022-05-30 12:48:45.914  TRACE dhcp_service.c:37: generate_dnsmasq_conf fail
[  ERROR   ] --- 0xffffffffffffffff != 0
[   LINE   ] --- /home/alois/Documents/EDGESec/tests/dhcp/test_dhcp_service.c:65: error: Failure!
[  FAILED  ] test_run_dhcp
[ RUN      ] test_close_dhcp
2022-05-30 12:48:45.914  TRACE dhcp_service.c:37: generate_dnsmasq_conf fail
[  ERROR   ] --- %s() has remaining non-returned values.
/home/alois/Documents/EDGESec/tests/dhcp/test_dhcp_service.c:75: note: remaining item was declared here

[  FAILED  ] test_close_dhcp
[ RUN      ] test_clear_dhcp_lease
[       OK ] test_clear_dhcp_lease
[==========] 3 test(s) run.
[  PASSED  ] 1 test(s).
[  FAILED  ] 2 test(s), listed below:
[  FAILED  ] test_run_dhcp
[  FAILED  ] test_close_dhcp

 2 FAILED TEST(S)
[...some lines removed...]

Wifi Dongle support: AC1200 Techkey

This is device: https://www.amazon.ca/gp/product/B07FCN6WGX

It uses driver: https://github.com/cilynx/rtl88x2BU_WiFi_linux_v5.3.1_27678.20180430_COEX20180427-5959

Bus 001 Device 003: ID 0bda:b812 Realtek Semiconductor Corp. RTL88x2bu [AC1200 Techkey]
wlx54ef33ec605c: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 54:ef:33:ec:60:5c  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

It is not VLAN capable:

2022-01-15 22:01:42.845  TRACE iw.c:199: phy1 -> P2P-GO
2022-01-15 22:01:42.845  TRACE iw.c:377: WiFi interface wlx54ef33ec605c doesn't suport vlan tagging
2022-01-15 22:01:42.846  DEBUG engine.c:338: interface wlx54ef33ec605c not VLAN capable
2022-01-15 22:01:42.846  TRACE generic_hsm_driver.c:69: context param is NULL

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.