DNP3 decoding incorrect

[alabastercodify]

Been trying to modify some DNP3 (scada) packets, and am having issues with the decoding.
Although the DNP3 protocol is automatically picked up (I assume from wireshark), the template / layer / fields are not all correct. Specifically the application layer slices seem to be using the wrong start byte.

From example here you see that al.fragment starts at byte 0. In actual fact the DNP3 message doesnt start until byte 54 (05 64). The al.fragment should start at byte 65 (E5).

If I open in wirehark then the packet does get correctly decoded so I'm not sure why the template is wrong.

How exactly does Polymorph load in filters from wireshark/tshark?

I tried to use the struct -f to recalcaute it, however cannot get the syntax correct here "Wrong syntax for referring to the fields. Please use 'this.field' syntax". There is only 1 example I can find in documentation which doesnt help.

I also tried to instead make my own layer / structure.. however cannot get how to create the structs at all.

Finally I could ignore the structure completely to manipluate my packet if I could maniplute the hex directly in a function then write back to raw, however I simply cannot get the bytes to convert to hex in a function. I tried using binascii.hexlify (works fine directly in python but not within my function inside Polymorph), I tried using bytes_hex (from scapy) and I tried using Polymorphs raw2hex as well. I want to get the same output as "dump -hexstr" but cannot seem to make that work within a function.

Thanks in advance.. .this a great project.

[alabastercodify]

@shramos - I've been able to make this work for my needs for the meantime… I think I kind of see what the issue is though.
I was able to just create a new field which took the entire DNP3 portion of the packet out as hex. Its then possible to manipulate the parts I need. Once I change a value I also need to recalculate the data chunk crc before sending the packet onwards.

I'm still not clear on why the DNP3 layer is being incorrectly applied.. as I say wireshark dissector does correctly pick it up. I tried to see where in the source polymorph is pulling the packet 'type' in to see if I can further diagnose but couldn't figure it out.

I wonder if it has something to do with the 'data chunks' element. I.e. the DNP3 message is fragmented and reassembled to get the 'application layer'. I cant see how to do that with Polymorph, as fields are a simple case of defining a start / end byte and type. It is possible to build more logic in to a modify_packet function to reassemble the DNP3 message, manipulate it and then go back to the fragmented format.. it just makes a bit more work in the function than being able to rely on the polymorph 'template'. Are there other examples of protocols being reassembled / disassembled in polymorph?