Duplicate connections to some onion peers #1408

New Issue

Closed

opened 2018-12-13 13:43:24 +01:00 by g1itch · 12 comments

g1itch commented 2018-12-13 13:43:24 +01:00 (Migrated from github.com)

Copy Link

The description is based on messages from [chan] bitmessage but I've seen it myself a couple of weeks ago (I thought it's related to my #1394 - wrongly).

Changes proposed today:

diff --git a/src/network/connectionpool.py b/src/network/connectionpool.py
index e599cdf..c5ba701 100644
--- a/src/network/connectionpool.py
+++ b/src/network/connectionpool.py
@@ -93,7 +93,7 @@ class BMConnectionPool(object):
                     del self.inboundConnections[connection.destination.host]
                 except KeyError:
                     pass
-        connection.close()
+        connection.handle_close()
 
     def getListeningIP(self):
         if BMConfigParser().safeGet("bitmessagesettings", "onionhostname").endswith(".onion"):

The description is based on messages from `[chan] bitmessage` but I've seen it myself a couple of weeks ago (I thought it's related to my #1394 - wrongly).  Changes proposed today: ```patch diff --git a/src/network/connectionpool.py b/src/network/connectionpool.py index e599cdf..c5ba701 100644 --- a/src/network/connectionpool.py +++ b/src/network/connectionpool.py @@ -93,7 +93,7 @@ class BMConnectionPool(object): del self.inboundConnections[connection.destination.host] except KeyError: pass - connection.close() + connection.handle_close() def getListeningIP(self): if BMConfigParser().safeGet("bitmessagesettings", "onionhostname").endswith(".onion"): ```

stman commented 2018-12-13 14:00:13 +01:00 (Migrated from github.com)

Copy Link

Are you saying this node was not an attack on bitmessage to sandbox users ?

Envoyé de mon iPhone

Le 13 déc. 2018 à 13:43, Dmitri Bogomolov notifications@github.com a écrit :

The description is based on messages from [chan] bitmessage but I've seen it myself a couple of weeks ago (I thought it's related to my #1394 - wrongly).

Changes proposed today:

diff --git a/src/network/connectionpool.py b/src/network/connectionpool.py
index e599cdf..c5ba701 100644
--- a/src/network/connectionpool.py
+++ b/src/network/connectionpool.py
@@ -93,7 +93,7 @@ class BMConnectionPool(object):
del self.inboundConnections[connection.destination.host]
except KeyError:
pass

•    connection.close()
  

•    connection.handle_close()
  

  def getListeningIP(self):
  if BMConfigParser().safeGet("bitmessagesettings", "onionhostname").endswith(".onion"):
  —
  You are receiving this because you are subscribed to this thread.
  Reply to this email directly, view it on GitHub, or mute the thread.

Are you saying this node was not an attack on bitmessage to sandbox users ? Envoyé de mon iPhone > Le 13 déc. 2018 à 13:43, Dmitri Bogomolov <notifications@github.com> a écrit : > > The description is based on messages from [chan] bitmessage but I've seen it myself a couple of weeks ago (I thought it's related to my #1394 - wrongly). > > > > Changes proposed today: > > diff --git a/src/network/connectionpool.py b/src/network/connectionpool.py > index e599cdf..c5ba701 100644 > --- a/src/network/connectionpool.py > +++ b/src/network/connectionpool.py > @@ -93,7 +93,7 @@ class BMConnectionPool(object): > del self.inboundConnections[connection.destination.host] > except KeyError: > pass > - connection.close() > + connection.handle_close() > > def getListeningIP(self): > if BMConfigParser().safeGet("bitmessagesettings", "onionhostname").endswith(".onion"): > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread.

g1itch commented 2018-12-13 14:25:11 +01:00 (Migrated from github.com)

Copy Link

Are you saying this node was not an attack on bitmessage to sandbox users ? Envoyé de mon iPhone

I don't know

> Are you saying this node was not an attack on bitmessage to sandbox users ? Envoyé de mon iPhone I don't know

g1itch commented 2018-12-13 15:50:22 +01:00 (Migrated from github.com)

Copy Link

My own screenshot with the same peer:

And with other peer from 11.28:

My own screenshot with the same peer:  And with other peer from 11.28: 

stman commented 2018-12-13 17:10:08 +01:00 (Migrated from github.com)

Copy Link

Have you implemented a mecanism to select the best noted peers to connect preferably to them first ?

Because it is the case, I think this could be a sandboxing attack.

Envoyé de mon iPhone

Le 13 déc. 2018 à 15:50, Dmitri Bogomolov notifications@github.com a écrit :

My own screenshot with the same peer:

And with other peer from 11.28:

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Have you implemented a mecanism to select the best noted peers to connect preferably to them first ? Because it is the case, I think this could be a sandboxing attack. Envoyé de mon iPhone > Le 13 déc. 2018 à 15:50, Dmitri Bogomolov <notifications@github.com> a écrit : > > My own screenshot with the same peer: > > > And with other peer from 11.28: > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or mute the thread.

PeterSurda commented 2018-12-15 10:19:38 +01:00 (Migrated from github.com)

Copy Link

@stman The rating adjust dynamically and influences the likelihood the peer will be retried in the future. The client isn't supposed to connect to the same peer multiple times, it's a bug. It also could be a UI bug, erroneously forgetting to remove an entry from the list upon disconnect. Looking at @g1itch 's patch, I think it's probably the UI. I haven't had time to investigate it yet but I also saw something similar happening on my local client.

@stman The rating adjust dynamically and influences the likelihood the peer will be retried in the future. The client isn't supposed to connect to the same peer multiple times, it's a bug. It also could be a UI bug, erroneously forgetting to remove an entry from the list upon disconnect. Looking at @g1itch 's patch, I think it's probably the UI. I haven't had time to investigate it yet but I also saw something similar happening on my local client.

stman commented 2018-12-15 14:08:57 +01:00 (Migrated from github.com)

Copy Link

Yep.

I think it must be seriously investigated, and this mecanism to preferably connect to the best peers, even randomly, is at the root, according to me, to a way for the trick exploited to sandbox me and several users, to sabotage silently bitmessage’ peer ring.

Envoyé de mon iPhone

Le 15 déc. 2018 à 10:19, Peter Šurda notifications@github.com a écrit :

@stman The rating adjust dynamically and influences the likelihood the peer will be retried in the future. The client isn't supposed to connect to the same peer multiple times, it's a bug. It also could be a UI bug, erroneously forgetting to remove an entry from the list upon disconnect. Looking at @g1itch 's patch, I think it's probably the UI. I haven't had time to investigate it yet but I also saw something similar happening on my local client.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Yep. I think it must be seriously investigated, and this mecanism to preferably connect to the best peers, even randomly, is at the root, according to me, to a way for the trick exploited to sandbox me and several users, to sabotage silently bitmessage’ peer ring. Envoyé de mon iPhone > Le 15 déc. 2018 à 10:19, Peter Šurda <notifications@github.com> a écrit : > > @stman The rating adjust dynamically and influences the likelihood the peer will be retried in the future. The client isn't supposed to connect to the same peer multiple times, it's a bug. It also could be a UI bug, erroneously forgetting to remove an entry from the list upon disconnect. Looking at @g1itch 's patch, I think it's probably the UI. I haven't had time to investigate it yet but I also saw something similar happening on my local client. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread.

stman commented 2018-12-15 15:39:57 +01:00 (Migrated from github.com)

Copy Link

Peter, I suggest a small conf call on mumble to explain to all those interested how, according to me, the sandboxing could be operating.

Envoyé de mon iPhone

Le 15 déc. 2018 à 10:19, Peter Šurda notifications@github.com a écrit :

@stman The rating adjust dynamically and influences the likelihood the peer will be retried in the future. The client isn't supposed to connect to the same peer multiple times, it's a bug. It also could be a UI bug, erroneously forgetting to remove an entry from the list upon disconnect. Looking at @g1itch 's patch, I think it's probably the UI. I haven't had time to investigate it yet but I also saw something similar happening on my local client.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Peter, I suggest a small conf call on mumble to explain to all those interested how, according to me, the sandboxing could be operating. Envoyé de mon iPhone > Le 15 déc. 2018 à 10:19, Peter Šurda <notifications@github.com> a écrit : > > @stman The rating adjust dynamically and influences the likelihood the peer will be retried in the future. The client isn't supposed to connect to the same peer multiple times, it's a bug. It also could be a UI bug, erroneously forgetting to remove an entry from the list upon disconnect. Looking at @g1itch 's patch, I think it's probably the UI. I haven't had time to investigate it yet but I also saw something similar happening on my local client. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread.

g1itch commented 2018-12-15 17:55:50 +01:00 (Migrated from github.com)

Copy Link

Personally I doubt that proposed patch solves the issue. To test it I added logging in network.connectionpool:

diff --git a/src/network/connectionpool.py b/src/network/connectionpool.py
index e599cdfb..5444e736 100644
--- a/src/network/connectionpool.py
+++ b/src/network/connectionpool.py
@@ -253,6 +253,7 @@ class BMConnectionPool(object):
         for i in self.inboundConnections.values() + self.outboundConnections.values() + self.listeningSockets.values() + self.udpSockets.values():
             if not (i.accepting or i.connecting or i.connected):
                 reaper.append(i)
+                logger.warning('Reap connection to %s', i.destination)
             else:
                 try:
                     if i.state == "close":

Today I noticed strange log message:

2018-12-14 18:02:49,870 - WARNING - Reap connection to Peer(host='', port=8444)

But when the duplicate connections appear there is no such message in log.

Personally I doubt that proposed patch solves the issue. To test it I added logging in `network.connectionpool`: ```patch diff --git a/src/network/connectionpool.py b/src/network/connectionpool.py index e599cdfb..5444e736 100644 --- a/src/network/connectionpool.py +++ b/src/network/connectionpool.py @@ -253,6 +253,7 @@ class BMConnectionPool(object): for i in self.inboundConnections.values() + self.outboundConnections.values() + self.listeningSockets.values() + self.udpSockets.values(): if not (i.accepting or i.connecting or i.connected): reaper.append(i) + logger.warning('Reap connection to %s', i.destination) else: try: if i.state == "close": ``` Today I noticed strange log message: ``` 2018-12-14 18:02:49,870 - WARNING - Reap connection to Peer(host='', port=8444) ``` But when the duplicate connections appear there is no such message in log.

stman commented 2018-12-15 18:26:06 +01:00 (Migrated from github.com)

Copy Link

I insist, we need to talk through mumble. In less than 30 minutes we will collectively solve this issue definitely. And we must solve this issue.

Le 15 déc. 2018 à 17:55, Dmitri Bogomolov notifications@github.com a écrit :

Personally I doubt that proposed patch solves the issue. To test it I added logging in network.connectionpool:

diff --git a/src/network/connectionpool.py b/src/network/connectionpool.py
index e599cdfb..5444e736 100644
--- a/src/network/connectionpool.py
+++ b/src/network/connectionpool.py
@@ -253,6 +253,7 @@ class BMConnectionPool(object):
for i in self.inboundConnections.values() + self.outboundConnections.values() + self.listeningSockets.values() + self.udpSockets.values():
if not (i.accepting or i.connecting or i.connected):
reaper.append(i)

•            logger.warning('Reap connection to %s', i.destination)
         else:
             try:
                 if i.state == "close":
  

Today I noticed strange log message:

2018-12-14 18:02:49,870 - WARNING - Reap connection to Peer(host='', port=8444)
But when the duplicate connections appear there is no such message in log.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I insist, we need to talk through mumble. In less than 30 minutes we will collectively solve this issue definitely. And we must solve this issue. > Le 15 déc. 2018 à 17:55, Dmitri Bogomolov <notifications@github.com> a écrit : > > Personally I doubt that proposed patch solves the issue. To test it I added logging in network.connectionpool: > > diff --git a/src/network/connectionpool.py b/src/network/connectionpool.py > index e599cdfb..5444e736 100644 > --- a/src/network/connectionpool.py > +++ b/src/network/connectionpool.py > @@ -253,6 +253,7 @@ class BMConnectionPool(object): > for i in self.inboundConnections.values() + self.outboundConnections.values() + self.listeningSockets.values() + self.udpSockets.values(): > if not (i.accepting or i.connecting or i.connected): > reaper.append(i) > + logger.warning('Reap connection to %s', i.destination) > else: > try: > if i.state == "close": > Today I noticed strange log message: > > 2018-12-14 18:02:49,870 - WARNING - Reap connection to Peer(host='', port=8444) > But when the duplicate connections appear there is no such message in log. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread.

g1itch commented 2018-12-16 18:08:13 +01:00 (Migrated from github.com)

Copy Link

I confirm that it can be reproduced by adding trustedpeer = <thatpeer.onion>:8444 to keys.dat.

I confirm that it can be reproduced by adding `trustedpeer = <thatpeer.onion>:8444` to keys.dat.

stman commented 2018-12-16 21:10:43 +01:00 (Migrated from github.com)

Copy Link

Ok then, I'm taking a few minutes to write down my sandboxing scenario.

Of course, all these are just assumptions, and some close variants must
also be considered.

It is a multistage attack scenario.

• The attacker wishing to sandbox create a bunch of BM nodes in VM,
  preferably with onion addresses, it allow duplication in a much more
  easy way than with real IP addresses, and he ensure a very good
  connectivity to the netork, modifying the source code to accept much
  more than 8 connections, and avoiding his own peers, ti ensure that he
  is always has the most synchronized peers on the network, therefor
  gaining the best notations from all other peers.

• He makes his system running for a sufficient period of time to ensure
  most of the peers connecting to the BM network will know the addresses
  of his peers, with the highest rating possible.

Let’s summerize this first attack step :

• Creation of many fake peers (Arbitrarily 10 times more than the
  current real number of bitmessage distinct users), using preferably
  onion adresses (easier, fully scalable), and ensuring they all get the
  best rating by giving those fake peers a good internet bandwidth, and
  letting them running 24h/24.

The second stage of the attack is the following :

• The attacker takes advantage of the fact that Pybitmessage is the
  mostly used node.

• The tattacker takes advantage that this client is rating peers, and is
  now connecting in priority to the highest rated peers.

• The attacker takes advantage that the latest versions of Pybitmessage
  has limited the number of outgoing connections to 8, and that most users
  don’t let their configuration run 24h/24, so indeed mostly use outgoing
  connections to connect to the network.

• The probability in such conditions that a target user like me,
  connecting cuasually to the network, gets connected first to the
  attacker peers is therefore getting very high.

• Modifying the source code of its fake peers, the attack can easily
  implement a detection mecanism when a targeted users is exclusively
  connected onto his fake peers : This is possible thanks to the peer
  authentification mecanism, and the only thing the attacker wishing to
  sandbox a user had to do is to modify pybitmessage source code, and add
  a special communication functionnality between his fake nodes, to know
  when 8 connections from the targeted peer have connected to his attacker
  peer ring. He just have to build a kind of hypervisor of all his running
  peers.

Doing so, he can know when some targeted peers are under his control,
because exclusively connected to his peers, and none of the targeted
users connected between them, they all goi through his peer ring to
communicate.

Doing so, it is fucking easy for him to start making his fake peer ring
filtering messages on demand, and start slowly filtering most messages
comming from the real bitmessage network.

And he’s done. He can isolate selected peers on demand.

This is why a motherfucking guy told me once I should preferably connect
exclusively through Tor, I remember that. I told him : But what is
entrapped in a fake peer ring, and never answered me (In my head, this
is rising an alarm you know).

FUCK JEFF BEZOS, THE CIA, THE NSA and their fucking transnational
corruption ring.

Le 15/12/2018 à 17:55, Dmitri Bogomolov a écrit :

Personally I doubt that proposed patch solves the issue. To test it I
added logging in |network.connectionpool|:

diff --git a/src/network/connectionpool.py b/src/network/connectionpool.py
index e599cdfb..5444e736 100644
--- a/src/network/connectionpool.py
+++ b/src/network/connectionpool.py
@@ -253,6 +253,7 @@ class BMConnectionPool(object):
for i in self.inboundConnections.values() + self.outboundConnections.values() + self.listeningSockets.values() + self.udpSockets.values():
if not (i.accepting or i.connecting or i.connected):
reaper.append(i)

• logger.warning('Reap connection to %s', i.destination)
  else:
  try:
  if i.state == "close":

Today I noticed strange log message:

|2018-12-14 18:02:49,870 - WARNING - Reap connection to Peer(host='',
port=8444) |

But when the duplicate connections appear there is no such message in log.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Bitmessage/PyBitmessage/issues/1408#issuecomment-447582121,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOyDZtx4MwrqvwvEHNeREIRguDuj0vkks5u5SmXgaJpZM4ZRjrO.

Ok then, I'm taking a few minutes to write down my sandboxing scenario. Of course, all these are just assumptions, and some close variants must also be considered. It is a multistage attack scenario. - The attacker wishing to sandbox create a bunch of BM nodes in VM, preferably with onion addresses, it allow duplication in a much more easy way than with real IP addresses, and he ensure a very good connectivity to the netork, modifying the source code to accept much more than 8 connections, and avoiding his own peers, ti ensure that he is always has the most synchronized peers on the network, therefor gaining the best notations from all other peers. - He makes his system running for a sufficient period of time to ensure most of the peers connecting to the BM network will know the addresses of his peers, with the highest rating possible. Let’s summerize this first attack step : * Creation of many fake peers (Arbitrarily 10 times more than the current real number of bitmessage distinct users), using preferably onion adresses (easier, fully scalable), and ensuring they all get the best rating by giving those fake peers a good internet bandwidth, and letting them running 24h/24. The second stage of the attack is the following : * The attacker takes advantage of the fact that Pybitmessage is the mostly used node. * The tattacker takes advantage that this client is rating peers, and is now connecting in priority to the highest rated peers. * The attacker takes advantage that the latest versions of Pybitmessage has limited the number of outgoing connections to 8, and that most users don’t let their configuration run 24h/24, so indeed mostly use outgoing connections to connect to the network. - The probability in such conditions that a target user like me, connecting cuasually to the network, gets connected first to the attacker peers is therefore getting very high. - Modifying the source code of its fake peers, the attack can easily implement a detection mecanism when a targeted users is exclusively connected onto his fake peers : This is possible thanks to the peer authentification mecanism, and the only thing the attacker wishing to sandbox a user had to do is to modify pybitmessage source code, and add a special communication functionnality between his fake nodes, to know when 8 connections from the targeted peer have connected to his attacker peer ring. He just have to build a kind of hypervisor of all his running peers. Doing so, he can know when some targeted peers are under his control, because exclusively connected to his peers, and none of the targeted users connected between them, they all goi through his peer ring to communicate. Doing so, it is fucking easy for him to start making his fake peer ring filtering messages on demand, and start slowly filtering most messages comming from the real bitmessage network. And he’s done. He can isolate selected peers on demand. This is why a motherfucking guy told me once I should preferably connect exclusively through Tor, I remember that. I told him : But what is entrapped in a fake peer ring, and never answered me (In my head, this is rising an alarm you know). FUCK JEFF BEZOS, THE CIA, THE NSA and their fucking transnational corruption ring. Le 15/12/2018 à 17:55, Dmitri Bogomolov a écrit : > > Personally I doubt that proposed patch solves the issue. To test it I > added logging in |network.connectionpool|: > > diff --git a/src/network/connectionpool.py b/src/network/connectionpool.py > index e599cdfb..5444e736 100644 > --- a/src/network/connectionpool.py > +++ b/src/network/connectionpool.py > @@ -253,6 +253,7 @@ class BMConnectionPool(object): > for i in self.inboundConnections.values() + self.outboundConnections.values() + self.listeningSockets.values() + self.udpSockets.values(): > if not (i.accepting or i.connecting or i.connected): > reaper.append(i) > + logger.warning('Reap connection to %s', i.destination) > else: > try: > if i.state == "close": > > Today I noticed strange log message: > > |2018-12-14 18:02:49,870 - WARNING - Reap connection to Peer(host='', > port=8444) | > > But when the duplicate connections appear there is no such message in log. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/Bitmessage/PyBitmessage/issues/1408#issuecomment-447582121>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAOyDZtx4MwrqvwvEHNeREIRguDuj0vkks5u5SmXgaJpZM4ZRjrO>. >

g1itch commented 2018-12-18 17:04:27 +01:00 (Migrated from github.com)

Copy Link

Hmm, I confirm that patch from [chan] bitmessage solves the issue (at least when I reproduce it with trustedpeer in config). Debug:

2018-12-18 17:54:43,476 - DEBUG - Outbound proxy connection to t7hb2h5gvudfht6u.onion:8444
2018-12-18 17:54:55,509 - DEBUG - remoteProtocolVersion: 3
2018-12-18 17:54:55,510 - DEBUG - services: 0x00000000
2018-12-18 17:54:55,510 - DEBUG - time offset: -6
2018-12-18 17:54:55,511 - DEBUG - my external IP: 127.0.0.1
2018-12-18 17:54:55,511 - DEBUG - remote node incoming address: t7hb2h5gvudfht6u.onion:8444
2018-12-18 17:54:55,511 - DEBUG - user agent: /PyBitmessage:0.6.3.2/
2018-12-18 17:54:55,512 - DEBUG - streams: [1]
2018-12-18 17:54:55,512 - DEBUG - Initial skipping processing getdata for 14.78s
2018-12-18 17:54:55,605 - DEBUG - Sending huge inv message with 26208 objects to just this one peer
2018-12-18 17:54:58,270 - DEBUG - Bad checksum, ignoring
2018-12-18 17:54:58,271 - DEBUG - Closing due to invalid command close
2018-12-18 17:54:59,486 - DEBUG - Outbound proxy connection to t7hb2h5gvudfht6u.onion:8444
2018-12-18 17:55:11,500 - DEBUG - remoteProtocolVersion: 3
2018-12-18 17:55:11,501 - DEBUG - services: 0x00000000
2018-12-18 17:55:11,501 - DEBUG - time offset: -6
2018-12-18 17:55:11,502 - DEBUG - my external IP: 127.0.0.1
2018-12-18 17:55:11,502 - DEBUG - remote node incoming address: t7hb2h5gvudfht6u.onion:8444
2018-12-18 17:55:11,502 - DEBUG - user agent: /PyBitmessage:0.6.3.2/
2018-12-18 17:55:11,503 - DEBUG - streams: [1]
2018-12-18 17:55:11,503 - DEBUG - Initial skipping processing getdata for 14.79s
2018-12-18 17:55:11,617 - DEBUG - Sending huge inv message with 26207 objects to just this one peer
2018-12-18 17:55:14,146 - DEBUG - Bad checksum, ignoring
2018-12-18 17:55:14,147 - DEBUG - Closing due to invalid command close
2018-12-18 17:55:15,504 - DEBUG - Outbound proxy connection to t7hb2h5gvudfht6u.onion:8444
...

Hmm, I confirm that patch from `[chan] bitmessage` solves the issue (at least when I reproduce it with `trustedpeer` in config). Debug: ``` 2018-12-18 17:54:43,476 - DEBUG - Outbound proxy connection to t7hb2h5gvudfht6u.onion:8444 2018-12-18 17:54:55,509 - DEBUG - remoteProtocolVersion: 3 2018-12-18 17:54:55,510 - DEBUG - services: 0x00000000 2018-12-18 17:54:55,510 - DEBUG - time offset: -6 2018-12-18 17:54:55,511 - DEBUG - my external IP: 127.0.0.1 2018-12-18 17:54:55,511 - DEBUG - remote node incoming address: t7hb2h5gvudfht6u.onion:8444 2018-12-18 17:54:55,511 - DEBUG - user agent: /PyBitmessage:0.6.3.2/ 2018-12-18 17:54:55,512 - DEBUG - streams: [1] 2018-12-18 17:54:55,512 - DEBUG - Initial skipping processing getdata for 14.78s 2018-12-18 17:54:55,605 - DEBUG - Sending huge inv message with 26208 objects to just this one peer 2018-12-18 17:54:58,270 - DEBUG - Bad checksum, ignoring 2018-12-18 17:54:58,271 - DEBUG - Closing due to invalid command close 2018-12-18 17:54:59,486 - DEBUG - Outbound proxy connection to t7hb2h5gvudfht6u.onion:8444 2018-12-18 17:55:11,500 - DEBUG - remoteProtocolVersion: 3 2018-12-18 17:55:11,501 - DEBUG - services: 0x00000000 2018-12-18 17:55:11,501 - DEBUG - time offset: -6 2018-12-18 17:55:11,502 - DEBUG - my external IP: 127.0.0.1 2018-12-18 17:55:11,502 - DEBUG - remote node incoming address: t7hb2h5gvudfht6u.onion:8444 2018-12-18 17:55:11,502 - DEBUG - user agent: /PyBitmessage:0.6.3.2/ 2018-12-18 17:55:11,503 - DEBUG - streams: [1] 2018-12-18 17:55:11,503 - DEBUG - Initial skipping processing getdata for 14.79s 2018-12-18 17:55:11,617 - DEBUG - Sending huge inv message with 26207 objects to just this one peer 2018-12-18 17:55:14,146 - DEBUG - Bad checksum, ignoring 2018-12-18 17:55:14,147 - DEBUG - Closing due to invalid command close 2018-12-18 17:55:15,504 - DEBUG - Outbound proxy connection to t7hb2h5gvudfht6u.onion:8444 ... ```

This repo is archived. You cannot comment on issues.

No Branch/Tag Specified

Branches Tags

v0.6

gitea-122

gitea-118

kashikoibumi/py3qt

kashikoibumi/py3

gitea-112

gitea-111

kivy-fix

test3

anand-skss/test_case

test5

gitea-107

gitea-106

test

gitea-102

gitea-100

gitea-91

kashikoibumi/qt5-wip

kashikoibumi/strict-blob

kashikoibumi/binary

kashikoibumi/bytes-key

kashikoibumi/memoryview

kashikoibumi/literal

kashikoibumi/six

kashikoibumi/import-path

test4

test2

kashikoibumi/dark-theme

gitea-89

gitea-95

gitea-93

gitea-97

gitea-96

gitea-86

gitea-87

gitea-88

gitea-80

gitea-81

gitea-84

gitea-83

gitea-79

gitea-78

master

bootstrap

shportix/sql-refactoring

dependabot/pip/mistune-lt-2.0.6

shekhar-cis/test_sqlthread_refactor

sandakersmann/v0.6

osamacis/Kivy-baseclass-localization

osamacis/kivy-transifex-config

dependabot/pip/kivymd-1.1.1

teruteru128/refactor-swap64

813492291816/v0.6

akeelahmedqureshi/v0.6

dependabot/pip/docutils-lt-0.20.0

cis-muzahid/test_refactor_sqlthread

kdcis/mock-test

g1itch/qt5-wip

kdcis/v0.6-flatpak

g1itch/doc-python3

PeterSurda/cq101

navjotcis/telenium-test-cases

g1itch/knownnodes-opt

g1itch/ui-refactoring

g1itch/tests-screenshot

g1itch/refactoring-sql

navjotcis/bug-fixes18

g1itch/windows

kaue/patch-1

navjotcis/bug-fixes4

sgj3/issue1538

coolguy-cell/CQfixes11

python3

PeterSurda/w64fix

lakshyacis/graphicalqttest

sgj3/attachments

dimyme/cherry

dimyme/patch-3

python3android

Kleshni/POW

f97ada87/opmode-netcat-v2

kyucrane/mobileRecv

continuous

0.6.3.2

0.6.3.1

v0.6.3

v0.6.2

v0.6.1

v0.6.0

v0.5.8

v0.5.7

v0.5.6

v0.5.5

v0.5.4

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.5.2

v0.4.5.1

v0.4.5

v0.4.4

v0.4.3

v0.4.2

v0.4.1

v0.4.0

v0.3.5

Labels

Clear labels   

bug

Something isn't working as it's supposed to

  

build

Related to building or build system

  

dependencies

Pull requests that update a dependency file

  

developers

The issue is relevant mainly for developers rather than users

  

documentation

  

duplicate

  

enhancement

New feature

  

formatting

Code or UI text formatting

  

invalid

  

legal

  

mobile

Frontend for mobile devices (kivy)

  

obsolete

  

packaging

  

performance

  

protocol

Protocol change

  

question

  

refactoring

  

regression

Some issue, fixed in the past, appears again

  

security

  

test

  

translation

  

usability

  

wontfix

No Label

bug

build

dependencies

developers

documentation

duplicate

enhancement

formatting

invalid

legal

mobile

obsolete

packaging

performance

protocol

question

refactoring

regression

security

test

translation

usability

wontfix

Milestone

Clear milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

No Assignees

1 Participants

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2024-12-01#1408

No description provided.