E1 line debug L1/L2

historical

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 at 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 at osmocom.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201009/e867b671/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bsc.insite.cfg
Type: application/octet-stream
Size: 1393 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201009/e867b671/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2020005-insite.pcap
Type: application/octet-stream
Size: 4819 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201009/e867b671/attachment-0001.obj>