View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003802 | GNUnet | transport service | public | 2015-05-29 13:39 | 2018-06-27 21:51 |
| Reporter | lynX | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Product Version | Git master | ||||
| Summary | 0003802: Should GNUnet offer options for more aggressive finding of peers in the vicinity | ||||
| Description | I 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. :) | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
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… |
|
|
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... |
|
|
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? |
|
|
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. |
|
|
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. |
|
|
> 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? |
|
|
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! :) |
|
|
> 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. |
|
|
> 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? |
|
|
> 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 |
|
|
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. |
|
|
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. |
|
|
> 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? |
|
|
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. |
|
|
Feedback from other GNUnet devs wanted. |
|
|
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 ~4 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). |
| 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 |
