I have a server application and a client application which, for now, just do a login procedure together. I send 43 bytes worth of login information to the server (20 bytes for a name, 20 bytes for a password, 1 byte for error, state and type). It is in the order of type, name, password, state, error. The server unpacks the packet into the same object that the client uses, validates the information and sends an updated packet with the same structure back to the client. It worked flawlessly until I added validation, additional states and made the errors more specific.
For some strange reason the packet does not arrive as the client had sent it. The first 21 (possibly less) bytes are corrupt, but are predictable. The first byte of the first packet starts at 184 and the next packet is always 112. Then the next is 184, and it switches like that constantly. The name (which starts at byte 2) always appears as '`ลก'. On the client I log the packet immediately before the call to enet_peer_send() like so:
TRACE("Connection::Send() - Sending packet %p (%u bytes, 1st byte: %u)\n",_packet,_packet->dataLength,*(_packet->data)); enet_peer_send(peer,0,_packet);
The packet type of 1 is always logged (which is correct). Like so:
Connection::Send() - Sending packet 01DA6428 (43 bytes, 1st byte: 1)
Similarly, on the server, I check the first byte of the packet before I do anything else with it:
switch (e.type) { case ENET_EVENT_TYPE_RECEIVE: TRACE("A packet of length %u was received from %s. The first byte is : %u\n", e.packet -> dataLength,ipStr,*(e.packet->data)); // ...
But the server logs a different type!
A packet of length 43 was received from 206.186.35.60. The first byte is : 184
Gah!!
I'm pulling my hair out 
There is a lot of code in total, but here is the main server code, which I think is where the problem is:
Here is the connection.cpp:
If necessary, the logincontrol.cpp:
Any help is appeciated. I have no idea what happened, it's been like this for about 3 coding sessions without any progress ><
Update
The client has the same problem when receiving from the server. The first byte interchanges between 88 and 168 every other packet
I would stop using the library.
Does the library contain any example files ?
Do they work ?
Have you tried hacking them apart and using them ?
Are you using a library for a reason ?
DIY TCP/IP isn't that hard, unless this library offers you features you want, i'd stop using it.
Is this library stable? or even complete?
Oh my. It's almost as if someone had warned earlier that enet was a bad idea...
Yes, like all good newbs, let's blame the library! I've had no problems with enet, but I don't enjoy picking through someone else's C++, so I really cannot offer any advice. Plus, Speedhack is almost upon us...
Sounds to me like you are corrupting the memory somehow with the recent changes you made.
Did you recompile everything after you made changes?
Just some general advice - it's not a good idea to use a UDP-based library if you want to process all your packets reliably and in order. Sure, some libraries may offer some slight advantages over TCP in the way they implement that, but with UDP you also have to worry about things like NAT punch-through, especially with all the varying implementations of NAT that seem to be found on routers.
I would suggest using whatever asynchronous I/O is offered by the target OS (assuming Windows from looking at the code) or even better, a platform-independent abstraction of asynchronous TCP/IP.
Yeah, I tried a clean make. No luck
I don't enjoy picking through someone else's C++
Me either, and my code is especially spaghetti-like
I'm just at a total loss as to what is causing this problem. It APPEARS that I'm corrupting something, but that doesn't make sense. I am examining it going out and outputting the results, they are fine. But coming back in, on a separate application, the packet is damaged and half corrupted. That doesn't make any sense! 
The changes that I did make were relatively simplistic. The biggest changes were made by the addition of the Verify function on the login control... which doesn't even have any actual networking code in it.
Oh my. It's almost as if someone had warned earlier that enet was a bad idea...
I thought of that after I had came across this problem. "Maybe X-G was right and enet isn't as simple as it seems.", but it was working so great on Friday, before I added user verification.
Right now I am thinking that it is enet's fault, but nothing makes any sense really. The networking code was hardly changed at all which is what really makes it strange.
If I can't solve this problem by next saturday I'll likely be switching libraries.. but none of the others are quite as simple as enet, that's the only problem
Plain old sockets didn't work very well for my MUD engine. They did work, but I needed some sort of optimization. When a lot of users connected (a lot is 5 or more, heh) latency would drastically increase. 
Now to answer AJ's questions:
Does the library contain any example files ?
Yes. Google is your friend.
Do they work ?
Yes.
Have you tried hacking them apart and using them ?
Yes.
Are you using a library for a reason ?
Yes.
DIY TCP/IP isn't that hard, unless this library offers you features you want, i'd stop using it.
I've used sockets directly (if that's what you mean by do-it-yourself TCP/IP), out of the box they do not have very many features. I wouldn't recommend it, really. If you're new to networking it is a good learning experience, though.
Is this library stable?
As far as I can tell, yes. Numerous other projects have used this library. However, I am a little new to enet and have no prior experience with it.
or even complete?
You can visit their website and decide for yourself. Personally, it is as complete as I need it to be. You may need more features or a higher level library, but if you're looking for a networking library please create a new thread or use the search feature. It's been asked many times, so you should be able to find some results worth viewing.
[edit]
it's not a good idea to use a UDP-based library if you want to process all your packets reliably and in order.
ENet claims to have reliable and sequenced packets. I've set the appropriate values for reliable packets. The problem is elsewhere.
if you've testing the entry and exit points of the library and the data is getting corrupted within, its the library at fault.
unless your passing invalid length data..
when you pass the length of the data to send, what are you passing ?
is it derived from a strlen() or a fixed packet size?
->Unpack() ->Pack() what are these ? they seem like something that will modify your data
if you've testing the entry and exit points of the library and the data is getting corrupted within, its the library at fault.
The problem is that I made changes to cause this problem... I should have kept better records of what exactly I changed 
The problem appears to be with enet, but because it was working fine before I find it hard to accept that.
The size of the data is 43 bytes (on both ends). It is fixed. Pack() creates an ENet Packet from the data and Unpack() takes an ENet Packet and turns it into useable data. I did have trace calls at every step of the pack/unpack process and it did not show anything different. Unpack() is called after the problem is evident and Pack() is called just before sending the packet which does not show the problem happening.
Oh well. SpeedHack time.
I searched the mailing list archive, but I couldn't find anyone else complaing about a data corruption problem. Let's not forget that Enet adds information (most likely at the beginning) to packets such as sequence and channel numbers. I don't know anything about Enet, but I've got a hunch this has something to do with that.
Try reducing your code to the smallest code that will reproduce the error you're experiencing.
Also try the Enet mailing list.