Bug #5824
openLine dead message in the log after start
0%
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.
Updated by laforge about 1 year 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.
Updated by performer about 1 year 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
Updated by performer about 1 year 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:
[...]
Updated by laforge 9 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?
Updated by performer 9 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
Updated by laforge 9 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).
Updated by performer 9 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
Updated by laforge 9 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.