Building applications without AGPL restriction
Hi, I've been interested in GNUnet for quite a while now. Recently I got time to learn the API and be able to build a C++ wrapper for some of the subsystems. It's fun! Now I want to build applications using GNUnet. As I understand, GNUnet is licensed under AGPL thus my application also has to be AGPL. But it may not be suitable for my use case. For example I want to show GNUnet stats on my personal website. Or some REST that exposes GNUnet metadata, FS proxy for download, DHT get/put, etc.. Which enable others to have easy-ish access to GNUnet. But I don't want to force them to also use AGPL. (Or even some security/commercial application in the future.) Is it possible to let applications be licensed under BSD/MIT/LGPL (or even via special clauses in GNUnet) without complicating the code? I know this is a long shot. But no harm to ask. Best Regards, Martin
Unexpectly short DHT entry lifetime
Hi all, I've been messing around with GNUnet and building fun applications with it. One thing I noticed recently. Looking at the source code of gnunet-dht-put. The default lifetime of a DHT entry should be an hour[1]. But when I run the following command. The key `hello` is not found via the get command just 5 minutes or less later. > gnunet-dht-put -k "hello" -d "world" # Set hello to world > # Running immediately after set works > gnunet-dht-get -k "hello" -T 1000 Result 0, type 8: world > sleep 300 > gnunet-dht-get -k "hello" -T 1000 # No key found [1]: https://git.gnunet.org/gnunet.git/tree/src/dht/gnunet-dht-put.c#n235 Am I doing something wrong? My application needs the DHT to bootstrap group information. Best, Martin
Re: Unexpectly short DHT entry lifetime
Hi Martin, I increased the cache and routing table size and that seems to do the trick. Didn't try restarting GNUnet on it's own. Not sure what fixed it. Best --- Original Message --- On Tuesday, May 9th, 2023 at 11:38 PM, Schanzenbach, Martin wrote: > Hi Martin, > > I just tested this and I don't get results at all. Not even when I am > not connected to the network. > This may be related to some recent changes to the DHT. > > BR > > Am 09.05.23 um 08:02 schrieb marty1885: > > > Hi all, > > > > I've been messing around with GNUnet and building fun applications with it. > > One thing I noticed recently. Looking at the source code of gnunet-dht-put. > > The default lifetime of a DHT entry should be an hour1. But when I run the > > following command. The key `hello` is not found via the get command just 5 > > minutes or less later. > > > > > gnunet-dht-put -k "hello" -d "world" # Set hello to world > > > # Running immediately after set works > > > gnunet-dht-get -k "hello" -T 1000 > > > Result 0, type 8: > > > world > > > sleep 300 > > > gnunet-dht-get -k "hello" -T 1000 > > > # No key found > > > > Am I doing something wrong? My application needs the DHT to bootstrap group > > information. > > > > Best, > > Martin
New node won't connect to existing nodes without manually providing HELLO message
Hi, Sorry it's me again. Today I was setting up 2 new nodes at a new location for my experiments. However, I fail over and over to connect them to the GNUnet network. I've tried adding my existing nodes via hello using the peerinfo tool. But the node 1. takes about 30min to establish a connection to the other node. If that happens at all. 2. Afterwards, it node is not making new peers. Thus is the node I added manually goes down, that node is also disconnected from GNUnet. Also, I have tried bootstraping off my node's hostlist. I have also tried enabling the -e -b flag of the hostlist daemon. Still can't get the node to connect to others. How can I solve this? Is there a drastic change recently leading to bootstrapping so difficult? Hopefully these information helps Currently, the new nodes are setup with connections to my other node ❯ gnunet-core Sun Jul 23 14:06:48 2023: connection established CCXH (timeout in 299 s) However, I can find many more peers in peerinfo Peer `V8XXK9GAN5ZJFRFQP8MQX3D83BZTSBQVHKWWD0JPE63Z821906EG' Peer `7WRDFAMRXJ14K752Z2SF9SSD3VR5XAVKPEBJ19ZKA2M6QHT3YBV0' But gnunet-cadet -P shows I have no path to all of them (besides the ones I added manually). 008Q3SKSXDAQDBMKZSJ4VHPVV2ZNG9PF783RA4132SD96PRJZ1Z0 tunnel: N, paths: 0 CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG tunnel: N, paths: 1 5GYZVBTD5K0WCSVQGRHG18ZDBC3TT6905M34R9WKWQZHD906PDBG tunnel: N, paths: 0 DSTJBRRKZ8TBW3FGK6B0M5QXWT9WYNZ45H5MCV4HY7ST64Q8T9F0 tunnel: N, paths: 0 DRD47JG4E9X1B67TXHV9M6V03RYD415FGCSA63X11F23NRRXDQFG tunnel: N, paths: 0 1YGNJFY3VM6VQYY9M8K80ZZ9233TCBSZDQG93NSJM7J0T47D9VY0 tunnel: N, paths: 1 Y924NSHMMZ1N1SQCE5TXF93ED6S6JY311K0QT86G9WJC68F6XVZ0 tunnel: N, paths: 0 2WWVHMQX4DY90K3N9BFJXSZZ6F7E85VCJ66MYD1RG5BGMXBAY9FG tunnel: N, paths: 0 V8XXK9GAN5ZJFRFQP8MQX3D83BZTSBQVHKWWD0JPE63Z821906EG tunnel: N, paths: 0 VQPDVF1QZ7QV6JQATFATYBSA3SAQQ0F6VM5VZK264S5EVXPB8ZX0 tunnel: N, paths: 0 KW7VNM3R256MCFBA5BJ644NXQC9NX58VRFBSQB15M76B4YTQR10G tunnel: N, paths: 0 7XF202E96N2THGAGXZ00M15GJGH7K4V1S29KHWV3031WM96PE16G tunnel: N, paths: 0 Best, Martin
Re: Any peers running 0.20?
Hi Kevin, I am not sure about the NAT part. But I am running 0.20 on a public IP address. My node ID is CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG Can you try adding `http://clehaxze.tw:9876/` to your hostlist provider? I've opened mine for others to use too. Martin > gnunet-core Mon Dec 18 10:12:58 2023: connection established 5GYZ (timeout in 298 s) Mon Dec 18 10:12:58 2023: connection established 008Q (timeout in 299 s) Mon Dec 18 10:12:58 2023: connection established FGXY (timeout in 299 s) Mon Dec 18 10:12:58 2023: connection established 1YGN (timeout in 262 s) Mon Dec 18 10:12:58 2023: connection established 1T8F (timeout in 296 s) Mon Dec 18 10:12:58 2023: connection established DESN (timeout in 299 s) Mon Dec 18 10:12:58 2023: connection established 51V4 (timeout in 290 s) Mon Dec 18 10:12:58 2023: connection established DRD4 (timeout in 297 s) Mon Dec 18 10:12:58 2023: connection established SMS8 (timeout in 200 s) gnunet-cadet -P 008Q3SKSXDAQDBMKZSJ4VHPVV2ZNG9PF783RA4132SD96PRJZ1Z0 tunnel: N, paths: 1 RJCSG4Z1AMS9PFTCQBX95CWRTR3BRD0FCRXQ90CCA1Y31KEQH47G tunnel: N, paths: 1 SMS8ADJPF83165FG78EEZ0EJCNCDDBQPQR5S5KN56NKG2W3BCDCG tunnel: N, paths: 1 1T8FY3QRXC4XJWWG8X7T2NYNVAM00CNVDTE4AQQEVB6PQ3ED8MC0 tunnel: N, paths: 1 1YGNJFY3VM6VQYY9M8K80ZZ9233TCBSZDQG93NSJM7J0T47D9VY0 tunnel: Y, paths: 2 JJ1N7W3C36XQT272JTXTD331H8196V09C37BM7Y433WXZ8ZA82DG tunnel: Y, paths: 0 AKN0F88HH4BQY1TB5Z2V6PRF3KWKFCCRZBJYVH0BD7P4S1D0NJF0 tunnel: N, paths: 2 V8XXK9GAN5ZJFRFQP8MQX3D83BZTSBQVHKWWD0JPE63Z821906EG tunnel: N, paths: 0 KHHRWZ0MYZVPWR5NQGFV5T15GE0M01TP4WJ8ZKRENYA8TZE038A0 tunnel: Y, paths: 0 KW7VNM3R256MCFBA5BJ644NXQC9NX58VRFBSQB15M76B4YTQR10G tunnel: Y, paths: 0 CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG tunnel: N, paths: 0 WH8J95E3GVC9C54G0AV7EYY744TZ7NV4TXDGFWN5XCM770CN0HT0 tunnel: N, paths: 2 MHBHB5BH2V877T1W8CE9BNXTV3P4Q43H12J3Q7DQKP2S9QFJ301G tunnel: Y, paths: 0 CR0V1C1P529RDWKMSP64MGWPT5E8VZARYZH2J5B6W2YED66WWKK0 tunnel: N, paths: 0 51V4ZGBXA7E5WQF9WHW5KWNYYP7TRA10FWF1SPEVZRTC5G2K75N0 tunnel: N, paths: 1 DESNPFW7GF0NT3XZ9GJ5JPK18JF6DFZ9PD01QS31X8T93AN8X12G tunnel: N, paths: 1 5GYZVBTD5K0WCSVQGRHG18ZDBC3TT6905M34R9WKWQZHD906PDBG tunnel: N, paths: 4 NNQMC4284WYAKYKSK8WE4T4NJBC4SARXC1MR67DPRVAVNJJRYP6G tunnel: Y, paths: 0 DRD47JG4E9X1B67TXHV9M6V03RYD415FGCSA63X11F23NRRXDQFG tunnel: N, paths: 1 DSTJBRRKZ8TBW3FGK6B0M5QXWT9WYNZ45H5MCV4HY7ST64Q8T9F0 tunnel: N, paths: 0 Y924NSHMMZ1N1SQCE5TXF93ED6S6JY311K0QT86G9WJC68F6XVZ0 tunnel: N, paths: 0 7EQ9XKYTQSDZZ735A2XQ5YG7RBN4VNDBJ1EGX7QXVQDF2SGGENXG tunnel: N, paths: 1 FGXY5RP0YJBS4XSMG0ERWBE4YQPWQ712VSJ6PJ6FSVDQDDXE5NC0 tunnel: N, paths: 1 QRKT0506TTR7TG940NNYFPX5GCT83YZQAAYA81TE48XYG5WD34AG tunnel: Y, paths: 0 On Monday, December 18th, 2023 at 7:20 AM, Kevin Steen wrote: > Greetings > > Firstly, congratulations on getting the RFC published! > > I've managed to get GNUnet v0.20 running by installing from the Debian > Testing repository, but it doesn't seem to be connecting to any peers. > Are there any compatible peers running, or is everyone running an > incompatible version straight from source? > > The hostlist URL used by this version ("http://v15.gnunet.org/hostlist";) > refuses connections, but I found "https://gnunet.io/hostlist"; which > seems to return some data after I added it to the config. > > `gnunet-cadet -P` gives me: > Y924NSHMMZ1N1SQCE5TXF93ED6S6JY311K0QT86G9WJC68F6XVZ0 tunnel: N, paths: 0 > V8XXK9GAN5ZJFRFQP8MQX3D83BZTSBQVHKWWD0JPE63Z821906EG tunnel: N, paths: 0 > DSTJBRRKZ8TBW3FGK6B0M5QXWT9WYNZ45H5MCV4HY7ST64Q8T9F0 tunnel: N, paths: 0 > QTJ1MHPKXY1HTRJGBP1WDETBGFZ8QK27RDTNBMZ5JBV6TPY2YYWG tunnel: N, paths: 0 > > and `gnunet-core` returns nothing. > > If someone could post the output of `gnunet-peerinfo -g` I would > appreciate it. > > I'm behind a CG-NAT setup, so outgoing connections only - will GNUnet be > able to operate at all? > > Thanks in advance > -Kevin > > -- > Following the easy path, strewn with treats, is how animals end up in cages.
Failing to resolve gnunet.org via GNS
Hi, I found that I can't resolve gnunet.org via GNS.The following command simply do not finish. I'm resolving gnunet.org in my unit test to make sure my GNS resolving works. Is the node hosting that domain down? Or something happened? Or it got upgraded to an incomparable version with the official 0.20? ``` ❯ gnunet-gns -u gnunet.org ``` I am peer CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG. And I do see I'm connected to other nodes. I don't think network connection is the issue. Martin
Re: Failing to resolve gnunet.org via GNS
Hi, I see the FCFS page has a new zone key now. I still got the gnunet.org and pin zone in my config. I believe this is from an old(?) configuration and the old pin zone is discontinued? Can you confirm? ``` ❯ gnunet-config -s gns .gnunet.org = 000G0047M3HN599H57MPXZK4VB59SWK4M9NRD68E1JQFY3RWAHDMKAPN30 .pin = 000G001MF6DVMZZ4Y8XRZQDXM1PB3D3VGEK29ZHXBA57EPSNW1QBPKT8J0 INTERCEPT_DNS = NO MAX_PARALLEL_BACKGROUND_QUERIES = 1000 UNIX_MATCH_GID = YES UNIX_MATCH_UID = NO UNIXPATH = $GNUNET_RUNTIME_DIR/gnunet-service-gns.sock BINARY = gnunet-service-gns HOSTNAME = localhost IMMEDIATE_START = YES START_ON_DEMAND = YES ``` Best, Martin On Sunday, January 14th, 2024 at 3:54 PM, Schanzenbach, Martin wrote: > Hi, > > "gnunet.org" is not configured by default through any start zone > https://www.rfc-editor.org/rfc/rfc9498.html#name-start-zones > > You can look at all suffix-to-zone mappings on your system using > > $ gnunet-config -s gns > > What is configured is our current registrar, as "gnunet.gns.alt". > Basically, zones registered at https://fcfs.gnunet.org are reachable > with that suffix. > You can try registering your own zone and try it. > You can also try resolving names of other user's zones (if you know any). > > We currently do not publish the gnunet.org IP addresses in GNS I think. > The unit tests locally configures gnunet.org. > > I hope that helps. > > BR > Martin > > > On 14.01.24 08:35, marty1885 wrote: > > > Hi, > > > > I found that I can't resolve gnunet.org via GNS.The following command > > simply do not finish. I'm resolving gnunet.org in my unit test to make sure > > my GNS resolving works. Is the node hosting that domain down? Or something > > happened? Or it got upgraded to an incomparable version with the official > > 0.20? > > > > `❯ gnunet-gns -u gnunet.org ` > > > > I am peer CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG. And I do > > see I'm connected to other nodes. I don't think network connection is the > > issue. > > > > Martin
Cannot bootstrap GNUnet 0.21.0
Hi all, I've just built and installed the new GNUnet 0.21. But my node isn't connected to any peer after hours of waiting. Running gnunet-core shows no node is connected to me. ``` ❯ gnunet-core (no output) ``` I have also checked `iotop` and can confirm gnunet-service-transport isn't doing much IO. While I was expecting at least hundreds of Kbps from experience in the past. How can I connect to the network? Please let me know what information I can provide to diagnose the issue. Best, Martin
Re: Cannot bootstrap GNUnet 0.21.0
Thanks for the reply. I tried a few commands and still feels like my node is really not connected. DHT can't put, NSE returns a very small network size and GNS cannot resolve. Is this expected? ``` ❯ gnunet-core -si Current local peer identity: CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG (no further output) ❯ gnunet-dht-put -k "hello" -d "world" -e 40m (hangs, this used to return almost immidately) ❯ gnunet-nse 1710047156276913 1.688203 0.755488 1.474102 ❯ gnunet-gns -u gnunet.gns.alt -t PKEY >>> Looking for `PKEY' records under `gnunet.gns.alt' (no output) ``` On Saturday, March 9th, 2024 at 11:39 PM, Schanzenbach, Martin wrote: > Hi, > > the behaviour of gnunet-core changed. You can check the new switches > with --help. > Long-term core connections are know to be problematic behind NATs, still. > But with a freshly started peer, "gnunet-core -i" should give you your > peer id, "gnunet-core -s" the connections (you can also combine the > switches). > The command should probably output the help when called without arguments. > > BR > Martin > > On 09.03.24 14:55, marty1885 wrote: > > > Hi all, > > > > I've just built and installed the new GNUnet 0.21. But my node isn't > > connected to any peer after hours of waiting. Running gnunet-core shows no > > node is connected to me. > > > > `❯ gnunet-core (no output)` > > > > I have also checked `iotop` and can confirm gnunet-service-transport isn't > > doing much IO. While I was expecting at least hundreds of Kbps from > > experience in the past. > > > > How can I connect to the network? Please let me know what information I can > > provide to diagnose the issue. > > > > Best, > > Martin
Re: Cannot bootstrap GNUnet 0.21.0
I deleted the databases for namestore and peerstore to get all processes running (peerstore and namestore was failing). But still no peer connections. ``` ❯ gnunet-arm -I Services (excluding stopped services): (started: 23 / stopped: 22) cadet (binary='gnunet-service-cadet', status=started) core (binary='gnunet-service-core', status=started) datastore (binary='gnunet-service-datastore', status=started) dht (binary='gnunet-service-dht', status=started) fs (binary='gnunet-service-fs', status=started) gns (binary='gnunet-service-gns', status=started) hostlist (binary='gnunet-daemon-hostlist', status=started) identity (binary='gnunet-service-identity', status=started) namecache (binary='gnunet-service-namecache', status=started) namestore (binary='gnunet-service-namestore', status=started) nat (binary='gnunet-service-nat', status=started) nse (binary='gnunet-service-nse', status=started) peerstore (binary='gnunet-service-peerstore', status=started) reclaim (binary='gnunet-service-reclaim', status=started) rest (binary='gnunet-rest-server', status=started) revocation (binary='gnunet-service-revocation', status=started) rps (binary='gnunet-service-rps', status=started) setu (binary='gnunet-service-setu', status=started) statistics (binary='gnunet-service-statistics', status=started) topology (binary='gnunet-daemon-topology', status=started) transport (binary='gnunet-service-transport', status=started) communicator-tcp (binary='gnunet-communicator-tcp', status=started) zonemaster (binary='gnunet-service-zonemaster', status=started) ``` On Sunday, March 10th, 2024 at 3:00 PM, Schanzenbach, Martin wrote: > Hi, > > what does gnunet-arm -I output? Are all of the services running? > For example, the peerstore database layout changed, so you probably have > to delete your old database ($HOME/.local/share/gnunet/peerstore/sqlite.db). > > The road to a stable TNG will also be bumpy, so we rely on reports such > as this to iron out the remaining bugs with it. > > BR > Martin > > On 10.03.24 06:08, marty1885 wrote: > > > Thanks for the reply. > > > > I tried a few commands and still feels like my node is really not > > connected. DHT can't put, NSE returns a very small network size and GNS > > cannot resolve. > > > > Is this expected? > > > > ``` > > ❯ gnunet-core -si > > Current local peer identity: > > CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG > > (no further output) > > > > ❯ gnunet-dht-put -k "hello" -d "world" -e 40m > > (hangs, this used to return almost immidately) > > > > ❯ gnunet-nse > > 1710047156276913 1.688203 0.755488 1.474102 > > > > ❯ gnunet-gns -u gnunet.gns.alt -t PKEY > > > > > > > Looking for `PKEY' records under` gnunet.gns.alt' > > > > > (no output) > > > > > ``` > > > > On Saturday, March 9th, 2024 at 11:39 PM, Schanzenbach, Martin > > schan...@gnunet.org wrote: > > > > > Hi, > > > > > > the behaviour of gnunet-core changed. You can check the new switches > > > with --help. > > > Long-term core connections are know to be problematic behind NATs, still. > > > But with a freshly started peer, "gnunet-core -i" should give you your > > > peer id, "gnunet-core -s" the connections (you can also combine the > > > switches). > > > The command should probably output the help when called without arguments. > > > > > > BR > > > Martin > > > > > > On 09.03.24 14:55, marty1885 wrote: > > > > > > > Hi all, > > > > > > > > I've just built and installed the new GNUnet 0.21. But my node isn't > > > > connected to any peer after hours of waiting. Running gnunet-core shows > > > > no node is connected to me. > > > > > > > > `❯ gnunet-core (no output)` > > > > > > > > I have also checked `iotop` and can confirm gnunet-service-transport > > > > isn't doing much IO. While I was expecting at least hundreds of Kbps > > > > from experience in the past. > > > > > > > > How can I connect to the network? Please let me know what information I > > > > can provide to diagnose the issue. > > > > > > > > Best, > > > > Martin
Re: Cannot bootstrap GNUnet 0.21.0
Hi, Yes. I've restarted GNUnet several times. For safety I've restarted it once again after reeving your reply. Still can't bootstrap. Martin On Tuesday, March 12th, 2024 at 10:15 PM, Schanzenbach, Martin wrote: > Hi, > > did you try again the last few days? > We are currently observing better connectivity after fixing a > configuration mistake on the bootstrap peer. > > Best > Martin > > On 10.03.24 15:41, marty1885 wrote: > > > I deleted the databases for namestore and peerstore to get all processes > > running (peerstore and namestore was failing). But still no peer > > connections. > > > > `❯ gnunet-arm -I Services (excluding stopped services): (started: 23 / > > stopped: 22) cadet (binary='gnunet-service-cadet', status=started) core > > (binary='gnunet-service-core', status=started) datastore > > (binary='gnunet-service-datastore', status=started) dht > > (binary='gnunet-service-dht', status=started) fs > > (binary='gnunet-service-fs', status=started) gns > > (binary='gnunet-service-gns', status=started) hostlist > > (binary='gnunet-daemon-hostlist', status=started) identity > > (binary='gnunet-service-identity', status=started) namecache > > (binary='gnunet-service-namecache', status=started) namestore > > (binary='gnunet-service-namestore', status=started) nat > > (binary='gnunet-service-nat', status=started) nse > > (binary='gnunet-service-nse', status=started) peerstore > > (binary='gnunet-service-peerstore', status=started) reclaim > > (binary='gnunet-service-reclaim', status=started) rest > > (binary='gnunet-rest-server', status=started) revocation > > (binary='gnunet-service-revocation', status=started) rps > > (binary='gnunet-service-rps', status=started) setu > > (binary='gnunet-service-setu', status=started) statistics > > (binary='gnunet-service-statistics', status=started) topology > > (binary='gnunet-daemon-topology', status=started) transport > > (binary='gnunet-service-transport', status=started) communicator-tcp > > (binary='gnunet-communicator-tcp', status=started) zonemaster > > (binary='gnunet-service-zonemaster', status=started)` > > > > On Sunday, March 10th, 2024 at 3:00 PM, Schanzenbach, Martin > > schan...@gnunet.org wrote: > > > > > Hi, > > > > > > what does gnunet-arm -I output? Are all of the services running? > > > For example, the peerstore database layout changed, so you probably have > > > to delete your old database > > > ($HOME/.local/share/gnunet/peerstore/sqlite.db). > > > > > > The road to a stable TNG will also be bumpy, so we rely on reports such > > > as this to iron out the remaining bugs with it. > > > > > > BR > > > Martin > > > > > > On 10.03.24 06:08, marty1885 wrote: > > > > > > > Thanks for the reply. > > > > > > > > I tried a few commands and still feels like my node is really not > > > > connected. DHT can't put, NSE returns a very small network size and GNS > > > > cannot resolve. > > > > > > > > Is this expected? > > > > > > > > ``` > > > > ❯ gnunet-core -si > > > > Current local peer identity: > > > > CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG > > > > (no further output) > > > > > > > > ❯ gnunet-dht-put -k "hello" -d "world" -e 40m > > > > (hangs, this used to return almost immidately) > > > > > > > > ❯ gnunet-nse > > > > 1710047156276913 1.688203 0.755488 1.474102 > > > > > > > > ❯ gnunet-gns -u gnunet.gns.alt -t PKEY > > > > > > > > > > > Looking for `PKEY' records under` gnunet.gns.alt' > > > > > > > (no output) > > > > > > > ``` > > > > > > > > On Saturday, March 9th, 2024 at 11:39 PM, Schanzenbach, Martin > > > > schan...@gnunet.org wrote: > > > > > > > > > Hi, > > > > > > > > > > the behaviour of gnunet-core changed. You can check the new switches > > > > > with --help. > > > > > Long-term core connections are know to be problematic behind NATs, > > > > > still. > > > > > But with a freshly started peer, "gnunet-core -i" should give you your > > > > > peer id, "gnunet-core -s" the connections (you can also combine the > > > > > switches). > > > > > The command should probably output the help when called without > > > > > arguments. > > > > > > > > > > BR > > > > > Martin > > > > > > > > > > On 09.03.24 14:55, marty1885 wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > I've just built and installed the new GNUnet 0.21. But my node > > > > > > isn't connected to any peer after hours of waiting. Running > > > > > > gnunet-core shows no node is connected to me. > > > > > > > > > > > > `❯ gnunet-core (no output)` > > > > > > > > > > > > I have also checked `iotop` and can confirm > > > > > > gnunet-service-transport isn't doing much IO. While I was expecting > > > > > > at least hundreds of Kbps from experience in the past. > > > > > > > > > > > > How can I connect to the network? Please let me know what > > > > > > information I can provide to diagnose the issue. > > > > > > > > > > > > Best, > > > > > > Martin
Failing to build GNUnet 0.22.0 on Arch Linux with incorrect detection of libgcrypt version
Hi, Congrats for releasing 0.22.0. I tried to build the code on my Arch Linux server and ran into the following error during configuration. GNUnet is unhappy that my libgcrypt is too old and wants at least version 1.6.0. checking for struct tm.tm_gmtoff... yes checking for getaddrinfo_a in -lanl... yes checking for libgcrypt-config... no checking for LIBGCRYPT - version >= 1.6.0... no checking for gcc options needed to detect all undeclared functions... none needed checking whether gcry_mpi_set_opaque_copy is declared... yes configure: error: You need libgcrypt to build this program. At least version 1.6.0 (API 1) is required. However, pacman says I have version 1.11.0-2. pacman -Qi libgcrypt | head -n 2 Name: libgcrypt Version : 1.11.0-2 Is there anything I can do to solve this problem? Hope my system info helps resolving this issue. OS: Arch Linux ARM Compile: GCC 14.1 GNUnet: 0.22.0 libgcrypt: 1.11.0 autotools: 2.72 BR, Martin
Re: Failing to build GNUnet 0.22.0 on Arch Linux with incorrect detection of libgcrypt version
Hi, Sorry nevermind. I checked out the wrong tag. My apologies for the inconvenience. BR, Martin Sent with Proton Mail secure email. On Monday, September 2nd, 2024 at 10:34 PM, Christian Grothoff wrote: > Please provide (a gzipped/compressed) attachment with your config.log, > that has key diagnostics for us. Thanks! -Christian > > On 9/2/24 4:31 PM, marty1885 wrote: > > > Hi, > > > > Congrats for releasing 0.22.0. I tried to build the code on my Arch Linux > > server and ran into the following error during configuration. GNUnet is > > unhappy that my libgcrypt is too old and wants at least version 1.6.0. > > > > checking for struct tm.tm_gmtoff... yes > > checking for getaddrinfo_a in -lanl... yes > > checking for libgcrypt-config... no > > checking for LIBGCRYPT - version >= 1.6.0... no > > checking for gcc options needed to detect all undeclared functions... none > > needed > > checking whether gcry_mpi_set_opaque_copy is declared... yes > > configure: error: You need libgcrypt to build this program. > > At least version 1.6.0 (API 1) is required. > > > > However, pacman says I have version 1.11.0-2. > > > > pacman -Qi libgcrypt | head -n 2 > > Name : libgcrypt > > Version : 1.11.0-2 > > > > Is there anything I can do to solve this problem? Hope my system info helps > > resolving this issue. > > > > OS: Arch Linux ARM > > Compile: GCC 14.1 > > GNUnet: 0.22.0 > > libgcrypt: 1.11.0 > > autotools: 2.72 > > > > BR, > > Martin