Activity for Aex Aey
-
Aex Aey posted a comment on ticket #44
If we take an example of: From: "Joe Random" <joe@example.com> ...would that be "Joe Random" that you want to match on?
-
Fixed with #include <netinet/in.h>
-
ipv6 + vlan
-
Should be fixed in [r157]. Can you give it a try?
-
add another encapsulation - 802.1Q-then-IPv6
-
First one (8100 0007 8864 1100 27c3 05d6) appears to be PPPoE inside an 802.1Q VLAN. I've added this in [r155] (untested, I don't have any pcaps with such traffic) On the LAN: - Ethernet tag 86dd is IPv6 - added in [r156] - Ethernet tag 88e1 homeplug (ethernet over powerline) protocol: https://en.avm.de/service/fritzbox/fritzbox-7360/knowledge-base/publication/show/249_Firewall-reports-attacks-on-TCP-port-80-or-14013-or-unsolicited-packets-of-type-0x88e1/ - Ethernet tag 8912 - can't figure this one...
-
support 0x86dd as IPv6 EtherType
-
support PPPoE-in-802.1Q
-
Yes, of course. thank you for attaching. I've integrated your fix as [r152] With a fresh svn checkout, you should see SIP working on both native IPv6 and IPv4-tunneled-in-IPv6 (as is customary to do in DS-lite). However, RTP will likely still be missing (if SDP is not in the first fragment, like it is in the attached pcap). To make that work, we need teach pcapsipdump to do full segment reassembly. I'll add this on to-do list.
-
[r154] should deal with DS-lite and some IPv6 fragmented packets, but latter is quite limited similarly to the IPv4 fragmenation handler - RTP will only be picked up if enough of SDP (m= and c=) are included in first fragment.
-
handle ipv4-in-ipv6 (a.k.a. dual-stack lite)
-
first attempt to handle ipv6 fragmentation
-
refactor ethernet header parsing and add pppoe support
-
Hi Oliver, thanks for reporing this. Would you be able to attach a .pcap file with pppoe ipv4/ipv6 sip packets? Just one packet for each(ipv4/ipv6) would be enough.
-
Endian issue, pcapsipdump not working on big endian
-
Ok, I you are right. I was confused beween solaris-style defines (either _LITTLE_ENDIAN == 1 or _BIG_ENDIAN == 1; other one undefined) and BSD/Linux-style defines (either __BYTE_ORDER == __LITTLE_ENDIAN or __BYTE_ORDER == __BIG_ENDIAN; all three always defined), so trunk since [r139] was broken on BE systems. Should be fixed in [r151], can you give it a try?
-
refactor endianness detection (fix #39 2/2)
-
Hello Aex, I crosscompile on x86_64 with OpenWrt buildroot. gcc is 7.4.0 and libc in this case is musl. Will try tonight. I think __LITTLE_ENDIAN and __BIG_ENDIAN can't be used for tests, because they seem to be defined both at the same time. I put an #error below if !defined (__LITTLE_ENDIAN) && !defined (__BIG_ENDIAN) and the build never reached this error. Also, pcapsipdump testing like this ("do this if both __LITTLE_ENDIAN and __BIG_ENDIAN aren't defined") suggests this is normal. I found this...
-
Re: endinannes though - that is not what is going on here. __LITTLE_ENDIAN or __BIG_ENDIAN are used to construct packet header structs. On most systems, one of them is defined to indicate endianness (not both). If neither is defined, then, as a fallback __BYTE_ORDER is probed, and either __LITTLE_ENDIAN or __BIG_ENDIAN is defined locally. Do you complile this natively on BE host? Which gcc/libc? Can you try to compile lines 31..42 of pcapsipdump.h standalone to see if this is what compliler chokes...
-
Endian issue, pcapsipdump not working on big endian
-
time_t fix is in [r150], thanks!
-
Fix #39 (1/2)
-
Major bug -- Inverted logical expression
-
Fixed in [r149], thanks for reporting! Note that while missing "!" before memcmp is indeed a bug, it was never a problem, being masked by another bug in the same line: confusion between sizeof (string constant length including final \0, i.e. memcmp does exact match) vs. strlen (string length excluding final \0, i.e. memcmp does prefix match). That is to say - if you don't see .pcap files being created, check other things too.
-
Fix #38
-
Support q-in-q VLANs
-
hm... looks like sf wouldn't allow me to set you as commit author :-/
-
Support q-in-q VLANs
-
Commited in [r148]. Thanks for contributing!
-
Allow q-in-q capture. This should really be dynamic number of tags - walk through all the 0x8100s until we get 0x0800
-
BSD
-
Thanks for reporting. According to /usr/include/pcap/dlt.h link type 113 is "Linux cooked sockets". This interface type (lo, tun, etc...) lack L2 header, and therefore vlan support. Vlan was, until now, part of default pcap filter expression. This should be fixed in [r147] (by dropping default pcap filter expression altogether). For earlier version, any explicit pcap expression compatible with linktype can be specified after all the other parameters, for example ip. This will override default pcap...
-
Unable to split pcap file
-
Thanks for reporting. According to /usr/include/pcap/dlt.h link type 113 is "Linux cooked sockets". This interface type (lo, tun, etc...) lack L2 header, and therefore vlan support. Vlan was, until now, part of default pcap filter expression. This should be fixed in [r147] (by dropping default pcap filter expression altogether). For earlier version, any explicit pcap expression compatible with linktype can be specified after all the other parameters, for example ip. This will overrive default pcap...
-
Drop the default pcap filter expression
-
Should be fixed in [r146], thanks for reporting!
-
Fix gettag()
-
That's weird. If you feed a known-good .pcap file to the pcapsipdump (with -r option), do you see the same problem (which would squarely imply internal pcapsipdump's logic in this bug), or do you only see this when capturing on the interface directly (which would possibly imply a bug in how pcapsipdump talks to libpcap). Also, which OS & libpcap version are on the host pcapsipdump is running?
-
handle packets larger than snaplen
-
handle tel: urls in from/to headers
-
handle non-standard line-ends
-
sanitize filenames
-
BSD
-
Hi Marcelius, Thanks a lot for the patches. I've refactored them a bit and added as [r139], [r140], and [r141]
-
tautological-compare
-
Take care of some compiler warnings
-
BSD port
-
Ok, nevermind about AppArmor - just checked with fresh ubuntu bionic install, and it all works fine. Same for "false" directory. I have slightly improved this in [r138], but that's not the problem either. Problem likely is - there is no SIP/UDP traffic on specified interface. So: Check that capture is done on correct interface (option -i); Check if there is some SIP/UDP to go along with that RTP (pcapsipdump would not capture RTP without session initiation); If you are using SIP/TCP instead, have...
-
no files and false directory structure
-
Ok, nevermind about AppArmor - just checked with fresh ubuntu bionic install, and it all works fine. Same for "false" directory. I have slightly improved this in [r138], but that's not the problem either. Problem likely is - there is no SIP/UDP traffic on specified interface. So: Check that capture is done on correct interface (option -i); Check if there is some SIP/UDP to go along with that RTP (pcapsipdump would not capture RTP without session initiation); If you are using SIP/TCP instead, have...
-
Use slightly better defaults for -d option
-
Sounds like some of system calls by the pcapsipdump binary are getting blocked - gettimeofday() and libpcap-related bindings. I would suspect an LSM interfering. Try disabling AppArmor, or if you have a lot of time on hand, try creating an appropriate AppArmor profile: https://help.ubuntu.com/community/AppArmor
-
What happened here is: idx is not set because current packet was filtered out (didn't match number-filter, option -n), but IPv4 fragmentation code still tried to save this (first) fragment. Since fragmentation code used idx to access calltable, of course, that failed. Fix moves part of IPv4 fragmentation code that handles first fragment inside "if(idx>=0)" conditional, where it should've been to begin with. Thanks again for detailed report!
-
trunk r135 segfault after a few minutes of runtime
-
This should be fixed in [r137], thanks for reporting!
-
Don't try to reassemble fragments from filtered out packets
-
Avoid confusion between IPv6 UDP and IPv4 UDP
-
Fix the capturing of IPv6 UDP packets
-
Fixed in [r135], thanks!
-
Fix the capturing of IPv6 UDP packets
-
There are two problems here: Option "-d" requires either directory name or filename template, not a bare filename. As specified, pcapsipdump will overwrite the same file over and over again with each individual call. This is fixed in [r134]. Fixed in a sense that pcapsipdump will reject such option. Segmenation fault. Likely, something unusual in the packet seen triggered this. Could you please re-compile this as "make pcapsipdump-debug", then run inside gdb: mkdir /home/test gdb pcapsipdump-debug...
-
There are two problems here: Option "-d" requires either directory name or filename template, not a bare filename. As specified, pcapsipdump will overwrite the same file over and over again with each individual all. This is fixed in [r134]. Fixed in a sense that pcapsipdump will reject such option. Segmenation fault. Likely, something unusual in the packet seen triggered this. Could you please re-compile this as "make pcapsipdump-debug", then run inside gdb: mkdir /home/test gdb pcapsipdump-debug...
-
There are two problems here: Option "-d" requires either directory name or filename template, not a bare filename. As specified, pcapsipdump will overwrite the same file over and over again with each individual all. This is fixed in [r134]. Fixed in a sense that pcapsipdump will reject such option. Segmenation fault. ILikely, something unusual in the packet seen triggered this. Could you please re-compile this as "make pcapsipdump-debug", then run inside gdb: mkdir /home/test gdb pcapsipdump-debug...
-
More checks in opts_sanity_check_d()
-
Alternate port capture
-
failing at "Empty SIP method"
-
Unable to install
-
Capturing on ports other than 5060
-
RTP Traffic missing
-
rtpevent filter doesn't match
-
Already implemented.
-
Source / Destination IP filter feature (patch provided)
-
No media in sip-t calls
-
Capturing logs
-
Handle IP fragmentation
-
Have a look at mergecap, if you haven't already: https://www.wireshark.org/docs/man-pages/mergecap.html mergecap can write to stdout. pcapsipdump can read from stdin. You get the idea. Maybe sort arguments first (assuming fragments are linearly named, i.e. 0001, 0002, etc...): mergecap -w - $(ls -rt *.pcap) | pcapsipdump -fr /dev/stdin -d .
-
Analyze multiple (split) pcap files
-
Same as with any other daemon - redirect stdout/stderr into whatever logging system is used. SystemD does that automatically. In a shellscript-style supervisor, "logger" tool would come in handy: ( pcapsipdump -f other-options-go-here | logger -t pcapsipdump ) & pcapsipdump doesn't emit all that many messages though, even at verbosity level 3, which is the most verbose. On the other hand, if you want to have a transaction log, for example CDR, or registration log - have a look at the trigger system...
-
Capturing logs
-
fix typo
-
PID is a CONST
-
Added in [r131]. Note that daemons self-forking is not the only and not the best way to fork. Some supervisors (inittab, systemd, djb's supervise) prefer supervisor to do the forking. This makes both pid discovery and wait(3) trivial. For example, from bash with any version of pcapsipdump: pcapsipdump -fi eth0 & echo $! >/var/run/pcapsipdump-eth0.pid pcapsipdump -fi eth1 & echo $! >/var/run/pcapsipdump-eth1.pid
-
Make pid_file configurable
-
PF_RING kernel interface is not quite the same as PACKET_RX_RING support that [r43] introduced. PF_RING is supposed to be faster (0-copy, whereas libcap 1.x is 1-copy, and libpcap 0.x is 2-copy). Although, it could be debatable if that makes all that much of a difference - on a modern high-end system, RAM (or local RAM on a NUMA system) would typically be plenty fast to accommodate few copies of 100Gbit/s line-speed stream. On the other hand, context switches between kernel and userspace do eat into...
-
Thanks for reporting. Would you mind taking [r130] for a spin? This is far from full SIP-I / SIP-T support yet, but should be enough to capture complete calls with RTP, where ISUP payload is supplimented by a normal, RFC4566-style SDP inside a MIME multipart container (as seen in the example you've attached).
-
No media in sip-t calls
-
Basic support for Content-Type multipart/mixed (SIP-T)
-
This backtrace doesn't look terribly useful: everything is in libc, plus pcapsipdump uses a bit unconventional architecture where bulk of processing is in main() - this makes backtrace even less likely to be useful. Is there any chance you can build a debug-enabled binary? make CXXFLAGS=-DUSE_TCP=1 pcapsipdump-debug ...then run it under gdb (adjust "set args" as needed, make sure "-f" option is present): gdb pcapsipdump-debug set args -f -d . -r myfile.pcap run ...and finally, when it crashes, make...
-
bufferover flow crash
-
SIP over TCP
-
For really crude TCP support, check out [r128]. Known problems: 1. SYN, empty ACK, FIN, RST and keepalive packets are omitted; 2. when SIP (+SDP) are long enough to be split into multiple segments, only first segment is recorded; 3. if ip/port allocation lines of SDP happen to be beyong first TCP segment, RTP defined in that SDP is omitted.
-
Clean-up / typos
-
For really crude TCP support, check out [r128]. Known problems: 1. SYN, empty ACK, FIN, RST and keepalive packets are omitted; 2. when SIP (+SDP) are long enough to be split into multiple segments, only first segment is recorded; 3. if ip/port allocation lines of SDP happen to be beyong first TCP segment, RTP defined in that SDP is omitted. Proper support with fragment reassembly and reordering is going to take a bit more effort. Ping me on aexaey [at] gmail, if you're interested in contributing...
-
For really crude TCP support, check out [r128]. Known problems: SYN, empty ACK, FIN, RST and keepalive packets are omitted; when SIP (+SDP) are long enough to be split into multiple segments, only first segment is recorded; * if ip/port allocation lines of SDP happen to be beyong first TCP segment, RTP defined in that SDP is omitted. Proper support with fragment reassembly and reordering is going to take a bit more effort. Ping me on aexaey [at] gmail, if you're interested in contributing and/or...
-
Add crude TCP support. Compile with make CXXFLAGS=-DUSE_TCP=1
-
Hi Michael, Couple more things sanity-check: Are you running latest SVN (127)? Are you capturing SIP/UDP? pcapsipdump doesn't support SIP/TCP or SIP/TLS yet (but might in near future) I've did a quick test with: sipp -sn uac -p 5070 127.0.0.1:5080 ./pcapsipdump -f -i lo -d . and svn127 seem to capture just fine.
-
Capturing on ports other than 5060
-
Thanks for reporting this. Fixed in [r127]. Now, with no additional options, pcapsipdump...
-
Alternate port capture
1 >
