libosmogb is an anomaly since it has its headers in osmocom/gprs
directory instead of osmocom/gb. This is really confusing for users.
Furthermore, libosmo-gprs is also using osmocom/gprs, which will create
even more confusion.
This patch moves all existing osmocom/gprs/ header files under
osmocom/gb/ directory (except the backward-compat ones which were
added pointing to the ones in osmocom/gsm/).
Next, new files are added in osmocom/gprs/ replacing the ones that used
to be tehre, with a pragma message announcing deprecating and asking
users to use the new path instead.
This allows keeping old applications working, while announcing
deprecation of the old osmocom/gprs/ patch and have all new development
happen under osmocom/gb/.
Change-Id: I6e826775552766e34e4c06fe2390084596dfc286
Rename contrib/struct_endianess.py to contrib/struct_endianness.py, and
fix the typo everywhere. This is in preparation to call the script in
CI on all repositories.
Related: OS#5884
Change-Id: Idc4af9098ba1de26243464c772d6ea8be330646a
When doing a "show ns", let's also dump the state of the frame
relay network, with all its links and DLCs (if any).
Change-Id: I798af3e97dc014b6e0fcde86560a1809852f7510
Related: OS#4877
Fix the encoding of the asynchronous Q.933 STATUS message
we send at DLC creation time.
Change-Id: Id1460ffa6266be85f44579c447421eed12481b02
Closes: OS#5010
this is a bit of a hack. Q.933 explicitly forbids either side from ever
sending a sequence number of '0'. Values start from '1' and are modulo 256,
but '0' is always skipped. So if the peer is sending us a "last received
sequence number of '0' it means it has not yet received any packets from us,
which in turn can only mean that it has just been restarted. Let's treat
this as "service affecting condition" and notify upper layers. This helps
particularly in recovering from rapidly re-starting peers, where the Q.933
nor NS have time to actually detect the connection was lost.
Change-Id: I960a7b17f2550cb49a7b9d72ed87cd271bb64122
Related: OS#4974
If we receive messages for a DLC which has not yet reported as being
available by Q.933 LMI, drop the incoming message. Otherwise we would
dispatch it to the user, and the user wants to respond - but then
we reject the transmission due to the inactive DLC.
Change-Id: Ia4a045fdf165b526f429f4617e0fdc76036480bd
Related: OS#4999
If we are the 'user' side of FR and a link has just recovered,
we should ensure the next STATUS is for "full status". This way
we learn about the present DLCs as quickly as possible, saving up
to 10 seconds of further delay in link recovery.
Related: OS#4999
Change-Id: I6f905a18a7d130a3c02b4a3e7a2a2dc24afc0ea1
Add support for frame relay over dahdi hdlc device.
It's supporting lmi by q933 and supports both
SGSN and BSS.
Change-Id: Id3b49f93d33c271f77cd9c9db03cde6b727a4d30
Pau Espin
Oliver Smith
Daniel Willmann
Harald Welte
Alexander Couzens