Re: [tcpdump-workers] Adding support for ETSI GeoNetworking network and BTP transport protocol
Hi, I am kind of new to git and github. I think I did something useful with https://github.com/lykkja/tcpdump/tree/geonet_and_calmfast Can you check it out please, to see if I did it right? Kind regards, Ola Martin ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Adding support for ETSI GeoNetworking network and BTP transport protocol
27.06.2013, 13:28, "Ola Martin Lykkja" : > Hi, > > I am kind of new to git and github. > > I think I did something useful with > https://github.com/lykkja/tcpdump/tree/geonet_and_calmfast > Can you check it out please, to see if I did it right? Hello. The git part of the job is almost finished, there is a repository forked and containing a branch with the commit implementing the new decoders. It takes pushing the right button to place a pull request, so that it will be visible in the queue. Regarding the source code, I have _briefly_ looked through and attached a few comments to the commit. May be somebody else is willing to review as well? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Adding support for ETSI GeoNetworking network and BTP transport protocol
Denis Ovsienko yandex.ru> writes: > > 27.06.2013, 13:28, "Ola Martin Lykkja" q-free.com>: > > Hi, > > > > I am kind of new to git and github. > > > > I think I did something useful with > > https://github.com/lykkja/tcpdump/tree/geonet_and_calmfast > > Can you check it out please, to see if I did it right? > > Hello. > > The git part of the job is almost finished, there is a repository forked and containing a branch with the > commit implementing the new decoders. It takes pushing the right button to place a pull request, so that it > will be visible in the queue. > > Regarding the source code, I have _briefly_ looked through and attached a few comments to the commit. May be > somebody else is willing to review as well? > Thanks for your constructive comments. I have followed up on all of them and did a git add/commit/push. I also pressed "pull request" in github. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] libpcap: what is the efficiency of pcap_dispatch or pcap_next
I use libpcap to capture a lot packets, and then process/modify these packets and send them to another host. First, I create a libpcap handler `handle` and set it NON-BLOCKING, and use `pcap_get_selecable_fd(handle)` to get a corresponding file descriptor `pcap_fd`. Then I add an event for this `pcap_fd` to a libevent loop(it is like select() or epoll()). In order to avoid frequently polling this file descriptor, each time there are packet arrival event, I use pcap_dispatch to collect a bufferful of packets and put them into a queue `packet_queue`, and then call `process_packet` to process/modify/send each packet in the queue `packet_queue`. pcap_dispatch(handle, -1, collect_pkt, (u_char *)packet_queue); process_packet(packet_queue); I use tcpdump to capture the packets that are sent by `process_packet(packet_queue)`, and notice 1 at the very beginning, the interval between sent packets is small 2 after that several packets are sent, the interval becomes around 0.055 second 3 after 20 packets are sent, the interval becomes 0.031 second and keeps on being 0.031 second I carefully checked my source code and find no suspicious blocks or logic which leads to so big intervals. So I wonder whether it is due to the problem of the function `pcap_dispatch`. are there any efficiency problem on pcap_dispatch or pcap_next? thanks! ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for new DLT
Anders Broman wrote: > Currently there is two tags defined to indicate which protocol the > packet block starts with: > #define EXP_PDU_TAG_LINKTYPE 11 /**< The value part is the linktype value defined by tcpdump > * http://www.tcpdump.org/linktypes.html > */ > #define EXP_PDU_TAG_PROTO_NAME12 /**< The value part should be >an ASCII non NULL terminated string > * of the short protocol name used by Wireshark e.g "sip" > * Will be used to call the next dissector. > */ > The Wireshak implementation currently only uses EXP_PDU_TAG_PROTO_NAME . > Is this good enough? Seems good enough to me. Is there a stable reference in the wireshark tree/doc/etc. I can point to? How does this sound: /* * DLT type for upper-protocol layer PDU saves from wireshark. * * the actual contents are determined by two TAGs stored with each * packet: * EXP_PDU_TAG_LINKTYPE the link type (DLT value) of the * original packet. * * EXP_PDU_TAG_PROTO_NAMEthe name of the wireshark dissector * that can make sense of the data stored. */ #define DLT_WIRESHARK_UPPER_PDU 252 Code should be on github in... there: https://github.com/the-tcpdump-group/libpcap/commit/e65639c26a00397703102861466473c24181b47c please fork/edit with more info, and let us know how it works. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for new DLT
-Original Message- From: m...@sandelman.ca [mailto:m...@sandelman.ca] Sent: den 28 juni 2013 01:51 To: Anders Broman Cc: tcpdump-workers@lists.tcpdump.org Subject: Re: [tcpdump-workers] Request for new DLT Anders Broman wrote: > Currently there is two tags defined to indicate which protocol the > packet block starts with: > #define EXP_PDU_TAG_LINKTYPE 11 /**< The value part is the linktype value defined by tcpdump > * http://www.tcpdump.org/linktypes.html > */ > #define EXP_PDU_TAG_PROTO_NAME12 /**< The value part should be >an ASCII non NULL terminated string > * of the short protocol name used by Wireshark e.g "sip" > * Will be used to call the next dissector. > */ > The Wireshak implementation currently only uses EXP_PDU_TAG_PROTO_NAME . > Is this good enough? Seems good enough to me. Is there a stable reference in the wireshark tree/doc/etc. I can point to? Currently the header file contain the documentation of the TLV:s http://anonsvn.wireshark.org/viewvc/trunk/epan/exported_pdu.h?revision=50060&view=markup I plan to add a wiki page at http://wiki.wireshark.org/ the "next PDU" TLV:s will not change but TAG:s may be added as the need arises. It would be great if this suffices To get the DLT then we can proceed to finalize the documentation and have a nice wiki page too. If you feel more documentation is needed before allocating the DLT we can work on that. Best regards Anders Broman How does this sound: /* * DLT type for upper-protocol layer PDU saves from wireshark. * * the actual contents are determined by two TAGs stored with each * packet: * EXP_PDU_TAG_LINKTYPE the link type (DLT value) of the * original packet. * * EXP_PDU_TAG_PROTO_NAMEthe name of the wireshark dissector * that can make sense of the data stored. */ #define DLT_WIRESHARK_UPPER_PDU 252 Code should be on github in... there: https://github.com/the-tcpdump-group/libpcap/commit/e65639c26a00397703102861466473c24181b47c please fork/edit with more info, and let us know how it works. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Link-Layer Header Type request for Linux Kernel Messages
Hi, Here you are complete implementation of this feature in libpcap. https://github.com/MichalLabedzki/libpcap/commit/e450c6e664c98c90a9e2c44702aa61a92276012c(for: review and test) If you need I can provide implementation for Wireshark (currently: I am waiting for support that in libpcap). Pozdrawiam / Best regards - Michał Łabędzki, Software Engineer Tieto Corporation Product Development Services http://www.tieto.com / http://www.tieto.pl --- ASCII: Michal Labedzki location: Swobodna 1 Street, 50-088 Wrocław, Poland room: 5.01 (desk next to 5.08) --- Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --- Please consider the environment before printing this e-mail. --- Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
