[Home]

Summary:DAHLIN-00289: te820 and nethdlc issues
Reporter:Max Khon (max khon)Labels:
Date Opened:2012-04-17 05:55:05Date Closed:2012-10-04 15:29:41
Priority:CriticalRegression?
Status:Closed/CompleteComponents:wct4xxp
Versions:2.6.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:CentOS 6.2, kernel 2.6.32-220.7.1.el6Attachments:
Description:1) dahdi is built with #define CONFIG_DAHDI_NET uncommented in
include/dahdi/dahdi_config.h

2) wct4xxp is loaded with default_linemode="e1"

3) /etc/dahdi/system.conf:

span=1,1,0,ccs,hdb3,crc4
nethdlc=1-31

4) hdlc0 Interface is configured as

dahdi_cfg -vv
sethdlc hdlc0 cisco
ifconfig hdlc0 10.0.32.2 pointopoint 10.0.32.1

5) The other end is Cisco 2811 E1 with the following configuration:

controller E1 0/0/0
clock source internal
channel-group 0 timeslots 1-31
!
interface Serial0/0/0:0
ip address 10.0.32.1 255.255.255.128

Symptoms are:

1) E1 is up (no alarms)

2) Cisco sees HDLC keepalive packets sent from the Linux box (yourseen
is not 0), but Linux box does not see Cisco HDLC keep alive packets:
mineseen is 0 -- this is myseq as seen from the remote side, i.e.
Cisco sends myseq to the remote in the Cisco HDLC keepalive packet,
remote replies with Cisco HDLC keepalive packet with the last received
myseq, which is 0 which means that it did not receive any keepalive
packets

*Apr 17 08:45:39.367: Serial0/0/0:0: HDLC myseq 31, mineseen 0*,
yourseen 26, line up
*Apr 17 08:45:49.367: Serial0/0/0:0: HDLC myseq 32, mineseen 0*,
yourseen 27, line down

3) tcpdump shows only outgoing Cisco HDLC keepalive packets on hdlc0:

[root@localhost dahdi-tools-2.6.0]# tcpdump -i hdlc0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on hdlc0, link-type C_HDLC (Cisco HDLC), capture size 65535 bytes
12:56:03.523828 SLARP (length: 18), keepalive: mineseen=0x00000048,
yourseen=0x00000000, reliability=0xffff, link uptime=0d0h48m49s
12:56:13.523688 SLARP (length: 18), keepalive: mineseen=0x00000049,
yourseen=0x00000000, reliability=0xffff, link uptime=0d0h48m59s
12:56:23.523803 SLARP (length: 18), keepalive: mineseen=0x0000004a,
yourseen=0x00000000, reliability=0xffff, link uptime=0d0h49m9s
12:56:33.523812 SLARP (length: 18), keepalive: mineseen=0x0000004b,
yourseen=0x00000000, reliability=0xffff, link uptime=0d0h49m19s

4) If I insert debug logging to __putbuf_chunk I see that "abort" is
always 0 and "eof" is also always 0 right before "if (eof)" check

The same setup (dahdi and cisco config, cabling and everything) works
ok with te420 card.
The same setup works for Linux <-> Linux nethdlc with te420 cards. The
only difference in the configs on the other Linux box is clock source
(should be internal) and IP address (should be other way around).
Comments:By: Max Khon (max khon) 2012-04-17 11:32:39.125-0500

1) Tested between Linux te820 <-> Linux te820 in T1 mode -- the same symptoms (both ends only send and nothing appears on hdlc0)

2) If one of the ends is te420, it both sends and receives:

[root@localhost dahdi-tools-2.6.0]# tcpdump -i hdlc0
...
0:23:08.714846 SLARP (length: 18), keepalive: mineseen=0x00000008, yourseen=0x00000000, reliability=0xffff, link uptime=0d0h14m34s
20:23:14.962918 SLARP (length: 18), keepalive: mineseen=0x00000011, yourseen=0x00000008, reliability=0xffff, link uptime=0d0h14m38s
20:23:18.715507 SLARP (length: 18), keepalive: mineseen=0x00000009, yourseen=0x00000000, reliability=0xffff, link uptime=0d0h14m44s
20:23:24.962920 SLARP (length: 18), keepalive: mineseen=0x00000012, yourseen=0x00000009, reliability=0xffff, link uptime=0d0h14m48s
20:23:28.715175 SLARP (length: 18), keepalive: mineseen=0x0000000a, yourseen=0x00000000, reliability=0xffff, link uptime=0d0h14m54s

Cisco HDLC keepalive packets with non-zero yourseen are sent by local (te420) end, with zero yourseen are received from remote (yourseen is 0 because remote did not receive any of our keepalives).

nethdlc works as expected with the same te420 box with exactly the same config when connected to Cisco 2811 E1 (or another Linux box with te420).
By: Russ Meyerriecks (rmeyerriecks) 2012-05-21 13:44:15.185-0500

I was able to reproduce this issue in the lab.
By: Shaun Ruffell (sruffell) 2012-05-30 17:41:14.777-0500

Max, sorry about the delay on this issue.

I'm not sure exactly what is happening, but I jumped on the machines Russ setup, and it appears that all the spans need to be configured. If you change your /etc/dahdi/system.conf file to the following do you still have problems?

{code}
span=1,1,0,ccs,hdb3,crc4
nethdlc=1-31
span=2,1,0,ccs,hdb3,crc4
span=3,1,0,ccs,hdb3,crc4
span=4,1,0,ccs,hdb3,crc4
span=5,1,0,ccs,hdb3,crc4
span=6,1,0,ccs,hdb3,crc4
span=7,1,0,ccs,hdb3,crc4
span=8,1,0,ccs,hdb3,crc4
{code}

I still plan to look at this to see why this is necessary on our test machines.
By: Max Khon (max khon) 2012-06-14 13:29:26.809-0500

-I tested the workaround with more complex configuration and it did not work. Trying to narrow it down it seems that only the 1st span is working.-

-For example the same problem was reproduced with the following configuration:-

span=1,1,0,ccs,hdb3,crc4
span=2,1,0,ccs,hdb3,crc4
span=3,1,0,ccs,hdb3,crc4
span=4,1,0,ccs,hdb3,crc4
span=5,1,0,ccs,hdb3,crc4
span=6,1,0,ccs,hdb3,crc4
span=7,1,0,ccs,hdb3,crc4
span=8,1,0,ccs,hdb3,crc4
nethdlc=32-62

-The issue is blocking for us.-

Sorry, there was a mistake in my setup. The example above works for me.
By: Shaun Ruffell (sruffell) 2012-06-18 09:14:32.906-0500

Max, just a heads up, I'll be testing this today and post back what I find.  One question though is what is your intended end configuration?
By: Max Khon (max khon) 2012-06-18 11:44:39.214-0500

Ideally we would like to use it in a mixed setup (some spans use nethdlc, others use voice).
By: Shaun Ruffell (sruffell) 2012-06-19 09:38:22.654-0500

{noformat}
root@juliet:~# cat /etc/dahdi/system.conf
span=1,1,0,ccs,hdb3,crc4
span=2,2,0,ccs,hdb3,crc4
span=3,3,0,ccs,hdb3,crc4
span=4,4,0,ccs,hdb3,crc4
span=5,5,0,ccs,hdb3,crc4
span=6,6,0,ccs,hdb3,crc4
span=7,7,0,ccs,hdb3,crc4
span=8,8,0,ccs,hdb3,crc4

clear=32-62
# Global data

loadzone        = us
defaultzone     = us
root@juliet:~# cat /sys/module/dahdi/version
SVN-trunk-r10691
Span 2: TE8/0/2 "T8XXP (PCI) Card 0 Span 2" (MASTER) CCSHDB3//CRC4
       IRQ misses: 1

         32 TE8/0/2/1 Clear Master (EC: VPMOCT256 - INACTIVE)
         33 TE8/0/2/2 Clear (EC: VPMOCT256 - INACTIVE)
         34 TE8/0/2/3 Clear (EC: VPMOCT256 - INACTIVE)
         35 TE8/0/2/4 Clear (EC: VPMOCT256 - INACTIVE)
         36 TE8/0/2/5 Clear (EC: VPMOCT256 - INACTIVE)
         37 TE8/0/2/6 Clear (EC: VPMOCT256 - INACTIVE)
         38 TE8/0/2/7 Clear (EC: VPMOCT256 - INACTIVE)
         39 TE8/0/2/8 Clear (EC: VPMOCT256 - INACTIVE)
         40 TE8/0/2/9 Clear (EC: VPMOCT256 - INACTIVE)
         41 TE8/0/2/10 Clear (EC: VPMOCT256 - INACTIVE)
         42 TE8/0/2/11 Clear (EC: VPMOCT256 - INACTIVE)
         43 TE8/0/2/12 Clear (EC: VPMOCT256 - INACTIVE)
         44 TE8/0/2/13 Clear (EC: VPMOCT256 - INACTIVE)
         45 TE8/0/2/14 Clear (EC: VPMOCT256 - INACTIVE)
         46 TE8/0/2/15 Clear (EC: VPMOCT256 - INACTIVE)
         47 TE8/0/2/16 Clear (EC: VPMOCT256 - INACTIVE)
         48 TE8/0/2/17 Clear (EC: VPMOCT256 - INACTIVE)
         49 TE8/0/2/18 Clear (EC: VPMOCT256 - INACTIVE)
         50 TE8/0/2/19 Clear (EC: VPMOCT256 - INACTIVE)
         51 TE8/0/2/20 Clear (EC: VPMOCT256 - INACTIVE)
         52 TE8/0/2/21 Clear (EC: VPMOCT256 - INACTIVE)
         53 TE8/0/2/22 Clear (EC: VPMOCT256 - INACTIVE)
         54 TE8/0/2/23 Clear (EC: VPMOCT256 - INACTIVE)
         55 TE8/0/2/24 Clear (EC: VPMOCT256 - INACTIVE)
         56 TE8/0/2/25 Clear (EC: VPMOCT256 - INACTIVE)
         57 TE8/0/2/26 Clear (EC: VPMOCT256 - INACTIVE)
         58 TE8/0/2/27 Clear (EC: VPMOCT256 - INACTIVE)
         59 TE8/0/2/28 Clear (EC: VPMOCT256 - INACTIVE)
         60 TE8/0/2/29 Clear (EC: VPMOCT256 - INACTIVE)
         61 TE8/0/2/30 Clear (EC: VPMOCT256 - INACTIVE)
         62 TE8/0/2/31 Clear (EC: VPMOCT256 - INACTIVE)
root@juliet:~#
{noformat}

I'm able to pass patlooptest. This was failing for me before when I only had one span configured. -I do see that when I have the timing configured as you did (all spans set to 1) I have failures- This worked for me whether I had spans configured with timing priority all 1 or not (I had a mistake in my test script before). So I'm not sure what is different between our setups now.  Let me test with nethdlc, but way the data is assigned to the channels is the same.
By: Max Khon (max khon) 2012-06-21 12:59:24.046-0500

Shaun, there was a mistake in my setup. Workaround still works (even if only 2nd span is configured).
By: Russ Meyerriecks (rmeyerriecks) 2012-10-04 15:29:41.736-0500

Patch applied to trunk
http://svnview.digium.com/svn/dahdi?view=revision&revision=10728