tcpdump
tcpdump copied to clipboard
Code cleanup
@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...
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
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
@fxlb So what? Do I need to create pull request or what?
¿ NECESITO HACER UNA SOLICITUD DE EXTRACCIÓN ? ¿?.