Compilation error - pybind11

Please make sure that this is a build/installation issue. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:build_template
System information

Centos 6.9
N/A
TensorFlow installed from (source or binary): source
TensorFlow version: 2.0
Python version: 3.7
Installed using virtualenv? pip? conda?: N/A
Bazel version (if compiling from source):  0.25.2
GCC/Compiler version (if compiling from source): 7.4.0
CUDA/cuDNN version: 10/7
GPU model and memory: v100

Describe the problem
Compilation fails around tensorflow/python
Provide the exact sequence of commands / steps that you executed before running into the problem
./configure
bazel build --jobs=16 --config=opt --config=cuda //tensorflow/tools/pip_package:build_pip_package
Any other info / logs
Need to compile for RHEL6 and Centos6 as precompiled packages need glibc > 2.12
Have successfully compiled most previous versions with a little massaging. Attached is the log from where the error occurs.
tens2.0err.txt

@berniekirby, Please include the ./configure output. Thanks!

@berniekirby, Is this still an issue.

Commenting out the first include in tensorflow/python/framework/op_def_registry.cc
Thus:
/* Copyright 2019 The TensorFlow Authors. All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
==============================================================================*/
//#include "include/pybind11/pybind11.h"
#include "tensorflow/core/framework/op.h"
#include "tensorflow/core/framework/op_def.pb.h"
#include "tensorflow/core/framework/op_def_util.h"
#include "tensorflow/python/lib/core/pybind11_status.h"
Resolves the issue.
pybind11.h must also be included somewhere else via the other includes.

@berniekirby, Glad it resolved.
Are you happy to close this issue. Thanks!

Assuming the "fix" is verified and I don't need to do that in the next git download of course you can close it. Surprised others have not seen this issue.

Closing this issue now, Feel free to reopen if the issue still persists. Thanks!


Replace Transaction with UserOperation

In some places, Transaction is mentioned when really we are talking about UserOperation
For example:
https://github.com/eth-infinitism/bundler-spec/blob/main/src/eth/transaction.yaml#L1-L11
https://github.com/eth-infinitism/bundler-spec/blob/main/src/eth/submit.yaml#L1-L11
spec should be corrected / disambiguated

Created issue AA-433


kinocilium tip

I would like to see “kinocilium tip” added as a part_of child term of “kinocilium (GO:0060091). Definition could be “The tip of a nonmotile primary cilium that is found at the apical surface of auditory receptor cells”. Synonym: tip of kinocilium PMID:25601850

We already have a term for 'ciliary tip' that is a part_of child of the term 'cilium'. I'm not sure we want to start going down the route of duplicating the part_of children of the term 'cilium' under 'kinocilium'.
You could already co-annotate with 'kinocilium' and 'ciliary tip'. In a GO-CAM model, you would be able to indicate 'ciliary tip' part_of 'kinocilium'.
thoughts? @ukemi @paolaroncaglia

Unless there is something special about the kinocilium tip, I would go with your suggestion.

The term 'ciliary tip' is already a sort of non-specific term that lets you annote the general region of the 'tip' without being very specific about a particular substructure of the cilium.
It seems to me that the combination of the two existing terms is sufficient so I'm going to close this, but if you have more comments @slaulederkind, you can add them here and reopen.

Hi @krchristie and @ukemi, I agree with your resolution.


Provide a way to edit the session before uploading

Editing the session before it's uploaded would allow me to fix y^Htypos and accidental passwords.

For anyone else that lands here searching for how to edit a session before uploading, I found it slightly confusing at first so I wrote up how I did it. Hopefully this is helpful to someone else.

Nice hack, thanks Marvin!
Sent via Superhuman<EMAIL_ADDRESS>)
On Sun, Sep 17, 2017 at 1:30 PM, Marvin Pinto <<EMAIL_ADDRESS><EMAIL_ADDRESS>) > wrote:

For anyone else that lands here searching for how to edit a session before
uploading, I found it slightly confusing at first so I wrote up (
https://disjoint.ca/til/2017/09/17/create-a-screencast-of-your-terminal-session-using-showterm
) how I did it. Hopefully this is helpful to someone else.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub (
https://github.com/ConradIrwin/showterm/issues/11#issuecomment-330077316 )
, or mute the thread (
https://github.com/notifications/unsubscribe-auth/AAFwQFub5HxyC921V9b1dV2A-_WXduTXks5sjXM6gaJpZM4A5FR-
) .


Zoom is applied delayed when using capture_continuous

Hi,
I want to process images with open cv to track an object in front of the camera. To do this more efficiently I resized the image to a lower resolution. When the object gets far away from the camera it is lost in the pixels of the resized image.  To resolve this I want to adjust the zoom of the camera continuously.
When I set the camera.zoom as in following code, I need to run over 3-4 frames in this loop to wait for the zoom becoming active. Is there a way to reduce this delay and get the zoomed frame instantly in the next iteration of the for loop?
camera.resolution = (1640, 922)
camera.framerate = 25
time.sleep(0.5)
size_resize = (213, 120)
rawCapture = PiRGBArray(camera, size=size_resize)

for frame in camera.capture_continuous(rawCapture, format="bgr", use_video_port=True,
                                               resize=size_resize,
                                               splitter_port=3)
    frame = frame.array
    new_zoom_parameters = get_zoom_parameters_to_center_object(frame)
    camera.zoom = new_zoom_parameters
    rawCapture.truncate(0)

No, that's not available from the firmware, although may be possible to expose.
Due to the mobile phone origins of the whole camera stack, the requirement was for zoom to be nice and smooth rather than jumping in huge steps.
Even so you haven't a simple mechanism to synchronise requesting frames and updating settings, so you may need a number of frames, particularly if you're using use_video_port=True which will keep the pipeline running independent of your application consuming the resulting frames.


Merging #180 @psmit hidden command impl

Closes #180

@meatballhat can you add a spec for the VisibleCategories and VisibleCommands logic? Otherwise :shipit:

@jszwedko howzat look?

I couldn't ask for anything more.

Added to CHANGELOG in https://github.com/codegangsta/cli/commit/28eb7b2cc4bf1b4d266fe55fe7d94f958170cdf8


bounding boxes for columns and rows detected, but empty dataframe is returned

from gmft import AutoTableFormatter, TATRFormatConfig, TATRTableFormatter
config = TATRFormatConfig()
config.total_overlap_reject_threshold = 0.5
formatter = TATRTableFormatter(config = config)
ft = formatter.extract(tables[0])
ft.visualize() # detected all rows and columns

The table is a simple one spanning the whole page, so far all the bounding boxes look alright, but _df is an empty dataframe.
Unfortunately I cannot share the document. do you have any suggestions on how to go about debugging, or what parameters to tweak

It seems that null is returned for each cell of the table, and the cause is either odd underlying text object, encoding issue, or simply there is no text data.
Is there any way to switch to OCR for parsing?

Sorry, gmft doesn't currently have in-built support for OCR. You can export it to image via table.image(). I'm also aware of this huggingface space but your doc will be transmitted over the internet.


bug(*): error in list if contains a dash

If https://github.com/deis/memkv/blob/master/store.go#L146 not commented there's an error if the key contains a dash
aledbf:memkv aledbf$ go test
--- FAIL: TestListDir (0.00s)
	store_test.go:174: List(/deis/services) = [notaservice srv1 srv2], want [key notaservice srv1 srv2 with-space]
	store_test.go:174: List(/deis/services/) = [notaservice srv1 srv2], want [key notaservice srv1 srv2 with-space]
FAIL
exit status 1
FAIL	github.com/aledbf/memkv	0.004s

with https://github.com/deis/memkv/blob/master/store.go#L146 commented it pass
aledbf:memkv aledbf$ go test
PASS
ok  	github.com/aledbf/memkv	0.004s

This PR contains just the tests to validate that dashes are ok. Should it also comment out the code line you mentioned in order to fix deis/deis#4346?

@aledbf @bacongobbler is this still needed now that confd v0.11.0 is out?

nope! we've since fixed the underlying issue.


Completions doesn't show with OnTypeFormatting

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.77.1
OS Version:  Windows 10

Steps to Reproduce:
Code:
const vscode = require('vscode')

function activate(context) {
    vscode.languages.registerCompletionItemProvider('plaintext', {
        provideCompletionItems(document, position, token, context) {
            return [new vscode.CompletionItem("Xtest")];
        }
    }, 'x');

    vscode.languages.registerOnTypeFormattingEditProvider('plaintext', {
        provideOnTypeFormattingEdits(document, position, ch, options, token) {
            const fullText = document.lineAt(position.line).text
            const fullRange = new vscode.Range(position.line, 0, position.line, fullText.length);
            return [vscode.TextEdit.replace(fullRange, fullText + " ")];
        }
    }, 'x');
}

function deactivate() { }

module.exports = {
    activate,
    deactivate
}

Copy and paste sample code to file with .js extension
Run extension with plaintext and hits x key.
Completions dosn't shows
Comments or remove code with registerOnTypeFormattingEditProvider function.
Try again Run extension with plaintext and hits x key
Completions now shows

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.77.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

On the latest version this issue still remains.

The described behavior is how it is expected to work. If you disagree, please explain what is expected and what is not in more detail. See also our issue reporting guidelines.
Happy Coding!

This happens because the x trigger a code change (from format on type) which then cancels the pending request for suggestions. That's because we don't continue suggestion requests when a new word starts (which happens because the formatter inserts a whitespace).
As aside:  note that x is ignore as a trigger character because it is also a word character, so your provider only gets called because of quick suggestions


I installed the latest version,when i start the apk massege open 'check your wifi conection' when i press retry it stuck on the screen plz fix this problem

I installed the latest version,when i start the apk message open 'check your wifi connection' when i press retry it stuck on the screen please fix this problem

Describe the bug A clear and concise description of what the bug is.
To Reproduce Steps to reproduce the behavior:
1. Go to '...'

2. Click on '....'

3. See error

Expected behavior A clear and concise description of what you expected to happen.
Logs Attach logs (app, node, supervisor) to the issue. Where to find the logs: https://github.com/mysteriumnetwork/mysterium-vpn-desktop#logs
Screenshots If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
* OS: [e.g. Windows 10]

* App Version [e.g. 4.1.0]

Additional context Add any other context about the problem here.

I installed the latest version,when i start the apk massege open 'check your wifi conection' when i press retry it stuck on the screen plz fix this problem

@ArefAgha Apologies for the delayed reply. Do you still experience this kind of problem?

Yes its still stuck
On Mon, Mar 21, 2022, 11:34 AM etherunit @.***> wrote:

@ArefAgha https://github.com/ArefAgha Apologies for the delayed reply.
Do you still experience this kind of problem?
—
Reply to this email directly, view it on GitHub
https://github.com/mysteriumnetwork/mysterium-vpn-desktop/issues/258#issuecomment-1073680774,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXKNSTNUWLYMRVYVEYMKVGDVBA7BVANCNFSM5MCYAWZQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

Have you tried connecting via wifi at all?

Yes via wifi and mobile data
On Mon, Apr 25, 2022, 11:06 AM isaackielma @.***> wrote:

Have you tried connecting via wifi at all?
—
Reply to this email directly, view it on GitHub
https://github.com/mysteriumnetwork/mysterium-vpn-desktop/issues/258#issuecomment-1108219607,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXKNSTKGCYKT7THGNMKTXW3VGZHB5ANCNFSM5MCYAWZQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


Find a better way to manage paths to the datasets for developement

At the moment I have hardcoded the paths in the tests and examples to my local machine. That is fine as long as I am the only person, but I should find a better way!

Solved in #8


Allow iterable for Vec\concat first argument

I am not sure why Psl\Vec\concat() only accepts array as the first argument instead of iterable. It seems an oversite. All other function from Psl\Vec allow it and there is nothing special in the implemenation to not support iterable

Pull Request Test Coverage Report for Build<PHONE_NUMBER>6
Details

0 of 0   changed or added relevant lines in 0 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage remained the same at 98.691%

Files with Coverage Reduction
New Missed Lines
%

src/Psl/DateTime/Internal/high_resolution_time.php
2
90.48%

Totals

Change from base Build<PHONE_NUMBER>0:
0.0%

Covered Lines:
5352

Relevant Lines:
5423

💛  - Coveralls


Unable to find twig base template from HackzillaTicketBundle::layout.html.twig

Hi,
and first thanks for your work, I'm really happy to try this bundle, and not to have to use external software !
But, I have an issue, I have updated my symfony to 2.8, and install the bundle, following the doc:
composer require hackzilla/ticket-bundle
When I try to rich the ticket bundle page, I have this error:

Unable to find template "::base.html.twig" (looked into: /var/www/folder/subfolder/site/vendor/symfony/symfony/src/Symfony/Bridge/Twig/Resources/views/Form) in HackzillaTicketBundle::layout.html.twig at line 1.

I use bootstrap3 form, and I have configured twig like this:
twig:
    [...]
    form:
        resources: ['bootstrap_3_layout.html.twig']

When I see the layout file:
https://github.com/hackzilla/TicketBundle/blob/develop/Resources/views/layout.html.twig

{% extends '::base.html.twig' %}

{% block body %}
    {% block hackzilla_ticket_content %}{% endblock %}
{% endblock body %}

But in my twig directory:

I do not have base.html.twig file
Am I missing something ?
SOLUTION: you need to have a base.html.twig in the app/Resources/views/ thanks to @bubnov-mikhail

You are missing app/Resources/views/base.html.twig

ok, make sense :)
I can see it here: https://github.com/hackzilla/TicketBundleDemoApp/tree/master/app/Resources/views
But, I don't see it in the doc, I have to take it from the demo app or another way ?
Why I don't have this file ? My fault or install issue ?

Usually you have it )
So just add/copy/create this file

Ok, understood ! It is my base template, but I dont have it.
I have started my project some times ago, and I have all my tpl files in my bundles, a file_exist check could be a good idea.
Thanks for the quick and effective help !

The demo was based on the Symfony-Standard project, and there is were the file ::base.html.twig came from.

If you don't want to create that file, then override layout.html.twig.

Ok, I will do that, but in my usecase, with an old symfony install the file is not necessary here by default
Thanks for your reply, I close :)


Support patch: protocol with local patches without needing to specify outputHash in manifest

The package could be fetched in a FOD derivation and then patched in a separate derivation with no outputHash needed.

Is there currently any way to use local patches at all? I don't mind specifying outputHash manually, but as much as I've tried, I didn't manage to make patching work at all.

Is there currently any way to use local patches at all? I don't mind specifying outputHash manually, but as much as I've tried, I didn't manage to make patching work at all.

Yes patches are supported, you can see the example here https://github.com/madjam002/yarnpnp2nix/blob/3dfd02b812b003817fb0fa20ebf47a5dc047bbb0/test/workspace/package.json#L10
Make sure the patch path is relative from the location of your yarn.lock file

Hmm, that requirement is kinda problematic, as I also need to patch dependencies in workspaces, for which yarn uses the ~ prefix. (example from my repo: patch:next@npm%3A13.2.1#~/.yarn/patches/next-npm-13.2.1-585715321e.patch).
Yarn fails to install these, as the .yarn/patches directory doesn't exist in the builder's workdir. I have a half-assed patch for this repo that just links the patch directory to where it needs to be for yarn to find it, but I'd like to solve this properly.
I haven't done much debugging, as admittedly I am still figuring out how this library works, but I'd love to help if I can.

Sorry, I meant to write workspace member :smile:
After getting rid of the prefix, and fixing the paths to be relative to their respective package.jsons, everything works like a charm. Thanks so much for the help!
Would you accept a PR adding a note about this (and perhaps other stuff I wished I knew without reading the source code) to the readme.md?


Updated Developer Profile Card

🛠 Issue (Number)

Closes #912
Description
Changed the whole layout and look of the developer profile card using HTML and CSS.
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist:

[ ] I have made this from my own
[x] I have taken help from some online resourses
[x] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[x] The title of my pull request is a short description of the requested changes.

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK

Resolve merge conflicts and make fresh PR


Bratseth/initially down take 2

@gjoranv or @arnej27959 please review
My changes didn't work in the case where there are multiple local one-node search clusters ... which is exactly the case we test. This reverts to the old behavior for local dispatch. I want to revisit it because it isn't quite right, but not in this PR.

the old way that you're now going back to looks much more correct to me :-)

I think the old way really does nothing since the cluster is still up.
What we want in this case is to take the container down even if the cluster is still up, but I suppose, only if there are also no other clusters than the one which we local dispatch to. But that is for another PR.


Update README.md

added notes about protecting certain URLs to the README

Thanks, I already updated readme.


Memory reporting is inconsistent with "free"

Description
The total memory amount is consistent but the free amount does not add up to what 'free' reports using the same units.  I suspect that this is due to the handling of 'shared memory' that simply should be ignored, and is accounted for in the other fields already.
The reference to how the mess in /proc/meminfo should be interpreted is undoubtedly 'free.c' from procps.
https://gitlab.com/procps-ng/procps/-/tree/master?ref_type=heads
Neofetch version
7.1.0
Screenshot

Config file
nil
Verbose log
https://pastebin.com/GAcSZZWc

free is consistent with what the kernel developers suggest user space to do:
MemTotal = MemAvailable + "Used" (in various ways, but not directly defined by /proc/meminfo)

==>
"Used" = MemTotal - MemAvailable

And this is what free effectively does:

@tobbez Torbjörn, do you care to comment on this things or have you moved on to more important things than bit-picking on memory reporting? ;-)


OWL-2993: Fix stack overflow in HTML-to-text recursion

:trihackathon: :nerdsnipe:
The html2text_ruby gem traverses the DOM via recursion.  This should generally be fine for
well-constructed HTML, but we use it to process user-created templates, so...
With some templates with incredibly deeply nested HTML, a stack overflow occurs.  For some reason,
this started occurring when we upgraded Backend from Unicorn to Puma.  I don't see the connection
there, but maybe Puma adds some additional Nokogiri instrumentation?
We have a fork of this gem so that we can customize the handling of images and links.  See #1.  I
checked the original gem, and its latest version also uses recursion, so we can't just merge the
upstream code.
My solution here is to do a stack-based recursion, popping off nodes to process, and pushing new
ones for the processed node's children.  This is a little clumsy because of the pre- and
post-processing done for each node.  See the comments in the code for more details.
Note that one detail of the original processing is omitted: the stripping of the output for links.
That would require passing around too much state in the stack, and really doesn't accomplish much.
It just means that something like
Click on <a href="...">  my link  </a> please
will be output as
Click on   my link   please
instead of
Click on my link please
I don't think that's anything to worry about, and in fact none of the existing test cases included
that (they all pass as-is with my changes).
I also took this opportunity to try to make the string building more efficient.  The original built
an array of string elements and then joined them at various points in the recursion to create a
final string.  This seems inefficient not just because of working with arrays instead of strings,
but also because += was used in some places instead of <<.  << modifies the object in-place,
while += makes a new copy on each call.
This simple but convincing experiment
supports that.  I changed gsub to gsub! for the same reason.
The original gem didn't have a changelog, so I created one.  Also, since this is a gem, we shouldn't
have Gemfile.lock committed to git.

Hmm... we had been using Travis CI previously on this repo, because that's what the original one used, and it was free for public repos.  That's no longer the case:

Building on a public repositories only
We love our OSS teams who choose to build and test using TravisCI and we fully want to support that community. However, in recent months we have encountered significant abuse of the intention of this offering (increased activity of cryptocurrency miners, TOR nodes operators etc.). Abusers have been tying up our build queues and causing performance reductions for everyone. In order to bring the rules back to fair playing grounds, we are implementing some changes for our public build repositories.

It looks like I'll have to get TeamCity set up here.

OK, TC is working now.

Hmm... we had been using Travis CI previously on this repo, because that's what the original one used, and it was free for public repos. That's no longer the case:

Building on a public repositories only
We love our OSS teams who choose to build and test using TravisCI and we fully want to support that community. However, in recent months we have encountered significant abuse of the intention of this offering (increased activity of cryptocurrency miners, TOR nodes operators etc.). Abusers have been tying up our build queues and causing performance reductions for everyone. In order to bring the rules back to fair playing grounds, we are implementing some changes for our public build repositories.

It looks like I'll have to get TeamCity set up here.

FYI @mkostick, you might be able to set up GitHub Actions here, I used that for the sequel-snowflake gem, which is also a public repo: https://github.com/Yesware/sequel-snowflake/blob/main/.github/workflows/ruby.yml


Implement azure-spring-security 4.0

Design doc:
https://github.com/Azure/azure-sdk-for-java/wiki/Spring-Security-for-Azure-design

[x] https://github.com/Azure/azure-sdk-for-java/issues/23922
[x] https://github.com/Azure/azure-sdk-for-java/issues/23932
[x] https://github.com/Azure/azure-sdk-for-java/issues/23942
[x] https://github.com/Azure/azure-sdk-for-java/issues/24353

Closing this issue. I'll use this issue to track all tasks: https://github.com/Azure/azure-sdk-for-java/issues/23402

Reopen this issue. Because  #23402 is too big to track all sub tasks.

Closing this issue. Because all sub issues has been closed.


1 Node stopped from connecting to other nodes in Kubernetes Cluster

What you expected to happen?
What happened?
Yesterday one of the 4 nodes I have in kubernetes cluster stopped working, any traffic going to other pods in another node stopped working and vice versal
How to reproduce it?
I could not find any difference in configuration so I can't reproduce it but it is still there now
Anything else we need to know?
This is the node <IP_ADDRESS> that stopped talking to others with reason: Received update for IP range I own at <IP_ADDRESS> v4961: incoming ...
(⎈ |production:kube-system)➜  ~ kubectl exec -n kube-system weave-net-n98pg -c weave -- /home/weave/weave --local status connections
-> <IP_ADDRESS>:6783     failed      Received update for IP range I own at <IP_ADDRESS> v4961: incoming message says owner da:68:9b:b7:51:65 v4997, retry: 2018-09-03 14:03:18.569215277 +0000 UTC m=+2667.309046958
-> <IP_ADDRESS>:6783   failed      Received update for IP range I own at <IP_ADDRESS> v4961: incoming message says owner da:68:9b:b7:51:65 v4997, retry: 2018-09-03 14:05:40.259769405 +0000 UTC m=+2808.999601088
-> <IP_ADDRESS>:6783   failed      cannot connect to ourself, retry: never

(⎈ |production:kube-system)➜  ~ kubectl exec -n kube-system weave-net-5p9zb -c weave -- /home/weave/weave --local status connections
-> <IP_ADDRESS>:6783   established sleeve 2a:44:ef:34:94:3b(kube-master) mtu=1438
-> <IP_ADDRESS>:6783   established sleeve da:68:9b:b7:51:65(engine02) mtu=1438
-> <IP_ADDRESS>:6783   failed      read tcp4 <IP_ADDRESS>:33627-><IP_ADDRESS>:6783: read: connection reset by peer, retry: 2018-09-03 14:02:50.598792999 +0000 UTC m=+23008.104583296
-> <IP_ADDRESS>:6783     failed      cannot connect to ourself, retry: never

(⎈ |production:kube-system)➜  ~ kubectl exec -n kube-system weave-net-ts4fp -c weave -- /home/weave/weave --local status connections
<- <IP_ADDRESS>:60522    established sleeve 9e:1f:f3:46:dd:12(engine03) mtu=1438
<- <IP_ADDRESS>:52895  established fastdp 2a:44:ef:34:94:3b(kube-master) mtu=1376
-> <IP_ADDRESS>:6783   failed      read tcp4 <IP_ADDRESS>:49715-><IP_ADDRESS>:6783: read: connection reset by peer, retry: 2018-09-03 14:04:38.797392876 +0000 UTC m=+4938783.801228928
-> <IP_ADDRESS>:6783   failed      cannot connect to ourself, retry: never

(⎈ |production:kube-system)➜  ~ kubectl exec -n kube-system weave-net-wzbt9 -c weave -- /home/weave/weave --local status connections
<- <IP_ADDRESS>:52226    established sleeve 9e:1f:f3:46:dd:12(engine03) mtu=1438
-> <IP_ADDRESS>:6783   established fastdp da:68:9b:b7:51:65(engine02) mtu=1376
-> <IP_ADDRESS>:6783   failed      cannot connect to ourself, retry: never
-> <IP_ADDRESS>:6783   failed      read tcp4 <IP_ADDRESS>:46196-><IP_ADDRESS>:6783: read: connection reset by peer, retry: 2018-09-03 14:05:36.038993072 +0000 UTC m=+23243.658647602

Versions:

$ weave version
`weave script 2.3.0`
$ docker version
docker version
Client:
 Version:         1.13.1
 API version:     1.26
 Package version: <unknown>
 Go version:      go1.8.3
 Git commit:      774336d/1.13.1
 Built:           Wed Mar  7 17:06:16 2018
 OS/Arch:         linux/amd64

Server:
 Version:         1.13.1
 API version:     1.26 (minimum version 1.12)
 Package version: <unknown>
 Go version:      go1.8.3
 Git commit:      774336d/1.13.1
 Built:           Wed Mar  7 17:06:16 2018
 OS/Arch:         linux/amd64
 Experimental:    false
$ uname -a
Linux engine01 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 19:03:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ kubectl version
(⎈ |production:kube-system)➜  ~ kubectl version
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T22:29:25Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.2", GitCommit:"bb9ffb1654d4a729bb4cec18ff088eacc153c239", GitTreeState:"clean", BuildDate:"2018-08-07T23:08:19Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

Logs:
(⎈ |production:kube-system)➜  ~ kubectl logs  weave-net-n98pg weave
DEBU: 2018/09/03 13:18:51.236888 [kube-peers] Checking peer "72:be:1a:b8:98:77" against list &{[{2a:44:ef:34:94:3b kube-master} {72:be:1a:b8:98:77 engine01.} {da:68:9b:b7:51:65 engine02} {9e:1f:f3:46:dd:12 engine03}]}
INFO: 2018/09/03 13:18:51.311055 Command line options: map[ipalloc-init:consensus=3 ipalloc-range:<IP_ADDRESS>/12 no-dns:true datapath:datapath db-prefix:/weavedb/weave-net docker-api: host-root:/host metrics-addr:<IP_ADDRESS>:6782 port:6783 expect-npc:true name:72:be:1a:b8:98:77 nickname:engine01. conn-limit:100 http-addr:<IP_ADDRESS>:6784]
INFO: 2018/09/03 13:18:51.311312 weave  2.3.0
INFO: 2018/09/03 13:18:51.597063 Bridge type is bridged_fastdp
INFO: 2018/09/03 13:18:51.597131 Communication between peers is unencrypted.
INFO: 2018/09/03 13:18:51.623481 Our name is 72:be:1a:b8:98:77(engine01.)
INFO: 2018/09/03 13:18:51.623560 Launch detected - using supplied peer list: [<IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS>]
INFO: 2018/09/03 13:18:51.623684 Checking for pre-existing addresses on weave bridge
INFO: 2018/09/03 13:18:51.624044 weave bridge has address <IP_ADDRESS>/12
INFO: 2018/09/03 13:18:51.659581 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/03 13:18:51.678220 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/03 13:18:51.696947 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/03 13:18:51.714631 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/03 13:18:51.732737 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/03 13:18:51.745257 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/03 13:18:51.758333 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/03 13:18:51.769979 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/03 13:18:51.785279 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/03 13:18:51.798937 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/03 13:18:51.800843 [allocator 72:be:1a:b8:98:77] Initialising with persisted data
INFO: 2018/09/03 13:18:51.801210 Sniffing traffic on datapath (via ODP)
INFO: 2018/09/03 13:18:51.802815 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 13:18:51.802990 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 13:18:51.803123 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 13:18:51.803364 ->[<IP_ADDRESS>:50218] connection accepted
INFO: 2018/09/03 13:18:51.805241 ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: connection ready; using protocol version 2
INFO: 2018/09/03 13:18:51.805415 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01.)]: connection shutting down due to error: cannot connect to ourself
INFO: 2018/09/03 13:18:51.805531 ->[<IP_ADDRESS>:50218|72:be:1a:b8:98:77(engine01.)]: connection shutting down due to error: cannot connect to ourself
INFO: 2018/09/03 13:18:51.805664 Listening for HTTP control messages on <IP_ADDRESS>:6784
INFO: 2018/09/03 13:18:51.805687 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using fastdp
INFO: 2018/09/03 13:18:51.805790 ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: connection added (new peer)
INFO: 2018/09/03 13:18:51.805823 Listening for metrics requests on <IP_ADDRESS>:6782
INFO: 2018/09/03 13:18:51.805876 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection ready; using protocol version 2
INFO: 2018/09/03 13:18:51.807567 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using fastdp
INFO: 2018/09/03 13:18:51.808297 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 13:18:51.810538 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection added (new peer)
INFO: 2018/09/03 13:18:51.811838 ->[<IP_ADDRESS>:6783|da:68:9b:b7:51:65(engine02.)]: connection ready; using protocol version 2
INFO: 2018/09/03 13:18:51.811945 overlay_switch ->[da:68:9b:b7:51:65(engine02.)] using fastdp
INFO: 2018/09/03 13:18:51.811988 ->[<IP_ADDRESS>:6783|da:68:9b:b7:51:65(engine02.)]: connection added (new peer)
INFO: 2018/09/03 13:18:51.812019 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4961: incoming message says owner da:68:9b:b7:51:65 v4995
INFO: 2018/09/03 13:18:51.812173 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection deleted
INFO: 2018/09/03 13:18:51.812271 ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4961: incoming message says owner da:68:9b:b7:51:65 v4995
INFO: 2018/09/03 13:18:51.813052 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] sleeve write tcp4 <IP_ADDRESS>:39220-><IP_ADDRESS>:6783: use of closed network connection
INFO: 2018/09/03 13:18:51.814581 ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: connection deleted
INFO: 2018/09/03 13:18:51.815535 ->[<IP_ADDRESS>:6783|da:68:9b:b7:51:65(engine02.)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4961: incoming message says owner da:68:9b:b7:51:65 v4995
INFO: 2018/09/03 13:18:51.815700 ->[<IP_ADDRESS>:6783|da:68:9b:b7:51:65(engine02.)]: connection deleted
INFO: 2018/09/03 13:18:51.815761 Removed unreachable peer da:68:9b:b7:51:65(engine02.)
INFO: 2018/09/03 13:18:51.815798 Removed unreachable peer 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/03 13:18:51.815825 Removed unreachable peer 2a:44:ef:34:94:3b(kube-master)
INFO: 2018/09/03 13:18:52.304924 Weave version 2.4.0 is available; please update at https://github.com/weaveworks/weave/releases/download/v2.4.0/weave
INFO: 2018/09/03 13:18:52.829705 [kube-peers] Added myself to peer list &{[{2a:44:ef:34:94:3b kube-master} {72:be:1a:b8:98:77 engine01.} {da:68:9b:b7:51:65 engine02.} {9e:1f:f3:46:dd:12 engine03}]}
DEBU: 2018/09/03 13:18:52.833896 [kube-peers] Nodes that have disappeared: map[engine02.:{da:68:9b:b7:51:65 engine02.}]
DEBU: 2018/09/03 13:18:52.833956 [kube-peers] Preparing to remove disappeared peer {da:68:9b:b7:51:65 engine02.}
DEBU: 2018/09/03 13:18:52.833978 [kube-peers] Noting I plan to remove  da:68:9b:b7:51:65
DEBU: 2018/09/03 13:18:52.840629 weave DELETE to http://<IP_ADDRESS>:6784/peer/da:68:9b:b7:51:65 with map[]
INFO: 2018/09/03 13:18:52.842911 [kube-peers] rmpeer of da:68:9b:b7:51:65: 0 IPs taken over from da:68:9b:b7:51:65
INFO: 2018/09/03 13:18:52.847470 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 13:18:52.851480 ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: connection ready; using protocol version 2
INFO: 2018/09/03 13:18:52.851778 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using fastdp
INFO: 2018/09/03 13:18:52.851858 ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: connection added (new peer)
INFO: 2018/09/03 13:18:52.853624 ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4961: incoming message says owner da:68:9b:b7:51:65 v4995
INFO: 2018/09/03 13:18:52.853890 ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: connection deleted
INFO: 2018/09/03 13:18:52.853959 Removed unreachable peer 9e:1f:f3:46:dd:12(engine03)
DEBU: 2018/09/03 13:18:52.868152 [kube-peers] Nodes that have disappeared: map[]
<IP_ADDRESS>
INFO: 2018/09/03 13:18:53.623710 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 13:18:53.630233 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection ready; using protocol version 2
INFO: 2018/09/03 13:18:53.630644 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using fastdp
INFO: 2018/09/03 13:18:53.630716 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection added (new peer)
INFO: 2018/09/03 13:18:53.631638 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 13:18:53.632233 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4961: incoming message says owner da:68:9b:b7:51:65 v4995
INFO: 2018/09/03 13:18:53.632377 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection deleted
INFO: 2018/09/03 13:18:53.632436 Removed unreachable peer 2a:44:ef:34:94:3b(kube-master)
INFO: 2018/09/03 13:18:53.632458 Removed unreachable peer da:68:9b:b7:51:65(engine02.)
INFO: 2018/09/03 13:18:53.632473 Removed unreachable peer 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/03 13:18:53.633775 ->[<IP_ADDRESS>:6783] connection shutting down due to error during handshake: Found unknown remote name: da:68:9b:b7:51:65 at <IP_ADDRESS>:6783
INFO: 2018/09/03 13:18:55.427538 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 13:18:55.430304 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection ready; using protocol version 2
INFO: 2018/09/03 13:18:55.430504 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using fastdp
INFO: 2018/09/03 13:18:55.430571 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection added (new peer)
INFO: 2018/09/03 13:18:55.432532 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4961: incoming message says owner da:68:9b:b7:51:65 v4995
INFO: 2018/09/03 13:18:55.432725 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection deleted
INFO: 2018/09/03 13:18:55.432785 Removed unreachable peer 2a:44:ef:34:94:3b(kube-master)
INFO: 2018/09/03 13:18:56.914843 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 13:18:56.917841 ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: connection ready; using protocol version 2
INFO: 2018/09/03 13:18:56.918074 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using fastdp
INFO: 2018/09/03 13:18:56.918169 ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: connection added (new peer)
INFO: 2018/09/03 13:18:56.919823 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 13:18:56.921437 ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4961: incoming message says owner da:68:9b:b7:51:65 v4995
INFO: 2018/09/03 13:18:56.921580 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] sleeve write tcp4 <IP_ADDRESS>:59466-><IP_ADDRESS>:6783: use of closed network connection
INFO: 2018/09/03 13:18:56.921627 ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: connection deleted
INFO: 2018/09/03 13:18:56.921683 Removed unreachable peer 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/03 13:18:56.921709 Removed unreachable peer 2a:44:ef:34:94:3b(kube-master)
INFO: 2018/09/03 13:18:56.921734 Removed unreachable peer da:68:9b:b7:51:65(engine02.)
INFO: 2018/09/03 13:18:56.923764 ->[<IP_ADDRESS>:6783] connection shutting down due to error during handshake: Found unknown remote name: da:68:9b:b7:51:65 at <IP_ADDRESS>:6783
INFO: 2018/09/03 13:18:59.315929 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 13:18:59.319051 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection ready; using protocol version 2
INFO: 2018/09/03 13:18:59.319263 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using fastdp
INFO: 2018/09/03 13:18:59.319342 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection added (new peer)
INFO: 2018/09/03 13:18:59.320601 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 13:18:59.321230 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4961: incoming message says owner da:68:9b:b7:51:65 v4995
INFO: 2018/09/03 13:18:59.321387 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection deleted
INFO: 2018/09/03 13:18:59.321450 Removed unreachable peer 2a:44:ef:34:94:3b(kube-master)
INFO: 2018/09/03 13:18:59.321470 Removed unreachable peer da:68:9b:b7:51:65(engine02.)

Yes below is the log, the error started today 2018/09/03 02:01:09.890616 , I did copy the log from yesterday till after the error started.
Engine02 is still working, Engine01 is the one that stopped. Unfortunatly i did restart it several time i don't know if i can still capture the log from Engine01.
INFO: 2018/09/02 07:57:39.947749 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 08:20:13.514069 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 08:37:49.940102 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 08:37:56.897223 Discovered remote MAC 82:a8:ee:f9:43:c7 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 08:38:31.620601 Discovered remote MAC 5e:76:e7:30:8a:82 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 08:38:46.654588 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 09:03:47.850445 Discovered remote MAC 82:a8:ee:f9:43:c7 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 09:05:20.679644 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 09:05:39.610444 Discovered remote MAC 82:e1:db:87:bb:cc at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 09:14:53.087907 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 09:30:17.859595 Discovered remote MAC 82:a8:ee:f9:43:c7 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 09:30:29.405022 Discovered remote MAC 5e:76:e7:30:8a:82 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 09:40:28.296713 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 09:57:59.148413 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 10:11:11.402068 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 10:11:11.403067 Discovered remote MAC 4e:8d:c6:c5:b7:3f at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 10:35:20.129633 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 10:35:34.337247 Discovered remote MAC ba:2b:4b:02:ba:33 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 10:35:34.422560 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 10:35:34.423791 Discovered remote MAC 4e:8d:c6:c5:b7:3f at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 11:00:03.429587 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 11:19:21.107324 Discovered remote MAC 4e:8d:c6:c5:b7:3f at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 11:19:27.064823 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 11:22:51.489002 Discovered remote MAC aa:6c:ff:c8:67:8e at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 11:38:30.310062 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 11:58:18.597562 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 11:58:29.286691 Discovered remote MAC 82:e1:db:87:bb:cc at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 12:20:36.871167 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 12:50:26.713598 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 13:01:04.090857 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 13:01:09.820950 Discovered remote MAC 82:a8:ee:f9:43:c7 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 13:02:26.574532 Discovered remote MAC 5e:76:e7:30:8a:82 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 13:06:24.541316 Discovered remote MAC 82:e1:db:87:bb:cc at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 13:17:29.496544 Discovered remote MAC 5e:76:e7:30:8a:82 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 13:58:37.699882 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 14:20:25.993693 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 14:37:33.032799 Weave version 2.4.0 is available; please update at https://github.com/weaveworks/weave/releases/download/v2.4.0/weave
INFO: 2018/09/02 14:49:08.591552 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 14:58:32.178835 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 15:12:56.212298 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 15:20:35.562991 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 15:41:36.134000 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 15:48:40.129956 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 15:58:01.012097 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 16:18:34.035792 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 16:18:52.965142 Discovered remote MAC 4e:8d:c6:c5:b7:3f at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 16:18:59.950369 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 16:19:12.421304 Discovered remote MAC 82:a8:ee:f9:43:c7 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 16:20:05.788052 Discovered remote MAC 5e:76:e7:30:8a:82 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 16:34:18.023375 Discovered remote MAC 82:a8:ee:f9:43:c7 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 16:34:36.652489 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 16:35:04.349994 Discovered remote MAC 5e:76:e7:30:8a:82 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 16:38:33.034092 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 16:57:59.565781 Discovered remote MAC 5e:76:e7:30:8a:82 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 17:20:24.768960 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 17:57:15.534162 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 18:18:34.075730 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 18:51:24.402316 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 19:20:13.865525 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 19:43:35.303324 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 19:58:35.155542 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 20:51:58.973838 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 21:25:49.018756 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 21:35:35.338692 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 21:35:38.376224 Discovered remote MAC 82:a8:ee:f9:43:c7 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 21:41:23.881150 Discovered remote MAC 82:e1:db:87:bb:cc at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 21:58:54.842481 Weave version 2.4.0 is available; please update at https://github.com/weaveworks/weave/releases/download/v2.4.0/weave
INFO: 2018/09/02 21:59:54.278181 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 22:28:44.045935 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 23:20:22.198513 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 23:42:51.907136 Discovered remote MAC 4e:7c:ec:9a:fe:c6 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 23:44:25.715324 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/02 23:45:46.780895 Discovered remote MAC 82:a8:ee:f9:43:c7 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 23:49:40.447411 Discovered remote MAC 5e:76:e7:30:8a:82 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/02 23:58:28.189598 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 00:06:37.413210 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/03 00:17:27.859132 Discovered remote MAC aa:6c:ff:c8:67:8e at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 00:20:21.749392 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/03 00:35:48.205470 Discovered remote MAC 82:a8:ee:f9:43:c7 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 00:58:38.023448 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 00:58:38.239916 Discovered remote MAC 82:e1:db:87:bb:cc at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 01:31:16.392851 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 01:58:47.719606 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:01:09.890616 ->[<IP_ADDRESS>:36422|72:be:1a:b8:98:77(engine01)]: connection shutting down due to error: read tcp4 <IP_ADDRESS>:6783-><IP_ADDRESS>:36422: read:
connection reset by peer
INFO: 2018/09/03 02:01:10.049001 ->[<IP_ADDRESS>:36422|72:be:1a:b8:98:77(engine01)]: connection deleted
INFO: 2018/09/03 02:01:10.049884 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:01:10.050732 ->[<IP_ADDRESS>:6783] error during connection attempt: dial tcp4 :0-><IP_ADDRESS>:6783: connect: connection refused
INFO: 2018/09/03 02:01:10.282928 Removed unreachable peer 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:01:32.156972 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:01:32.157686 ->[<IP_ADDRESS>:6783] error during connection attempt: dial tcp4 :0-><IP_ADDRESS>:6783: connect: connection refused
INFO: 2018/09/03 02:01:53.887483 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:01:53.888291 ->[<IP_ADDRESS>:6783] error during connection attempt: dial tcp4 :0-><IP_ADDRESS>:6783: connect: connection refused
INFO: 2018/09/03 02:01:59.701008 ->[<IP_ADDRESS>:41901] connection accepted
INFO: 2018/09/03 02:01:59.783638 ->[<IP_ADDRESS>:41901|72:be:1a:b8:98:77(engine01)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:01:59.785635 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using fastdp
INFO: 2018/09/03 02:01:59.785733 ->[<IP_ADDRESS>:41901|72:be:1a:b8:98:77(engine01)]: connection added (new peer)
INFO: 2018/09/03 02:01:59.788291 ->[<IP_ADDRESS>:41901|72:be:1a:b8:98:77(engine01)]: connection fully established
INFO: 2018/09/03 02:01:59.834532 Discovered remote MAC 3a:be:9e:66:51:59 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:01:59.836940 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:01:59.837778 sleeve ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:01:59.970644 Discovered remote MAC f6:31:e4:ec:f0:b1 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:01:59.970794 Discovered remote MAC 12:c8:48:21:7f:8a at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:01:59.971190 Discovered remote MAC 32:83:33:d0:ab:fb at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:01:59.972070 Discovered remote MAC ae:8f:dc:e6:af:5e at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:01:59.972692 Discovered remote MAC ce:96:48:f8:ef:b9 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:02:00.259710 Discovered remote MAC 72:be:1a:b8:98:77 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:02:00.459619 Discovered remote MAC de:12:18:f8:59:78 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:02:00.464077 Discovered remote MAC 8a:ae:60:1a:bb:f7 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:02:00.480709 Discovered remote MAC 22:53:7b:91:50:9a at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:02:00.630096 ->[<IP_ADDRESS>:41901|72:be:1a:b8:98:77(engine01)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: inco
ming message says owner 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:02:00.630392 ->[<IP_ADDRESS>:41901|72:be:1a:b8:98:77(engine01)]: connection deleted
INFO: 2018/09/03 02:02:01.109592 Discovered remote MAC 72:46:9b:71:91:06 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:02:01.914453 Discovered remote MAC de:50:2a:17:e6:db at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:02:03.252788 ->[<IP_ADDRESS>:36418] connection accepted
INFO: 2018/09/03 02:02:03.254390 ->[<IP_ADDRESS>:36418|72:be:1a:b8:98:77(engine01)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:02:03.254807 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using fastdp
INFO: 2018/09/03 02:02:03.254890 ->[<IP_ADDRESS>:36418|72:be:1a:b8:98:77(engine01)]: connection added
INFO: 2018/09/03 02:02:03.260519 ->[<IP_ADDRESS>:36418|72:be:1a:b8:98:77(engine01)]: connection fully established
INFO: 2018/09/03 02:02:03.265140 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:02:03.266109 sleeve ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:02:03.997683 Discovered remote MAC 5e:aa:46:e4:99:6c at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:02:05.118862 ->[<IP_ADDRESS>:54661|9e:1f:f3:46:dd:12(engine03)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message says own
er 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:02:05.119057 ->[<IP_ADDRESS>:54661|9e:1f:f3:46:dd:12(engine03)]: connection deleted
INFO: 2018/09/03 02:02:05.120796 ->[<IP_ADDRESS>:55641] connection accepted
INFO: 2018/09/03 02:02:05.121123 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:02:05.121799 ->[<IP_ADDRESS>:6783] error during connection attempt: dial tcp4 :0-><IP_ADDRESS>:6783: connect: no route to host
INFO: 2018/09/03 02:02:05.122659 ->[<IP_ADDRESS>:55641|9e:1f:f3:46:dd:12(engine03)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:02:05.122794 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using fastdp
INFO: 2018/09/03 02:02:05.122844 ->[<IP_ADDRESS>:55641|9e:1f:f3:46:dd:12(engine03)]: connection added
INFO: 2018/09/03 02:02:05.127467 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using sleeve
INFO: 2018/09/03 02:02:05.127536 ->[<IP_ADDRESS>:55641|9e:1f:f3:46:dd:12(engine03)]: connection fully established
INFO: 2018/09/03 02:02:05.127837 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:02:05.131496 sleeve ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:02:06.886923 Discovered remote MAC 5e:2f:3d:94:9b:46 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:02:09.886430 Discovered remote MAC aa:6c:ff:c8:67:8e at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:02:10.788929 Discovered remote MAC 4e:7c:ec:9a:fe:c6 at 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:02:14.761621 Discovered remote MAC 9e:1f:f3:46:dd:12 at 9e:1f:f3:46:dd:12(engine03)
ERRO: 2018/09/03 02:02:14.761727 Captured frame from MAC (9e:1f:f3:46:dd:12) to (8a:ae:60:1a:bb:f7) associated with another peer 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/03 02:02:25.471127 ->[<IP_ADDRESS>:59220|2a:44:ef:34:94:3b(kube-master)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message say
s owner 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:02:25.471415 ->[<IP_ADDRESS>:59220|2a:44:ef:34:94:3b(kube-master)]: connection deleted
INFO: 2018/09/03 02:02:25.473648 ->[<IP_ADDRESS>:60448] connection accepted
INFO: 2018/09/03 02:02:25.474887 ->[<IP_ADDRESS>:60448|2a:44:ef:34:94:3b(kube-master)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:02:25.476170 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using fastdp
INFO: 2018/09/03 02:02:25.478602 ->[<IP_ADDRESS>:60448|2a:44:ef:34:94:3b(kube-master)]: connection added
INFO: 2018/09/03 02:02:25.533042 ->[<IP_ADDRESS>:60448|2a:44:ef:34:94:3b(kube-master)]: connection fully established
INFO: 2018/09/03 02:02:25.979721 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:02:25.980443 sleeve ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:02:35.118197 ->[<IP_ADDRESS>:55641|9e:1f:f3:46:dd:12(engine03)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message says own
er 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:02:35.118314 ->[<IP_ADDRESS>:55641|9e:1f:f3:46:dd:12(engine03)]: connection deleted
INFO: 2018/09/03 02:02:35.120296 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:02:36.122441 ->[<IP_ADDRESS>:6783] error during connection attempt: dial tcp4 :0-><IP_ADDRESS>:6783: connect: no route to host
INFO: 2018/09/03 02:02:36.613377 ->[<IP_ADDRESS>:40426] connection accepted
INFO: 2018/09/03 02:02:36.614988 ->[<IP_ADDRESS>:40426|9e:1f:f3:46:dd:12(engine03)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:02:36.615409 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using fastdp
INFO: 2018/09/03 02:02:36.615503 ->[<IP_ADDRESS>:40426|9e:1f:f3:46:dd:12(engine03)]: connection added
INFO: 2018/09/03 02:02:36.628394 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using sleeve
INFO: 2018/09/03 02:02:36.628484 ->[<IP_ADDRESS>:40426|9e:1f:f3:46:dd:12(engine03)]: connection fully established
INFO: 2018/09/03 02:02:36.628901 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:02:36.630378 sleeve ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: Effective MTU verified at 1438
ERRO: 2018/09/03 02:02:44.624193 Captured frame from MAC (9e:1f:f3:46:dd:12) to (f6:31:e4:ec:f0:b1) associated with another peer 9e:1f:f3:46:dd:12(engine03)
INFO: 2018/09/03 02:02:56.992808 ->[<IP_ADDRESS>:36418|72:be:1a:b8:98:77(engine01)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: inco
ming message says owner 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:02:56.992926 ->[<IP_ADDRESS>:36418|72:be:1a:b8:98:77(engine01)]: connection deleted
INFO: 2018/09/03 02:02:56.995225 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:02:56.998690 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:02:56.998982 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using fastdp
INFO: 2018/09/03 02:02:56.999047 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: connection added
INFO: 2018/09/03 02:02:57.001195 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:02:57.001453 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using sleeve
INFO: 2018/09/03 02:02:57.001514 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: connection fully established
INFO: 2018/09/03 02:02:57.001739 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using fastdp
INFO: 2018/09/03 02:02:57.002895 sleeve ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:03:05.118258 ->[<IP_ADDRESS>:40426|9e:1f:f3:46:dd:12(engine03)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message says own
er 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:03:05.118536 ->[<IP_ADDRESS>:40426|9e:1f:f3:46:dd:12(engine03)]: connection deleted
INFO: 2018/09/03 02:03:07.330127 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:03:07.331412 ->[<IP_ADDRESS>:6783] error during connection attempt: dial tcp4 :0-><IP_ADDRESS>:6783: connect: no route to host
INFO: 2018/09/03 02:03:07.552033 ->[<IP_ADDRESS>:60290] connection accepted
INFO: 2018/09/03 02:03:07.553640 ->[<IP_ADDRESS>:60290|9e:1f:f3:46:dd:12(engine03)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:03:07.555789 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using fastdp
INFO: 2018/09/03 02:03:07.555941 ->[<IP_ADDRESS>:60290|9e:1f:f3:46:dd:12(engine03)]: connection added
INFO: 2018/09/03 02:03:08.056081 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using sleeve
INFO: 2018/09/03 02:03:08.056271 ->[<IP_ADDRESS>:60290|9e:1f:f3:46:dd:12(engine03)]: connection fully established
INFO: 2018/09/03 02:03:08.056567 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:03:08.057930 sleeve ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:03:35.120098 ->[<IP_ADDRESS>:60290|9e:1f:f3:46:dd:12(engine03)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message says own
er 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:03:35.120730 ->[<IP_ADDRESS>:60290|9e:1f:f3:46:dd:12(engine03)]: connection deleted
INFO: 2018/09/03 02:03:41.821102 ->[<IP_ADDRESS>:57576] connection accepted
INFO: 2018/09/03 02:03:41.822649 ->[<IP_ADDRESS>:57576|9e:1f:f3:46:dd:12(engine03)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:03:41.822929 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using fastdp
INFO: 2018/09/03 02:03:41.823005 ->[<IP_ADDRESS>:57576|9e:1f:f3:46:dd:12(engine03)]: connection added
INFO: 2018/09/03 02:03:42.325311 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using sleeve
INFO: 2018/09/03 02:03:42.325450 ->[<IP_ADDRESS>:57576|9e:1f:f3:46:dd:12(engine03)]: connection fully established
INFO: 2018/09/03 02:03:42.325468 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:03:42.327661 sleeve ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:03:55.471303 ->[<IP_ADDRESS>:60448|2a:44:ef:34:94:3b(kube-master)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message say
s owner 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:03:55.471486 ->[<IP_ADDRESS>:60448|2a:44:ef:34:94:3b(kube-master)]: connection deleted
INFO: 2018/09/03 02:03:55.474116 ->[<IP_ADDRESS>:47543] connection accepted
INFO: 2018/09/03 02:03:55.474440 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:03:55.476426 ->[<IP_ADDRESS>:47543|2a:44:ef:34:94:3b(kube-master)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:03:55.476723 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using fastdp
INFO: 2018/09/03 02:03:55.476802 ->[<IP_ADDRESS>:47543|2a:44:ef:34:94:3b(kube-master)]: connection added
INFO: 2018/09/03 02:03:55.484673 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:03:55.484960 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using fastdp
INFO: 2018/09/03 02:03:55.485405 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection shutting down due to error: Multiple connections to 2a:44:ef:34:94:3b(kube-master) added to da:68:9b:b7:
51:65(engine02)
INFO: 2018/09/03 02:03:55.490909 ->[<IP_ADDRESS>:47543|2a:44:ef:34:94:3b(kube-master)]: connection fully established
INFO: 2018/09/03 02:03:55.491077 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:03:55.490799 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using sleeve
INFO: 2018/09/03 02:03:55.503919 sleeve ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:03:55.978484 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using fastdp
INFO: 2018/09/03 02:03:56.992391 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incom
ing message says owner 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:03:56.992498 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: connection deleted
INFO: 2018/09/03 02:03:56.993892 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:03:57.012175 ->[<IP_ADDRESS>:56102] connection accepted
INFO: 2018/09/03 02:03:57.013167 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:03:57.013229 ->[<IP_ADDRESS>:56102|72:be:1a:b8:98:77(engine01)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:03:57.013360 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using fastdp
INFO: 2018/09/03 02:03:57.013380 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using fastdp
INFO: 2018/09/03 02:03:57.013402 ->[<IP_ADDRESS>:56102|72:be:1a:b8:98:77(engine01)]: connection added
INFO: 2018/09/03 02:03:57.013722 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: connection shutting down due to error: Multiple connections to 72:be:1a:b8:98:77(engine01.teltacwor
ldwide.co) added to da:68:9b:b7:51:65(engine02)
INFO: 2018/09/03 02:03:57.015726 ->[<IP_ADDRESS>:56102|72:be:1a:b8:98:77(engine01)]: connection fully established
INFO: 2018/09/03 02:03:57.028830 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:03:57.029464 sleeve ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:04:05.118852 ->[<IP_ADDRESS>:57576|9e:1f:f3:46:dd:12(engine03)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message says own
er 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:04:05.119057 ->[<IP_ADDRESS>:57576|9e:1f:f3:46:dd:12(engine03)]: connection deleted
INFO: 2018/09/03 02:04:05.121674 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:04:06.124245 ->[<IP_ADDRESS>:6783] error during connection attempt: dial tcp4 :0-><IP_ADDRESS>:6783: connect: no route to host
INFO: 2018/09/03 02:04:12.485802 ->[<IP_ADDRESS>:44010] connection accepted
INFO: 2018/09/03 02:04:12.487551 ->[<IP_ADDRESS>:44010|9e:1f:f3:46:dd:12(engine03)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:04:12.487738 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using fastdp
INFO: 2018/09/03 02:04:12.487815 ->[<IP_ADDRESS>:44010|9e:1f:f3:46:dd:12(engine03)]: connection added
INFO: 2018/09/03 02:04:12.993284 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using sleeve
INFO: 2018/09/03 02:04:12.994048 ->[<IP_ADDRESS>:44010|9e:1f:f3:46:dd:12(engine03)]: connection fully established
INFO: 2018/09/03 02:04:12.994246 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:04:12.995819 sleeve ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:04:25.472032 ->[<IP_ADDRESS>:47543|2a:44:ef:34:94:3b(kube-master)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message say
s owner 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:04:25.472239 ->[<IP_ADDRESS>:47543|2a:44:ef:34:94:3b(kube-master)]: connection deleted
INFO: 2018/09/03 02:04:25.475207 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:04:25.477777 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:04:25.478081 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using fastdp
INFO: 2018/09/03 02:04:25.478142 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection added
INFO: 2018/09/03 02:04:25.480997 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection fully established
INFO: 2018/09/03 02:04:25.481155 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:04:25.485508 sleeve ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:04:35.117789 ->[<IP_ADDRESS>:44010|9e:1f:f3:46:dd:12(engine03)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message says own
er 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:04:35.117955 ->[<IP_ADDRESS>:44010|9e:1f:f3:46:dd:12(engine03)]: connection deleted
INFO: 2018/09/03 02:04:50.123856 ->[<IP_ADDRESS>:48117] connection accepted
INFO: 2018/09/03 02:04:50.125463 ->[<IP_ADDRESS>:48117|9e:1f:f3:46:dd:12(engine03)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:04:50.125678 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using fastdp
INFO: 2018/09/03 02:04:50.125767 ->[<IP_ADDRESS>:48117|9e:1f:f3:46:dd:12(engine03)]: connection added
INFO: 2018/09/03 02:04:50.628065 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using sleeve
INFO: 2018/09/03 02:04:50.628150 ->[<IP_ADDRESS>:48117|9e:1f:f3:46:dd:12(engine03)]: connection fully established
INFO: 2018/09/03 02:04:50.628382 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:04:50.629520 sleeve ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:04:55.471836 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message says
 owner 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:04:55.472179 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection deleted
INFO: 2018/09/03 02:04:55.473460 ->[<IP_ADDRESS>:51359] connection accepted
INFO: 2018/09/03 02:04:55.477211 ->[<IP_ADDRESS>:51359|2a:44:ef:34:94:3b(kube-master)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:04:55.477555 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using fastdp
INFO: 2018/09/03 02:04:55.477627 ->[<IP_ADDRESS>:51359|2a:44:ef:34:94:3b(kube-master)]: connection added
INFO: 2018/09/03 02:04:55.493741 ->[<IP_ADDRESS>:51359|2a:44:ef:34:94:3b(kube-master)]: connection fully established
INFO: 2018/09/03 02:04:55.505409 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:04:55.507382 sleeve ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:05:05.117753 ->[<IP_ADDRESS>:48117|9e:1f:f3:46:dd:12(engine03)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message says own
er 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:05:05.117912 ->[<IP_ADDRESS>:48117|9e:1f:f3:46:dd:12(engine03)]: connection deleted
INFO: 2018/09/03 02:05:23.802106 ->[<IP_ADDRESS>:58682] connection accepted
INFO: 2018/09/03 02:05:23.803838 ->[<IP_ADDRESS>:58682|9e:1f:f3:46:dd:12(engine03)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:05:23.804138 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using fastdp
INFO: 2018/09/03 02:05:23.804210 ->[<IP_ADDRESS>:58682|9e:1f:f3:46:dd:12(engine03)]: connection added
INFO: 2018/09/03 02:05:24.306594 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using sleeve
INFO: 2018/09/03 02:05:24.306688 ->[<IP_ADDRESS>:58682|9e:1f:f3:46:dd:12(engine03)]: connection fully established
INFO: 2018/09/03 02:05:24.306759 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:05:24.308601 sleeve ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:05:25.472288 ->[<IP_ADDRESS>:51359|2a:44:ef:34:94:3b(kube-master)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message say
s owner 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:05:25.472629 ->[<IP_ADDRESS>:51359|2a:44:ef:34:94:3b(kube-master)]: connection deleted
INFO: 2018/09/03 02:05:25.474392 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:05:25.477780 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:05:25.477942 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using fastdp
INFO: 2018/09/03 02:05:25.477993 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection added
INFO: 2018/09/03 02:05:25.480285 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:05:25.480325 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection fully established
INFO: 2018/09/03 02:05:25.480288 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using sleeve
INFO: 2018/09/03 02:05:25.495980 sleeve ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:05:25.496555 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using fastdp
INFO: 2018/09/03 02:05:26.992492 ->[<IP_ADDRESS>:56102|72:be:1a:b8:98:77(engine01)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: inco
ming message says owner 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:05:26.992671 ->[<IP_ADDRESS>:56102|72:be:1a:b8:98:77(engine01)]: connection deleted
INFO: 2018/09/03 02:05:26.994314 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:05:26.995375 ->[<IP_ADDRESS>:56945] connection accepted
INFO: 2018/09/03 02:05:26.996587 ->[<IP_ADDRESS>:56945|72:be:1a:b8:98:77(engine01)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:05:26.996804 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using fastdp
INFO: 2018/09/03 02:05:26.996942 ->[<IP_ADDRESS>:56945|72:be:1a:b8:98:77(engine01)]: connection added
INFO: 2018/09/03 02:05:26.997562 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:05:26.997720 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using fastdp
INFO: 2018/09/03 02:05:26.997781 ->[<IP_ADDRESS>:56945|72:be:1a:b8:98:77(engine01)]: connection shutting down due to error: Multiple connections to 72:be:1a:b8:98:77(engine01.teltacwo
rldwide.co) added to da:68:9b:b7:51:65(engine02)
INFO: 2018/09/03 02:05:26.997806 ->[<IP_ADDRESS>:56945|72:be:1a:b8:98:77(engine01)]: connection deleted
INFO: 2018/09/03 02:05:26.998274 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: connection added
INFO: 2018/09/03 02:05:26.998893 overlay_switch ->[72:be:1a:b8:98:77(engine01)] fastdp write tcp4 <IP_ADDRESS>:6783-><IP_ADDRESS>:56945: use of closed network connection
INFO: 2018/09/03 02:05:27.000108 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using sleeve
INFO: 2018/09/03 02:05:27.000171 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: connection fully established
INFO: 2018/09/03 02:05:27.000417 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:05:27.001890 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using fastdp
INFO: 2018/09/03 02:05:27.001934 sleeve ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:05:35.118815 ->[<IP_ADDRESS>:58682|9e:1f:f3:46:dd:12(engine03)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message says own
er 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:05:35.119070 ->[<IP_ADDRESS>:58682|9e:1f:f3:46:dd:12(engine03)]: connection deleted
INFO: 2018/09/03 02:05:55.471430 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message says
 owner 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:05:55.471639 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection deleted
INFO: 2018/09/03 02:05:55.479248 ->[<IP_ADDRESS>:47588] connection accepted
INFO: 2018/09/03 02:05:55.483644 ->[<IP_ADDRESS>:47588|2a:44:ef:34:94:3b(kube-master)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:05:55.483843 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using fastdp
INFO: 2018/09/03 02:05:55.483882 ->[<IP_ADDRESS>:47588|2a:44:ef:34:94:3b(kube-master)]: connection added
INFO: 2018/09/03 02:05:55.488008 ->[<IP_ADDRESS>:47588|2a:44:ef:34:94:3b(kube-master)]: connection fully established
INFO: 2018/09/03 02:05:55.986736 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:05:55.987594 sleeve ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:06:06.373127 ->[<IP_ADDRESS>:48277] connection accepted
INFO: 2018/09/03 02:06:06.375099 ->[<IP_ADDRESS>:48277|9e:1f:f3:46:dd:12(engine03)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:06:06.375360 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using fastdp
INFO: 2018/09/03 02:06:06.375451 ->[<IP_ADDRESS>:48277|9e:1f:f3:46:dd:12(engine03)]: connection added
INFO: 2018/09/03 02:06:06.878483 overlay_switch ->[9e:1f:f3:46:dd:12(engine03)] using sleeve
INFO: 2018/09/03 02:06:06.878589 ->[<IP_ADDRESS>:48277|9e:1f:f3:46:dd:12(engine03)]: connection fully established
INFO: 2018/09/03 02:06:06.878748 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:06:06.879992 sleeve ->[<IP_ADDRESS>:6783|9e:1f:f3:46:dd:12(engine03)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:06:25.470952 ->[<IP_ADDRESS>:47588|2a:44:ef:34:94:3b(kube-master)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message say
s owner 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:06:25.471147 ->[<IP_ADDRESS>:47588|2a:44:ef:34:94:3b(kube-master)]: connection deleted
INFO: 2018/09/03 02:06:25.474918 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:06:25.480237 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:06:25.480437 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using fastdp
INFO: 2018/09/03 02:06:25.480528 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection added
INFO: 2018/09/03 02:06:25.482511 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection fully established
INFO: 2018/09/03 02:06:25.484273 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:06:25.488256 sleeve ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:06:26.992428 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incom
ing message says owner 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:06:26.992628 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: connection deleted
INFO: 2018/09/03 02:06:26.994004 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:06:26.994634 ->[<IP_ADDRESS>:38378] connection accepted
INFO: 2018/09/03 02:06:26.999731 ->[<IP_ADDRESS>:38378|72:be:1a:b8:98:77(engine01)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:06:26.999900 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using fastdp
INFO: 2018/09/03 02:06:26.999917 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:06:26.999957 ->[<IP_ADDRESS>:38378|72:be:1a:b8:98:77(engine01)]: connection added
INFO: 2018/09/03 02:06:27.000220 ->[<IP_ADDRESS>:38378|72:be:1a:b8:98:77(engine01)]: connection shutting down due to error: read tcp4 <IP_ADDRESS>:6783-><IP_ADDRESS>:38378: read:
connection reset by peer
INFO: 2018/09/03 02:06:27.000485 ->[<IP_ADDRESS>:38378|72:be:1a:b8:98:77(engine01)]: connection deleted
INFO: 2018/09/03 02:06:27.000595 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using fastdp
INFO: 2018/09/03 02:06:27.001015 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: connection added
INFO: 2018/09/03 02:06:27.001096 overlay_switch ->[72:be:1a:b8:98:77(engine01)] fastdp write tcp4 <IP_ADDRESS>:6783-><IP_ADDRESS>:38378: use of closed network connection
INFO: 2018/09/03 02:06:27.001130 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using sleeve
INFO: 2018/09/03 02:06:27.003824 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using sleeve
INFO: 2018/09/03 02:06:27.003898 ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: connection fully established
INFO: 2018/09/03 02:06:27.004004 EMSGSIZE on send, expecting PMTU update (IP packet was 60028 bytes, payload was 60020 bytes)
INFO: 2018/09/03 02:06:27.004360 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using fastdp
INFO: 2018/09/03 02:06:27.005554 sleeve ->[<IP_ADDRESS>:6783|72:be:1a:b8:98:77(engine01)]: Effective MTU verified at 1438
INFO: 2018/09/03 02:06:35.118957 ->[<IP_ADDRESS>:48277|9e:1f:f3:46:dd:12(engine03)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message says own
er 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:06:35.119373 ->[<IP_ADDRESS>:48277|9e:1f:f3:46:dd:12(engine03)]: connection deleted
INFO: 2018/09/03 02:06:35.125596 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:06:36.128395 ->[<IP_ADDRESS>:6783] error during connection attempt: dial tcp4 :0-><IP_ADDRESS>:6783: connect: no route to host
INFO: 2018/09/03 02:06:55.471862 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection shutting down due to error: Received update for IP range I own at <IP_ADDRESS> v4959: incoming message says
 owner 72:be:1a:b8:98:77 v4961
INFO: 2018/09/03 02:06:55.472044 ->[<IP_ADDRESS>:6783|2a:44:ef:34:94:3b(kube-master)]: connection deleted
INFO: 2018/09/03 02:06:55.480760 ->[<IP_ADDRESS>:57145] connection accepted
INFO: 2018/09/03 02:06:55.486244 ->[<IP_ADDRESS>:57145|2a:44:ef:34:94:3b(kube-master)]: connection ready; using protocol version 2
INFO: 2018/09/03 02:06:55.486481 overlay_switch ->[2a:44:ef:34:94:3b(kube-master)] using fastdp

The symptom is that two nodes in your cluster disagree on the contents of the IPAM data structure.  Since there's no clue in the first log you provided as to why, I asked for the other.
Absent any clues as to what happened at the time of the failure, this is the same as #3310, and I wrote about how you can clean up at https://github.com/weaveworks/weave/issues/3310#issuecomment-416885365

@shahbour Thanks for the logs.
Do you know whether engine02 was running at the time of the following?
INFO: 2018/09/03 13:18:52.829705 [kube-peers] Added myself to peer list &{[{2a:44:ef:34:94:3b kube-master} {72:be:1a:b8:98:77 engine01.} {da:68:9b:b7:51:65 engine02.} {9e:1f:f3:46:dd:12 engine03}]}
DEBU: 2018/09/03 13:18:52.833896 [kube-peers] Nodes that have disappeared: map[engine02.:{da:68:9b:b7:51:65 engine02.}]
DEBU: 2018/09/03 13:18:52.833956 [kube-peers] Preparing to remove disappeared peer {da:68:9b:b7:51:65 engine02.}
DEBU: 2018/09/03 13:18:52.833978 [kube-peers] Noting I plan to remove  da:68:9b:b7:51:65
DEBU: 2018/09/03 13:18:52.840629 weave DELETE to http://<IP_ADDRESS>:6784/peer/da:68:9b:b7:51:65 with map[]
INFO: 2018/09/03 13:18:52.842911 [kube-peers] rmpeer of da:68:9b:b7:51:65: 0 IPs taken over from da:68:9b:b7:51:65

Unfortunatly i did restart it several time i don't know if i can still capture the log from Engine01.

Maybe you can find the stopped container with docker ps -a?

Yes engine02 was on all the time , the error started at 02:01 as below
INFO: 2018/09/03 02:01:09.890616 ->[<IP_ADDRESS>:36422|72:be:1a:b8:98:77(engine01)]: connection shutting down due to error: read tcp4 <IP_ADDRESS>:6783-><IP_ADDRESS>:36422: read: connection reset by peer
INFO: 2018/09/03 02:01:10.049001 ->[<IP_ADDRESS>:36422|72:be:1a:b8:98:77(engine01)]: connection deleted
INFO: 2018/09/03 02:01:10.049884 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:01:10.050732 ->[<IP_ADDRESS>:6783] error during connection attempt: dial tcp4 :0-><IP_ADDRESS>:6783: connect: connection refused
INFO: 2018/09/03 02:01:10.282928 Removed unreachable peer 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 02:01:32.156972 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:01:32.157686 ->[<IP_ADDRESS>:6783] error during connection attempt: dial tcp4 :0-><IP_ADDRESS>:6783: connect: connection refused
INFO: 2018/09/03 02:01:53.887483 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/03 02:01:53.888291 ->[<IP_ADDRESS>:6783] error during connection attempt: dial tcp4 :0-><IP_ADDRESS>:6783: connect: connection refused
INFO: 2018/09/03 02:01:59.701008 ->[<IP_ADDRESS>:41901] connection accepted

at hour 13:18 I think I was doing a restart to engine01 to check if goes up , and for sure engine02 was up because all our pods were in it and system was up
below log are from engine02 at 13:18:52
INFO: 2018/09/03 13:18:09.010613 Removed unreachable peer 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 13:18:51.787727 ->[<IP_ADDRESS>:52588] connection accepted
INFO: 2018/09/03 13:18:51.790587 ->[<IP_ADDRESS>:52588|72:be:1a:b8:98:77(engine01)]: connection ready; using protocol version 2
INFO: 2018/09/03 13:18:51.790733 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using fastdp
INFO: 2018/09/03 13:18:51.790803 ->[<IP_ADDRESS>:52588|72:be:1a:b8:98:77(engine01)]: connection added (new peer)
INFO: 2018/09/03 13:18:51.793576 ->[<IP_ADDRESS>:52588|72:be:1a:b8:98:77(engine01)]: connection fully established
INFO: 2018/09/03 13:18:51.794588 ->[<IP_ADDRESS>:52588|72:be:1a:b8:98:77(engine01)]: connection shutting down due to error: read tcp4 <IP_ADDRESS>:6783-><IP_ADDRESS>:52588: read: connection reset by peer
INFO: 2018/09/03 13:18:51.794895 ->[<IP_ADDRESS>:52588|72:be:1a:b8:98:77(engine01)]: connection deleted
INFO: 2018/09/03 13:18:51.795131 Removed unreachable peer 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 13:18:51.797380 Removed unreachable peer 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 13:18:52.834296 Removed unreachable peer 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 13:18:53.610733 ->[<IP_ADDRESS>:57000] connection accepted
INFO: 2018/09/03 13:18:53.612583 ->[<IP_ADDRESS>:57000|72:be:1a:b8:98:77(engine01)]: connection ready; using protocol version 2
INFO: 2018/09/03 13:18:53.612721 overlay_switch ->[72:be:1a:b8:98:77(engine01)] using fastdp
INFO: 2018/09/03 13:18:53.612849 ->[<IP_ADDRESS>:57000|72:be:1a:b8:98:77(engine01)]: connection added (new peer)
INFO: 2018/09/03 13:18:53.613091 ->[<IP_ADDRESS>:57000|72:be:1a:b8:98:77(engine01)]: connection shutting down due to error: read tcp4 <IP_ADDRESS>:6783-><IP_ADDRESS>:57000: read: connection reset by peer
INFO: 2018/09/03 13:18:53.614032 ->[<IP_ADDRESS>:57000|72:be:1a:b8:98:77(engine01)]: connection deleted
INFO: 2018/09/03 13:18:53.614160 Removed unreachable peer 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 13:18:53.614727 Removed unreachable peer 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 13:18:55.416425 Removed unreachable peer 72:be:1a:b8:98:77(engine01)
INFO: 2018/09/03 13:18:56.900218 ->[<IP_ADDRESS>:55045] connection accepted
INFO: 2018/09/03 13:18:56.901104 Removed unreachable peer 72:be:1a:b8:98:77(engine01)

Sweet! Here is the culprit: engine02 has neither internalIP nor externalIP, so https://github.com/weaveworks/weave/blob/master/prog/kube-utils/main.go#L28 removes the node from the list of available ones, and therefore weave-kube reclaimer tries to remove the node.
Any idea why it does not have any internalIP?

Nope i don't , i noticed that few weeks ago and was trying to manually set it but it did not work for me and i forgot about it .

I don't see how to set it manually, so you might need to drain the node and re-deploy k8s on it.
I'm working on a fix for Weave Net but it will take a while until its release.

I did fix the internal and external IPs
(⎈ |production:default)➜  ~ kubectl get node -o wide
NAME                          STATUS                     ROLES     AGE       VERSION   INTERNAL-IP      EXTERNAL-IP      OS-IMAGE                KERNEL-VERSION               CONTAINER-RUNTIME
engine01                      Ready                      <none>    59d       v1.11.2   <IP_ADDRESS>   <IP_ADDRESS>   CentOS Linux 7 (Core)   3.10.0-693.21.1.el7.x86_64   docker://1.13.1
engine02                      Ready,SchedulingDisabled   <none>    59d       v1.11.2   <IP_ADDRESS>   <IP_ADDRESS>   CentOS Linux 7 (Core)   3.10.0-693.21.1.el7.x86_64   docker://1.13.1
engine03                      Ready                      <none>    59d       v1.11.2   <IP_ADDRESS>     <IP_ADDRESS>     CentOS Linux 7 (Core)   3.10.0-693.21.1.el7.x86_64   docker://1.13.1
kube-master                   Ready                      master    89d       v1.11.2   <IP_ADDRESS>   <IP_ADDRESS>   CentOS Linux 7 (Core)   3.10.0-693.21.1.el7.x86_64   docker://1.13.1

Today Morning i just checked and seems node is loosing its ip address some how

Fixed in #3393

in my case, it was only one node that was not able to connect to other nodes in the waeve cluster.
solution was :

Identify the failing node
SSH to the node
rm /var/lib/weave/weave-netdata.db
Restart weave-net POD that is running on the problematic node.


does not support sockaddr_in for libc::accept

Hi thanks for the lib! I find the accept does not allow us to know the struct sockaddr_in.

Could you describe your problem in more detail, please?

@asomers Looking at the nix doc and the linux doc, it seems that the nix's accept has one less effective argument, thus we cannot get info of sockaddr_in. Thanks!

Workaround
For people reading this in the future: I worked around it by calling getpeername() on the file descriptor.
We can prevent this call to getpeername() and I'll provide a PR if there's any possibility that it would get merged.
Description of the problem:
Posix requires that the accept() function looks like this in C:
#include <sys/socket.h>

int accept(int socket, struct sockaddr *restrict address,
       socklen_t *restrict address_len);

So, in C, we can specify the file descriptor of the socket and get the address of the peer using the last two arguments.
Using Rust and Nix, we can't do that, because Nix sends NULL pointers, which means the C library won't tell us the peer address.
Suggested change of signature
// current signature
pub fn accept(sockfd: RawFd) -> Result<RawFd>

// proposed signature
pub fn accept<T: SockaddrLike>(sockfd: RawFd) -> Result<(RawFd, T)>

We would keep the API consistent with getpeername() and other functions in the socket crate.
This change is not backwards compatible, but that seems unavoidable to me.


⛔ Use standarized components and pages to fit to base

Currently, our code bases are structured differently. This means that we cannot do a merge without completely breaking the project.
In order to avoid this, a concept of pages and components is to be developed, which will determine the file structure according to which we have to design our code.

The page folder contains the following hierarchy:

The pages which are displayed with brackets [ ] are dynamic routes. So for these routes, the file in the page folder is the middleware for example for the auth and state management and the content itself is managed by components which are served in the components folder.

@Jonas22rr I'll implement this and when it is merged in develop branch you'll need to revise your branch to meet the specifications.