Not handling packets with empty body properly?

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Some incoming packets seemed to have null body.
For example, a packet like:
[1, 1, 6, 1, 2, 97, 112, 101, 167, 123, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 139, 185, 141, 2, 0, 23, 239, 241, 248, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0, ... 99, 130, 83, 99, 255, 0, 0, 0, 0, 0, 0, 0, ...]
The magic cookie is at its normal position, but the next byte is '255'.
Because the magic cookie is set correctly, it is deemed as a valid dhcp packet. 
In dhcp_network.py's '_getNextDHCPPacket', there are following logic:

 if data:
                packet = dhcp_packet.DHCPPacket(data)
                if packet.isDHCPPacket():
                    pxe = source_address[1] == self._pxe_port
                    if packet.isDHCPRequestPacket():
                        threading.Thread(target=self._handleDHCPRequest, args=(packet, source_address, pxe)) ...

Because it is a packet with empty body, the if packet.isDHCPRequestPacket() 
will trigger exception like:

   return self.getOption('dhcp_message_type')[0] == 1
TypeError: 'NoneType' object is not subscriptable

I added a line in dhcp_network.py's '_getNextDHCPPacket'
to avoid this, not sure if this is correct, please let me know.
Thanks!

      packet = dhcp_packet.DHCPPacket(data)

      if not packet._options_data: return False  # some packets only have header, need to skip them

      if packet.isDHCPPacket():

2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?

1.4.3 on Redhat el4 u3

Please provide any additional information below.

Original issue reported on code.google.com by andrew.x...@gmail.com on 15 Jan 2011 at 1:15

[GoogleCodeExporter]

I've got a more transparent solution for this problem, though I'm quite 
surprised you actually encountered it. Do you happen to know what device was 
sending these packets?

Thank you very much for this report.

Original comment by red.hamsterx on 15 Jan 2011 at 2:40

• Changed state: Started

[GoogleCodeExporter]

http://code.google.com/p/staticdhcpd/source/detail?r=304 addresses this issue; 
the fix is in the dev/ branch.

My solution was to make all of the is?Packet() functions return False in the 
event that the message-type is not set. This will cause the packet to fail 
through all of the tests and get caught by the general handler, without needing 
to look at a private variable.

I'll merge it into trunk after it's had a chance to soak on my server over the 
weekend, and once I've revamped logging and the web interface. You should 
probably expect an official release later this weekend or early next week.

Original comment by red.hamsterx on 15 Jan 2011 at 2:55

• Changed state: Fixed

[GoogleCodeExporter]

I do not know where the packets came from.

Original comment by andrew.x...@gmail.com on 15 Jan 2011 at 12:35

[GoogleCodeExporter]

That's too bad. :(

If you do find out, please let me know. That's a pretty significant RFC 
violation and I'd like to report it to the device's vendor, since they may not 
be aware of the problem. 

Original comment by red.hamsterx on 15 Jan 2011 at 7:07