Hello all,
Brief question. Is it possible to debug E1 line by connecting it to the 2nd port of the same NIC making a wired loop? Is it enough to open->ioctl->read from /dev/dahdi/channel to get a stream of LAPD SABME messages transmitted by BSC?
A bit more details for those interested
I'm still trying to bring up BTS Nokia Flexi with OSMO-BSC. I'm using an E1 card Digium TE405P on the server side. OSMO-BSC is connected with Nokia BTS via a single E1 line. Looks like on Level1 everything is ok because BTS can detect the link and raise an alarm if the wire is getting disconnected. I can observe some data from timeslots on BTS side and if some channel is configured as D-Channel in /etc/dahdi/system I see transmission of block "01111110". But the problem is that LAPD link is not establishing. I can't find any tries on BTS side and BSC does not receive anything from BTS, just set of SABME messages in PCAP file. T200 expires and so on. I tried various T200 values. So, now it looks for me like L1 does not receive anything from L2 on BSC side and nothing is transmitted over the wire to BTS.
dahdi_tool shows status "OK"
So, my nearest plan to check data transmission over wired loopback.
Thank you Babanov Ivan
Recent osmo-bsc accept a 'pcap' argument under the e1_input config.
e1_input pcap /tmp/e1.pcap e1_line 0 driver dahdi
This will record all E1 traffic in that pcap for analysis with wireshark.
Cheers,
Sylvain
Hi Ivan,
On Thu, Oct 08, 2020 at 01:14:03AM +0300, Ivan Babanov wrote:
Brief question. Is it possible to debug E1 line by connecting it to the 2nd port of the same NIC making a wired loop?
well, you would normally need a series resistor for the tapping port, you cannot just put them in parallel without signal degradation.
You can check https://osmocom.org/projects/e1-tap/wiki for a small OSHW device that has the series resistors built in, and which provides two tap ports (one for each direction). For full-duplex sniffing of one E1 line, you obviously need two other ports.
Is it enough to open->ioctl->read from /dev/dahdi/channel to get a stream of LAPD SABME messages transmitted by BSC?
not /dev/dahdi/channel. On that device you need a special ioctl.
you could look into osmo-e1-recorder, if you wanted to do tracing with DAHDI ports behind a osmo-e1-tap.
I'm still trying to bring up BTS Nokia Flexi with OSMO-BSC.
great.
I'm using an E1 card Digium TE405P on the server side. OSMO-BSC is connected with Nokia BTS via a single E1 line. Looks like on Level1 everything is ok because BTS can detect the link and raise an alarm if the wire is getting disconnected.
great.
I can observe some data from timeslots on BTS side and if some channel is configured as D-Channel in /etc/dahdi/system I see transmission of block "01111110".
that's the flag octets
But the problem is that LAPD link is not establishing. I can't find any tries on BTS side and BSC does not receive anything from BTS, just set of SABME messages in PCAP file.
That's somewhat of a contradiction.
* SABME is the first frame used to establish a LAPD data link * it should be sent from BTS to BSC * the BSC responds with UA
T200 expires and so on. I tried various T200 values. So, now it looks for me like L1 does not receive anything from L2 on BSC side and nothing is transmitted over the wire to BTS.
it would be useful to see your configs. I would guess most likely you didn't select the same timeslot for signaling on both sides.
Hello Harald, I'm attaching config and pcap. Hopefully mailserver allows attachments. Regarding SABME message it's correct behaviour, I checked twice, BSC initializes link establishment and BTS responds with UA
Today I was digging in dahdi-linux docs again and I see that it uses BKL mechanisms in the kernel. Is it still valid? Because BKL was removed from kernels starting from 2.6.39 Looks like I need to re-build kernel with BKL enabled (if it's possible. Not sure if it's possible). Other solution is to install CentOS6 it uses kernels 2.6.x What linux kernel do you use on your server with dadhi E1 adapters?
Thank you Babanov Ivan
чт, 8 окт. 2020 г. в 20:30, Harald Welte laforge@osmocom.org:
Hi Ivan,
On Thu, Oct 08, 2020 at 01:14:03AM +0300, Ivan Babanov wrote:
Brief question. Is it possible to debug E1 line by connecting it to the
2nd
port of the same NIC making a wired loop?
well, you would normally need a series resistor for the tapping port, you cannot just put them in parallel without signal degradation.
You can check https://osmocom.org/projects/e1-tap/wiki for a small OSHW device that has the series resistors built in, and which provides two tap ports (one for each direction). For full-duplex sniffing of one E1 line, you obviously need two other ports.
Is it enough to open->ioctl->read from /dev/dahdi/channel to get a stream of LAPD SABME messages
transmitted
by BSC?
not /dev/dahdi/channel. On that device you need a special ioctl.
you could look into osmo-e1-recorder, if you wanted to do tracing with DAHDI ports behind a osmo-e1-tap.
I'm still trying to bring up BTS Nokia Flexi with OSMO-BSC.
great.
I'm using an E1 card Digium TE405P on the server side. OSMO-BSC is connected with Nokia BTS via a single E1 line. Looks like on Level1 everything is ok because BTS can detect the link and raise an alarm if the wire is getting disconnected.
great.
I can observe some data from timeslots on BTS side and if some channel is configured as D-Channel in /etc/dahdi/system I see transmission of block "01111110".
that's the flag octets
But the problem is that LAPD link is not establishing. I can't find any tries on BTS side and BSC does not receive anything from BTS, just set of SABME messages in PCAP file.
That's somewhat of a contradiction.
- SABME is the first frame used to establish a LAPD data link
- it should be sent from BTS to BSC
- the BSC responds with UA
T200 expires and so on. I tried various T200 values. So, now it looks for me like L1 does not receive anything from L2 on BSC side and nothing is transmitted over the wire to BTS.
it would be useful to see your configs. I would guess most likely you didn't select the same timeslot for signaling on both sides.
--
- Harald Welte laforge@osmocom.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Ivan,
On Fri, Oct 09, 2020 at 10:51:02PM +0300, Ivan Babanov wrote:
Regarding SABME message it's correct behaviour, I checked twice, BSC initializes link establishment and BTS responds with UA
I never worked a lot with Nokia, so you may be right. In the 3GPP specs (and as implemented in Siemens), the BTS initiates the data link to the BSC.
Today I was digging in dahdi-linux docs again and I see that it uses BKL mechanisms in the kernel. Is it still valid? Because BKL was removed from kernels starting from 2.6.39
I'm not sure what you are referring to. I have kernels up to 5.8.0 running with DAHDI without any problems.
What linux kernel do you use on your server with dadhi E1 adapters?
mostly whatever version Debian 10 (amd64) ships. I then build DAHDI for that kernel from source. https://github.com/osmocom/dahdi-linux has a few fixes for recent kernel versions that upstream doesn't yet have merged to master. But if upstream compiles on your kernel, you don't need those patches.
Hi Ivan,
from your config:
timeslot 0 phys_chan_config CCCH+SDCCH4 e1 line 0 timeslot 2 sub-slot full timeslot 1 phys_chan_config SDCCH8 e1 line 0 timeslot 2 sub-slot 1 timeslot 2 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 2 timeslot 3 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 3 timeslot 4 phys_chan_config TCH/F
you cannot use e1 line 0 timeslot 2 as a full slot for signaling, and at the same time use it as 16k channelized sub-slots. That's clearly wrong. I just realized that the example config also does that. I guess we simply never use the 'e1 line ...' setting for a CCCH+SDCCH slot, as they always go via the RSL link configured in the TRX.
The pcap file shows that OsmoBSC is sending SABME requests but that the BTS never responds to any of them. I would assume that somehow the timeslot configuration on BTS and BSC side don't agree, i.e. you're sending the SABME on a timeslot that the BTS doesn't expect it on.
I remember that the E1 related configuration on the Noika BTS (at least the InSite) is relatively complex. Might be best to check all related settings.
Hello Harald,
Thank you for your responses. I'll change configs with slot-overlapping but looks like I'm quite far from getting it to work. Today I found that I have "kernel: wct4xxp 0000:03:02.0: Interrupts not detected." in syslog. This line was visible only if I load modules manually (not via systemctl start dahdi) I heard that it happens on some hardware with Digium cards, I'll try tomorrow to change PCI slot to avoid sharing one IRQ with USB devices, maybe disable USB at all. If it doesn't help, I'll try a new server with different HW. Now it seems a root cause of the most of problems with communication between BSC and BTS
Thank you Babanov Ivan
сб, 10 окт. 2020 г. в 18:50, Harald Welte laforge@gnumonks.org:
The pcap file shows that OsmoBSC is sending SABME requests but that the BTS never responds to any of them. I would assume that somehow the timeslot configuration on BTS and BSC side don't agree, i.e. you're sending the SABME on a timeslot that the BTS doesn't expect it on.
I remember that the E1 related configuration on the Noika BTS (at least the InSite) is relatively complex. Might be best to check all related settings.
--
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Dear Ivan,
On Mon, Oct 12, 2020 at 12:26:22AM +0300, Ivan Babanov wrote:
I heard that it happens on some hardware with Digium cards, I'll try tomorrow to change PCI slot to avoid sharing one IRQ with USB devices, maybe disable USB at all. If it doesn't help, I'll try a new server with different HW.
I'm sorry but I think you are looking at the wrong level. I doubt that the hardware is the problem.
If you are worried about the hardware/OS/drivers, just use a loopback E1 cable between two ports and run e1-prbs-test (from osmo-e1d/contrib) on both sides to see if you can communicate between two ports. If that works, you can exclude any problems related to hardware or drivers.
If you have connceted span 1 + 2 via loopback, start
in one shell: e1-prbs-test /dev/dahdi/chan/001
in another shell: e1-prbs-test /dev/dahdi/chan/002
and check the stdout to see if they find sync in both direction.
This program sends pseudo-random bit sequences over every timeslot and checks that the correct PRBS sequence arrives on the other side, bidirectionally.
Regards, Harald
Hello Harald!
Today I was able to get hardware working. At least L2 link established and I see OML/NM messages. Files are attached.
Briefly the problem was with ports connections. I did not expected that quad-port card requires all ports to be connected. Everything started to work after I placed dummy loopback connectors to unused ports 3 and 4. After it I was able to check physical link with e1-prbs-test and was able to communicate with BTS.
Thank you Babanov Ivan
пн, 12 окт. 2020 г. в 12:20, Harald Welte laforge@gnumonks.org:
Dear Ivan,
On Mon, Oct 12, 2020 at 12:26:22AM +0300, Ivan Babanov wrote:
I heard that it happens on some hardware with Digium cards, I'll try tomorrow to change PCI slot to avoid sharing one IRQ with USB devices, maybe disable USB at all. If it doesn't help, I'll try a new server with different HW.
I'm sorry but I think you are looking at the wrong level. I doubt that the hardware is the problem.
If you are worried about the hardware/OS/drivers, just use a loopback E1 cable between two ports and run e1-prbs-test (from osmo-e1d/contrib) on both sides to see if you can communicate between two ports. If that works, you can exclude any problems related to hardware or drivers.
If you have connceted span 1 + 2 via loopback, start
in one shell: e1-prbs-test /dev/dahdi/chan/001
in another shell: e1-prbs-test /dev/dahdi/chan/002
and check the stdout to see if they find sync in both direction.
This program sends pseudo-random bit sequences over every timeslot and checks that the correct PRBS sequence arrives on the other side, bidirectionally.
Regards, Harald --
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Ivan,
On Tue, Oct 13, 2020 at 07:07:12PM +0300, Ivan Babanov wrote:
Today I was able to get hardware working. At least L2 link established and I see OML/NM messages.
congratulations! Now the fun part starts.
Briefly the problem was with ports connections. I did not expected that quad-port card requires all ports to be connected. Everything started to work after I placed dummy loopback connectors to unused ports 3 and 4.
This definitely does not reflect my experience with any of the DAHDI quad-port cards I have used so far.
After it I was able to check physical link with e1-prbs-test and was able to communicate with BTS.
Strange. Maybe some bug or problem with the specific model you use, or related to the suspected IRQ trouble, or it is a question of clocking? Maybe the clock reference was configured to (only) use a port that had no signal applied?
-
Harald Welte -
Harald Welte -
Ivan Babanov -
Sylvain Munaut