Re: [tcpdump-workers] error-message "IP11 truncated-ip" in last tcpdump/libpcap
Guy Harris wrote: On Mon, Jul 12, 2004 at 03:13:33PM +0200, Klaus Schrod wrote: Does anybody have any idea why we still get this error? Because, for whatever reason, the dissector for the protocol atop which the purported IP traffic is running thinks it's IP even though it isn't? (The version field has 11, not 4 or 6, in it.) Could you send us a capture file with this problem? We'd probably need that in order to figure out why it's happening. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe. Dear Guy Harris, first of all I want to thank you for your response of my error message. Today I noticed that the error message changed sometimes. Again our situation: Two computers connected to the net, one (lion) with a fixed ip address and one (styx) with pppoe. We established an ipsec tunnel between them successfully. tcpdump showed an error in the ESP traffic between styx and lion. But the error messages changed depending on the computer which sent the first packet after the ipsec tunnel is initiated. The errors appear only on styx, the pppoe side of the connection. tcpdump on lion shows the correct (and expacted) ESP traffic. If the first package (in my case a ping) came from lion the error message of tcpdump was "IP7 bad-hlen 12". In one case I saw also a "IP3 bad-hlen 8" message. There is no "truncated-ip" message in this case. If the first package (also a ping) came from the styx side the error mesage was the "truncated-ip" stuff. I did not find any "bad-hlen" in the messages. Depending on where the first packege was coming from I get only one or the other type of message. I did not know if the two type of messages have any logical connection. You will find two capture files as an attachment, one with the bad-hlen message and one with the truncated-ip message. If you need any further information please do not hesitate to contanct me. regards, Klaus Schrod ping2_over_ipsec.pcap Description: Binary data ping_over_ipsec.pcap Description: Binary data - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Bug in print-ppp.c
thanks for your submission - checked in; - /hannes On Tue, Jul 13, 2004 at 03:04:43PM +1000, Darren Reed wrote: | I've come across a packet that causes me to get a stack trace something | like this: | #0 0x in ?? () | #1 0x0807a0bd in handle_ctrl_proto (proto=32855, pptr=0x8195c82 "\001", length=14) at print-ppp.c:450 | #2 0x0807be24 in handle_ppp (proto=32855, p=0x8195c82 "\001", length=14) at print-ppp.c:1143 | #3 0x0807c072 in ppp_print (p=0x8195c82 "\001", length=14) at print-ppp.c:1229 | #4 0x0805fd22 in gre_print_1 (bp=0x8195c80 "\200W\001", length=28) at print-gre.c:305 | #5 0x0805f757 in gre_print (bp=0x8195c74 "0\001\210\v", length=28) at print-gre.c:108 | #6 0x080634c2 in ip_print (bp=0x8195c60 "E", length=48) at print-ip.c:606 | #7 0x08060307 in gtpv1u_print (bp=0x8195c60 "E", length=48) at print-gtp.c:323 | #8 0x080919d6 in udp_print (bp=0x8195c4c "\bh\bh", length=60, bp2=0x8195c38 "E", fragmented=0) at print-udp.c:635 | #9 0x080633b9 in ip_print (bp=0x8195c38 "E", length=88) at print-ip.c:539 | #10 0x0805e062 in ether_encap_print (ether_type=2048, p=0x8195c38 "E", length=88, caplen=88, extracted_ether_type=0xb2d0) | at print-ether.c:189 | #11 0x0805de85 in ether_print (p=0x8195c38 "E", length=88, caplen=88) at print-ether.c:142 | #12 0x0805def3 in ether_if_print (h=0xb340, p=0x8195c2a "") at print-ether.c:162 | #13 0x08094fc9 in print_packet (user=0xb520 "ÖÞ\005\b", h=0xb340, sp=0x8195c2a "") at tcpdump.c:1188 | #14 0x080a389a in pcap_offline_read () | #15 0x0809b486 in pcap_loop () | #16 0x08094b55 in main (argc=5, argv=0xb594) at tcpdump.c:997 | #17 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 | | Somewhere around like 445, print-ppp.c has: | default: | /* | * This should never happen, but we set | * "pfunc" to squelch uninitialized | * variable warnings from compilers. | */ | pfunc = NULL; | break; | } | | Adding a printout after the closing }, I see this for one packet: | pfunc (nil) tptr 0x8195c86 len 14 x 10 proto 0x8057 ptr 0x8195c82 length 14 | | We've come here from handle_ppp() which calls handl_ctrl_proto() for | PPP_IPV6CP. | | This patch (modulo white space) solves this problem for now. | | *** print-ppp.c 8 Jul 2004 11:10:37 - 1.2 | --- print-ppp.c 13 Jul 2004 05:01:15 - | *** | *** 447,452 | --- 447,454 | pfunc = NULL; | break; | } | + if (pfunc == NULL) | + break; | if ((j = (*pfunc)(tptr, len)) == 0) | break; | x -= j; | | Darren | - | This is the tcpdump-workers list. | Visit https://lists.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] http capture
I need to capture all incoming http requests to a webserver. I'm using the following command: /usr/sbin/tcpdump -i eth0 -p -n tcp port 80 However, that shows me all the traffic. I am specifically looking for each original request. Can someone help me here? Thanks, Kevin - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] http capture
On Jul 13, 2004, at 9:52 AM, Andersen, Kevin J. wrote: However, that shows me all the traffic. I am specifically looking for each original request. tcp dst port 80 should catch all traffic going *to* port 80 but not all traffic coming *from* port 80 (although if the client port is also 80, it'll catch that - there's nothing you can easily do about that at the BPF filter expression level). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] error-message "IP11 truncated-ip" in last tcpdump/libpcap
On Jul 13, 2004, at 7:56 AM, Klaus Schrod wrote: Again our situation: Two computers connected to the net, one (lion) with a fixed ip address and one (styx) with pppoe. We established an ipsec tunnel between them successfully. tcpdump showed an error in the ESP traffic between styx and lion. But the error messages changed depending on the computer which sent the first packet after the ipsec tunnel is initiated. The errors appear only on styx, the pppoe side of the connection. tcpdump on lion shows the correct (and expacted) ESP traffic. On what type of interface are you capturing on lion? A regular Ethernet interface? If the first package (in my case a ping) came from lion the error message of tcpdump was "IP7 bad-hlen 12". In one case I saw also a "IP3 bad-hlen 8" message. There is no "truncated-ip" message in this case. Ethereal's seeing similar problems. The traffic from 217.234.111.121 to 62.225.140.214 has, as the protocol layers: Linux cooked capture IP ESP whereas the traffic from 62.225.140.214 to 217.234.111.121 has Linux cooked capture IP with a protocol type of IP-inside-IP IP (with a bogus version number of 3 and a bogus header length of 8) It *might* be that the traffic from 217.234.111.121 to 62.225.140.214 (which I infer is sent from styx to lion, as the Linux cooked capture header shows it as "sent by us") is being shown as the ESP packets that are going on the wire, whereas the traffic from 62.225.140.214 to 217.234.111.121 is having the tunnel ESP headers stripped off, the tunnel IP header changed to say "IP inside IP", and the payload *NOT* being decrypted. I.e., I suspect this is probably a problem with the way the Linux kernel is supplying packets to user-mode code such as libpcap. Googling for ipsec linux IPIP ESP tcpdump truncated found http://www.uwsg.iu.edu/hypermail/linux/kernel/0401.0/1410.html and http://braindamage.alal.com/archives/linux-kernel/20030922/7627.html which looks as if they might be similar problems. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] error-message "IP11 truncated-ip" in last tcpdump/libpcap
On Jul 13, 2004, at 11:51 AM, Guy Harris wrote: whereas the traffic from 62.225.140.214 to 217.234.111.121 has Linux cooked capture IP with a protocol type of IP-inside-IP IP (with a bogus version number of 3 and a bogus header length of 8) The second capture is similar - and in both cases, the packets with a problem have a bad IP header checksum. The packets are being received by the host doing the capturing, so that's presumably not a result of checksum offloading. I suspect that the Linux networking stack is "helpfully" rewriting the headers to have IPIP rather than ESP as the protocol, and not changing the checksum (it'd be interesting to see whether changing the protocol field back to 0x32 makes the checksum correct), as I'd suggested in my previous message. It might be that the Linux IPsec implementation is doing that. Several pieces of Linux networking code appear to have the annoying habit of updating skbuffs in place without somehow arranging to do a copy-on-write if the traffic is being handed to a PF_PACKET socket, so that tcpdump and Ethereal and other packet capture applications don't see packets as they were received by the machine, they see them as modified in-place by the networking stack. I think that's been seen for the Token Ring, AppleTalk, and NFS code (there are workarounds in Ethereal for Token Ring and AppleTalk; there is, as I remember, no workaround even *possible* for NFS); IPsec might be another offender here. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] windump options 4 writing in a *.txt file
Dear all: It is possible to write raw packets in a *.txt file? I've already tried with: windump -w test.txt windump -w "test.txt" windump -w test but the text is coded or I could not read with notebook or wordpad or msoft word...Many thanks for your help I am using windows 2000 and winpcap 3.0, Best regards, César Cárdenas - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] windump options 4 writing in a *.txt file
On Jul 13, 2004, at 12:44 PM, César Cárdenas wrote: It is possible to write raw packets in a *.txt file? That depends on what you mean by "raw packets". Packet data is binary, so that wouldn't go into a .txt file. The packet data can be dumped in hex and/or ASCII, and that could be put into a text file. I've already tried with: windump -w test.txt windump -w "test.txt" windump -w test The "-w" flag writes raw packets, which are in a form that is not text. It can be read by tcpdump/WinDump, Ethereal, Analyzer, and a number of other applications that read the libpcap capture file format. If what you want is the textual dissection of the packet, such as would be printed if you ran tcpdump/WinDump with no command-line options, you could do windump >test.txt If you want the hex or ASCII dump of the raw packet data as text, you could try the "-x" and "-A" flags. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
