[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 07.12.2004 - 08.12.2004 GMT
CVS log entries from 07.12.2004 (Tue) 10:06:59 - 08.12.2004 (Wed) 10:08:52 GMT = Summary by authors = Author: guy File: libpcap/pcap-bpf.h; Revisions: 1.26 File: libpcap/savefile.c; Revisions: 1.114 = Combined list of identical log entries = Description: New link-layer header type for raw GPRS LLC frames, as per a request by Marc Hermstein <[EMAIL PROTECTED]>. Modified files: File: libpcap/pcap-bpf.h; Revision: 1.26; Date: 2004/12/07 17:27:45; Author: guy; Lines: (+3 -1) File: libpcap/savefile.c; Revision: 1.114; Date: 2004/12/07 17:27:45; Author: guy; Lines: (+5 -1) = Log entries = = Summary of modified files = File: libpcap/pcap-bpf.h Revisions: 1.26 Authors: guy (+3 -1) --- File: libpcap/savefile.c Revisions: 1.114 Authors: guy (+5 -1) -- Automatic cron job from /tcpdump/bin/makelog - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT_ request
marc hermstein wrote: When developing a handset, some manufacturers dump debugging data from the protocol stack out the serial port on the bottom of the handset. This is what I meant by a "logger". So you'll be writing, or have written, a piece of code that reads from the serial port and writes to a libpcap file? Or is there already software that logs the debugging data in another format (in which case you might be able to modify Ethereal's Wiretap library to read those files)? It might be interesting to add to libpcap a module to do live captures on a serial port. There will probably be other types of capturing people would want to do on serial ports, so there might eventually be a generic "serial port" capture module supporting multiple DLT_ types. There might have to be a way to specify the baud rate, bits per character, parity, etc. - the current "pcap_open_live()" API can't do that, but I'm thinking of a future open API that'd take an attribute/value list of options (so that it could, for example, have options to support "monitor mode" and setting the channel for 802.11), so that the option list could be extended without API changes (there might also be a way to find out what devices offer what options, so that applications such as Ethereal could offer GUI options). However, some or all of the serial port settings might be implied by the protocol, in which case they wouldn't have to be specified. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT_ request
Yes, live serial port capture does sound like a useful enhancement. However, for now I am going to keep it file-based and write code that extracts the LLC data from a log file and outputs it in libpcap. In conjunction with LLC, RLC/MAC blocks (the next layer 'down' on the air interface side) are being output by the logger and some other debugging info. --- Guy Harris <[EMAIL PROTECTED]> wrote: > marc hermstein wrote: > > When developing a handset, some manufacturers dump > > debugging data from the protocol stack out the > serial > > port on the bottom of the handset. This is what I > > meant by a "logger". > > So you'll be writing, or have written, a piece of > code that reads from > the serial port and writes to a libpcap file? Or is > there already > software that logs the debugging data in another > format (in which case > you might be able to modify Ethereal's Wiretap > library to read those files)? > > It might be interesting to add to libpcap a module > to do live captures > on a serial port. There will probably be other > types of capturing > people would want to do on serial ports, so there > might eventually be a > generic "serial port" capture module supporting > multiple DLT_ types. > There might have to be a way to specify the baud > rate, bits per > character, parity, etc. - the current > "pcap_open_live()" API can't do > that, but I'm thinking of a future open API that'd > take an > attribute/value list of options (so that it could, > for example, have > options to support "monitor mode" and setting the > channel for 802.11), > so that the option list could be extended without > API changes (there > might also be a way to find out what devices offer > what options, so that > applications such as Ethereal could offer GUI > options). > > However, some or all of the serial port settings > might be implied by the > protocol, in which case they wouldn't have to be > specified. > - > This is the tcpdump-workers list. > Visit https://lists.sandelman.ca/ to unsubscribe. > __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
