Project

General

Profile

Actions

Bug #5824

open

Line dead message in the log after start

Added by performer about 1 year ago. Updated 2 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
12/12/2022
Due date:
% Done:

0%

Spec Reference:

Description

In half cases I have next message in the log:
<0000> intf_line.c:95 (I0:L0) Received Only 0 bytes/s (expected: 262144): Line dead?

Also no traffic on client socket. Restart of e1d helps.

Actions #1

Updated by laforge 7 months ago

  • Status changed from New to Feedback
  • Assignee set to performer

sorry for the ultra-late response. Somehow I didn't notice it back then when you filed it, and as it was not assigned to anyone, it got unnoticed.

In all my work with icE1usb / osmo-e1d I didn't see this kind of behaviour. Can you please clarify which version of the gateware/firmware and osmo-e1d you're using? Also, are you seeing any strange messages in dmesg / kernel log when this happens?

If this still happens and you observe it, please do a short strace on the osmo-e1d process and post it here as attachment so we can see what is happening.

Actions #2

Updated by performer 7 months ago

Thank you for response )

I've tried with next version:

smo-e1d> show version
osmo-e1d 0.4.0.1-6cd9-dirty (osmo-e1d).
(C) 2019-2022 by Sylvain Munaut, Harald Welte and contributors

osmo-e1d> show interface
Interface #0 (***), Driver: usb
 GPS-DO: mode=DISABLED, fix=FALSE, state=DISABLED antenna=UNKNOWN, tune=0/0, freq_est=0

# lsusb -d 1d50:6145 -v 2> /dev/null | grep bcd
  bcdUSB               2.00
  bcdDevice            0.03
        bcdDFUVersion                   1.01

Actions #3

Updated by performer 7 months ago

Thank you for response )

I've tried with next version:

osmo-e1d> show version
osmo-e1d 0.4.0.1-6cd9-dirty (osmo-e1d).
(C) 2019-2022 by Sylvain Munaut, Harald Welte and contributors

osmo-e1d> show interface
Interface #0 (***), Driver: usb
 GPS-DO: mode=DISABLED, fix=FALSE, state=DISABLED antenna=UNKNOWN, tune=0/0, freq_est=0

performer wrote in #note-2:

Thank you for response )

I've tried with next version:
[...]

Actions #4

Updated by laforge 3 months ago

Sorry again for no follow-up. As long as the issue is in state "feedback" and assigned to you (and not to me!) I will not see it when looking at "my issues". Please always assign back to me if you want some input from me.

Is this still a problem? I think we need more details about your setup to understand. Did you try on any other computer or linux version? I there anything non-standard about your setup (like VMs, ...)? What USB host controller (see lspci) on what kind of computer are you experiencing this?

Actions #5

Updated by performer 3 months ago

I have no permissions to reassign issue here.

We used different hardware, mostly RasPi 3, 4, CM4 with current release of Raspberian and x86-64 running Ubuntu. Also I‘ve tried to use Debian 11 VM unter Parallels on Intel Mac.

We have to retest it again with fresh versions.

Btw, here is our usage description - https://wiki.tetrapack.online/books/tetra/page/e1t1-interface

Actions #6

Updated by laforge 3 months ago

On Sun, Dec 03, 2023 at 02:53:27PM +0000, performer wrote:

I have no permissions to reassign issue here.

thanks for reporting this. It seems the permission to edit your own issue was not present
for a non-member of the project. fixed now. Sorry for the related inconvenience.

We used different hardware, mostly RasPi 3, 4, CM4 with current release of Raspberian and x86-64 running Ubuntu. Also I‘ve tried to use Debian 11 VM unter Parallels on Intel Mac.

this is rather strange as we have a number of users of icE1usb on a variety of hardware (including rpi3/4) and nobody has so far reported any related issue.

Are you sure the E1 line is not actually dead? Normally this error should only happen if there is no E1
signal, i.e. no E1 bit clock received from the equipment attached to the port (tetra BTS in your case). It
should resolve by itself as soon as a signal is received on the port. You can normally provoke this by
un-plugging the cable (error messages about dead link start) and re-plugging it (error messages about dead link stop).

Actions #7

Updated by performer 3 months ago

laforge wrote in #note-6:

Are you sure the E1 line is not actually dead? Normally this error should only happen if there is no E1
signal, i.e. no E1 bit clock received from the equipment attached to the port (tetra BTS in your case).

5 different e1usb devices cannot have dead the same E1 line simultaneously :)

It starts to work after restart (or several restarts) of e1d. I made a workaround that detects availability of traffic on unix-socket and restarts a daemon.

#!/bin/bash

PREFIX=/opt/TetraPack

for INSTANCE in $(ls $PREFIX/*.env | xargs basename -s .env)
do
  SERVICE=dummy\@$INSTANCE
  STATE=$(systemctl show $SERVICE --property=ActiveState)
  STATE=${STATE#*=}

  if [ "$STATE" == "failed" ] || [ "$STATE" == "deactivating" ]
  then
    systemctl status $SERVICE | grep "E1 connection timeout" > /dev/null
    if [ $? -eq 0 ]
    then
      RESTART=true
    fi
  fi
done

if [ "$RESTART" == "true" ]
then
  echo Restarting Osmo E1D
  systemctl restart osmo-e1d
fi
[Service]
; system.service
ConditionPathExists=/tmp/osmo-e1d.ctl
ExecStartPre=+/bin/chmod o+rw /tmp/osmo-e1d.ctl
ExecStopPost=+/opt/TetraPack/failure.sh
Actions #8

Updated by performer 3 months ago

  • Assignee changed from performer to laforge
Actions #9

Updated by laforge 3 months ago

Hi performer,

On Sun, Dec 03, 2023 at 06:23:06PM +0000, performer wrote:

5 different e1usb devices cannot have dead the same E1 line simultaneously :)

Does this only occur with one specific vendor/model of E1 equipment (Tetra BTS in your case), or
have you seen this also when connecting to other equipment? It might be that the Tetra BTS
stops generating a valid E1 signal for some time. I'm just guessing here.

A good test case would be to use a loopback cable that feeds the Tx pair of the RJ45 back to the
Rx pair of the same RJ45 connector. In this case, the icE1usb will receive anything it
transmits. If the problem still occurs in that situation, we are sure it is not related to
the behaviour of external equipment.

Actions #10

Updated by performer 3 months ago

That occurs only on start of e1d and never happen when BTS (Motorola CTS, it seems Harald has it on his storage) connected to another DTMoIP equipment.
Will check with EBTS when get it.

Actions #11

Updated by performer 2 months ago

Latest versions of E1D and icE1usb behave much more stable. Using versions of 23.12.23
Now both CTS and EBTS are rock stable connected to Raspberry CM4 under Debian 12

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)