[tcpdump-workers] testing the list
This is another test of the mailing list. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] testing the list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael == Michael Richardson [EMAIL PROTECTED] writes: Michael This is another test of the mailing list. I don't know what I did wrong. But, it is fixed now. A kind gentleman was doing the spam moderation on the list last year. He went away on vacation --- I didn't hear from him when he returned. (his name was Elwyn, I think). I'm looking for some more volunteers. There can be more than one, since it is a web interface. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson,Xelerance Corporation, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ/Ss0oCLcPvd0N1lAQLmRwf+P5AfagURV9DzmMt8so1KBnobkYoRdY7G tNleWkT88MozHalcI1vNCc6NRxdu4FcVJlbOwDU1V9hJWmKQymtFzJ9zDgpCa5Wg vxGwzY+rw7TfuZXTUoKnORhj2mvzFWgyntqk5w1isZPzObOvjS++smPK3iAEpH92 e4AaEXcBcXG9gO5DQcOzgc2PbzuwBKgW8dLz2BohITkdFYbD8SALKfD6sX1yC/7n 9IOef7Efi1bEZVq4l9OACEUA0vg3eQLcTBdugRztzJja+QJ+1fP95Yi3M2KqhvLp v5yZpfxE+nPnXdWbtYwQEUtQD60hQORrDJ4BXlYE56/J2GyT/m6gTA== =bgDD -END PGP SIGNATURE- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] tcpdump.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Oh, I have removed the A record and the MX record for tcpdump.org The only address there was [EMAIL PROTECTED] If someone would like to run a well spam-filtered interface, I'll restore the MX record, but the spam level is rather high. (1 userids @tcpdump.org, continuously hit from 5-10 hosts, greylisting has minimal effect, since I 451 things I won't relay) - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson,Xelerance Corporation, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ/StNICLcPvd0N1lAQJz8gf+OOd3KftYVTlRHJp9z/+Go1Z2O5Dgvegy EaQGzrtl3jSL+lJyevathl/TeflafU9h4OeRO9/i/1gbJ8uFCch+0xGzszESpvcj HSmlHgi3CxNDpIcNw/9AM6G1rpLqA51kXX6RMAqIztJwDC5j54Ffj2ODBHF5Zx84 utnaff0pCb9KA1O4W8q5uQUCVAbpawDwTDctF+cpJ67c8XT5qGL+yrlfnebPbwe/ u68UJB0UUXkzuQbnm7biADrFotGIXHUBamFKTagLrwRBT58l8kSZNkQM3RAMPhvl B7PyqbA4l09zkpyTAuybQehWKuGN6Z2BgcF0Ec6M2GV0mT/86W3a0w== =tcid -END PGP SIGNATURE- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] What is the main reason in absent append capabilities of tcpdump and libpcap?
Hi there, All I wonder is why tcpdump still hasn't any binary dump append feature. A got some facts and thoughts: Implemetation of mentioned above feature is just a sligtly change to libcap's savefile.c ( i. e. addition of pcap_dump_open_append or add append flag to pcap_dump_open ( first won't break backward compatibiltiy) which will differ from original function in absence of sf_write_header procedure call, append write flags to fopen, check magic header, change position to end of old file ) and tcpdump's getopt parsing loop. All I need is solution that appends raw tcpdump packets to one file. I could made some crocks that will serve my current purpose ( e. g. $tcpdump opts -w - | magic_reaper old_dump ) and won't leave my work place, but I'd like to do some coding that will serve somebody else too. Here is the main troubles in addition of mentioned above capability in my own point of view: 1) Adding data to BIG file will slow down time, while tcpdump positioning at the end of old file so some packets will be dropped 2) All list is dreaming about new pcap format http://www.tcpdump.org/pcap/pcap.html Hmm, strange that i've found nearly one link ( http://www.tcpdump.org/lists/workers/2003/04/msg00248.html) and another on some russian forum where people discuss that problem. Thank you for you great work! -- Truly yours, Mikhail Manuilov - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] What is the main reason in absent append capabilities
On Thu, Feb 16, 2006 at 10:56:26AM -0800, Guy Harris wrote: Mikhail Manuylov wrote: All I wonder is why tcpdump still hasn't any binary dump append feature. Because nobody who needed that capability wrote code to implement it and contributed it to tcpdump-workers? I've just discovered that our local tree (at my work) has a patch to implement this functionality. Unfortuantely it's not quite complete; it doesn't check that the new link layer type is the same as the one in the existing capture file. I'll have a go at fixing it up and making it available. -ed - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] PATCH DCCP translate service code to host byte order
The DCCP service code is a u32 in network byte order. The current DCCP code does not call htonl() or equivalent. Fix attached. --- diff -crN tcpdump/print-dccp.c tcpdump-sorbo/print-dccp.c *** tcpdump/print-dccp.cMon Dec 5 21:36:24 2005 --- tcpdump-sorbo/print-dccp.c Wed Jan 25 10:34:50 2006 *** *** 312,318 struct dccp_hdr_request *dhr = (struct dccp_hdr_request *)(bp + dccp_basic_hdr_len(dh)); TCHECK(*dhr); ! (void)printf(request (service=%d) , dhr-dccph_req_service); extlen += 4; break; } --- 312,319 struct dccp_hdr_request *dhr = (struct dccp_hdr_request *)(bp + dccp_basic_hdr_len(dh)); TCHECK(*dhr); ! (void)printf(request (service=%d) , !EXTRACT_32BITS(dhr-dccph_req_service)); extlen += 4; break; } *** *** 320,326 struct dccp_hdr_response *dhr = (struct dccp_hdr_response *)(bp + dccp_basic_hdr_len(dh)); TCHECK(*dhr); ! (void)printf(response (service=%d) , dhr-dccph_resp_service); extlen += 12; break; } --- 321,328 struct dccp_hdr_response *dhr = (struct dccp_hdr_response *)(bp + dccp_basic_hdr_len(dh)); TCHECK(*dhr); ! (void)printf(response (service=%d) , !EXTRACT_32BITS(dhr-dccph_resp_service)); extlen += 12; break; } - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] multiple libpcap ring buffers?
Hey, If I have an application that opens two packet capturing sessions(ie eth0 and eth1) using the ring buffer version of libpcap, does libpcap create two separate ring buffers? Thanks for your help Cheers ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] What is the main reason in absent append
On Thu, 2006-02-16 at 20:17 +0300, Mikhail Manuylov wrote: Hi there, All I wonder is why tcpdump still hasn't any binary dump append feature. The biggest problem I imagine is that the resulting file would have only one header block, so the configuration of the capture for the appended records would have to be the same as for the original file. I'm not sure how you could check for or enforce this? The 'NTAR' file format intended for pcap-ng supports directly appending capture files together, allowing new header blocks to redescribe the interfaces and capture parameters. Stephen. -- --- Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED] Endace Technology Ltd phone: +64 7 839 0540 Hamilton, New Zealand cell: +64 21 1104378 --- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] What is the main reason in absent append
On Feb 16, 2006, at 12:06 PM, Stephen Donnelly wrote: The biggest problem I imagine is that the resulting file would have only one header block, so the configuration of the capture for the appended records would have to be the same as for the original file. I'm not sure how you could check for or enforce this? Require read and write access for appending, open for reading and writing, read the header, make sure the link-layer type and snapshot length are the same (and fail if they're not), and then seek to the end and start writing. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] NFS and TCP port numbers
hallo, i am wondering whether tcpdump should print rpc xid numbers instead of TCP port numbers in TCP NFS packets. check out the port numbers in the following dump: 12:27:39.078026 IP x.x.99.25.5001 x.x.99.26.5002: . ack 29 win 65535 12:27:39.088348 IP x.x.99.26.5001 x.x.99.25.2049: . ack 709 win 65535 12:27:41.851964 IP x.x.99.26.1757567062 x.x.99.25.2049: 264 getattr fh 0,11/1702064896 12:27:41.852053 IP x.x.99.25.2049 x.x.99.26.1757567062: reply ok 84 getattr ERROR: unk 10009 non-nfs ip packets are ok. but see that 1757567062 number instead of the port number? it turns out that nfs printer prints rm_xid instead of the tcp port number, like here in nfsreply_print(): snprintf(srcid, sizeof(srcid), %u, NFS_PORT); snprintf(dstid, sizeof(dstid), %u, EXTRACT_32BITS(rp-rm_xid)); where rp = (const struct rpc_msg *)bp; i also saw this packet in the beginning of the same dump: 12:27:38.940780 IP x.x.99.26.0 x.x.99.25.2049: 0 null note the src port number 0, but this is the same problem as above. is it the expected behavior? i'd personally rather see a tcp port number. thanks! -alexm 14:13 16/02/2006 - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
