corrupt packet checksum in kubernetes cluster

[ms4720]

This issue tracker is only for technical issues related to komodod

General Komodo questions and/or support requests and are best directed to Discord

Describe the issue

Please provide a general summary of the issue you're experiencing

Blockchain does not load, seed happens I think

Below is a tcpdump that is reporting bad checksums on packet headers

    100.96.109.12.52134 > static.146.196.47.78.clients.your-server.de.7770: Flags [.], cksum 0xe454 (incorrect -> 0x6424), seq 129, ack 68, win 58, options [nop,nop,TS val 1104671909 ecr 836041991], length 0
17:03:22.009940 IP (tos 0x0, ttl 38, id 65037, offset 0, flags [DF], proto TCP (6), length 52)
    static.146.196.47.78.clients.your-server.de.7770 > 100.96.109.12.52134: Flags [F.], cksum 0x6533 (correct), seq 68, ack 129, win 30, options [nop,nop,TS val 836042003 ecr 1104671653], length 0
17:03:22.010016 IP (tos 0x0, ttl 64, id 995, offset 0, flags [DF], proto TCP (6), length 52)
    100.96.109.12.52134 > static.146.196.47.78.clients.your-server.de.7770: Flags [F.], cksum 0xe454 (incorrect -> 0x63e5), seq 129, ack 69, win 58, options [nop,nop,TS val 1104671958 ecr 836042003], length 0
17:03:22.264031 IP (tos 0x0, ttl 38, id 65038, offset 0, flags [DF], proto TCP (6), length 52)
    static.146.196.47.78.clients.your-server.de.7770 > 100.96.109.12.52134: Flags [.], cksum 0x63c2 (correct), seq 69, ack 130, win 30, options [nop,nop,TS val 836042066 ecr 1104671958], length 0

here is what .kmd/debug.log says

tail debug.log
2019-03-20 09:04:02 connect() to 88.99.251.101:7770 failed after select(): Connection refused (111)
2019-03-20 09:09:25 Misbehaving: 149.56.19.212:7770 (0 -> 1)
2019-03-20 09:09:25 ProcessMessages(reject, 43 bytes) FAILED peer=568
2019-03-20 09:09:28 Misbehaving: 52.65.58.103:7770 (0 -> 1)
2019-03-20 09:09:28 ProcessMessages(reject, 43 bytes) FAILED peer=569
2019-03-20 09:09:37 connect() to 159.65.134.48:7770 failed after select(): Connection refused (111)
2019-03-20 09:09:40 connect() to 95.213.238.98:7770 failed after select(): Connection refused (111)
2019-03-20 09:10:03 Misbehaving: 66.70.180.46:7770 (0 -> 1)
2019-03-20 09:10:03 ProcessMessages(reject, 43 bytes) FAILED peer=570
2019-03-20 09:10:11 connect() to 178.128.25.203:7770 failed after select(): Connection refused (111)

the state .kmd dir is in, it is missing some things compaired to a working instance:

root@kmd-0:~/.kmd# ls -l
total 948
drwx------ 3 root root   4096 Mar 14 10:45 blocks
drwx------ 2 root root   4096 Mar 19 09:59 chainstate
drwx------ 2 root root   4096 Mar 14 10:45 database
-rw------- 1 root root      0 Mar 14 10:45 db.log
-rw------- 1 root root 834353 Mar 20 09:22 debug.log
drwxrwxrwx 2 root root   4096 Mar 19 09:59 komodo.conf
-rw------- 1 root root      2 Mar 19 09:59 komodod.pid
drwx------ 2 root root  16384 Mar 14 10:42 lost+found
drwx------ 2 root root   4096 Mar 19 09:59 notarisations
-rw------- 1 root root   4904 Mar 20 09:11 peers.dat
-rw------- 1 root root  81920 Mar 14 10:45 wallet.dat

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

I load the pod in kubernetes

Expected behaviour

it loads block chain info

Actual behaviour + errors

Tell us what happens instead including any noticable error output (any messages displayed on-screen when e.g. a crash occurred)

error is block count is 0 after several days

The version of Komodo you were using:

Komodo Daemon version v1.0.15-5563cfe

Machine specs:

• OS name + version: ubuntu 16.04
• CPU: 1 vcpu
• RAM: 4gb
• Disk size: 50gb
• Disk Type (HD/SDD): ssd
• Linux kernel version (uname -a): 4.15.0-45-generic DPoW #48~16.04.1-Ubuntu
• Compiler version (gcc -version): don't know

Any extra information that might be useful in the debugging process.

Do you have a backup of ~/.komodo directory and/or take a VM snapshot?

[jl777]

do things work when not in some kubernates cluster. I have heard of some issues setting up containers, but not familiar with the details of what needs to be done. if it works normally, but not when put in a container that is supposed to work as normal, then it would be an issue with the container

[ms4720]

it works in a different, older, cluster. and it worked elsewhere in docker. I am curious why the packets could go out with checksum issues. And thanks for the quick reply.

[jl777]

checksum issues indicates some sort of low level networking error or a bad version of software using wrong network magic