>> since netbsd's -D and -L seem instrinsically related, yet the official >> tcpdump -D doesn't seem that far off, and since the netbsd change is >> rather recent, how about merging/switching the two functionalities? >> this would mean that -D would give me (for example): >> >> % tcpdump -D >> 1.lo0 NULL >> 8.ep0 EN10MB >> 9.wi0 EN10MB IEEE802_11 > >Yes, that might be a good idea, although that doesn't offer an option to >display just the link-layer types for one particular interface - I guess >we could allow "-i" and "-D" to be used together, and have that display >the link-layer types for the interface specified with "-i" (and maybe >leave out the interface number if that's done).
that seems fair. oh, but i see that in order to dump the available dlt values, it needs already to have an open bpf. hmm... >> (1) use -W to indicate "open the underlying network tap device in >> read/write mode". > >Why would tcpdump do that? It doesn't transmit packets. tcpdump wouldn't. in fact, users of tcpdump would probably never need the flag. sorry, i was a bit confused. what is wanted is a way for a "user" of libpcap to tell libpcap to open the bpf r/w so that it can inject packets. the simh simulator can use this to make the emulated network interface work. >> jason thorpe has done a bit of this to the netbsd >> copy of the libpcap code, but only insofar as the bpf unconditionally >> gets opened read/write. his reasoning: >> >> Open the BPF file descriptor as read-write. Some pcap-using >> programs (notably, simulators) expect to be able to send >> packets on the descriptor, as well as receive. >> >> but that sucks for me, since i like to give special purpose accounts >> read-only access to the bpf so that they can monitor, but not write to >> the network. > >You are correct - I would not advocate having libpcap open BPF devices >read-write by default, for that very reason. I guess it could try >opening each device read-write and, if that fails with EACCES, try >opening it read-only. that seems reasonable. >> being able to tell pcap_open_live() to use read-only or >> read/write would be a big win (i get what i want and jason gets what >> he wants), and i think i can see how to do it. pcap_open_live() has a >> promisc argument that could be "altered" to be flags. promisc could >> then become 0x01 and read/write could be 0x02. etc. > >Unfortunately, as the man page only speaks of "promisc" specifying if >the interface is to be put in promiscuous mode, I don't think we can >assume that applications using promiscuous mode will necessarily pass 1 >as the value meaning "promiscuous" - most of them probably do, but I >wouldn't count on all of them doing so. bleah. >My inclination would be to do the "try read-write and, if that fails >with EACCESS, try read-only" - that might not do the right thing if some >BPF devices are read-write by the user trying to open them and some are >read-only, but all the BPF devices should, if accessible by a user at >all, be accessible with the same permissions (I guess somebody might >want to make some of them accessible only be root to reserve them for >use by root). that would probably help me, but i'm not sure the application would like getting write errors on something it thought it could write to. i'll check. >> (2) use -U to tell tcpdump to write the dump to the output file in an >> unbuffered manner. packets that dribble in take a long time to fill >> the stdio buffer and get flushed to the file. this can be incredibly >> annoying, especially if you're impatient. > >Are you talking about a file being written to with "-w"? If tcpdump is >just printing text, "-l" makes the output line-buffered. yes, the file being written with -w. >For a file being written to with "-w", you probably don't want >unbuffered output, you probably just want the output written out before >tcpdump blocks again - that'd do fewer "write()"/"WriteFile()" calls, >and be more efficient. there are situations where i wish to record the packet capture and analyze it at the same time (in which case, the number of write() calls isn't a concern). for slow packet exchange, it can take a long while before a buffer flushes and there are packets for me to look at. this would certainly not be the default, but i would like to see it be an option. >That could be done by adding a "pcap_dump_flush()" call, to force the >stdio buffer to be flushed, and have tcpdump's main loop be a loop using >"pcap_dispatch()" rather than just being "pcap_loop()", and have it do >the "pcap_dump_flush()" call after "pcap_dispatch()" returns. okay...a patch to tcpdump without intruding into/breaking the libpcap api is good. >> (3) use another letter (there aren't any really good mnemonics left >> off the top of my head, so i'm open to suggestions) to tell tcpdump to >> dump the link layer data as well when using -x or -X. when printing >> ip datagrams using -X (or -x), the link layer stuff is skipped. call >> me crazy, but i'd like to be able to see that somewhere. i initially >> used -L for this (to indicate link layer), but that got used by >> someone else because i was lazy. -E was already gone at that point. > >Yes, that'd be useful. i suppose i'll use -y. y not? lemme see if i can dig out my code... -- |-----< "CODE WARRIOR" >-----| [EMAIL PROTECTED] * "ah! i see you have the internet [EMAIL PROTECTED] (Andrew Brown) that goes *ping*!" [EMAIL PROTECTED] * "information is power -- share the wealth." - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
