node_pcap
node_pcap copied to clipboard
DNS: Malformed DNS RR pcap.js:986
There seems to be a problem with the decodeRR function when parsing non compressed names. Occurrence: run simple_capture load google.com in firefox Environment: Host MacOSX Maverick, VMware, Ubuntu 14.04 Error: Malformed DNS RR Reason: It seems like sometimes the name is not terminated by a 0x00 character. This causes all the characters to be shifted by one, therefore the rrtype, rrclass, ttl, and rdlength values are incorrect. I do not know what is the correct definition. Debugging: Print each byte separately of the name and following bytes, count back from the ip bytes. Fix/Hack: This is a very specific fix, i don't know if this will apply in general. // Malformed DNS RR will throw error // Likely one only one 0x00 character missing after name. Shifting by one byte and try again. if(result.rrtype.indexOf('Unknown') > -1 && result.rrclass.indexOf('Unknown') > -1 && internal_offset+result.rdlength > raw_packet.pcap_header.len) { internal_offset -= 11; result.rrtype = dns_util.qtype_to_string(unpack.uint16(raw_packet, internal_offset)); internal_offset += 2; result.rrclass = dns_util.qclass_to_string(unpack.uint16(raw_packet, internal_offset)); internal_offset += 2; result.ttl = unpack.uint32(raw_packet, internal_offset); internal_offset += 4; result.rdlength = unpack.uint16(raw_packet, internal_offset); internal_offset += 2; }
Please provide an example pcap with such a packet. Preliminary research suggests names must be null terminated. Best case scenario we can avoid throwing an exception, but will still be unable to decode a dns frame which does not have a null terminated name.
Dns refactoring underway over at https://github.com/jmaxxz/node_pcap/tree/dnsRefactor this is a work in progress though I hope to end up with a more robust, cleaner implementation of the dns decoder.
I don't know if there is another problem, but I've seen this error caused by IP fragmentation (see https://github.com/mranney/node_pcap/issues/173). It tries to decode the whole UDP frame (due to length in UDP header is full, not the lenth of the part) when it has only the first part.