View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002805 | GNUnet | transport service | public | 2013-02-22 07:18 | 2013-07-10 23:59 |
| Reporter | bratao | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | W32 | OS | Windows | OS Version | 8 |
| Product Version | Git master | ||||
| Target Version | 0.9.5a | Fixed in Version | 0.9.5a | ||
| Summary | 0002805: gnunet-peerinfo offer hello don't make two clients connect. | ||||
| Description | Hello, From my understanding if we offer a hello ( generated by gnunet-peerinfo -g) to gnunet-peerinfo -p HELLO , gnunet should try to connect those two clients. But with 0.9.5a and SVN I can't make this happen. | ||||
| Additional Information | Feb 21 22:12:17-00000000000036871666 util-2768 INFO Accepting connection from `[::1]:47699': 0x62f458 Feb 21 22:12:17-00000000000036871666 util-2768 INFO Accepting connection from `127.0.0.1:47700': 0x62f848 Feb 21 22:13:39-00000000000036953527 gnunet-peerinfo-4228 INFO Starting transport plugins `tcp udp' Feb 21 22:13:39-00000000000036953527 gnunet-peerinfo-4228 INFO Loading `tcp' transport plugin Feb 21 22:13:39-00000000000036953527 gnunet-peerinfo-4228 INFO Loading `udp' transport plugin Feb 21 22:13:39-00000000000036953530 util-4228 INFO Trying to connect to `[::1]:2090' (0x5c7b58) Feb 21 22:13:39-00000000000036953531 util-4228 INFO Trying to connect to `127.0.0.1:2090' (0x5c7b58) Feb 21 22:13:39-00000000000036953531 util-3024 INFO Accepting connection from `[::1]:47726': 0x52e0c0 | ||||
| Tags | No tags attached. | ||||
|
|
There are quite a lot of services included in this process: Peerinfo: providing HELLO Topology: making the decision to whom to connect Transport + Plugins: connecting peers Each component on it's own seems to work ... at least tests pass. And for transport I can say: No major changes in transport in SVN head and 0.9.5.a besides the crypto stuff |
|
|
Well more information as I remember: -The client show in peerinfo as a known peer after this, but no connection attempt is ever made. Even after restarts. The only way I found to put two clients to talk, was using one as hostlist server and asking the another one to bootstrap from that hostlist. |
|
|
Tested, worked out of the box. - 2 peer, same machine: - no hellos in service home - no connections gnunet-peerinfo -c peer1.conf -s I am peer `KTS6BAF9VHNUP1JFEFV19IBC9MTAGSH4PK43E3CUUBLNTIUFFHRT4HPB8H6GH607IC1NNOTJ7NEE85CARM3QCNB5QJR5KOHRMCHLC7O'. gnunet-peerinfo -c peer2.conf -s I am peer `4ISB03GNKKO73NPJ1SLEUT63SP1AJNMQT49CFU80NDD61AEQH1S7S1HNHUL3272U3VQ6I3SH7ICFR3HU74G1T4BBA1KDFFEHIFE6QAO'. |
|
|
gnunet-peerinfo -c peer1.conf -g gnunet://hello/04302060SD70K06D5EM02351I8NJ71G54448FTMT002DLV0AC94HKIV6LOP14T0I9EHE05TV1FQFIQN48QT90L79642BKSMLFM8VF26M4LFIIVJBU82L9E26471AJ9JHCSLLL5R2J3NIIOD87RNKQ8BVPTS16Q9D3J3JV4VUBF9ROAT8NPBMS4SVV966SN4LBUI3N2JKC3OTKKK37JKA78O6IQUM79FN167J8FONA8UH0OBUDBLCICBCOVUECHT0GATH9BP82TBTCJ6VON1L257SGT0NDNSBKD76PRLB4IFRD3PQR1AEGD27505V7I2EP2HCB7DA86N5GJ4Q1642QETAC8F9RFGUVE4C95IF3C7V89E35954TQ3CNIA0H028H1HH3QC3MAD6EPFQVNIODFGB726E0CL7040G000!20130315023024!udp!10.0.2.15:2086!20130315023024!tcp!10.0.2.15:2086 gnunet-peerinfo -c peer2.conf -p 'gnunet://hello/04302060SD70K06D5EM02351I8NJ71G54448FTMT002DLV0AC94HKIV6LOP14T0I9EHE05TV1FQFIQN48QT90L79642BKSMLFM8VF26M4LFIIVJBU82L9E26471AJ9JHCSLLL5R2J3NIIOD87RNKQ8BVPTS16Q9D3J3JV4VUBF9ROAT8NPBMS4SVV966SN4LBUI3N2JKC3OTKKK37JKA78O6IQUM79FN167J8FONA8UH0OBUDBLCICBCOVUECHT0GATH9BP82TBTCJ6VON1L257SGT0NDNSBKD76PRLB4IFRD3PQR1AEGD27505V7I2EP2HCB7DA86N5GJ4Q1642QETAC8F9RFGUVE4C95IF3C7V89E35954TQ3CNIA0H028H1HH3QC3MAD6EPFQVNIODFGB726E0CL7040G000!20130315023024!udp!10.0.2.15:2086!20130315023024!tcp!10.0.2.15:2086' Mar 14 15:31:24-014062 util-19058 INFO Accepting connection from `<unbound UNIX client>': 0xf0b950 Mar 14 15:31:24-014288 gnunet-peerinfo-19063 INFO Starting transport plugins `tcp udp' Mar 14 15:31:24-014835 gnunet-peerinfo-19063 INFO Loading `tcp' transport plugin Mar 14 15:31:24-015208 gnunet-peerinfo-19063 INFO Loading `udp' transport plugin Mar 14 15:31:24-016968 util-19054 INFO Trying to connect to `10.0.2.15:2086' (0x8e9940) Mar 14 15:31:24-019526 util-19059 INFO Accepting connection from `<unbound UNIX client>': 0xc41140 Mar 14 15:31:24-019826 util-19059 INFO Accepting connection from `<unbound UNIX client>': 0xc41630 gnunet@gnunet-VirtualBox:~$ Mar 14 15:31:24-027853 util-19054 INFO Accepting connection from `10.0.2.15:54129': 0x8e9ef0 Mar 14 15:31:29-018407 transport-19054 INFO We are now connected to peer `KTS6' and 1 peers in total Mar 14 15:31:29-067165 util-19059 INFO Accepting connection from `<unbound UNIX client>': 0xc43c20 gnunet@gnunet-VirtualBox:~$ gnunet-core -c peer1.conf Peer `4ISB03GNKKO73NPJ1SLEUT63SP1AJNMQT49CFU80NDD61AEQH1S7S1HNHUL3272U3VQ6I3SH7ICFR3HU74G1T4BBA1KDFFEHIFE6QAO' gnunet@gnunet-VirtualBox:~$ gnunet-core -c peer2.conf Peer `KTS6BAF9VHNUP1JFEFV19IBC9MTAGSH4PK43E3CUUBLNTIUFFHRT4HPB8H6GH607IC1NNOTJ7NEE85CARM3QCNB5QJR5KOHRMCHLC7O' |
|
|
Technically, giving the HELLO does not necessarily create a connection --- it is likely, if the HELLO is new and thus should be validated; however, the way to ask two peers to connect is usually to first give a HELLO and then call gnuent-transport -C PID. Still, the behavior you described is odd. |
|
|
I'm setting this to resolved/no change required as we either have normal behavior (peers MAY not connect despite your peerinfo interaction) or because Matthias could not reproduce this. Also, again, code changed quite a bit. If you can still reproduce actually problematic behavior, please file a more detailed report (and try using gnunet-transport -C to connect peers in addition to passing HELLOs to peerinfo). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-02-22 07:18 | bratao | New Issue | |
| 2013-02-22 07:18 | bratao | Status | new => assigned |
| 2013-02-22 07:18 | bratao | Assigned To | => Matthias Wachs |
| 2013-02-22 09:31 | Matthias Wachs | Assigned To | Matthias Wachs => |
| 2013-02-22 09:35 | Matthias Wachs | Note Added: 0006893 | |
| 2013-02-22 18:45 | bratao | Note Added: 0006894 | |
| 2013-03-13 23:55 | Christian Grothoff | Status | assigned => acknowledged |
| 2013-03-14 15:32 | Matthias Wachs | Note Added: 0006979 | |
| 2013-03-14 15:34 | Matthias Wachs | Note Added: 0006980 | |
| 2013-03-14 15:35 | Matthias Wachs | Status | acknowledged => feedback |
| 2013-06-03 13:21 | Christian Grothoff | Note Added: 0007150 | |
| 2013-07-10 23:59 | Christian Grothoff | Note Added: 0007229 | |
| 2013-07-10 23:59 | Christian Grothoff | Status | feedback => resolved |
| 2013-07-10 23:59 | Christian Grothoff | Resolution | open => no change required |
| 2013-07-10 23:59 | Christian Grothoff | Product Version | => Git master |
| 2013-07-10 23:59 | Christian Grothoff | Fixed in Version | => 0.9.5a |
| 2013-07-10 23:59 | Christian Grothoff | Target Version | => 0.9.5a |
| 2013-07-10 23:59 | Christian Grothoff | Status | resolved => closed |
