public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* Unexpected EOF in 7.2.0
@ 2021-07-09 15:23 John Goerzen
2021-07-09 16:42 ` John Goerzen
0 siblings, 1 reply; 7+ messages in thread
From: John Goerzen @ 2021-07-09 15:23 UTC (permalink / raw)
To: nncp-devel
Hello,
I have a 3GB packet that was transferred from its origin to my
gateway machine via nncp-call. When called on it, nncp-check
works fine and verifies its integrity. However:
nncp@nncp:~$ nncp-toss -progress
2021-07-09T15:10:27Z ERROR Tossing
mccoy/74HUFHYZOB7J7MLU7SHKTRODN7OH7HRLSSTKWEEDKNMXLOJBDI2Q:
unmarshal: xdr:DecodeFixedOpaque: unexpected EOF while decoding 8
bytes - read: '[]'
And the log shows:
When: 2021-07-09T15:12:13.896311727Z
Err: xdr:DecodeFixedOpaque: unexpected EOF while decoding 8 bytes
- read: '[]'
Who: rx-unmarshal
Node: NE2CD32WK62N3QWWQLJUZXVX2WZAIMM7DBIXQVJTFDSXHAWSULBQ
Pkt: 74HUFHYZOB7J7MLU7SHKTRODN7OH7HRLSSTKWEEDKNMXLOJBDI2Q
Nice: 226
Msg: Tossing
mccoy/74HUFHYZOB7J7MLU7SHKTRODN7OH7HRLSSTKWEEDKNMXLOJBDI2Q:
unmarshal
(this is a transitional packet)
Also:
nncp@nncp:~$ nncp-pkt -dump <
/var/spool/nncp/NE2CD32WK62N3QWWQLJUZXVX2WZAIMM7DBIXQVJTFDSXHAWSULBQ/rx/74HUFHYZOB7J7MLU7SHKTRODN7OH7HRLSSTKWEEDKNMXLOJBDI2Q
main.go:163: unexpected EOF
These commands that return with "unexpected EOF" are returning
almost immediately. They could not possibly have processed 3GB
like nncp-check does. If I omit -dump from nncp-pkt, it works
fine. I tried reblocking with dd, and that didn't help either.
This occurs both with go 1.14 and go 1.15.
The only unique thing here is that it's from a new node on my
network.
Other packets from that node were processed successfully, though
they were much smaller. I tried removing the .hdr file and that
didn't help either (it was recreated).
Thanks!
- John
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unexpected EOF in 7.2.0
2021-07-09 15:23 Unexpected EOF in 7.2.0 John Goerzen
@ 2021-07-09 16:42 ` John Goerzen
2021-07-09 20:23 ` John Goerzen
0 siblings, 1 reply; 7+ messages in thread
From: John Goerzen @ 2021-07-09 16:42 UTC (permalink / raw)
To: nncp-devel
I'm fairly baffled by this. I ran it under strace, and there's no
syscall that's returning EOF. nncp-pkt is easier to analyze under
strace, and it does a 4096-byte read, gets a 4096-byte result,
then crashes with unexpected EOF.
I don't know Go, though... I'm also baffled at how the test at
pkt.go line 163 could cause an error.
- John
On Fri, Jul 09 2021, John Goerzen wrote:
> Hello,
>
> I have a 3GB packet that was transferred from its origin to my
> gateway machine
> via nncp-call. When called on it, nncp-check works fine and
> verifies its
> integrity. However:
>
> nncp@nncp:~$ nncp-toss -progress
> 2021-07-09T15:10:27Z ERROR Tossing
> mccoy/74HUFHYZOB7J7MLU7SHKTRODN7OH7HRLSSTKWEEDKNMXLOJBDI2Q:
> unmarshal: xdr:DecodeFixedOpaque: unexpected EOF while decoding
> 8 bytes - read:
> '[]'
>
> And the log shows:
>
> When: 2021-07-09T15:12:13.896311727Z
> Err: xdr:DecodeFixedOpaque: unexpected EOF while decoding 8
> bytes - read: '[]'
> Who: rx-unmarshal
> Node: NE2CD32WK62N3QWWQLJUZXVX2WZAIMM7DBIXQVJTFDSXHAWSULBQ
> Pkt: 74HUFHYZOB7J7MLU7SHKTRODN7OH7HRLSSTKWEEDKNMXLOJBDI2Q
> Nice: 226
> Msg: Tossing
> mccoy/74HUFHYZOB7J7MLU7SHKTRODN7OH7HRLSSTKWEEDKNMXLOJBDI2Q:
> unmarshal
>
> (this is a transitional packet)
>
> Also:
>
> nncp@nncp:~$ nncp-pkt -dump <
> /var/spool/nncp/NE2CD32WK62N3QWWQLJUZXVX2WZAIMM7DBIXQVJTFDSXHAWSULBQ/rx/74HUFHYZOB7J7MLU7SHKTRODN7OH7HRLSSTKWEEDKNMXLOJBDI2Q
> main.go:163: unexpected EOF
>
> These commands that return with "unexpected EOF" are returning
> almost
> immediately. They could not possibly have processed 3GB like
> nncp-check does.
> If I omit -dump from nncp-pkt, it works fine. I tried
> reblocking with dd, and
> that didn't help either.
>
> This occurs both with go 1.14 and go 1.15.
>
> The only unique thing here is that it's from a new node on my
> network.
>
> Other packets from that node were processed successfully, though
> they were much
> smaller. I tried removing the .hdr file and that didn't help
> either (it was
> recreated).
>
> Thanks!
>
> - John
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unexpected EOF in 7.2.0
2021-07-09 16:42 ` John Goerzen
@ 2021-07-09 20:23 ` John Goerzen
2021-07-10 7:38 ` Sergey Matveev
0 siblings, 1 reply; 7+ messages in thread
From: John Goerzen @ 2021-07-09 20:23 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
I think I have a lead on this.
The packet was generated on a Raspberry Pi (32-bit ARM userland),
is 3GB in size, and is being processed on an x86_64 machine
(64-bit userland).
I added some debug info to pkt.go, and this was printed when -dump
was used:
pktEncRead: Making LimitedReader, size: -1097891139
readBytes: 0, len(buf): 131088, len(toRead): 131088, EnbClkSize:
131072, aead.Overhead: 16, doEncrypt %!d(bool=false)
main.go:163: unexpected EOF
So the presence of that LimitedReader looks to me like what caused
the UnexpectedEof... and if it's being called with a negative
size, that could particularly cause it.
I did try decoding this packet on the Raspberry Pi, but got the
same result.
Attached is the modified pkt.go that produced this output.
Hope this helps! Hopefully whatever the issue is in nncp-pkt also
leads to the issue in nncp-toss.
- John
[-- Attachment #2: pkt.go --]
[-- Type: application/octet-stream, Size: 9030 bytes --]
/*
NNCP -- Node to Node copy, utilities for store-and-forward data exchange
Copyright (C) 2016-2021 Sergey Matveev <stargrave@stargrave•org>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, version 3 of the License.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
package nncp
import (
"bytes"
"crypto/cipher"
"crypto/rand"
"encoding/binary"
"errors"
"io"
"fmt"
xdr "github.com/davecgh/go-xdr/xdr2"
"golang.org/x/crypto/chacha20poly1305"
"golang.org/x/crypto/curve25519"
"golang.org/x/crypto/ed25519"
"golang.org/x/crypto/nacl/box"
"golang.org/x/crypto/poly1305"
"lukechampine.com/blake3"
)
type PktType uint8
const (
EncBlkSize = 128 * (1 << 10)
PktTypeFile PktType = iota
PktTypeFreq PktType = iota
PktTypeExec PktType = iota
PktTypeTrns PktType = iota
PktTypeExecFat PktType = iota
PktTypeArea PktType = iota
MaxPathSize = 1<<8 - 1
NNCPBundlePrefix = "NNCP"
PktSizeOverhead = 8 + poly1305.TagSize
)
var (
BadPktType error = errors.New("Unknown packet type")
PktOverhead int64
PktEncOverhead int64
)
type Pkt struct {
Magic [8]byte
Type PktType
Nice uint8
PathLen uint8
Path [MaxPathSize]byte
}
type PktTbs struct {
Magic [8]byte
Nice uint8
Sender *NodeId
Recipient *NodeId
ExchPub [32]byte
}
type PktEnc struct {
Magic [8]byte
Nice uint8
Sender *NodeId
Recipient *NodeId
ExchPub [32]byte
Sign [ed25519.SignatureSize]byte
}
func init() {
pkt := Pkt{Type: PktTypeFile}
var buf bytes.Buffer
n, err := xdr.Marshal(&buf, pkt)
if err != nil {
panic(err)
}
PktOverhead = int64(n)
buf.Reset()
dummyId, err := NodeIdFromString(DummyB32Id)
if err != nil {
panic(err)
}
pktEnc := PktEnc{
Magic: MagicNNCPEv5.B,
Sender: dummyId,
Recipient: dummyId,
}
n, err = xdr.Marshal(&buf, pktEnc)
if err != nil {
panic(err)
}
PktEncOverhead = int64(n)
}
func NewPkt(typ PktType, nice uint8, path []byte) (*Pkt, error) {
if len(path) > MaxPathSize {
return nil, errors.New("Too long path")
}
pkt := Pkt{
Magic: MagicNNCPPv3.B,
Type: typ,
Nice: nice,
PathLen: uint8(len(path)),
}
copy(pkt.Path[:], path)
return &pkt, nil
}
func ctrIncr(b []byte) {
for i := len(b) - 1; i >= 0; i-- {
b[i]++
if b[i] != 0 {
return
}
}
panic("counter overflow")
}
func aeadProcess(
aead cipher.AEAD,
nonce, ad []byte,
doEncrypt bool,
r io.Reader,
w io.Writer,
) (int, error) {
ciphCtr := nonce[len(nonce)-8:]
buf := make([]byte, EncBlkSize+aead.Overhead())
var toRead []byte
var toWrite []byte
var n int
var readBytes int
var err error
if doEncrypt {
toRead = buf[:EncBlkSize]
} else {
toRead = buf
}
for {
fmt.Printf("readBytes: %d, len(buf): %d, len(toRead): %d, EnbClkSize: %d, aead.Overhead: %d, doEncrypt %d\n", readBytes, len(buf), len(toRead), EncBlkSize, aead.Overhead(), doEncrypt)
n, err = io.ReadFull(r, toRead)
if err != nil {
if err == io.EOF {
break
}
if err != io.ErrUnexpectedEOF {
return readBytes + n, err
}
}
readBytes += n
ctrIncr(ciphCtr)
if doEncrypt {
toWrite = aead.Seal(buf[:0], nonce, buf[:n], ad)
} else {
toWrite, err = aead.Open(buf[:0], nonce, buf[:n], ad)
if err != nil {
return readBytes, err
}
}
if _, err = w.Write(toWrite); err != nil {
return readBytes, err
}
}
return readBytes, nil
}
func sizeWithTags(size int64) (fullSize int64) {
fullSize = size + (size/EncBlkSize)*poly1305.TagSize
if size%EncBlkSize != 0 {
fullSize += poly1305.TagSize
}
return
}
func PktEncWrite(
our *NodeOur,
their *Node,
pkt *Pkt,
nice uint8,
size, padSize int64,
data io.Reader,
out io.Writer,
) ([]byte, error) {
pubEph, prvEph, err := box.GenerateKey(rand.Reader)
if err != nil {
return nil, err
}
var pktBuf bytes.Buffer
if _, err := xdr.Marshal(&pktBuf, pkt); err != nil {
return nil, err
}
tbs := PktTbs{
Magic: MagicNNCPEv5.B,
Nice: nice,
Sender: our.Id,
Recipient: their.Id,
ExchPub: *pubEph,
}
var tbsBuf bytes.Buffer
if _, err = xdr.Marshal(&tbsBuf, &tbs); err != nil {
return nil, err
}
signature := new([ed25519.SignatureSize]byte)
copy(signature[:], ed25519.Sign(our.SignPrv, tbsBuf.Bytes()))
pktEnc := PktEnc{
Magic: MagicNNCPEv5.B,
Nice: nice,
Sender: our.Id,
Recipient: their.Id,
ExchPub: *pubEph,
Sign: *signature,
}
ad := blake3.Sum256(tbsBuf.Bytes())
tbsBuf.Reset()
if _, err = xdr.Marshal(&tbsBuf, &pktEnc); err != nil {
return nil, err
}
pktEncRaw := tbsBuf.Bytes()
if _, err = out.Write(pktEncRaw); err != nil {
return nil, err
}
sharedKey := new([32]byte)
curve25519.ScalarMult(sharedKey, prvEph, their.ExchPub)
key := make([]byte, chacha20poly1305.KeySize)
blake3.DeriveKey(key, string(MagicNNCPEv5.B[:]), sharedKey[:])
aead, err := chacha20poly1305.New(key)
if err != nil {
return nil, err
}
nonce := make([]byte, aead.NonceSize())
fullSize := pktBuf.Len() + int(size)
sizeBuf := make([]byte, 8+aead.Overhead())
binary.BigEndian.PutUint64(sizeBuf, uint64(sizeWithTags(int64(fullSize))))
if _, err = out.Write(aead.Seal(sizeBuf[:0], nonce, sizeBuf[:8], ad[:])); err != nil {
return nil, err
}
fmt.Printf("pktEncWrite: Making LimitedReader, size: %d\n", size);
lr := io.LimitedReader{R: data, N: size}
mr := io.MultiReader(&pktBuf, &lr)
written, err := aeadProcess(aead, nonce, ad[:], true, mr, out)
if err != nil {
return nil, err
}
if written != fullSize {
return nil, io.ErrUnexpectedEOF
}
if padSize > 0 {
blake3.DeriveKey(key, string(MagicNNCPEv5.B[:])+" PAD", sharedKey[:])
xof := blake3.New(32, key).XOF()
if _, err = io.CopyN(out, xof, padSize); err != nil {
return nil, err
}
}
return pktEncRaw, nil
}
func TbsPrepare(our *NodeOur, their *Node, pktEnc *PktEnc) []byte {
tbs := PktTbs{
Magic: MagicNNCPEv5.B,
Nice: pktEnc.Nice,
Sender: their.Id,
Recipient: our.Id,
ExchPub: pktEnc.ExchPub,
}
var tbsBuf bytes.Buffer
if _, err := xdr.Marshal(&tbsBuf, &tbs); err != nil {
panic(err)
}
return tbsBuf.Bytes()
}
func TbsVerify(our *NodeOur, their *Node, pktEnc *PktEnc) ([]byte, bool, error) {
tbs := TbsPrepare(our, their, pktEnc)
return tbs, ed25519.Verify(their.SignPub, tbs, pktEnc.Sign[:]), nil
}
func PktEncRead(
our *NodeOur,
nodes map[NodeId]*Node,
data io.Reader,
out io.Writer,
signatureVerify bool,
sharedKeyCached []byte,
) ([]byte, *Node, int64, error) {
var pktEnc PktEnc
_, err := xdr.Unmarshal(data, &pktEnc)
if err != nil {
return nil, nil, 0, err
}
switch pktEnc.Magic {
case MagicNNCPEv1.B:
err = MagicNNCPEv1.TooOld()
case MagicNNCPEv2.B:
err = MagicNNCPEv2.TooOld()
case MagicNNCPEv3.B:
err = MagicNNCPEv3.TooOld()
case MagicNNCPEv4.B:
err = MagicNNCPEv4.TooOld()
case MagicNNCPEv5.B:
default:
err = BadMagic
}
if err != nil {
return nil, nil, 0, err
}
if *pktEnc.Recipient != *our.Id {
return nil, nil, 0, errors.New("Invalid recipient")
}
var tbsRaw []byte
var their *Node
if signatureVerify {
their = nodes[*pktEnc.Sender]
if their == nil {
return nil, nil, 0, errors.New("Unknown sender")
}
var verified bool
tbsRaw, verified, err = TbsVerify(our, their, &pktEnc)
if err != nil {
return nil, nil, 0, err
}
if !verified {
return nil, their, 0, errors.New("Invalid signature")
}
} else {
tbsRaw = TbsPrepare(our, &Node{Id: pktEnc.Sender}, &pktEnc)
}
ad := blake3.Sum256(tbsRaw)
sharedKey := new([32]byte)
if sharedKeyCached == nil {
curve25519.ScalarMult(sharedKey, our.ExchPrv, &pktEnc.ExchPub)
} else {
copy(sharedKey[:], sharedKeyCached)
}
key := make([]byte, chacha20poly1305.KeySize)
blake3.DeriveKey(key, string(MagicNNCPEv5.B[:]), sharedKey[:])
aead, err := chacha20poly1305.New(key)
if err != nil {
return sharedKey[:], their, 0, err
}
nonce := make([]byte, aead.NonceSize())
sizeBuf := make([]byte, 8+aead.Overhead())
if _, err = io.ReadFull(data, sizeBuf); err != nil {
return sharedKey[:], their, 0, err
}
sizeBuf, err = aead.Open(sizeBuf[:0], nonce, sizeBuf, ad[:])
if err != nil {
return sharedKey[:], their, 0, err
}
size := int64(binary.BigEndian.Uint64(sizeBuf))
fmt.Printf("pktEncRead: Making LimitedReader, size: %d\n", size);
lr := io.LimitedReader{R: data, N: size}
written, err := aeadProcess(aead, nonce, ad[:], false, &lr, out)
if err != nil {
return sharedKey[:], their, int64(written), err
}
if written != int(size) {
return sharedKey[:], their, int64(written), io.ErrUnexpectedEOF
}
return sharedKey[:], their, size, nil
}
[-- Attachment #3: Type: text/plain, Size: 2179 bytes --]
On Fri, Jul 09 2021, John Goerzen wrote:
> I'm fairly baffled by this. I ran it under strace, and there's
> no syscall
> that's returning EOF. nncp-pkt is easier to analyze under
> strace, and it does a
> 4096-byte read, gets a 4096-byte result, then crashes with
> unexpected EOF.
>
> I don't know Go, though... I'm also baffled at how the test at
> pkt.go line 163
> could cause an error.
>
> - John
>
> On Fri, Jul 09 2021, John Goerzen wrote:
>
>> Hello,
>>
>> I have a 3GB packet that was transferred from its origin to my
>> gateway machine
>> via nncp-call. When called on it, nncp-check works fine and
>> verifies its
>> integrity. However:
>>
>> nncp@nncp:~$ nncp-toss -progress
>> 2021-07-09T15:10:27Z ERROR Tossing
>> mccoy/74HUFHYZOB7J7MLU7SHKTRODN7OH7HRLSSTKWEEDKNMXLOJBDI2Q:
>> unmarshal: xdr:DecodeFixedOpaque: unexpected EOF while decoding
>> 8 bytes -
>> read:
>> '[]'
>>
>> And the log shows:
>>
>> When: 2021-07-09T15:12:13.896311727Z
>> Err: xdr:DecodeFixedOpaque: unexpected EOF while decoding 8
>> bytes - read: '[]'
>> Who: rx-unmarshal
>> Node: NE2CD32WK62N3QWWQLJUZXVX2WZAIMM7DBIXQVJTFDSXHAWSULBQ
>> Pkt: 74HUFHYZOB7J7MLU7SHKTRODN7OH7HRLSSTKWEEDKNMXLOJBDI2Q
>> Nice: 226
>> Msg: Tossing
>> mccoy/74HUFHYZOB7J7MLU7SHKTRODN7OH7HRLSSTKWEEDKNMXLOJBDI2Q:
>> unmarshal
>>
>> (this is a transitional packet)
>>
>> Also:
>>
>> nncp@nncp:~$ nncp-pkt -dump <
>> /var/spool/nncp/NE2CD32WK62N3QWWQLJUZXVX2WZAIMM7DBIXQVJTFDSXHAWSULBQ/rx/74HUFHYZOB7J7MLU7SHKTRODN7OH7HRLSSTKWEEDKNMXLOJBDI2Q
>> main.go:163: unexpected EOF
>>
>> These commands that return with "unexpected EOF" are returning
>> almost
>> immediately. They could not possibly have processed 3GB like
>> nncp-check does.
>> If I omit -dump from nncp-pkt, it works fine. I tried
>> reblocking with dd, and
>> that didn't help either.
>>
>> This occurs both with go 1.14 and go 1.15.
>>
>> The only unique thing here is that it's from a new node on my
>> network.
>>
>> Other packets from that node were processed successfully,
>> though they were
>> much
>> smaller. I tried removing the .hdr file and that didn't help
>> either (it was
>> recreated).
>>
>> Thanks!
>>
>> - John
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unexpected EOF in 7.2.0
2021-07-09 20:23 ` John Goerzen
@ 2021-07-10 7:38 ` Sergey Matveev
2021-07-10 13:04 ` John Goerzen
0 siblings, 1 reply; 7+ messages in thread
From: Sergey Matveev @ 2021-07-10 7:38 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 838 bytes --]
Greetings!
*** John Goerzen [2021-07-09 15:23]:
>The packet was generated on a Raspberry Pi (32-bit ARM userland), is 3GB in
>size, and is being processed on an x86_64 machine (64-bit userland).
>pktEncRead: Making LimitedReader, size: -1097891139
Currently I did not investigate that, but when you talked about 3GB
sizes my first thought was about 32-bits indeed. Negative size in your
output confirms that.
I quickly looked at the code and indeed see some places with plain
"int"s, instead of "int64"s. I hoped that noone will use 32-bit system
anymore :-). Thank you very very much for that report! I will create
32-bit system in VM and will check its workability there. Hope that
today I will fix that.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unexpected EOF in 7.2.0
2021-07-10 7:38 ` Sergey Matveev
@ 2021-07-10 13:04 ` John Goerzen
2021-07-10 13:38 ` Sergey Matveev
0 siblings, 1 reply; 7+ messages in thread
From: John Goerzen @ 2021-07-10 13:04 UTC (permalink / raw)
To: Sergey Matveev; +Cc: nncp-devel
On Sat, Jul 10 2021, Sergey Matveev wrote:
> I quickly looked at the code and indeed see some places with
> plain
> "int"s, instead of "int64"s. I hoped that noone will use 32-bit
> system
> anymore :-). Thank you very very much for that report! I will
> create
> 32-bit system in VM and will check its workability there. Hope
> that
> today I will fix that.
Thank you!
Yes, I'm afraid that 32-bit systems are still very much with us.
Most of the Raspberry Pi models (which make excellent NNCP nodes)
are 32-bit. Even the Pi Model 4, which has a 64-bit CPU, is
generally run with a 32-bit userland (it is, oddly, often faster
that way and this lets people have a single image that works on
all the Pi models). It is *possible* to run arm64 on the pi 4,
but rarely is done.
This particular unit is the second Pi I've backed up over NNCP.
It is probable that the first one never generated a packet over
2GB, so your theory could fit.
- John
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unexpected EOF in 7.2.0
2021-07-10 13:04 ` John Goerzen
@ 2021-07-10 13:38 ` Sergey Matveev
2021-07-10 22:38 ` John Goerzen
0 siblings, 1 reply; 7+ messages in thread
From: Sergey Matveev @ 2021-07-10 13:38 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
*** John Goerzen [2021-07-10 08:04]:
>Raspberry Pi models (which make excellent NNCP nodes) are 32-bit.
>It is *possible* to run arm64 on the pi 4, but rarely is done.
I see. Do not know why, but I thought that all of that RPi computers are arm64.
Well, 32-bit will stay for a long time indeed :-)
>probable that the first one never generated a packet over 2GB, so your
>theory could fit.
I tested previous and current latest 7.3.0 version on 32-bit machine.
Previous was really incorrectly working with big files: sometimes it can
produce negative values, sometimes is will just cut the data, but
provide perfectly valid hashes and successful tossing process on amd64
machines. I checked 7.3.0 version with big files sending, bundles and
online commands.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Unexpected EOF in 7.2.0
2021-07-10 13:38 ` Sergey Matveev
@ 2021-07-10 22:38 ` John Goerzen
0 siblings, 0 replies; 7+ messages in thread
From: John Goerzen @ 2021-07-10 22:38 UTC (permalink / raw)
To: Sergey Matveev; +Cc: nncp-devel
On Sat, Jul 10 2021, Sergey Matveev wrote:
>>probable that the first one never generated a packet over 2GB,
>>so your
>>theory could fit.
>
> I tested previous and current latest 7.3.0 version on 32-bit
> machine.
> Previous was really incorrectly working with big files:
> sometimes it can
> produce negative values, sometimes is will just cut the data,
> but
> provide perfectly valid hashes and successful tossing process on
> amd64
> machines. I checked 7.3.0 version with big files sending,
> bundles and
> online commands.
Yes, that fixed the problem. Thank you!
It is possible I was seeing some of the other symptoms from the
other Raspberry Pi also. That would explain a few mysterious
failures I had now and then.
- John
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-07-10 22:39 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-09 15:23 Unexpected EOF in 7.2.0 John Goerzen
2021-07-09 16:42 ` John Goerzen
2021-07-09 20:23 ` John Goerzen
2021-07-10 7:38 ` Sergey Matveev
2021-07-10 13:04 ` John Goerzen
2021-07-10 13:38 ` Sergey Matveev
2021-07-10 22:38 ` John Goerzen