BUG! packet->iph == NULL && packet->iphv6 == NULL && packet->tcp != NULL

[vel21ripn]

@IvanNardi I found bug! ndpi_main.c:4234 ndpi_init_packet_header()

      /* check for new tcp syn packets, here
       * idea: reset detection state if a connection is unknown
       */
      if(flow->packet.tcp->syn != 0 && flow->packet.tcp->ack == 0 && flow->init_finished != 0 &&
         flow->detected_protocol_stack[0] == NDPI_PROTOCOL_UNKNOWN) {
...
         memset(flow, 0, sizeof(*(flow)));
        /* Restore pointers */
        flow->packet_direction_counter[0] = packet_direction_counter[0];
        flow->packet_direction_counter[1] = packet_direction_counter[1];
        flow->num_processed_pkts = backup;
        flow->guessed_protocol_id = backup1;
        flow->guessed_host_protocol_id = backup2;
        flow->packet.tcp = (struct ndpi_tcphdr *) l4ptr;
        flow->l4_proto = IPPROTO_TCP;

        NDPI_LOG_DBG(ndpi_str, "tcp syn packet for unknown protocol, reset detection state\n");

After executing memset(flow, 0, sizeof(*(flow))) we did not restore the flow->packet.iph, flow->packet.iphv6 and many another fields (payload, current_time_ms, l3_packet_len, l4_packet_len, payload_packet_len, l4_protocol). The protocol tinc is not ready for this case.

[IvanNardi]

Great catch!! That code has been quite tricky: this is the third bug found there, after 2a6532188 and 78b1295dc. It is not obvious (to me) which fields should be restored (all the fields about current packet dissection?) but your list seems fine