search for: cksum

...early what the other person is saying, but the other person (on the PSTN(B) side) hears nothing from PSTN(A). I use tcpdump for debug de rtp trafic, and ouput contains 19:06:00.741293 IP (tos 0x0, ttl 64, id 179, offset 0, flags [DF], proto 17, length: 60) x.x.x.x.19926 > y.y.y.y.18974: [no cksum] UDP, length 32 19:06:00.763133 IP (tos 0x0, ttl 64, id 179, offset 0, flags [DF], proto 17, length: 60) x.x.x.x.19926 > y.y.y.y.18974: [no cksum] UDP, length 32 19:06:00.740415 IP (tos 0x0, ttl 64, id 179, offset 0, flags [DF], proto 17, length: 60) x.x.x.x.19926 > y.y.y.y.18974: [no cksum...

...ck (although i've not tried without because i need to masquerade). 0:e0:7d:74:ab:cc 0:e0:7d:74:ab:cd 0800 1514: 192.168.0.1.51420 > 192.168.0.223.56058: FRW 3723124278:3723124306(28) ack 2602302847 win 60390 urg 44527 <[bad opt]> (DF) [tos 0x12,ECT(0)] (ttl 64, id 11333, len 100, bad cksum 8cd4!) 0:e0:7d:74:ab:cc 0:e0:7d:74:ab:cd 0800 1514: 172.183.247.57.1282 > 192.168.0.223.12899: P [bad tcp cksum be1d!] 176162560:176162584(24) ack 3969909265 win 52224 (DF) (ttl 118, id 18806, len 52, bad cksum 569d!) 0:e0:7d:74:ab:cc 0:e0:7d:74:ab:cd 0800 1514: 192.168.0.1.3356 > 192.168.0.2...

...ot using it for things like this in the future.) So I stopped the daemons and corrected that (gluster-2 had a tiering entry the others didn't). Started things back up and now gluster-3 is being rejected by the other two. The error is below. I'm tempted to repeat - down things, copy the checksum the "good" ones agree on, start things; but given that this has turned into a balloon-squeezing exercise, I want to make sure I'm not doing this the wrong way. What is the currently accepted best method for fixing this? And given that this happened on a nearly brand-new deployment...

...16.904961] I [MSGID: 106490] [glusterd-handler.c:2606:__glusterd_handle_incoming_friend_req] 0-glusterd: Received probe from uuid: 2a17edb4-ae68-4b67-916e-e38a2087ca28 [2017-08-29 13:36:16.906477] E [MSGID: 106010] [glusterd-utils.c:3034:glusterd_compare_friend_volume] 0-management: Version of Cksums CO-DATA differ. local cksum = 4088157353, remote cksum = 2870780063 on peer 10.5.6.17 [2017-08-29 13:36:16.907187] I [MSGID: 106493] [glusterd-handler.c:3866:glusterd_xfer_friend_add_resp] 0-glusterd: Responded to 10.5.6.17 (0), ret: 0, op_ret: -1 ... Why would adding a new peer make cluster j...

...e. 3.12.6 and the cluster.op-version is set to latest, then ideally you shouldn't see this problem. Could you clarify? > > Started things back up and now gluster-3 is being rejected by the other > two. The error is below. > > I'm tempted to repeat - down things, copy the checksum the "good" ones > agree on, start things; but given that this has turned into a > balloon-squeezing exercise, I want to make sure I'm not doing this the > wrong way. > Yes, that's the way. Copy /var/lib/glusterd/vols/<volname>/ from the good node to the rejected...

Hi Ji-Hyeon, Thanks to your help I could find out the problematic file. This would be the quota file of my volume it has a different checksum on node1 whereas node2 and arbiternode have the same checksum. This is expected as I had issues which my quota file and had to fix it manually with a script (more details on this mailing list in a previous post) and I only did that on node1. So what I now did is to copy /var/lib/glusterd/vols/myvol...

Logs from newly added node helped me in RCA of the issue. Info file on node 10.5.6.17 consist of an additional property "tier-enabled" which is not present in info file from other 3 nodes, hence when gluster peer probe call is made, in order to maintain consistency across the cluster cksum is compared. In this case as both files are different leading to different cksum, causing state in "State: Peer Rejected (Connected)". This inconsistency arise due to upgrade you did. Workaround: 1.Go to node 10.5.6.17 2.Open info file from "/var/lib/glusterd/vols/<vol-name>...

...106490] > [glusterd-handler.c:2606:__glusterd_handle_incoming_friend_req] > 0-glusterd: Received probe from uuid: 2a17edb4-ae68-4b67-916e-e38a2087ca28 > [2017-08-29 13:36:16.906477] E [MSGID: 106010] > [glusterd-utils.c:3034:glusterd_compare_friend_volume] 0-management: > Version of Cksums CO-DATA differ. local cksum = 4088157353, remote cksum = > 2870780063 on peer 10.5.6.17 > [2017-08-29 13:36:16.907187] I [MSGID: 106493] > [glusterd-handler.c:3866:glusterd_xfer_friend_add_resp] 0-glusterd: > Responded to 10.5.6.17 (0), ret: 0, op_ret: -1 > ... > > Why would a...

...up (on both machines): `tcpdump -i eth0 port 7777 -v` Here is a TCP dump showing port 7777 is not blocked (I added an exception in IP tables) (Node 0) 13:13:11.711539 IP (tos 0x0, ttl 64, id 18286, offset 0, flags [DF], proto: TCP (6), length: 60) 10.128.7.33.47601 > 10.128.255.3.cbt: S, cksum 0xd272 (correct), 3820380795:3820380795(0) win 5840 <mss 1460,sackOK,timestamp 4294911253 0,nop,wscale 6> 13:13:14.710703 IP (tos 0x0, ttl 64, id 18287, offset 0, flags [DF], proto: TCP (6), length: 60) 10.128.7.33.47601 > 10.128.255.3.cbt: S, cksum 0xc6ba (correct), 3820380795:3820...

> On Mar 5, 2018, at 6:41 PM, Atin Mukherjee <amukherj at redhat.com> wrote: > I'm tempted to repeat - down things, copy the checksum the "good" ones agree on, start things; but given that this has turned into a balloon-squeezing exercise, I want to make sure I'm not doing this the wrong way. > > Yes, that's the way. Copy /var/lib/glusterd/vols/<volname>/ from the good node to the rejected one and r...

...ol. The OS is still SXCE snv_117 so far. Early tests which have filled the UltraStar with data in a couple of single-partition pools on it had shown that the writes and scrubs yielded 0 errors. However, now that this disk works as part of a larger old pool (9*5-vdev raidz1 sets), it suffers CKSUM error counts found on every scrub. They tried to reseat the disk in the same position (and will soon try the ex-position of another failed disk), but reseating did not help. For some reason, while early high CKSUM counts led to ZFS degrading the pool, this no longer happens (and my questionable scr...

...OS servers are trying to send logs to a logging server via 514/udp, however I'm not receiving anything. I did the following on CentOS *tcpdump -vvv -nn udp -i esn160 port 514* In another session on the same server: *nc syslog-server -u 514* tcpdump started to show me messages like: *[bad udp cksum 0x3ce9 -> 0xb0f5!] SYSLOG, length: 172* After some research I disabled TCO (ethtool -K ens160 tx off rx off), now tcpdump shows: *[udp sum ok] [|syslog]* And I'm also receiving the logs. Yay! I have the same issue on multiple servers with CentOS versions 7.3.1611, 7.4.1708 & 7.5.1804....

...ee software, and you are welcome to redistribute it under certain conditions. See the GNU General Public Licence for details. sh-3.2# uname -a Linux navi 2.6.31.5-bfs304 #9 Wed Dec 2 02:58:47 EET 2009 ppc GNU/Linux I ran navi:/mnt/miracle# foreach i ( "`cat ../miracle.txt`" ) foreach? cksum "$i" >> ../miracle.cksums.txt foreach? end miracle.txt has list of files (via find ./ -type f) from original partition. I did same for storage partition (target) The results of : navi:/mnt# diff miracle.cksums.txt storage.cksums.txt | wc -l were (includes some additional lines due...

...ications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed with 66 errors on Fri Mar 23 12:52:36 2007 config: NAME STATE READ WRITE CKSUM test ONLINE 0 0 134 /dev/md/dsk/d100 ONLINE 0 0 134 errors: 66 data errors, use ''-v'' for a list bash-3.00# Disks are from Clariion CX3-40 with FC 15K disks using MPxIO (2x 4Gb links). I was changing watermarks for cache...

...gt; [glusterd-handler.c:2540:__glusterd_handle_incoming_friend_req] > 0-glusterd: > Received probe from uuid: 546503ae-ba0e-40d4-843f-c5dbac22d272 > [2017-12-20 05:02:54.696956] E [MSGID: 106010] > [glusterd-utils.c:3370:glusterd_compare_friend_volume] 0-management: > Version > of Cksums shchst01-sto differ. local cksum = 4218452135, remote cksum = > 2747317484 on peer shchhv02-sto > [2017-12-20 05:02:54.697796] I [MSGID: 106493] > [glusterd-handler.c:3800:glusterd_xfer_friend_add_resp] 0-glusterd: > Responded to shchhv02-sto (0), ret: 0, op_ret: -1 > [2017-12-20 05...

...5:02:54.695823] I [MSGID: 106490] [glusterd-handler.c:2540:__glusterd_handle_incoming_friend_req] 0-glusterd: Received probe from uuid: 546503ae-ba0e-40d4-843f-c5dbac22d272 [2017-12-20 05:02:54.696956] E [MSGID: 106010] [glusterd-utils.c:3370:glusterd_compare_friend_volume] 0-management: Version of Cksums shchst01-sto differ. local cksum = 4218452135, remote cksum = 2747317484 on peer shchhv02-sto [2017-12-20 05:02:54.697796] I [MSGID: 106493] [glusterd-handler.c:3800:glusterd_xfer_friend_add_resp] 0-glusterd: Responded to shchhv02-sto (0), ret: 0, op_ret: -1 [2017-12-20 05:02:55.033822] I [MSGID:...

...#39;'. Then I make a ping out of domU2 to www.debian.de so I get no answer. The name isn''t resolved. A ping to IP of www.debian.de works fine. A ping on www.debian.de out of dom0 or a client in my LAN works fine. Only the resolving in domU2 crashed. With tcpdump I see many [bad udp cksum 83ec!]. For example: 21:32:12.457805 aa:00:00:00:00:13 > aa:00:00:00:00:12, ethertype IPv4 (0x0800), length 73: IP (tos 0x0, ttl 64, id 58967, offset 0, flags [DF], length: 59) 192.168.1.200.1045 > sns.kabel-bb.de.domain: [bad udp cksum 626c!] 47711+ A? www.debian.de. (31) I don'...

...you in advance for the help. > > Best, > Mabi > > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-users Hi mabi. In my opinion, It caused by some volfile/checksum mismatch. try to look glusterd log file(/var/log/glusterfs/glusterd.log) in REJECTED node, and find some log like below [2014-06-17 04:21:11.266398] I [glusterd-handler.c:2050:__glusterd_handle_incoming_friend_req] 0-glusterd: Received probe from uuid: 81857e74-a726-4f48-8d1b-c2a4bdbc094f [2014-06...

...puzzles me (questions follow): # zdb -dddddddd -bbbbbb rpool/ROOT/nightly-2012-01-31 260050 ... 1e80000 L0 DVA[0]=<0:200972e00:20200> DVA[1]=<0:391820a00:200> [L0 ZFS plain file] fletcher4 uncompressed LE gang unique single size=20000L/20000P birth=743480L/743480P fill=1 cksum=40ed72fd1a7e:10813724cba2f082:99adc8fc26918419:77a6a1f23fa0600 1ea0000 L0 DVA[0]=<0:206373000:20000> [L0 ZFS plain file] fletcher4 uncompressed LE contiguous unique single size=20000L/20000P birth=743481L/743481P fill=1 cksum=3e813c892009:fe2666367dd7397:eab4fcda09e1eda:920af5...

...2540:__glusterd_handle_incoming_friend_req] >> 0-glusterd: >> Received probe from uuid: 546503ae-ba0e-40d4-843f-c5dbac22d272 >> [2017-12-20 05:02:54.696956] E [MSGID: 106010] >> [glusterd-utils.c:3370:glusterd_compare_friend_volume] 0-management: >> Version >> of Cksums shchst01-sto differ. local cksum = 4218452135, remote cksum = >> 2747317484 on peer shchhv02-sto >> [2017-12-20 05:02:54.697796] I [MSGID: 106493] >> [glusterd-handler.c:3800:glusterd_xfer_friend_add_resp] 0-glusterd: >> Responded to shchhv02-sto (0), ret: 0, op_ret: -1 &gt...