tcpdump icon indicating copy to clipboard operation
tcpdump copied to clipboard

Code cleanup

Open ValZapod opened this issue 6 years ago • 3 comments

@mcr https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-802_15_4.c#L650-L658 Mmm. You do not change s_cnt in between.

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-802_15_4.c#L1471 This is always false as ie_len is uint16_t and so ie_len < 1 is the same as ie_len = 0 but we are inside if (ndo->ndo_vflag > 3 && ie_len != 0) {

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-aodv.c#L532 Check this please... maybe print smth else.

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-arp.c#L439 Can you unite ARPOP_REVREQUEST and ARPOP_INVREQUEST?

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-bgp.c#L1145-L1146 So, we assign not a global variable and then immediately return with other variable... Strange.

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-bgp.c#L1666 Mmm. This is always false. Because there is advance = decode_multicast_vpn(ndo, tptr, buf, buflen); in the previous line and if you look in decode_multicast_vpn() you will see it either return route_length + 2 or return -2 but route_length is uint8_t.

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-bgp.c#L1731 The same. Practically. plen in decode_labeled_vpn_l2 is u_int.

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-bgp.c#L2892 What is this?? Like really why would somebody write it like that? Why not length != remainder_offset + 21. Here I write all such places with file:line: print-domain.c 541 print-egp.c 171 https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-domain.c#L368 Strange. 'cp' variable is assigned values twice successively. Check lines: 368, 380.

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-domain.c#L467-L472 What is this???

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-esp.c#L276-L283 Is it safe to do this? I mean you could've already free() the pointer. And here print-esp.c 906.

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-esp.c#L320 This check is usually optimized to nothing by compiler because you then dereference *nsa = *sa;

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-esp.c#L344 Maybe return something here?

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-ether.c#L326 length_type > MAX_ETHERNET_LENGTH_VAL is always true because we are inside else if of if (length_type <= MAX_ETHERNET_LENGTH_VAL) {

Part one...

ValZapod avatar Aug 01 '19 07:08 ValZapod

Part two... https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-forces.c#L108 node >= 0x40000000 is always true...

The use of macro ND_TTEST_LEN() is really bad. I mean here are warnings for just one file. print-fr.c 105 always true print-fr.c 110 print-fr.c 123 print-fr.c 133 print-fr.c 266 print-fr.c 808 print-fr.c 827 print-fr.c 841 print-fr.c 1001 print-fr.c 1026 twice!! Both always true and false.

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-hncp.c#L669 policy >= 1 we are in else if of if where policy == 0 (policy is uint8_t) https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-isakmp.c#L2548 This is always true.

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-isoclns.c#L1181 There is no need for this check, it was already done in line 1148.

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-ldp.c#L684

hexdump != 1 because line 648

I do not know what is happening here but maybe https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-llc.c#L198 should be ND_DEFAULTPRINT((const u_char *)p, length); The same on line 166

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-llc.c#L372 This is always false, because caplen is of unsigned type and previous check caplen < 1 (the same as caplen == 0). The opposite here: https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-llc.c#L379 we know that caplen != 0 by here so always true again because unsigned.

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-ospf.c#L305

This is always false

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-rsvp.c#L1288 Always true

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-snmp.c#L512 Always false https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-snmp.c#L516 The same

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-snmp.c#L667 That was already. Immediate return. https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-snmp.c#L1857 Always true. There was already a check on line 1834.

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-tcp.c#L763 always true length > 0

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-telnet.c#L429 Always true.

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/extract.h#L132body of 'EXTRACT_IPV4_TO_HOST_ORDER' function is fully equivalent to the body of 'EXTRACT_BE_U_4' function

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-tcp.c#L918-L920 Wow. Is this right?

https://github.com/the-tcpdump-group/tcpdump/blob/64ab4a9e04c8f92871a9c3a89b91ddf3498741c3/print-lmp.c#L403-L406 Looks strange in bw.i

print-dvmrp.c 370 note It is odd that the body of 'print_graft_ack' function is fully equivalent to the body of 'print_graft' function

ValZapod avatar Aug 01 '19 08:08 ValZapod

@fxlb So what? Do I need to create pull request or what?

ValZapod avatar Sep 10 '19 12:09 ValZapod

¿ NECESITO HACER UNA SOLICITUD DE EXTRACCIÓN ? ¿?.

MICHAEL464-web avatar Feb 29 '20 04:02 MICHAEL464-web