n42n / n3n Goto Github PK

View Code? Open in Web Editor NEW

65.0 5.0 6.0 4.05 MB

Peer to Peer VPN

Home Page: https://n3n.dev

Makefile 0.93% Shell 6.14% M4 0.24% Roff 2.31% C 86.79% Python 2.12% Perl 0.49% Lua 0.74% HTML 0.09% JavaScript 0.14%

vpn

n3n's Introduction

n3n

n3n is a lightweight Peer-to-Peer VPN that creates virtual networks.

In order to start using n3n, two elements are required:

A supernode: it allows edge nodes to announce and discover other nodes. It must have a port publicly accessible on internet.
edge nodes: the nodes which will be a part of the virtual networks

A virtual network shared between multiple edge nodes in n3n is called a community. A single supernode can relay multiple communities and a single computer can be part of multiple communities at the same time (by running multiple edge daemons). An encryption key can be used by the edge nodes to encrypt the packets within their community.

n3n tries to establish a direct peer-to-peer connection via udp between the edge nodes when possible. When this is not possible (usually due to special NAT devices), the supernode is also used to relay the packets.

n3n was originally based on an older n2n project and hopes to keep protocol compatiblilty with that.

Note that some distributions have very old versions of n2n packaged that are incompatible with the protocol used by n3n. At the least, Debian has a n2n version 1.3.1 which uses a protocol from 2008 and has not been compatible with the stable releases of n2n for many years - thus will definitely not interoperate with n3n)

License

Any new self-contained tools or modules are licensed GPL-2.0-only.
Existing code is licensed GPL-3-only.
There are multiple distinct copyright holders throughout the codebase.
There is no Contributor Licence Agreement and thus there is no single body that can take ownership of the code and/or change the licensing.

Quick Start

For Debian, Ubuntu or similar dpkg based systems:

Download the package from the latest stable release.
Install the package

Create a config file - /etc/n3n/mynetwork.conf containing

[community]
name=mynetwork
key=mypassword
supernode=supernode.ntop.org:7777

Start the service: sudo systemctl start n3n-edge@mynetwork
Check the connection: sudo n3nctl -s mynetwork supernodes
List other nodes found: sudo n3nctl -s mynetwork edges

IMPORTANT: It is strongly advised to choose a custom community name (the community.name option) and a secret encryption key (the community.key option) in order to prevent other users from connecting to your computer.

It is also suggested that you setup your own supernode

Some of the management API calls can generate enough data to overflow the internal buffer used. Simply increasing this buffer is not reasonable as it can leave a lot of RAM in unused buffers. Dynamically allocating the buffer is also not possible - firstly, the total size of the JSON data is not known until after it has been rendered and secondly these buffer objects are intended to remove memory allocations from the normal path.

The alternative to resizing the buffer is to implement a paginated interface to these APIs.

Why is *.service installed in /lib/systemd/system/?

This may be a preference for a specific dist, but when --libdir=/xx/yy/zz is specified, it installs to both locations and does not override the default path.

Investigate "edge: * bit out of range 0 - FD_SETSIZE on fd_set *: terminated" errors

There have been some reports (ntop/n2n#1168 (comment)) of people getting this error.

Investigate adding FEC

FEC (Forward Error Correction) is a way to increase reliability when some data is lost.

If n3n users are experiencing packet loss, the addition of FEC could assist with that. However, FEC is not a simple cure-all - it has a cost of increased complexity and increased packet sizes (or increased number of packets - or probably both) and increased memory use (for caching the all the packets in a bundle before reassembly) and increased latency (often, a FEC algo cannot return the original packets until all the packets in the bundle have arrived). All this has meant that in most expected internet protocol situations, a simple packet retransmit is more reliable than the total overhead of adding FEC.

Since the internet is intended to be a low-loss system, before adding something like FEC, we should investigate what is causing these packet losses, and how to flexibly handle that.

For instance, the FEC convolution algorithm used is tuned to the expected percentage data loss - so either a flexible suite of algos is needed, or an acceptable failure rate determined.

How often are packet losses occurring?
Do we have metrics to capture this?
Can we find a protocol edge case that is causing drops?
Do we know what percentage loss is expected?
Can we detect this loss at runtime?
Are there some simple FEC algos that we can add?
What are the tradeoffs inherent in any algos proposed to add?

3.3.2 fails to build on OpenBSD 7.3

Same as in ntop/n2n#1170:

CC is: cc -DVERSION='"3.3.2"' -DBUILDDATE='"Sat Mar 30 13:36:42 UTC 2024"' -g -O2   -Wall   -In3n-3.3.2/include -DHAVE_BRIDGING_SUPPORT -In3n-3.3.2/libs  -c -o $@ $<
Build for version: 3.3.2
for dir in tools apps; do gmake -C $dir; done
gmake[1]: Entering directory 'n3n-3.3.2/tools'
CC is: cc -DVERSION='"3.3.2"' -DBUILDDATE='"Sat Mar 30 13:36:42 UTC 2024"' -g -O2   -Wall   -In3n-3.3.2/include -DHAVE_BRIDGING_SUPPORT -In3n-3.3.2/libs  -Ln3n-3.3.2/src -Ln3n-3.3.2/libs/connslot $^ -ln3n -lconnslot  -o $@
  CC      n3n-benchmark
edge_utils.c:2605 (src/edge_utils.c:2605)(edge_utils.o:(process_udp) in archive n3n-3.3.2/src/libn3n.a): warning: sprintf() is often misused, please use snprintf()
network_traffic_filter.c:85 (src/network_traffic_filter.c:85)(network_traffic_filter.o:(get_filter_packet_info_log_string) in archive n3n-3.3.2/src/libn3n.a): warning: strcpy() is almost always misused, please use strlcpy()
ld: error: undefined symbol: tuntap_read
>>> referenced by edge_utils.c:2208 (src/edge_utils.c:2208)
>>>               edge_utils.o:(edge_read_from_tap) in archive n3n-3.3.2/src/libn3n.a

ld: error: undefined symbol: tuntap_close
>>> referenced by edge_utils.c:2221 (src/edge_utils.c:2221)
>>>               edge_utils.o:(edge_read_from_tap) in archive n3n-3.3.2/src/libn3n.a
>>> referenced by edge_utils.c:3424 (src/edge_utils.c:3424)
>>>               edge_utils.o:(quick_edge_init) in archive n3n-3.3.2/src/libn3n.a

ld: error: undefined symbol: tuntap_open
>>> referenced by edge_utils.c:2222 (src/edge_utils.c:2222)
>>>               edge_utils.o:(edge_read_from_tap) in archive n3n-3.3.2/src/libn3n.a
>>> referenced by edge_utils.c:3408 (src/edge_utils.c:3408)
>>>               edge_utils.o:(quick_edge_init) in archive n3n-3.3.2/src/libn3n.a

ld: error: undefined symbol: tuntap_write
>>> referenced by edge_utils.c:1875 (src/edge_utils.c:1875)
>>>               edge_utils.o:(process_udp) in archive n3n-3.3.2/src/libn3n.a

ld: error: undefined symbol: tuntap_get_address
>>> referenced by edge_utils.c:3120 (src/edge_utils.c:3120)
>>>               edge_utils.o:(run_edge_loop) in archive n3n-3.3.2/src/libn3n.a
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[1]: *** [Makefile:28: n3n-benchmark] Error 1
gmake[1]: Leaving directory 'n3n-3.3.2/tools'
gmake[1]: Entering directory 'n3n-3.3.2/apps'
cc -DVERSION='"3.3.2"' -DBUILDDATE='"Sat Mar 30 13:36:42 UTC 2024"' -g -O2   -Wall   -In3n-3.3.2/include -DHAVE_BRIDGING_SUPPORT -In3n-3.3.2/libs  -Ln3n-3.3.2/src -Ln3n-3.3.2/libs/connslot  n3n-edge.c ../src/libn3n.a  -ln3n -lconnslot  -o n3n-edge
edge_utils.c:2605 (src/edge_utils.c:2605)(edge_utils.o:(process_udp) in archive ../src/libn3n.a): warning: sprintf() is often misused, please use snprintf()
network_traffic_filter.c:85 (src/network_traffic_filter.c:85)(network_traffic_filter.o:(get_filter_packet_info_log_string) in archive ../src/libn3n.a): warning: strcpy() is almost always misused, please use strlcpy()
ld: error: undefined symbol: tuntap_open
>>> referenced by n3n-edge.c:949
>>>               /tmp/n3n-edge-5e943c.o:(main)
>>> referenced by edge_utils.c:2222 (src/edge_utils.c:2222)
>>>               edge_utils.o:(edge_read_from_tap) in archive ../src/libn3n.a
>>> referenced by edge_utils.c:3408 (src/edge_utils.c:3408)
>>>               edge_utils.o:(quick_edge_init) in archive ../src/libn3n.a

ld: error: undefined symbol: tuntap_close
>>> referenced by n3n-edge.c:1072
>>>               /tmp/n3n-edge-5e943c.o:(main)
>>> referenced by edge_utils.c:2221 (src/edge_utils.c:2221)
>>>               edge_utils.o:(edge_read_from_tap) in archive ../src/libn3n.a
>>> referenced by edge_utils.c:3424 (src/edge_utils.c:3424)
>>>               edge_utils.o:(quick_edge_init) in archive ../src/libn3n.a

ld: error: undefined symbol: tuntap_read
>>> referenced by edge_utils.c:2208 (src/edge_utils.c:2208)
>>>               edge_utils.o:(edge_read_from_tap) in archive ../src/libn3n.a

ld: error: undefined symbol: tuntap_write
>>> referenced by edge_utils.c:1875 (src/edge_utils.c:1875)
>>>               edge_utils.o:(process_udp) in archive ../src/libn3n.a

ld: error: undefined symbol: tuntap_get_address
>>> referenced by edge_utils.c:3120 (src/edge_utils.c:3120)
>>>               edge_utils.o:(run_edge_loop) in archive ../src/libn3n.a
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[1]: *** [<builtin>: n3n-edge] Error 1
gmake[1]: Leaving directory 'n3n-3.3.2/apps'
gmake: *** [Makefile:248: subdirs] Error 2

edge running,but has warning :"WARNING: n3n has not been compiled with libcap-dev; some commands may fail"

./autogen.sh
./configure
make

Traffic Restrictions on supernode?

Thanks for the codes.
Any way to config Traffic Restrictions on supernode server side? Traffic Restrictions could be configured in supernode or only edge?

How is this different from n2n?

Does it mean that n2n stops updating?

Restarting edge can lead to "address already in use" errors

The supernode is supposed to keep any address from being reused for a period after the last message from that host. This allows an edge to release the address during a controlled shutdown/restart but also alows a crash stop/start to eventually reuse the address.

During a recent stop/start test in a production environment, it was noted that the "not release" message was still occurring over 5 minutes after the edge was restarted

[src/edge_utils.c:2716] ERROR: authentication error, MAC or IP address already in use or not released yet by supernode

Supernode crash when creating dynamic keys for username-password auth

Hey,
This is a repeat of the following issue: ntop/n2n#1161
Testing on a Windows 11 machine this happens on both n3n 3.3.4 and n2n 3.1.1 binaries with minimal config settings.

If username/password auth is enabled and community.list has any users listed the supernode process closes after announcing it is calculating dynamic keys.
e.g. the following is ran and the program closes with no error code.

n3n-supernode.exe start dynkey_test
14/May/2024 11:13:11 [src/sn_utils.c:433] added allowed community 'N3Ngroup' [total: 1]
14/May/2024 11:13:11 [src/sn_utils.c:1430] assigned sub-network 10.114.25.0/24 to community 'N3Ngroup'
14/May/2024 11:13:11 [src/sn_utils.c:378] added user 'Tester' with public key 'Sb7i-eKf3csny8Ai3aQGq+piopwrxBH-iUFzAONioWy' to community 'N3Ngroup'
14/May/2024 11:13:11 [src/sn_utils.c:479] loaded 1 fixed-name communities from community.list
14/May/2024 11:13:11 [src/sn_utils.c:482] loaded 0 regular expressions for community name matching from community.list
14/May/2024 11:13:11 [src/sn_utils.c:147] started shared secrets calculation for edge authentication
14/May/2024 11:13:11 [src/sn_utils.c:163] calculated shared secrets for edge authentication
14/May/2024 11:13:11 [src/sn_utils.c:172] calculating dynamic keys

community.list

N3Ngroup
* Tester Sb7i-eKf3csny8Ai3aQGq+piopwrxBH-iUFzAONioWy

dynkey_test.conf

[community]
key=EncryKey
cipher=ChaCha20

[connection]
bind=6777

[logging]
verbose=4

[supernode]
community_file=community.list
federation=N3Nfed

auto_ip_max=10.114.26.0/24
auto_ip_min=10.114.25.0/24

Can you add some features?

Can the boss add port access restrictions between nodes? For example, I hope that user A cannot access user B's 3389 remote port and only allow access to the 80 port that I specify can be accessed?
I hope the boss can compile an IPK version that supports arm64. I have a soft router for arm64, but I don't see any IPK files that support arm64 in the branch file

Allow p2p communication only

Is it possible to put a restriction on the super node to only allow p2p communication without relaying traffic from edge 🧐

Setting a static address should be simple

simply setting a value for tuntap.address should trigger the setting tuntap.address_mode=static (unless overridden by a subsequent address_mode setting)

Whitepaper for NAT traversal improvements

https://tailscale.com/blog/how-nat-traversal-works

dropped incoming data from unknown supernode

Hello, I use Supernode Federation, but only one edge is in a normal state. On other edges, only one supernode is online, prompting "15/May/2024 16:38:44 [src/edge_utils.c:2372] dropped incoming data from unknown supernode"

config

superNode1

[connection]
bind=42014
[supernode]
community_file=/etc/n3n/community.list
federation=***
[logging]
verbose=5

superNode2

[connection]
bind=13914
[supernode]
federation=***
peer=seek.mhwl.cc:42014
[logging]
verbose=5

edgeNode1

[community]
name=***
cipher=ChaCha20
key=***
supernode=seek.mhwl.cc:42014
[tuntap]
macaddr=DE:AD:BE:EF:12:01
address = 10.200.10.3
address_mode = static
[auth]
pubkey=***

edgeNode2

[community]
name=***
cipher=ChaCha20
key=***
supernode=seek.mhwl.cc:42014 
[tuntap]
macaddr=DE:AD:BE:EF:00:00
address = 10.200.10.1
address_mode = static
[auth]
pubkey=***

log

edgeNode1

versi c macaddr           sockaddr             upt last_see 
3.3.4 1 F6:0F:F1:91:EA:F8 163.179.36.110:42014 271 7s       
      0 56:48:07:EE:1F:8F 8.134.178.182:13914    0 19858d8h

edgeNode2

versi c macaddr           sockaddr             upt la 
3.3.4 1 F6:0F:F1:91:EA:F8 163.179.36.110:42014 342 1s 
3.3.4 0 56:48:07:EE:1F:8F 8.134.178.182:13914  318 1s

edgeNode1 Startup log

15/May/2024 16:38:32 [n3n-edge.c:810] starting n3n edge 3.3.4 Thu May 9 18:04:06 2024 +1000
15/May/2024 16:38:32 [n3n-edge.c:816] using compression: none.
15/May/2024 16:38:32 [n3n-edge.c:817] using ChaCha20 cipher.
15/May/2024 16:38:32 [src/edge_utils.c:489] number of supernodes in the list: 1
15/May/2024 16:38:32 [src/edge_utils.c:491] supernode 0 => seek.mhwl.cc:42014
15/May/2024 16:38:32 [src/transform_cc20.c:143] setup_cc20_key completed
15/May/2024 16:38:32 [src/conffile.c:1418] sessiondir: /run/n3n/my
15/May/2024 16:38:32 [n3n-edge.c:839] use manually set IP address
15/May/2024 16:38:32 [n3n-edge.c:857] skip PING to supernode
15/May/2024 16:38:32 [src/edge_utils.c:383] Setting pmtu_discovery false
15/May/2024 16:38:32 [n3n-edge.c:928] skip auto IP address asignment
15/May/2024 16:38:32 [src/tuntap_linux.c:221] Waiting for TAP interface to be up and running...
15/May/2024 16:38:32 [src/tuntap_linux.c:242] Interface is up and running
15/May/2024 16:38:32 [n3n-edge.c:962] created local tap device IPv4: 10.200.10.3/24, MAC: DE:AD:BE:EF:12:01
15/May/2024 16:38:32 [n3n-edge.c:1024] WARNING: n3n has not been compiled with libcap-dev; some commands may fail
15/May/2024 16:38:32 [n3n-edge.c:1029] dropping privileges to uid=997, gid=996
15/May/2024 16:38:32 [n3n-edge.c:1058] edge started
15/May/2024 16:38:32 [src/edge_utils.c:1596] update_supernode_reg: doing fast retry.
15/May/2024 16:38:32 [src/edge_utils.c:1208] successfully joined multicast group 224.0.0.68:1968
15/May/2024 16:38:32 [src/resolve.c:172] supernode2sock successfully resolves supernode IPv4 address for seek.mhwl.cc
15/May/2024 16:38:32 [src/edge_utils.c:1664] registering with supernode [seek.mhwl.cc:42014][number of supernodes 1][attempts left 2]
15/May/2024 16:38:32 [src/edge_utils.c:1334] send REGISTER_SUPER to [163.179.36.110:42014]
15/May/2024 16:38:32 [src/edge_utils.c:1070] sent=79
15/May/2024 16:38:32 [src/edge_utils.c:640] registering with multicast group 224.0.0.68:1968
15/May/2024 16:38:32 [src/edge_utils.c:1480] send REGISTER to [224.0.0.68:1968]
15/May/2024 16:38:32 [src/edge_utils.c:1070] sent=61
15/May/2024 16:38:32 [src/edge_utils.c:2309] Rx N2N_UDP of size 61 from [172.16.0.156:42067]
15/May/2024 16:38:32 [src/edge_utils.c:2460] skipping REGISTER from self
15/May/2024 16:38:32 [src/edge_utils.c:2223] Rx TAP packet (  90) for 33:33:00:00:00:16
15/May/2024 16:38:32 [src/edge_utils.c:2229] dropping Tx multicast
15/May/2024 16:38:32 [src/peer_info.c:176] Purging old registrations
15/May/2024 16:38:32 [src/peer_info.c:181] Remove 0 registrations
15/May/2024 16:38:32 [src/edge_utils.c:2223] Rx TAP packet (  86) for 33:33:FF:EF:12:01
15/May/2024 16:38:32 [src/edge_utils.c:2229] dropping Tx multicast
15/May/2024 16:38:32 [src/edge_utils.c:2309] Rx N2N_UDP of size 84 from [163.179.36.110:42014]
15/May/2024 16:38:32 [src/edge_utils.c:2581] Rx REGISTER_SUPER_ACK from F6:0F:F1:91:EA:F8 [163.179.36.110:42014] (external 218.204.178.2:42067) with 2 attempts left
15/May/2024 16:38:32 [src/edge_utils.c:2624] supernode '8.134.178.182:13914' added to the list of supernodes.
15/May/2024 16:38:32 [src/edge_utils.c:2649] [OK] edge <<< ================ >>> supernode
15/May/2024 16:38:32 [src/edge_utils.c:1574] sending gratuitous ARP...
15/May/2024 16:38:32 [src/transform_cc20.c:77] encode_cc20 42 bytes
15/May/2024 16:38:32 [src/edge_utils.c:2161] encode PACKET of 96 bytes, 42 bytes data, 54 bytes overhead, transform 4
15/May/2024 16:38:32 [src/edge_utils.c:1955] multicast or broadcast destination peer, using supernode
15/May/2024 16:38:32 [src/edge_utils.c:2014] Tx PACKET of 96 bytes to FF:FF:FF:FF:FF:FF [163.179.36.110:42014]
15/May/2024 16:38:32 [src/edge_utils.c:1070] sent=96
15/May/2024 16:38:32 [src/transform_cc20.c:77] encode_cc20 42 bytes
15/May/2024 16:38:32 [src/edge_utils.c:2161] encode PACKET of 96 bytes, 42 bytes data, 54 bytes overhead, transform 4
15/May/2024 16:38:32 [src/edge_utils.c:1955] multicast or broadcast destination peer, using supernode
15/May/2024 16:38:32 [src/edge_utils.c:2014] Tx PACKET of 96 bytes to FF:FF:FF:FF:FF:FF [163.179.36.110:42014]
15/May/2024 16:38:32 [src/edge_utils.c:1070] sent=96
15/May/2024 16:38:32 [src/peer_info.c:176] Purging old registrations
15/May/2024 16:38:32 [src/peer_info.c:181] Remove 0 registrations
15/May/2024 16:38:32 [src/edge_utils.c:2223] Rx TAP packet (  90) for 33:33:00:00:00:16
15/May/2024 16:38:32 [src/edge_utils.c:2229] dropping Tx multicast
15/May/2024 16:38:33 [src/edge_utils.c:2223] Rx TAP packet (  90) for 33:33:00:00:00:16
15/May/2024 16:38:33 [src/edge_utils.c:2229] dropping Tx multicast
15/May/2024 16:38:33 [src/edge_utils.c:2223] Rx TAP packet (  70) for 33:33:00:00:00:02
15/May/2024 16:38:33 [src/edge_utils.c:2229] dropping Tx multicast
15/May/2024 16:38:33 [src/edge_utils.c:2223] Rx TAP packet (  90) for 33:33:00:00:00:16
15/May/2024 16:38:33 [src/edge_utils.c:2229] dropping Tx multicast
15/May/2024 16:38:37 [src/edge_utils.c:2223] Rx TAP packet (  70) for 33:33:00:00:00:02
15/May/2024 16:38:37 [src/edge_utils.c:2229] dropping Tx multicast
15/May/2024 16:38:44 [src/edge_utils.c:2223] Rx TAP packet (  70) for 33:33:00:00:00:02
15/May/2024 16:38:44 [src/edge_utils.c:2229] dropping Tx multicast
15/May/2024 16:38:44 [src/edge_utils.c:1257] send PING to supernodes
15/May/2024 16:38:44 [src/edge_utils.c:1070] sent=38
15/May/2024 16:38:44 [src/edge_utils.c:1070] sent=38
15/May/2024 16:38:44 [src/edge_utils.c:2309] Rx N2N_UDP of size 74 from [8.134.178.182:13914]
15/May/2024 16:38:44 [src/edge_utils.c:2372] dropped incoming data from unknown supernode
15/May/2024 16:38:44 [src/edge_utils.c:2309] Rx N2N_UDP of size 74 from [163.179.36.110:42014]
15/May/2024 16:38:44 [src/edge_utils.c:2764] Rx PONG from supernode F6:0F:F1:91:EA:F8 version '3.3.4'

Can DHCP be added and placed in the same group, and edge can customize subnet masks?

For example, SuperNode sets the minimum IP range to 10.50.0.0 and the maximum IP range to 10.50.255.255
Edge A user sets IP to 10.50.60.1 and group to test
Edge B user group is test, but IP is not automatically obtained
If user B is assigned to another network segment, such as 10.50.70.1, then user B will not be able to access user A unless the subnet mask is manually set to 255.255.0.0. To manually set user B to the same group network segment, such as 10.50.60.100, mutual access can only be made at this time
I hope to customize the subnet mask when set to automatic acquisition

edge crashes on Windows, memory access violation (LZO decompression?)

Myself and some other users are experiencing common crashes on n3n-edge 3.3.4 due to access violation during lzo1x decompression. I'm unsure how to reproduce this for further debugging.
If the decompression method is unsafe I suppose one user sending corrupt packets could make a community momentarily unusable.

Issue ntop/n2n#1165 could be related.
We may test if using an older versions of n2n (pre 3.1.1) for edges on communities changes this behavior.

WinDbg !analyze -v result:

Details

*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


KEY_VALUES_STRING: 1

    Key  : AV.Fault
    Value: Read

    Key  : Analysis.Elapsed.mSec
    Value: 479

    Key  : Analysis.IO.Other.Mb
    Value: 0

    Key  : Analysis.IO.Read.Mb
    Value: 0

    Key  : Analysis.IO.Write.Mb
    Value: 0

    Key  : Analysis.Init.Elapsed.mSec
    Value: 7206

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 81

    Key  : Failure.Bucket
    Value: INVALID_POINTER_READ_c0000005_n3n-edge.exe!Unknown

    Key  : Failure.Hash
    Value: {c9829084-8ed0-c0cc-a3a7-5d8477630a4e}

    Key  : Timeline.OS.Boot.DeltaSec
    Value: 25183

    Key  : Timeline.Process.Start.DeltaSec
    Value: 520

    Key  : WER.OS.Branch
    Value: ni_release

    Key  : WER.OS.Version
    Value: 10.0.22621.1

    Key  : WER.Process.Version
    Value: 3.0.0.10


FILE_IN_CAB:  n3n-edge.exe.4000.dmp

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

CONTEXT:  (.ecxr)
rax=000000820b5fd6f8 rbx=0000000000000069 rcx=0000000000000003
rdx=000000820b5f2828 rsi=000000820b5fcefd rdi=000000820b5fd700
rip=00007ff64e824c48 rsp=000000820b5fc728 rbp=000000820b5fc8fc
 r8=000000820b5fd6d0  r9=000000820b5fc798 r10=000000820b5fced0
r11=000000820b5f2828 r12=0000000000000000 r13=0000000000000008
r14=0000000066477365 r15=000000820b5fc8f0
iopl=0         nv up ei pl zr ac po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010256
n3n_edge+0x34c48:
00007ff6`4e824c48 488b2a          mov     rbp,qword ptr [rdx] ds:00000082`0b5f2828=????????????????
Resetting default scope

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 00007ff64e824c48 (n3n_edge+0x0000000000034c48)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 000000820b5f2828
Attempt to read from address 000000820b5f2828

PROCESS_NAME:  n3n-edge.exe

READ_ADDRESS:  000000820b5f2828 

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

EXCEPTION_CODE_STR:  c0000005

EXCEPTION_PARAMETER1:  0000000000000000

EXCEPTION_PARAMETER2:  000000820b5f2828

IP_ON_STACK: 
+0
00000082`0b5fe53e 3b903f90b335    cmp     edx,dword ptr [rax+35B3903Fh]

FRAME_ONE_INVALID: 1

STACK_TEXT:  
00000082`0b5fc728 00000082`0b5fe53e     : 00000000`00000069 00000082`0b5fd6d0 00000082`0b5fc8fc 00000243`38c67ab0 : n3n_edge+0x34c48
00000082`0b5fc730 00000000`00000069     : 00000082`0b5fd6d0 00000082`0b5fc8fc 00000243`38c67ab0 00000082`0b5fd6d0 : 0x00000082`0b5fe53e
00000082`0b5fc738 00000082`0b5fd6d0     : 00000082`0b5fc8fc 00000243`38c67ab0 00000082`0b5fd6d0 00007ff6`4e81a104 : 0x69
00000082`0b5fc740 00000082`0b5fc8fc     : 00000243`38c67ab0 00000082`0b5fd6d0 00007ff6`4e81a104 00007ff6`4e841f3f : 0x00000082`0b5fd6d0
00000082`0b5fc748 00000243`38c67ab0     : 00000082`0b5fd6d0 00007ff6`4e81a104 00007ff6`4e841f3f 00000082`0b5fe53e : 0x00000082`0b5fc8fc
00000082`0b5fc750 00000082`0b5fd6d0     : 00007ff6`4e81a104 00007ff6`4e841f3f 00000082`0b5fe53e 00000000`00000079 : 0x00000243`38c67ab0
00000082`0b5fc758 00007ff6`4e81a104     : 00007ff6`4e841f3f 00000082`0b5fe53e 00000000`00000079 00000000`00000002 : 0x00000082`0b5fd6d0
00000082`0b5fc760 00007ff6`4e841f3f     : 00000082`0b5fe53e 00000000`00000079 00000000`00000002 00000000`00000000 : n3n_edge+0x2a104
00000082`0b5fc768 00000082`0b5fe53e     : 00000000`00000079 00000000`00000002 00000000`00000000 00000243`38c67ab0 : n3n_edge+0x51f3f
00000082`0b5fc770 00000000`00000079     : 00000000`00000002 00000000`00000000 00000243`38c67ab0 00000082`0b5fced0 : 0x00000082`0b5fe53e
00000082`0b5fc778 00000000`00000002     : 00000000`00000000 00000243`38c67ab0 00000082`0b5fced0 00000000`00000000 : 0x79
00000082`0b5fc780 00000000`00000000     : 00000243`38c67ab0 00000082`0b5fced0 00000000`00000000 00000082`0b5fc8f0 : 0x2


STACK_COMMAND:  ~0s; .ecxr ; kb

SYMBOL_NAME:  n3n_edge+34c48

MODULE_NAME: n3n_edge

IMAGE_NAME:  n3n-edge.exe

FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_n3n-edge.exe!Unknown

OS_VERSION:  10.0.22621.1

BUILDLAB_STR:  ni_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {c9829084-8ed0-c0cc-a3a7-5d8477630a4e}

Followup:     MachineOwner
---------

Add IPv6 support

While the underlying n3n protocol has support for IPv6, the current implementation does not use this properly.

With the future of IP clearly including IPv6, and more and more places supporting it, we want to ensure that n3n also supports it.

I suspect that the memory access issue is not in the lzo library, but in the pointers that have been handed to the lzo.

          I suspect that the memory access issue is not in the lzo library, but in the pointers that have been handed to the lzo.

Are you able to collect the verbose output from the edge at the time of a crash?
Is there anything in particular that you are doing at the time?
Can you paste your (sanitised) config file?

Originally posted by @hamishcoleman in #33 (comment)

n42n / n3n Goto Github PK

n3n's Introduction

n3n

License

Quick Start

See Also

Contribution

n3n's People

Contributors

Stargazers

Watchers

Forkers

n3n's Issues

config

log

Recommend Projects

Recommend Topics

Recommend Org