| Summary: | DAHLIN-00113: REJ S frame not handled properly | ||
| Reporter: | Tjardick van der Kraan (tjardick) | Labels: | |
| Date Opened: | 2009-06-04 05:17:21 | Date Closed: | 2010-10-08 10:15:27 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | wct4xxp |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Production on a 4 port E1 card starts and after about 30 minutes we start to have problems of receiving cause 34 Circuit or channel unavailable. When analysing the wireshark tracing on the D-channel and looking at the moment the problems starts, we see the following L2 (LAPD) issue: - The asterisk sometimes does not retransmit I frames after receiving a REJ S frame. - The network expects retransmission and in the meanwhile continues to send regular RR S frames with the same R counter - The asterisk – nicely - doesn’t send more than the allowed 7 unacknowledged I frames - The asterisk – less nicely - then starts repeating the 7th one regularly. - If the network resends a REJ S frame, retransmission occurs correctly. As the REJ frame was not handled correctly – or could just have been lost – wouldn’t it be smarter to retransmit the first unacknowledged I frame instead of the last one ? That behavior should meet the expectation of the network even if the REJ frame was not received or handled. ****** ADDITIONAL INFORMATION ****** LibPRI 1.4.10 hardhdlc active | ||
| Comments: | By: Shaun Ruffell (sruffell) 2010-10-08 10:15:27 This issue is pretty stale. But there have been 129 commits to the 1.4 branch of libpri since this issue was opened. I asked Richard Mudgett and he believes it was relatively recently resolved (indirectly perhaps) the SVN. If someone tries the recent libpri and has this problem, please feel free to reopen. | ||