Some issues with running N3N on cameras in the OpenIPC project.

[flyrouter]

Good afternoon !

Preamble

My name is Igor, and I am the founder and coordinator of the OpenIPC project - an open firmware for video cameras.
Some our resources here: https://openipc.org/ and https://github.com/OpenIPC
We are very interested in your project, and we are gladly and enthusiastically working on integration since we found it ;)
We are very grateful to you for the implementation and development, and we hope that our collaboration will be fruitful !
Thank you.

Now about the problems.

We compiled and tested the current version of N3N on 25+ different processors listed on our website.
In most cases, everything works well, however, some processors have two issues that I want to describe in order to try to resolve them and claim 100% compatibility before we release the package and include it in our repository officially.

1. Some processors, such as the HiSilicon Hi3518EV200 (not new but very popular and used in many devices), refuse to work with the supernode. There is a connection, but it seems like the headers get corrupted somewhere.
   I will give an example of what I see in the log of normally working devices when the Hi3518EV200 is activated (there are actually a bit over a five processors with this status, but I am providing one example to avoid confusion).

14/Feb/2026 19:08:11 [src/edge_utils.c:1746] WARNING: invalid transop ID: expected ChaCha20 (4), got (null) (78) from CC:64:1A:93:4C:DB [101.57.208.2:1268]
14/Feb/2026 19:08:12 [src/edge_utils.c:1746] WARNING: invalid transop ID: expected ChaCha20 (4), got (null) (7) from CC:64:1A:93:4C:DB [101.57.208.2:1268]
14/Feb/2026 19:08:13 [src/edge_utils.c:1746] WARNING: invalid transop ID: expected ChaCha20 (4), got (null) (40) from CC:64:1A:93:4C:DB [101.57.208.2:1268]
14/Feb/2026 19:08:15 [src/edge_utils.c:1746] WARNING: invalid transop ID: expected ChaCha20 (4), got (null) (109) from CC:64:1A:93:4C:DB [101.57.208.2:1268]
14/Feb/2026 19:08:16 [src/edge_utils.c:1746] WARNING: invalid transop ID: expected ChaCha20 (4), got (null) (91) from CC:64:1A:93:4C:DB [101.57.208.2:1268]
14/Feb/2026 19:08:17 [src/edge_utils.c:1746] WARNING: invalid transop ID: expected ChaCha20 (4), got (null) (103) from CC:64:1A:93:4C:DB [101.57.208.2:1268]

In the case of using AES, errors look like this:

14/Feb/2026 23:08:15 [src/edge_utils.c:2680] [OK] edge <<< ================ >>> supernode
14/Feb/2026 23:11:08 [src/edge_utils.c:1746] WARNING: invalid transop ID: expected AES (3), got null (1) from CC:64:1A:93:4C:DB [101.57.208.2:1265]
14/Feb/2026 23:11:08 [src/edge_utils.c:1746] WARNING: invalid transop ID: expected AES (3), got null (1) from CC:64:1A:93:4C:DB [101.57.208.2:1265]
14/Feb/2026 23:11:09 [src/edge_utils.c:1746] WARNING: invalid transop ID: expected AES (3), got null (1) from CC:64:1A:93:4C:DB [101.57.208.2:1265]
14/Feb/2026 23:11:10 [src/edge_utils.c:1746] WARNING: invalid transop ID: expected AES (3), got null (1) from CC:64:1A:93:4C:DB [101.57.208.2:1265]
14/Feb/2026 23:11:12 [src/edge_utils.c:1746] WARNING: invalid transop ID: expected AES (3), got null (1) from CC:64:1A:93:4C:DB [101.57.208.2:1265]
14/Feb/2026 23:11:13 [src/edge_utils.c:1746] WARNING: invalid transop ID: expected AES (3), got null (1) from CC:64:1A:93:4C:DB [101.57.208.2:1265]

I tried to use the compilation flag -fno-strict-aliasing, but I didn't see any improvements, or maybe I did it incorrectly.

2. When launching N3N Edge on Allwinner v851s hardware, for some reason it's impossible to specify the supernode name as a domain. For some reason, Edge cannot resolve it, even though pinging and performing any other standard operations in the console works fine.

root@plastiroma-sun8iw21p1:~# ping -c 3 openipc.cloud
PING openipc.cloud (212.47.227.69): 56 data bytes
64 bytes from 212.47.227.69: seq=0 ttl=51 time=79.843 ms
64 bytes from 212.47.227.69: seq=1 ttl=51 time=105.016 ms
64 bytes from 212.47.227.69: seq=2 ttl=51 time=192.873 ms

--- openipc.cloud ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 79.843/125.910/192.873 ms

14/Feb/2026 20:58:53 [n3n-edge.c:909] using ChaCha20 cipher.
14/Feb/2026 20:58:54 [src/conffile.c:1453] sessiondir: /run/n3n/edge
14/Feb/2026 20:58:54 [n3n-edge.c:941] use manually set IP address
14/Feb/2026 20:58:54 [n3n-edge.c:1079] created local tap device IPv4: 192.168.168.53/24, MAC: 9E:B2:BA:16:C9:AA
14/Feb/2026 20:58:54 [n3n-edge.c:1140] WARNING: The build option to add libcap-dev was not used. Some actions may cause permissions messages.
14/Feb/2026 20:58:54 [n3n-edge.c:1149] dropping privileges to uid=65534, gid=65534
14/Feb/2026 20:58:54 [n3n-edge.c:1167] edge started
14/Feb/2026 20:58:54 [src/edge_utils.c:1268] successfully joined multicast group 224.0.0.68:1968
14/Feb/2026 20:58:54 [src/resolve.c:188] WARNING: supernode2sock fails to resolve supernode host openipc.cloud, -11: System error
14/Feb/2026 20:59:01 [src/edge_utils.c:1193] WARNING: sendto(212.47.227.69:35222) failed (22) Invalid argument
14/Feb/2026 20:59:04 [src/edge_utils.c:1685] WARNING: supernode not responding, now trying [openipc.cloud:35222]
14/Feb/2026 20:59:04 [src/resolve.c:188] WARNING: supernode2sock fails to resolve supernode host openipc.cloud, -11: System error
14/Feb/2026 20:59:04 [src/resolve.c:188] WARNING: supernode2sock fails to resolve supernode host openipc.cloud, -11: System error
14/Feb/2026 20:59:04 [src/resolve.c:506] WARNING: could not resolve openipc.cloud:35222
14/Feb/2026 20:59:04 [src/edge_utils.c:3178] WARNING: resolve_hostnames_str_to_peer_info returned errors
14/Feb/2026 20:59:04 [src/resolve.c:188] WARNING: supernode2sock fails to resolve supernode host openipc.cloud, -11: System error
14/Feb/2026 20:59:04 [src/resolve.c:506] WARNING: could not resolve openipc.cloud:35222
14/Feb/2026 20:59:04 [src/edge_utils.c:3178] WARNING: resolve_hostnames_str_to_peer_info returned errors
14/Feb/2026 20:59:04 [src/resolve.c:188] WARNING: supernode2sock fails to resolve supernode host openipc.cloud, -11: System error

We haven't noticed any other issues so far and would be very grateful if you could help fix these two feedback items.
We are ready to provide any tests, actions, and remote access if needed.
Thank you.

Small sentences

One of our colleagues and co-founders of the OpenIPC project was concerned about the rather limited bandwidth of the communication channel being created. He needed to connect a video recorder collecting data from cameras to the central computer and conducted extensive research on the code.
Since this code has been quite heavily modified, including the use of certain algorithms, it cannot be automatically submitted as a PR. We would like you to take a look at it anyway and possibly improve your base code.

https://github.com/dimerr/n3n/commits/main/

In any case, the OpenIPC project is focused on using the original code from your central repository and does not plan to create forks or branches. We are interested in a unified core of your project for network/device integration.

Thank you for your attention, and have a good weekend.

[hamishcoleman]

Hi Igor,
Thanks for trying n3n. It sounds like your problems cover a couple of different areas. It might make sense to split them out into different issues after some initial discussion. If you can share the exact commit you are compiling, compile options used (eg, configure args), some details on the runtime environment (eg, is this using a embedded libc? if so, which one?) and a minimal config for the edges and supernodes that replicates the issues, that would probably help. Are these environments that you have the ability to run gdb in?

• HiSilicon Hi3518EV200 issues: This does sound like a compilation or compiler issue. It could also be a mismatch of the header encryption settings on the sender/receiver. It might help to have a pcap of some traffic that is causing these messages.
• Allwinner v851s supernode resolve issues: This looks like there is something not working with the resolver or networking in this environment - the following line with "failed (22) Invalid argument" suggests that there is a general network issue here. Ping is often implemented in a way that bypasses some of the usual networking - which might be why it is working. Can you try using netcat to send a UDP packet to the same address/port that the sendto() is trying?
• Performance concerns: The relatively low bandwidth achievable has been mentioned previously and is just waiting for time - and other projects - to permit working on it. I've looked at dimerr's branch, and it is unfortunate just how wide-reaching and entangled with other changes the speed improvements appear to be. I have been working on adding built-in benchmarking code so that some attempt to port that branch and systematically measure the results and changes can be done, but this has the same time constraints as mentioned.

[hamishcoleman]

Is there an easy source for matching hardware that I could run benchmarks on?

[hamishcoleman]

(See also #93 (comment) for some earlier discussion, which points at https://github.com/dimerr/n3n for a repo with the one-large-commit - I've been trying to pull apart that commit into smaller chunks that are possible to be benchmarked and tested)

[hamishcoleman]

https://github.com/hamishcoleman/n3n/tree/dimerr_speedups is my working branch where I am trying to separate out the large commit - once I have separated everything out, this branch will remain for reference