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
Hi Philipp,
while reading your comments to:
https://gerrit.osmocom.org/c/osmo-bsc/+/19670https://gerrit.osmocom.org/c/osmo-mgw/+/20250
I realized that it would be better to discuss here.
My initial idea was that the absence of attributes (in the command
definition and thus in the VTY reference) implicitly indicates that a
given VTY command in the 'config' node comes into effect immediately.
This way we would only need to add attributes to commands requiring
program restart or reestablishment of some link(s) / connection(s).
However, in some applications *most* of the commands may require full
program restart. Or the opposite: most commands may apply immediately.
Adding same attributes to every command is annoying, so I came up with a
concept of default 'applies when' policy: what if we add a new field to
'struct cmd_node' indicating default attributes of all commands
belonging to it?
struct cmd_node foo_node = {
.node = FOO_NODE,
.prompt = "%s(config-net)# ",
.vtysh = 1,
.usrattr = (1 << FOO_VTY_ATTR_RESTART_FULL), // (!)
};
This way a DEFUN() command definition would inherit foo_node.usrattr,
and a DEFUN_USRATTR() command definition would override it.
dexter wrote:
> I just wonder if there could be a VTY_ATTR_RESTART_FULL predefined in
> libosmore. Almost any of the osmo program will need it. Maybe also an
> VTY_ATTR_RESTART_IMMEDIATE?
ACK. I think they could be even moved to generic attributes:
/*! Attributes (flags) for \ref cmd_element */
enum {
CMD_ATTR_DEPRECATED = (1 << 0),
CMD_ATTR_HIDDEN = (1 << 1),
CMD_ATTR_APPLY_IMMEDIATE = (1 << 2),
CMD_ATTR_APPLY_FULL_RESTART = (1 << 3),
};
dexter wrote:
> Maybe we could have some standard letters defined in libosmocore
> for standard situations:
> F = Full restart required
> I = Applied Immediately
ACK. We can also agree that generic (pre-defined) attributes use upper
case letters, while the application specific ones use lower case?
What do you think about these ideas? If you agree, and nobody has any
objections, I can quickly implement them in libosmocore. Would be also
nice to know what other developers think. Neels, Harald, Pau, Daniel?
Best regards,
Vadim.
--
- Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Dear all,
I did a major upgrade from the (unsupported) 2.16.x gerrit version to the latest
3.2.x series.
For a detailed list of changes, please see the documentation / changelog.
At least one change affects our day-to-day usage: How to push to a 'tpopic'.
While in the past we would have done something like
git push gerrit HEAD:refs/for/master/fr
we now need to write
git push gerrit HEAD:refs/for/master%topic=fr
Don't ask me why that change was made...
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
