View Issue Details

IDProjectCategoryView StatusLast Update
0003802GNUnettransport servicepublic2018-06-27 21:51
ReporterlynX Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status confirmedResolutionopen 
Product VersionGit master 
Summary0003802: Should GNUnet offer options for more aggressive finding of peers in the vicinity
DescriptionI have two GNUnet peers in a LAN. One has connectivity to the Internet, so it can reach out for sam (DSTJ*). The other one depends on the gateway node to find the way into the backbone. My user-who-is-too-lazy-to-read-documentation expectation would be that…

- either I find something like a "gnunet-connect" command in my path that lets me initiate a LAN broadcast or connection attempt to a specific IP
- or I expect GNUnet to self-organize by scanning connected interfaces for fellow peers

Feel free to explain the philosophy combined with a WONTFIX if I simply didn't get it. :)
TagsNo tags attached.

Activities

Bart Polot

2015-05-29 13:49

manager   ~0009154

GNUnet *does* self organize and finds peers in the LAN. This is the job for transport + core. You can check which peers you know with 'gnunet-core' or 'gnunet-transport -ni'.

For cadet, you have a WiP tool called gnunet-cadet which has similar funcionality to netcat. Remember that cadet does not speak IP!

You can start 'gnunet-cadet -o PORT' on sam/your non-internet connected peer. Then you do 'gnunet-cadet PEER_ID PORT' on your-non-inet-peer/sam. They should automagially find each other thanks to your internet-enabled peer and talk to each other. You can pipe stuff in/out if you want.

lynX

2015-05-29 14:05

developer   ~0009157

Last edited: 2015-05-29 14:08

Thanks. Hi Bart!

'gnunet-core' and 'gnunet-transport -ni' both provide empty responses.

'gnunet-cadet -o 2086' still runs as we speak. no output.

providing a PEER_ID makes sense if I want to talk to a certain node and somehow found my way to the backbone, but I shouldn't have to provide the peer id of the gateway that is in my LAN..?! You really want me to use some other protocol to bring the peer id from one machine to the other?

Feel free to reassign this to transport or core if it has nothing to do with cadet…

Bart Polot

2015-05-29 14:11

manager   ~0009159

1. Hi!

2. If gnunet-core and gnunet-transport are giving empty responses that is bad: the peers are not seeing each other. That should maybe be a separate bug (that we thought was fixed!).

3. gnunet-cadet -o PORT just starts listening on a port as a server. No output is expected. Note that this is a CADET port, not an IP port (and it's 32bit).

4. No, you absolutely should not provide the gateway's ID, this is exactly the problem that CADET is solving for you. This requires however that you are connected *somehow* to the gateway and if you're not (see point 2) you obviously won't find the gateway.

5. Yes, we want you to use GNS to translate user-friendly IDs and names to PEER_IDs. But for some testing copy/pasting IDs on ssh sessions should do...

lynX

2015-05-29 14:23

developer   ~0009163

Alright. Mantis does not give me permission to re-assign this bug to transport or core. I understand CADET is not being the problem. The two nodes merely haven't tried to meet on the route that exists between them. They gladly see each other for other proxying purposes… so how do we move forward? Can we try to find out why they didn't scan the local networks?

Bart Polot

2015-05-29 14:44

manager   ~0009168

Since the gateway peer is indeed connected to sam I assume everything is fine with that one. About the other one:

- is it in the same subnetwork as the gateway peer?

- if not, do you have IPv6 enabled?

If not, I can't imagine a way for the peers to discover one another, other than bruteforce-scanning your LAN. We use IPv6 multicast and IPv4 broadcast to announce peers, IIRC.

lynX

2015-05-29 15:04

developer   ~0009176

It's a classic firewall configuration. One peer has proxy applications running and the other peers access the Internet through the gateway.

No IPv6 involved. Why should I use legacy future technology of an Internet that will never come? I'm trying to use GNUnet instead! GNUnet is fine with thousands of scattered or isolated IP4 networks, so IPv6 is useless and obsolete.

The IP4 broadcast should work. I can telnet to port 2086 on the gateway and get a connect.

Bart Polot

2015-05-29 15:06

manager   ~0009178

> The IP4 broadcast should work. I can telnet to port 2086 on the gateway and get a connect.

Those are not synonimous... Can you please try a 'ping -b 255.255.255.255', just to make sure it's our fault?

lynX

2015-05-29 15:20

developer   ~0009181

No reply on 'ping -b 255.255.255.255'

Since my configuration is intentionally not routing via the gateway into the Internet, I don't think my configuration is wrong.

GNUnet should be able to detect network cards and break free from whatever configuration on its own. I actually want it to also find fellow GNUnet nodes in wireless vicinity – but that I would want to be asked about at installation time.

GNUnet shouldn't even need the cabling and routes I have set up. Just smell liberty in the wi-fi and go! :)

Bart Polot

2015-05-29 15:25

manager   ~0009183

> No reply on 'ping -b 255.255.255.255'

Well, there's your problem! (Unless your gateway is kernel-configured to ignore broadcast pings...)

> GNUnet should be able to detect network cards and break free from whatever configuration on its own.

You complained about NSE using a bit of your CPU. I don't think gnunet scanning your network like crazy would make you happy ;)

> GNUnet shouldn't even need the cabling and routes I have set up. Just smell liberty in the wi-fi and go! :)

I agree. Will you post your patch here or do you want svn access? ;)


Now, seriously: the peer discovery relies on UDP-broadcast. This ends at your first router. If you have both peers separated by a nat/firewall/anything-higher-than-a-switch, it won't work. Ideas/patches are welcome.

lynX

2015-05-29 15:42

developer   ~0009186

> Well, there's your problem! (Unless your gateway is kernel-configured to ignore broadcast pings...)

I have three systems connected and none of them answers the broadcast call. Maybe it's a trend and we should be prepared for it. I didn't consciously flick any kernel config parameters.

> You complained about NSE using a bit of your CPU. I don't think gnunet scanning your network like crazy would make you happy ;)

Well, the process did look like a bug at first. Whereas gnunet trying to do its job wouldn't be surprising me at all. Consider that it is a fallback behaviour. What would the downsides be of scanning private networks for fellow nodes? Should the neighbours get angry?

And what about the manual hacker's solution, offering a gnunet-connect tool so I can give gnunet a hint where to look?

Bart Polot

2015-05-29 16:02

manager   ~0009187

> I have three systems connected and none of them answers the broadcast call.
> Maybe it's a trend and we should be prepared for it. I didn't consciously flick
> any kernel config parameters.

The kernel parameters only controls the *answer* to a *ping*, see:
/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
The ping command could only confirm a bug, not disprove it.

Now, the gnunet UDP socket does listen for broadcasts, if they are reaching the computer, they should know about each other.

Can you post an ASCII art of your network, or at least describe it precisely including switches and routers?

> What would the downsides be of scanning private networks for fellow nodes?
> Should the neighbours get angry?

Very angry. Network scanning is a big no-no. But not the neighbors, just the network admin, as in "I installed this GNUnet thing and it's scanning my network, we're all gonna die!" kind of way.

> And what about the manual hacker's solution, offering a gnunet-connect tool so I can give gnunet a hint where to look?

There is a small problem there, in that transport needs to know WHO it's connecting to (the broadcast includes IDs). So it would have to be:
gnunet-connect PEER_ID IP PORT
Right now you can emulate that with
$ ssh remote system
$ gnunet-peerinfo -g
[output] <-- this output is the hello message including ID, addr and timestamp
$ exit
$ gnunet-peerinfo -p '[output]' <-- this should trigger the local peer to connect to the remote

lynX

2015-05-29 18:32

developer   ~0009189

Last edited: 2016-08-11 22:23

Okay, broadcasts now arrive. I restarted the slave peer but it still hasn't connected. If the broadcasts contain the peerid, what difference does it make to unicast the peerid on request by the user?

ASCII Art: slave node <-> gateway node <-> dsl router

If Mozilla's Firefox is allowed to scan the network for proxies, I wouldn't expect that GNUnet can't offer a "get connected now!" feature. As long as it can be reduced to a one button on the gui like thing.

lynX

2015-07-18 13:27

developer   ~0009463

Update: I had an old-fashioned ethernet hub in-between. I was told certain newer types of broadcast do not pass that sort of hardware and it takes very old-fashioned approaches for that… I might pull out the 1994 psyc prototype to see how I did it back then… I was told that would be the method that works.

lynX

2016-08-09 16:44

developer   ~0011007

> There is a small problem there, in that transport needs to know WHO it's connecting to (the broadcast includes IDs). So it would have to be:
gnunet-connect PEER_ID IP PORT

Isn't that a protocol thing? If I connect to a gnunet node without knowing which PeerId it is, what's wrong with it telling me so? It can't fake any id anyhow. Are there any privacy implications?

lynX

2016-08-09 17:19

developer   ~0011008

Last edited: 2016-08-11 22:35

I just think, if a user fires up a GNUnet node without Internet connectivity, they probably appreciate if we are more intense about trying to find a way out of the jail.

I checked the old code. It still works, but it simply enumerates the interfaces and tries to figure out which ones are physical. I could add the ability to broadcast beacons to all visible network interfaces if I figure out how to skip gnunet-vpn and gnunet-exit.

Another possibility seems to be to provide a command that sends a directed beacon to a specific IP, and the address I would try to send to would be any host that is mentioned in a *_PROXY environment variable or whatever is a gateway in the routing table.

Give me feedback if you like me to add or not add any such code.

In my case only the env var approach would have worked, but imagine how neat if an organization simply needs to put a GNUnet node on the firewall and magically everyone inside can secushare or do conversation without needing to also open up to the broken internet.

lynX

2016-08-29 08:37

developer   ~0011073

Feedback from other GNUnet devs wanted.

Christian Grothoff

2017-10-12 13:55

manager   ~0012471

Here is some relevant discussion from IRC on the matter, especially wrt GNUNET_NAT_AC_LAN:

21:09 < redfish> the issue is that run_scan asks for list of ifaces from OS, then sees an iface with addr 10.x.x.x, and those
                 IFs on 719 conclude that the transport svc needs to be notified about an IP change
21:10 < redfish> the handler in transport i refer to is in plugin_transport_tcp.c:1453
21:10 < redfish> and the comment for that handler says "our *external* ip changed"
21:11 < redfish> yet, the notification is comming for a private NATed IP of 10.x.x.x
21:11 < redfish> and the result is that this private IP are added to my HELLO string
21:13 < redfish> i point at those IFs on 719 because they feel like they should determine that the notification for 10.x.x.x
                 should NOT be sent (like in the 0000009:0000004 if cases already there)
13:45 < grothoff> redfish: see your point about 719 now. Trying to understand what might be wrong now.
13:51 < grothoff> redfish: Ah, the primary issue seems to be your interpretation of "external". Here, it merely means any IP
                  address that some other peer may theoretically use to connect to us, and as there could (theoretically) be
                  other peers in the same NATed LAN, the 10.x.x.x do count as "IP addresses other peers may care about". Note
                  that the GNUNET_NAT_AC_LAN flag is set to indicate that this is a LAN-only address.
13:52 < grothoff> While not _yet_ implemented, the plan for the "near future" is to limit disclosing such LAN-addresses to
                  peers in the LAN/WLAN (by only including them in multicast/broadcast advertisements).

Issue History

Date Modified Username Field Change
2015-05-29 13:39 lynX New Issue
2015-05-29 13:39 lynX Status new => assigned
2015-05-29 13:39 lynX Assigned To => Bart Polot
2015-05-29 13:49 Bart Polot Note Added: 0009154
2015-05-29 14:05 lynX Note Added: 0009157
2015-05-29 14:08 lynX Note Edited: 0009157
2015-05-29 14:11 Bart Polot Note Added: 0009159
2015-05-29 14:23 lynX Note Added: 0009163
2015-05-29 14:44 Bart Polot Note Added: 0009168
2015-05-29 15:04 lynX Note Added: 0009176
2015-05-29 15:06 Bart Polot Note Added: 0009178
2015-05-29 15:20 lynX Note Added: 0009181
2015-05-29 15:25 Bart Polot Note Added: 0009183
2015-05-29 15:42 lynX Note Added: 0009186
2015-05-29 16:02 Bart Polot Note Added: 0009187
2015-05-29 18:32 lynX Note Added: 0009189
2015-07-18 13:27 lynX Note Added: 0009463
2016-08-09 16:44 lynX Note Added: 0011007
2016-08-09 17:17 lynX Assigned To Bart Polot => lynX
2016-08-09 17:19 lynX Note Added: 0011008
2016-08-09 17:19 lynX Status assigned => feedback
2016-08-11 22:22 lynX Category cadet service => transport service
2016-08-11 22:22 lynX Product Version 0.10.1 => Git master
2016-08-11 22:22 lynX Summary GNUnet peers do not find each other in a LAN => Should GNUnet offer options for more aggressive finding of peers in the vicinity
2016-08-11 22:23 lynX Note Edited: 0009189
2016-08-11 22:35 lynX Note Edited: 0011008
2016-08-29 08:37 lynX Assigned To lynX => Christian Grothoff
2016-08-29 08:37 lynX Status feedback => assigned
2016-08-29 08:37 lynX Note Added: 0011073
2016-08-29 08:37 lynX Status assigned => feedback
2017-10-12 13:55 Christian Grothoff Note Added: 0012471
2018-06-27 21:51 Christian Grothoff Assigned To Christian Grothoff =>
2018-06-27 21:51 Christian Grothoff Priority high => normal
2018-06-27 21:51 Christian Grothoff Status feedback => confirmed
2018-06-27 21:51 Christian Grothoff View Status private => public