Trouble while receiving data. (TCP mode)

[binary1248]

I really have to ask you: how long do you try to solve your problems before you come and post here? Between your first post and your last where you allegedly solved your problem (from what I understand) only half a day elapsed. Don't you think that trying to solve your problem on your own a bit longer would save us all these useless threads? I can take days if not weeks to solve some problems depending on how hard it is to solve them, but at least I don't spam forums with double and triple posts with bits of code that are useless to everybody else. And more importantly, I actually take what is posted by others into consideration, since it might help solve the problem faster.

I suggest to everybody who cares for the well being of this forum to ignore all of these "help requests" for at least a day before starting another pointless discussion that doesn't benefit anybody, least the thread starter. Don't even dare to double or triple post within the day with useless information or risk getting the thread locked. Even newcomers understand this and use the edit function.

[Jesper Juhl]

I think you should read this: http://stackoverflow.com/questions/5665698/evp-decryptfinal-ex-error-on-openssl

Ohh and BTW, @binary1248 : I agree 100%.

[Lolilolight]

I've printed the bytes values and the size of the encrypted packet and there are the same at both sides. (on the server and on the client, but openssl is still returning me an error sometimes, not at every execution)

Code: [Select]

data :
216 231 40 108 97 250 69 90 79 179 226 104 216 120 124 170 73 216 119 66 205 158 123 249 153 34 30 51 177 223 26 141 size : 32

data :
103 199 125 199 210 194 147 59 76 111 21 78 116 198 211 6 size : 16

Error encrypting message: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
data :
57 208 110 186 16 229 111 96 137 204 150 177 138 59 73 22 size : 16

Error encrypting message: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
data :
10 223 62 4 158 180 44 217 31 151 22 151 215 245 94 120 size : 16

Error encrypting message: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
data :
142 220 144 37 30 193 223 130 100 217 65 212 237 32 248 242 105 18 140 65 88 52 32 66 103 41 20 202 107 113 83 203 size : 32

This problem happens only when I send and receive data with sockets.

Is it possible that SFML wipes out some null bytes at the end of the packet when receiving data through a socket

And I can't find a forum, where can I get some help with openssl ?

Especially for those functions :

unsigned char* AES_ENC::encrypt(const unsigned char* data, int dataSize, int* newSize) {
    int cLen = dataSize+AES_BLOCK_SIZE;
    int fLen = 0;
    unsigned char *encData = (unsigned char*) malloc(cLen);
    if (!EVP_EncryptInit_ex(e_ctx, EVP_aes_256_cbc(), nullptr, key, iv))
        return nullptr;
    if (!EVP_EncryptUpdate(e_ctx, encData, &cLen, (unsigned char*) data, dataSize))
        return nullptr;
    if(!EVP_EncryptFinal_ex(e_ctx, encData+cLen, &fLen)) {
        return nullptr;
    }
    *newSize = cLen + fLen;
    return encData;
}
unsigned char* AES_ENC::decrypt(const unsigned char* encData, int dataSize, int* newSize) {
    int pLen = dataSize;
    int fLen = 0;
    unsigned char *data = (unsigned char*) malloc(pLen);
    if (!EVP_DecryptInit_ex(d_ctx, EVP_aes_256_cbc(), nullptr, key, iv))
        return nullptr;
    if (!EVP_DecryptUpdate(d_ctx, data, &pLen, (unsigned char*) encData, dataSize))
        return nullptr;
    if (!EVP_DecryptFinal_ex(d_ctx, data+pLen, &fLen)) {
        char* err = (char*) malloc(130);
        ERR_load_crypto_strings();
        ERR_error_string(ERR_get_error(), err);
        fprintf(stderr, "Error encrypting message: %s\n", err);
        free(err);
        return nullptr;
    }
    *newSize = pLen + fLen;
    return data;
}
 

[Lolilolight]

Hmmm it seems that SFML doesn't gives me the right bytes and the right size in the onSend function :

const void* SymEncPacket::onSend (size_t& dataSize) {
 unsigned char* buffer;
    std::cout<<"data : "<<std::endl;
    for (unsigned int i = 0; i < sizeof (static_cast<const unsigned char*> (getData())); i++) {
        std::cout<<(int) static_cast<const unsigned char*> (getData())[i]<<std::endl;
    }
    std::cout<<std::endl<<"data size : "<<dataSize<<std::endl;
    buffer = AES_ENC::encrypt(static_cast<const unsigned char*> (getData()), getDataSize(), (int*) &dataSize);
    std::cout<<"data : "<<std::endl;
    for (unsigned int i = 0; i < dataSize; i++) {
        std::cout<<(int) buffer[i]<<" ";
    }
    std::cout<<std::endl;
    std::cout<<"size : "<<dataSize<<std::endl;
    return &buffer[0];
}
 

I try to send the message "hello world!" and here it's what it gives me:

 Network::startCli(10000, 10001, sf::IpAddress::LocalHost);
    std::string text = "Hello world!";
    SymEncPacket packet;
    packet<<text;
    Network::sendTcpPacket(packet);
 

Code: [Select]

data :
0
0
0
12
72
101
108
108
dataSize : 0

Why SFML gives me a dataSize of 0, and why it add me null bytes at the begining of the packet

It happens before I encrypt the data so the decryption fails at the server-side.

[Lolilolight]

I've find for the size :

unsigned char* buffer;
    std::cout<<"data : "<<std::endl;
    for (unsigned int i = 0; i < getDataSize(); i++) {
        std::cout<<(int) static_cast<const unsigned char*> (getData())[i]<<std::endl;
    }
    std::cout<<std::endl<<"data size : "<<getDataSize()<<std::endl;
 

But it's still wrong, it gives me a size of 16 and add 3 '0' at the beginning of the packet, or the right size should be 13 (12 + the null byte) not 16!

[Laurent]

sf::Packet has its own internal protocol and adds bytes wherever it needs to. So you're not supposed to try to interpret the data once it is inside a sf::Packet. So, don't waste your time on that and check if you have an actual issue.

[Lolilolight]

Mmm I haven't an actual issue yet, but, it seems that in some cases SFML doesn't add the right number of bytes, so, the OpenSSL padding is not good and it crash.

And most surprising : if I don't initialize the dst size to 0, it always crash :

void SymEncPacket::onReceive (const void* data, size_t dataSize) {
    unsigned char* buffer;
    std::size_t dstSize = 0;
    /*std::cout<<"data : "<<std::endl;
    for (unsigned int i = 0; i < dataSize; i++) {
        std::cout<<(int) static_cast<const unsigned char*>(data)[i]<<" ";
    }
    std::cout<<"size : "<<dataSize<<std::endl;
    std::cout<<std::endl;*/
    buffer = AES_ENC::decrypt(reinterpret_cast<const unsigned char*> (data), dataSize, (int*) &dstSize);
    /*std::cout<<"data : "<<std::endl;
    for (unsigned int i = 0; i < dstSize; i++)
        std::cout<<(int) buffer[i]<<" ";*/
    //std::cout<<std::endl<<"data size : "<<dstSize<<std::endl;
    append(&buffer[0], dstSize);
}
 

[Lolilolight]

And it seems it's when I'm sending long TCP messages that I've sometimes a crash...

So, I think I'll check in the source code the place where you split and reconstitute your data.

[Laurent]

So, I think I'll check in the source code the place where you split and reconstitute your data.

I don't. It's done at lower-level by the TCP layer.

[binary1248]

It's done at lower-level by the TCP layer.

You mean IP right? Unless Nagle's algorithm is enabled, TCP will send a segment that is as large as the data you pass to send() (within the limits of course). Fragmentation is normally taken care of by IP if the segment is larger than the MTU the path supports. TCP doesn't and shouldn't care about packet sizes. It does its window scaling based on other factors.

[Laurent]

Arf. I thought it was TCP because UDP, which is based on IP too (right?), doesn't use fragmentation.

[binary1248]

Actually... UDP "uses" fragmentation... like any other transport (layer 4) protocol. It doesn't implement it itself, but like TCP, it can rely on IP taking care of it. The fact that a 60000 byte UDP datagram doesn't arrive at its destination has less to do with the fact that it isn't properly fragmented than with the fact that many internet routers just drop traffic that is oversized (the standard only requires that compliant devices try their best to reassemble packets up to a size of 576 bytes). IPv6 even requires path MTU discovery so that fragmentation is left to the sender to perform in its entirety, so your NIC will end up sending out many IPv6 packets when you send a 60000 byte UDP datagram.