[Home]

Summary:DAHLIN-00176: [patch] adding ss7 pcap support to dahdi
Reporter:Torrey Searle (tsearle)Labels:
Date Opened:2010-02-15 16:20:00.000-0600Date Closed:2010-12-20 09:06:17.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) dahdi_mirror.patch
( 1) dahdi_mirror2.patch
( 2) dahdi_pcap.c
( 3) dahdi_pcap2.c
( 4) dahdi_pcap3.c
( 5) dahdi_pcap4.c
( 6) dahdi_pcap6.c
( 7) dahdi_pcap-v5.c
( 8) dahdi-pcap-q931.c
( 9) dahdi-tools-pcap-v5.patch
(10) driver_v2.patch
(11) driver.patch
Description:as per the thread on the libss7 mailing list

1. changes to the dahdi driver to add ioctls to mirror reads/writes
from a signaling channel to a pseudo channel
2. a corresponding user app to set up the mirroring and record the
traffic in a pcap

This seems to work though I'm not sure if it's the best solution design-wise.
I might be abusing the pseudo channel concept.

to compile the app do the following
gcc dahdi_pcap.c -o dahdi_pcap -lpcap

and the syntax to run it is
./dahdi_pcap chan1  [chan2]* pcap.pcap

e.g.
./dahdi_pcap 16 47 test.pcap
Comments:By: Torrey Searle (tsearle) 2010-02-19 02:14:37.000-0600

I've tested successfully with the following equipment (as reported by lspci)

Digium, Inc. Device 0420 (rev 02)
Sangoma Technologies Corp. A104d QUAD T1/E1 AFT card
By: Torrey Searle (tsearle) 2010-03-26 10:44:07

uploaded new version of the pcap tool (dahdi_pcap2.c) this version, this version only logs messages if they are different from the previous one.  This prevents the pcap from being flooded with FISSU messages and make the pcaps much more readable.
By: Torrey Searle (tsearle) 2010-03-26 10:44:57

it should also be noted that libpcap0.8 is required for the tool to be compiled.
By: Nahuel Greco (nahuelgreco) 2010-03-31 13:13:14

chan2 must be a real physical channel, that should be noted. If you try to use a non existant channel kernel will oops:

[6125922.061667] dahdi: Master changed to TE4/0/1
[6126093.021402] dahdi: Chan 16 tx mirrored to 373
[6126093.021500] dahdi: Chan 16 rxmirrored to 374
[6126094.310416] dahdi: Chan 373 tx mirror to 16 stopped
[6126094.313991] dahdi: Chan 374 rx mirror to 16 stopped
[6126097.074642] dahdi: Chan 16 tx mirrored to 373
[6126097.074715] dahdi: Chan 16 rxmirrored to 374
[6126097.074781] dahdi: Chan 512 tx mirrored to 375
[6126097.074826] BUG: unable to handle kernel NULL pointer dereference at 00000000
[6126097.074891] IP: [<c02cbdb3>] _spin_lock_irqsave+0x25/0x5e
[6126097.074933] *pdpt = 0000000058618001 *pde = 0000000000000000
[6126097.074942] Oops: 0002 [#1] SMP
[6126097.076782] Modules linked in: xpp_usb xpp wcb4xxp wctdm wcfxo wctdm24xxp wcte11xp wct1xxp wcte12xp dahdi_voicebus wct4xxp dahdi nls_utf8 cifs nls_base nf_conntrack_ipv4 xt_state nf_conntrack xt_physdev iptable_filter ip_tables x_tables firmware_class crc_ccitt bridge netloop 8021q ipv6 w83627hf hwmon_vid loop dm_crypt crypto_blkcipher parport_pc intel_rng shpchp i2c_i801 parport evdev rng_core pcspkr i2c_core pci_hotplug container button ext3 jbd mbcache dm_mod ide_disk ata_generic ide_pci_generic uhci_hcd sata_sil libata scsi_mod dock e100 mii piix ide_core e1000 ehci_hcd usbcore intel_agp agpgart thermal processor fan thermal_sys [last unloaded: dahdi]
[6126097.076782]
[6126097.076782] Pid: 30163, comm: dahdi_pcap Not tainted (2.6.26-2-xen-686 #1)
[6126097.076782] EIP: 0061:[<c02cbdb3>] EFLAGS: 00010002 CPU: 2
[6126097.076782] EIP is at _spin_lock_irqsave+0x25/0x5e
[6126097.076782] EAX: 00000100 EBX: 00000000 ECX: c03d2ba8 EDX: f5656000
[6126097.076782] ESI: 00000000 EDI: d63cdc80 EBP: d63c6000 ESP: ecae1dc0
[6126097.076782]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
[6126097.076782] Process dahdi_pcap (pid: 30163, ti=ecae0000 task=cee574e0 task.ti=ecae0000)
[6126097.076782] Stack: ee35e536 00000200 00000177 ee358d8c ee35e536 ee36226c 00000200 00000177
[6126097.076782]        bf9a81f4 ed403550 c0362220 00000000 c0152f8a c0362220 00000000 00000000
[6126097.076782]        00000020 00000200 00000000 00000000 cee574e0 ecae1f14 00000080 f5656000
[6126097.076782] Call Trace:
[6126097.076782]  [<ee358d8c>] dahdi_chanandpseudo_ioctl+0x257/0x124b [dahdi]
[6126097.076782]  [<c0152f8a>] __alloc_pages_internal+0xb5/0x34e
[6126097.076782]  [<c0158aef>] mod_zone_page_state+0x30/0x5d
[6126097.076782]  [<ee35bcfa>] dahdi_ioctl+0x1736/0x17e9 [dahdi]
[6126097.076782]  [<ee35253e>] set_tone_zone+0x71/0x7e [dahdi]
[6126097.076782]  [<ee352a15>] dahdi_specchan_open+0x4ca/0x526 [dahdi]
[6126097.076782]  [<ee352bd3>] dahdi_open+0x162/0x182 [dahdi]
[6126097.076782]  [<c0172a55>] chrdev_open+0x15b/0x191
[6126097.076782]  [<c01728fa>] chrdev_open+0x0/0x191
[6126097.076782]  [<c016ea14>] __dentry_open+0x130/0x1fc
[6126097.076782]  [<c016eafc>] nameidata_to_filp+0x1c/0x2c
[6126097.076782]  [<c0179a36>] do_filp_open+0x34f/0x684
[6126097.076782]  [<ee35a5c4>] dahdi_ioctl+0x0/0x17e9 [dahdi]
[6126097.076782]  [<c017a958>] vfs_ioctl+0x1c/0x5d
[6126097.076782]  [<c017abe3>] do_vfs_ioctl+0x24a/0x261
[6126097.076782]  [<c016e876>] do_sys_open+0xa8/0xb0
[6126097.076782]  [<c017ac3b>] sys_ioctl+0x41/0x5a
[6126097.076782]  [<c0103f76>] syscall_call+0x7/0xb
[6126097.076782]  =======================
[6126097.076782] Code: c0 74 db 5b 5e c3 56 53 89 c3 83 ec 04 8b 15 c4 b1 35 c0 64 a1 04 b0 3b c0 c1 e0 06 0f b6 74 10 01 c6 44 10 01 01 b8 00 01 00 00 <f0> 66 0f c1 03 89 04 24 8b 04 24 ba 00 04 00 00 38 e0 74 09 4a
[6126097.076782] EIP: [<c02cbdb3>] _spin_lock_irqsave+0x25/0x5e SS:ESP 0069:ecae1dc0
[6126097.080598] ---[ end trace d840db0fcd0af415 ]---


I think you need to add some check to prevent this.
By: Torrey Searle (tsearle) 2010-04-01 02:57:33

Thanks for your response! Good to know that it's getting used :-)

I've added some more tests and posting a new version of the patch driver_v2.patch (it replaces the old one, so you'll need to -R the old patch)

Let me know if this resolves your issue


By: Torrey Searle (tsearle) 2010-04-14 02:27:54

nahuelgreco have you had a chance to try it yet?
By: Horacio Peña (horape) 2010-05-03 07:46:20

I've attached a version of your sniffer that works on PRI signalling links. It's rough but useful.
By: Torrey Searle (tsearle) 2010-05-05 09:28:08

ok,

combined the code, so dadhi_pcap3.c should be able to capture both ISDN and SS7 traffic.  I now hand it over to the dahdi community to test the ISDN part of it (and make any improvements :-) )
By: Sverker Abrahamsson (sverker) 2010-05-16 18:10:59

Hi,
I get the following output with this patch when starting dahdi:

Unrecognized garbage '???' in I??
Unrecognized garbage '???' in I??
Unrecognized garbage '???' in I??
Unrecognized garbage '???' in I??
Unrecognized garbage '???' in I??
Unrecognized garbage '???' in I??
Unrecognized garbage '???' in I??
Unrecognized garbage '???' in I??
Unrecognized garbage '???0' in I??

them the computer crashes and is automatically rebooted by watchdog.
By: Torrey Searle (tsearle) 2010-05-17 01:08:51

be sure to do a make clean/make install whe compiling the kernel module as the patch changes the sizes of certian structures.
By: Torrey Searle (tsearle) 2010-05-17 02:24:42

seems that trying to autodetect ss7 vs isdn didn't work
Made the protocol now a command line parameter (in dahdi_pcap4.c)

for ss7 pcaps do

./dahdi_pcap mtp2 16 47 test.pcap

for isdn put lapd as the first parameter
./dahdi_pcap lapd 16 47 test.pcap
By: Sverker Abrahamsson (sverker) 2010-05-17 03:05:13

Hi,
I build the package as a rpm so it's always a clean compile. I applied it on dahdi 2.3.0 on a 2.6.18 kernel (latest from Redhat)
By: Torrey Searle (tsearle) 2010-05-17 04:24:51

Am I correct in understanding that it is crashing on loading the kernel module dahdi?

For me it's not normal that you should experience crash on loading of the module, it's logic only gets invoked when you run dahdi pcap.

Try compiling the source by hand,
for me I used
dahdi-trunk revision 7722
and kernel 2.6.26

What type of card are you trying to use, and are you trying to do ss7 or ISDN?  Bad things would probably happen if you tried to use this on an FXO/FXS card...
By: Sverker Abrahamsson (sverker) 2010-05-17 05:12:40

Hi,
no I don't think it's on loading the module but when some initialization is done. I'm not sure what the startup script does, but this is the end of the output:

Unrecognized garbage '???1' in I??
Running dahdi_cfg:  DAHDI_CHANCONFIG failed on channel 1: Invalid argument (22)
Did you forget that FXS interfaces are configured with FXO signalling
and that FXO interfaces use FXS signalling?
By: Torrey Searle (tsearle) 2010-05-17 06:49:25

The patch will not work on analog interfaces.

If you would like to provide a patch to detect and self-disable on analog equipment it would be most appreciated :-)
By: Sverker Abrahamsson (sverker) 2010-05-17 07:00:08

No, it's a Sangoma A102E card, i.e. 2*E1.
By: Torrey Searle (tsearle) 2010-05-17 07:16:07

In the case of sangoma, after re-compiling dahdi, you need to do a clean recompile the sangoma driver... (it uses some dahdi includes that get modified in the patch)


By: Sverker Abrahamsson (sverker) 2010-05-17 07:26:40

Yes, that could be the issue. I'll report back on the results.
By: Torrey Searle (tsearle) 2010-05-17 07:27:42

example:

wanrouter stop
(from wanpipe directory)
make clean
make dahdi DAHDI_DIR=/src/to/patched/dahdi
make install
wanrouter start
/etc/init.d/dahdi start
By: Sverker Abrahamsson (sverker) 2010-05-17 09:06:07

It works much better now, no crash on starting at least

May I suggest to use getopts to parse command line btw instead of being dependant on the order? It's pretty simple, I could even do the change if you agree.
By: Torrey Searle (tsearle) 2010-05-17 09:36:38

Any improvements are appreciated, just remember that you need to be able to support specifying multiple channels on the command line, other than that I only suggest to not make the command line too long (allow options to be omittied)

Cheers!
By: Sverker Abrahamsson (sverker) 2010-05-18 05:35:17

Hi,
I've implemented options now as well as solved some compiler warnings. The result is uploaded as dahdi_pcap-v5.c as well as a patch which also include the changes needed for makefile. This is the usage:

Usage: dahdi_pcap [OPTIONS]
Capture packets from DAHDI channels to pcap file

Options:
 -p, --proto=[mtp2|lapd] The protocol to capture, default mtp2
 -c, --chan=<channels>   Comma separated list of channels to capture from, max 16. Mandatory
 -f, --file=<filename>   The pcap file to capture to. Mandatory
 -h, --help              Display this text
By: Torrey Searle (tsearle) 2010-05-19 02:39:41

uploaded a new version:
just cleanups, just removed some more useless auto-detection code
also modified the print statement to only count packets written to a file

sverker: thanks for your cleanups it looks really nice :-)
By: Horacio Peña (horape) 2010-05-21 16:56:54

Is there any way to make it work with sangoma cards? It works fine with digium cards but don't work on sangoma ones.
By: Sverker Abrahamsson (sverker) 2010-05-21 16:59:26

I use it with sangoma card. As tsearle points out it's neccesary to rebuild wanpipe after applying this patch.
By: Horacio Peña (horape) 2010-05-25 08:12:25

It fails when using sangoma hardware hdlc (nothing is received) Letting dahdi drivers made the hdlc coding solves the problem. Thanks.
By: Torrey Searle (tsearle) 2010-05-26 01:51:07

are you using ss7 or isdn signaling?  If ss7 how did you configure the hardware HDLC?

Torrey
By: Horacio Peña (horape) 2010-05-27 13:04:11

ISDN
By: Anton Vazir (vazir) 2010-09-25 06:44:57

Torrey, do you think this patch will not add too much extra CPU load?
By: Torrey Searle (tsearle) 2010-09-27 03:43:29

I don't think so,  when dahdi_pcap is not running there is 0 overhead...
By: Shaun Ruffell (sruffell) 2010-10-05 18:14:16

I looked at just the kernel part of the patches, and it isn't immediately clear to me what they provide that isn't already done by the existing conferencing ioctls.  

For example, if you look at dahdi_monitor, you will see it opens a pseudo and drops it into a conference with the channel to be monitored (via DAHDI_CONF_MONITOR/DAHDI_CONF_MONITORTX/DAHDI_CONF_MONITORRX confmodes) in order to achieve what I believe is the same effect as the new DAHDI_TXMIRROR / DAHDI_RXMIRROR ioctls.

Couldn't dahdi_pcap be modified to use the same method dahdi_monitor uses in order to get the channel data?
By: Torrey Searle (tsearle) 2010-10-06 02:15:15

I looked at the the DAHDI_CONF_MONITOR first but as far as I can tell, while it does a good job for capturing audio data, it doesn't work for capturing signaling channels.  Of course if I'm wrong in my understanding of this please let me know :-)

Thanks for the feed back!
By: Shaun Ruffell (sruffell) 2010-10-06 10:31:49

tsearle:  I stand corrected.  I see how DAHDI_SETCONF only works for channels in audio mode currently (on line 4846 of http://svn.asterisk.org/view/dahdi/linux/trunk/drivers/dahdi/dahdi-base.c?revision=9423&view=markup)

What about adding a flag (like DAHDI_CONF_PSEUDO_LISTENER etc..) to bypass that check?   That way we could still use the existing monitoring apparatus?  It could be DAHDI_CONF_NONAUDIOCHANNELS (or something...)
By: Torrey Searle (tsearle) 2010-10-06 11:21:38

It has been a quite a long time since I've looked at the code, but I think that's still not good enough

This is how Monitoring is being done


       case DAHDI_CONF_MONITORTX: /* Monitor a channel's tx mode */
             /* if a pseudo-channel, ignore */
           if (ms->flags & DAHDI_FLAG_PSEUDO) break;
           /* Add monitored channel */
           if (chans[ms->confna]->flags & DAHDI_FLAG_PSEUDO) {
               ACSS(getlin, chans[ms->confna]->putlin);
           } else {
               ACSS(getlin, chans[ms->confna]->getlin);
           }


It's doing both audio mixing (nasty) from a linear audio buffer (which I doubt is populated in the case of a signaling channel

and as the process is done in __dahdi_process_getaudio_chunk  I doubt the could would be even reached in the case of a signaling channel.

Likewise the tx monitoring is done by


       case DAHDI_CONF_MONITORTX:  /* Monitor a channel's tx mode */
             /* if not a pseudo-channel, ignore */
           if (!(ms->flags & DAHDI_FLAG_PSEUDO)) break;
           /* Add monitored channel */
           if (chans[ms->confna]->flags & DAHDI_FLAG_PSEUDO) {
               ACSS(putlin, chans[ms->confna]->putlin);
           } else {
               ACSS(putlin, chans[ms->confna]->getlin);
           }

in the method

__dahdi_process_getaudio_chunk



so I don't think this logic is very reusable for signaling... :-(
By: Shaun Ruffell (sruffell) 2010-10-07 12:36:14

I see what you mean.  What I'm thinking now is that DAHDI_CONF_DIGITALMON does something similar to this already, but doesn't quite work because you need two psuedo channels (one for tx on the monitored channel and one for rx).  But the actual code in the driver does what we want (and direct copy without going through the companding step).

So I'm currently thinking that tweaking the conferencing interface to allow specifying whether you want to digitally monitor just the tx or rx interface would be better in the long run because a new concept (channel mirroring) is not introduced and no new fields would need to be added to 'struct dahdi_chan'.  What do you think?  If you agree, I think the burden's on us to come up with a patch that will still allow dahdi_pcap.c to work but via DAHDI_SETCONF ioctl (but some additional mode/flag bits).


By: Torrey Searle (tsearle) 2010-10-08 07:55:25

I agree that DAHDI_CONF_DIGITALMON is closer to what is needed, but isn't it also true that __dahdi_process_getaudio_chunk and __dahdi_process_getaudio_chunk only are called for audio channels?  I'm not sure the conferencing code would even be reached in the case of signaling channels...
By: Shaun Ruffell (sruffell) 2010-10-08 20:48:08

tsearle:  Yes, but perhaps that shouldn't be the case when digitally monitoring the channel.  However,  I see what you're saying and understand why you added the mirroring IOCTLS.

I'll see if it's possible to tweak things in order to get the data from the signaling channel without adding a new concept to the interface but I'll probably need to go through the exercise at this point before I can debate any relative merits with you :)
By: Russ Meyerriecks (rmeyerriecks) 2010-11-11 13:35:15.000-0600

tsearle: We have future plans for revamping the conferencing logic in DAHDI. I think that if we add this patch as-is it would complicate future cleanups. So, I think it would be best to merge in the code as experimental and behind a build flag. sruffell and I have reworked the patch a bit and re-attached it to the issue for review as dahdi_mirror.patch
By: Torrey Searle (tsearle) 2010-11-15 10:45:21.000-0600

ok, I tried doing a quick test in the lab with this patch on the latest svn, however it seems like it's only capturing FISU message for some reason.... I'm at a lost as to why.... looking into it though....
By: Torrey Searle (tsearle) 2010-11-17 04:43:31.000-0600

Ok, I've uploaded a modified version of your patch that properly captures the packets.  Thank you very much for your time :-)
By: Digium Subversion (svnbot) 2010-11-19 11:34:26.000-0600

Repository: dahdi
Revision: 9491

U   linux/trunk/drivers/dahdi/dahdi-base.c
U   linux/trunk/include/dahdi/kernel.h
U   linux/trunk/include/dahdi/user.h

------------------------------------------------------------------------
r9491 | rmeyerriecks | 2010-11-19 11:34:25 -0600 (Fri, 19 Nov 2010) | 11 lines

dahdi: adding ss7 pcap support to dahdi.

Adding the patch from the issue with various fixups to fit style and
checkpatch

(issue DAHLIN-176)
Reported by: tsearle
Patches:
     driver_v2.patch uploaded by tsearle (license 373)
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=9491
By: Digium Subversion (svnbot) 2010-11-19 11:34:37.000-0600

Repository: dahdi
Revision: 9493

U   linux/trunk/drivers/dahdi/dahdi-base.c
U   linux/trunk/include/dahdi/dahdi_config.h

------------------------------------------------------------------------
r9493 | rmeyerriecks | 2010-11-19 11:34:36 -0600 (Fri, 19 Nov 2010) | 8 lines

dahdi: Stops junk data from overwriting the dahdi_mirror pseudo chans

(issue DAHLIN-176)
Reported by: tsearle
Patches:
     dahdi_mirror2.patch uploaded by tsearle (license 373)
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=9493
By: Digium Subversion (svnbot) 2010-11-19 11:34:43.000-0600

Repository: dahdi
Revision: 9494

U   linux/trunk/drivers/dahdi/dahdi-base.c

------------------------------------------------------------------------
r9494 | rmeyerriecks | 2010-11-19 11:34:42 -0600 (Fri, 19 Nov 2010) | 9 lines

dahdi: Fixup prior dahdi_mirror patch

Reworking tsearle's patch to fit with coding guidelines and make
process_masterspan a bit easier to read.

(closes issue DAHLIN-176)
Reported by: tsearle
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=9494