You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I know that this project is closed but I just wanted to inform about this situation.
I've found out in a system that the DHCPv6 server was dropping DHCPv6 messages from a client running dibbler-client 1.0.1.
According to the server logs, the reason was that the message ID was unkowned. This client was blocked (at the server), so all messages from this client were discarded.
I've run tcpdump on the client machine and indeed the message type had an id of 88 (0x58).
I've also attached a debugger to the running dibbler-client and these are my findings;
On the void TClntTransMgr::doDuties() the Transaction list had 4 messages on the queue, all SOLICIT.
Only one of that messages was not OK. That message had: MsgType = 731736, TransID = 731776,
Note that MsgType = 731736 (dec) = 0xb2a58 (Hex) and when the message is serialized to send to the network it takes the least significative byte (0x58 = 88 decimal). That is the number I'm seeing in the tcpdump.
Note also the similarity between the MsgType and TransID values. Can this be a write-out-of-bounds? They are one next to the other in memory.
Also, this happened with multiple dibbler-client processes running (in this case there were 3, and only 1 was sending the corrupt message). I know that the client shouldn't be running multiple instances of the dibbler-client, but it was a bug with the setup of the rest of the system that created this condition.
The text was updated successfully, but these errors were encountered:
Hi,
I know that this project is closed but I just wanted to inform about this situation.
I've found out in a system that the DHCPv6 server was dropping DHCPv6 messages from a client running dibbler-client 1.0.1.
According to the server logs, the reason was that the message ID was unkowned. This client was blocked (at the server), so all messages from this client were discarded.
I've run tcpdump on the client machine and indeed the message type had an id of 88 (0x58).
I've also attached a debugger to the running dibbler-client and these are my findings;
On the void TClntTransMgr::doDuties() the Transaction list had 4 messages on the queue, all SOLICIT.
Only one of that messages was not OK. That message had:
MsgType = 731736, TransID = 731776,
Note that MsgType = 731736 (dec) = 0xb2a58 (Hex) and when the message is serialized to send to the network it takes the least significative byte (0x58 = 88 decimal). That is the number I'm seeing in the tcpdump.
Note also the similarity between the MsgType and TransID values. Can this be a write-out-of-bounds? They are one next to the other in memory.
Also, this happened with multiple dibbler-client processes running (in this case there were 3, and only 1 was sending the corrupt message). I know that the client shouldn't be running multiple instances of the dibbler-client, but it was a bug with the setup of the rest of the system that created this condition.
The text was updated successfully, but these errors were encountered: