Libtins not able to Parse Dhcp Ack Packet for Xiaomi phones

[chirayu-patel]

There were 2 different instances where Libtins was not able to parse the Dhcp Ack packet for these two devices..It was able to parse the Request packet though..

Mac Address Hostname Vendor class Param Options 20:a6:xx:xx:xx:xx/POCOF1-POCOPHONE/android-dhcp-9/1,3,6,15,26,28,51,58,59,43 ec:d0:xx:xx:xx:xx/RedmiNote4-Redmi/android-dhcp-7.0/1,3,6,15,26,28,51,58,59,43

This is what I use for parsing the packet : DHCP dhcp = pdu.rfind_pdu().to();

[mfontanini]

Without a packet capture there's really not much we can do.

[chirayu-patel]

I understand.. I will have to find the people owning the device.. it's a big office :) But I will get the packet capture.. Thanks for the prompt reply..

[mfontanini]

Would you mind sharing what you're using libtins for? I don't usually get to ask people what they're doing with it :)

[chirayu-patel]

We have installed libtins on an Access Point and we use it to capture different kinds of traffic.. Right now mainly being DHCP, ICMPv6, ARP, DNS. We first started with Scapy but since Python itself is a huge package and Access Points being resource constrained, we decided to move away from it.. Also, in our initial runs, Scapy used to drop few packets. Thats where we decided to give libtins a try.. And so far so good. We appreciate the community's efforts for maintaining the package. We are in testing phase right now, so I will be annoying you with any issue I face :)

[chirayu-patel]

dhcpcapture3.zip

It seems the issue is not specific to xiaomi phones.. It happens in general I have attached the pcap for which the request was not captured. The mac address is "0c:9d:92:a1:e0:ae". If you open the pcap using wireshark, the filter for the same is : eth.addr ==0c:9d:92:a1:e0:ae

[chirayu-patel]

dhcpcapture4.zip

One more example. The mac address is "88:b4:a6:1f:53:33".

[chirayu-patel]

dhcp_packet_capture.zip

Attaching sample program. Compiled it using : g++ dhcp_packet_capture.cpp -o dhcpi -O3 -std=c++11 -lpthread -ltins

Have used FileSniffer. The capture packet file is mentioned in the main method.

[mfontanini]

You didn't mention which the problems exactly are on those files but:

• Don't do BootP bootp = pdu.rfind_pdu<RawPDU>().to<BootP>();. DHCP inherits from BootP. You can just do const BootP& bootp = dhcp; or even just use dhcp, as it's already a BootP. This makes the discovery processing succeed. The reason why this throws is because you're calling this constructor:

BootP(const uint8_t* buffer, uint32_t total_sz, uint32_t vend_field_size = 64);

Which expects at least 64 bytes for the extra data on the BootP layer but that packet has less than that. BootP isn't meant to be used alone, really. Plus, you're parsing the same layer twice which is likely not what you want.

• There was a "Error: option not found" being printed. That's because you were trying to get a hostname (via dhcp.hostname()) under the part of the code that processed the dhcp request. You're doing that for a packet that doesn't have a hostname, hence the throw.

Is there anything else you found not to work?

[chirayu-patel]

Ya.. sorry for not mentioning the exact issue.. Actually the Dhcp Requests were failing.. Thanks for the suggestion.. Let me try the same and will get back to you in case of any issues.