fix(docs): bad character in docs lint

Signed-off-by: Lucas Amaral <[email protected]>

Author: lucaaamaral

readmes/cwf/deploy_install.md

@@ -119,7 +119,7 @@ registered with the Orchestrator.
 
 To register the Carrier Wifi Gateway, go to the Orchestrator's APIdocs in your browser.
 **Note: It is highly encouraged to use V1 of the apidocs**
-(i.e. <https://controller.url.sample:9443/apidocs/v1/>).
+(i.e. \<https://controller.url.sample:9443/apidocs/v1/\>).
 
 Now, create a Carrier Wifi Network. This is found at `/cwf` under the
 **Carrier Wifi Networks** section. Then register the gateway under the

readmes/dp/debug_logs.md

@@ -9,7 +9,7 @@ hide_title: true
 Debugging Domain Proxy usually comes down to checking log content of individual pods. This document describes how to
 access these logs.
 
-## eNB <-> AGW/enodebd
+## eNB \<\-\> AGW/enodebd
 
 To debug the eNB side of Domain Proxy functionality, it typically comes down to inspecting the TR069 session data or
 looking into eNB specific data model/state machine implementation in `enodebd`.
@@ -34,7 +34,7 @@ Given the following log snippet (trimmed) from Baicells QRTB, the normal flow sh
     2022-04-25 15:41:17,549 DEBUG Handling TR069 message: Inform {...}
     2022-04-25 15:41:17,550 DEBUG (Inform msg) Received parameter: Device.DeviceInfo.HardwareVersion = ...
     [Inform msg output continues]
-    2022-04-25 15:41:17,557 DEBUG State transition from <WaitInformState> to <wait_empty>
+    2022-04-25 15:41:17,557 DEBUG State transition from \<WaitInformState\> to \<wait_empty\>
     2022-04-25 15:41:17,558 DEBUG Sending TR069 message: InformResponse {'MaxEnvelopes': '1'}
     ```
 
@@ -43,22 +43,22 @@ Given the following log snippet (trimmed) from Baicells QRTB, the normal flow sh
     ```console
     2022-04-25 15:41:22,608 DEBUG 10.0.2.243 - "POST / HTTP/1.1" 200 419
     2022-04-25 15:41:22,612 DEBUG Handling TR069 message: DummyInput {}
-    2022-04-25 15:41:22,612 DEBUG State transition from <WaitEmptyMessageState> to <check_fw_upgrade_download>
+    2022-04-25 15:41:22,612 DEBUG State transition from \<WaitEmptyMessageState\> to \<check_fw_upgrade_download\>
     12022-04-25 15:41:22,613 DEBUG Skipping FW Download for eNB [XXXXXXXXXXXXX], missing firmware upgrade config in enodebd.yml.
-    2022-04-25 15:41:22,613 DEBUG State transition from <CheckFirmwareUpgradeDownloadState> to <get_transient_params>
-    2022-04-25 15:41:22,613 DEBUG State transition from <SendGetTransientParametersState> to <wait_get_transient_params>
+    2022-04-25 15:41:22,613 DEBUG State transition from \<CheckFirmwareUpgradeDownloadState\> to \<get_transient_params\>
+    2022-04-25 15:41:22,613 DEBUG State transition from \<SendGetTransientParametersState\> to \<wait_get_transient_params\>
     2022-04-25 15:41:22,613 DEBUG Sending TR069 message: GetParameterValues {...}
     2022-04-25 15:41:22,617 DEBUG 10.0.2.243 - "POST / HTTP/1.1" 200 912
     2022-04-25 15:41:22,662 DEBUG Handling TR069 message: GetParameterValuesResponse {...}
     2022-04-25 15:41:22,662 DEBUG Fetched Transient Params: {...}
-    2022-04-25 15:41:22,663 DEBUG State transition from <WaitGetTransientParametersState> to <get_params>
-    2022-04-25 15:41:22,664 DEBUG State transition from <GetParametersState> to <wait_get_params>
+    2022-04-25 15:41:22,663 DEBUG State transition from \<WaitGetTransientParametersState\> to \<get_params\>
+    2022-04-25 15:41:22,664 DEBUG State transition from \<GetParametersState\> to \<wait_get_params\>
     2022-04-25 15:41:22,664 DEBUG Sending TR069 message: GetParameterValues {...}
     2022-04-25 15:41:22,671 DEBUG 10.0.2.243 - "POST / HTTP/1.1" 200 3242
     2022-04-25 15:41:22,718 DEBUG Handling TR069 message: GetParameterValuesResponse {...}
     2022-04-25 15:41:22,719 DEBUG Received CPE parameter values: {...}
-    2022-04-25 15:41:22,719 DEBUG State transition from <WaitGetParametersState> to <get_obj_params>
-    2022-04-25 15:41:22,720 DEBUG State transition from <GetObjectParametersState> to <wait_get_obj_params>
+    2022-04-25 15:41:22,719 DEBUG State transition from \<WaitGetParametersState\> to \<get_obj_params\>
+    2022-04-25 15:41:22,720 DEBUG State transition from \<GetObjectParametersState\> to \<wait_get_obj_params\>
     2022-04-25 15:41:22,720 DEBUG Sending TR069 message: GetParameterValues {...}
     2022-04-25 15:41:22,723 DEBUG 10.0.2.243 - "POST / HTTP/1.1" 200 877
     2022-04-25 15:41:22,769 DEBUG Handling TR069 message: GetParameterValuesResponse {...}
@@ -68,15 +68,15 @@ Given the following log snippet (trimmed) from Baicells QRTB, the normal flow sh
 1. `SetParameterValues` message followed by `GetParameterValues` - conditional, only appears if a configuration change needs to be done on the eNB side. The actual parameters that are set in order to enable transmission based on Domain Proxy grant may differ depending on the eNB model and eNB current configuration state. Please refer to your eNB device model implementation in `lte/gateway/python/magma/enodebd/devices`.
 
     ```console
-    2022-04-25 15:41:22,771 DEBUG State transition from <WaitGetObjectParametersState> to <set_params>`
+    2022-04-25 15:41:22,771 DEBUG State transition from \<WaitGetObjectParametersState\> to \<set_params\>`
     2022-04-25 15:41:22,772 DEBUG Sending TR069 request to set CPE parameter values: {...}`
-    2022-04-25 15:41:22,773 DEBUG State transition from <SetParameterValuesState> to <wait_set_params>`
+    2022-04-25 15:41:22,773 DEBUG State transition from \<SetParameterValuesState\> to \<wait_set_params\>`
     2022-04-25 15:41:22,773 DEBUG Sending TR069 message: SetParameterValues {...}`
     2022-04-25 15:41:22,777 DEBUG 10.0.2.243 - "POST / HTTP/1.1" 200 723`
     2022-04-25 15:41:22,837 DEBUG Handling TR069 message: SetParameterValuesResponse {'Status': '0'}`
     2022-04-25 15:41:22,838 INFO Successfully configured CPE parameters!`
-    2022-04-25 15:41:22,839 DEBUG State transition from <WaitSetParameterValuesState> to <check_get_params>`
-    2022-04-25 15:41:22,840 DEBUG State transition from <GetParametersState> to <check_wait_get_params>`
+    2022-04-25 15:41:22,839 DEBUG State transition from \<WaitSetParameterValuesState\> to \<check_get_params\>`
+    2022-04-25 15:41:22,840 DEBUG State transition from \<GetParametersState\> to \<check_wait_get_params\>`
     2022-04-25 15:41:22,840 DEBUG Sending TR069 message: GetParameterValues {...}`
     2022-04-25 15:41:22,849 DEBUG 10.0.2.243 - "POST / HTTP/1.1" 200 3242`
     2022-04-25 15:41:22,916 DEBUG Handling TR069 message: GetParameterValuesResponse {...}`
@@ -85,13 +85,13 @@ Given the following log snippet (trimmed) from Baicells QRTB, the normal flow sh
 1. Update transmission configuration from Domain Proxy and close TR069 session - `notify_dp` is an `enodebd` transition state that calls the Domain Proxy `GetCBSDState` gRPC API. The `GetCBSDState` response contains data, which indicate whether eNB radio should be disabled/turned off or enabled together with transmission parameters. `GetCBSDState` response data is translated to eNB specific parameters that will be applied to eNB. Please refer to your eNB device model implementation in `lte/gateway/python/magma/enodebd/devices`.
 
     ```console
-    2022-04-25 15:41:22,917 DEBUG State transition from <WaitGetParametersState> to <end_session>
-    2022-04-25 15:41:22,917 DEBUG State transition from <BaicellsQRTBEndSessionState> to <notify_dp>
+    2022-04-25 15:41:22,917 DEBUG State transition from \<WaitGetParametersState\> to \<end_session\>
+    2022-04-25 15:41:22,917 DEBUG State transition from \<BaicellsQRTBEndSessionState\> to \<notify_dp\>
     2022-04-25 15:41:23,046 DEBUG Updating desired config based on sas grant
     2022-04-25 15:41:23,046 DEBUG Sending TR069 message: DummyInput {}
     ```
 
-## AGW/enodebd <-> Domain Proxy
+## AGW/enodebd \<-\> Domain Proxy
 
 ### AGW
 
@@ -100,10 +100,10 @@ To debug AGW communication with Domain Proxy, look for `control_proxy` logs on t
 ```console
 journalctl -xu magma@control_proxy -r
 
-Apr 21 11:58:00 FreedomFi-Gateway control_proxy[1220289]: 2022-04-21T11:58:00.002Z [127.0.0.1 -> dp_service-controller.codistaging.dp.freedomfi.com,8443] "POST /DPService/GetCBSDState
-Apr 21 11:57:55 FreedomFi-Gateway control_proxy[1220289]: 2022-04-21T11:57:54.991Z [127.0.0.1 -> dp_service-controller.codistaging.dp.freedomfi.com,8443] "POST /DPService/GetCBSDState
-Apr 21 11:57:50 FreedomFi-Gateway control_proxy[1220289]: 2022-04-21T11:57:50.044Z [127.0.0.1 -> dp_service-controller.codistaging.dp.freedomfi.com,8443] "POST /DPService/GetCBSDState
-Apr 21 11:57:45 FreedomFi-Gateway control_proxy[1220289]: 2022-04-21T11:57:45.002Z [127.0.0.1 -> dp_service-controller.codistaging.dp.freedomfi.com,8443] "POST /DPService/GetCBSDState
+Apr 21 11:58:00 FreedomFi-Gateway control_proxy[1220289]: 2022-04-21T11:58:00.002Z [127.0.0.1 -\> dp_service-controller.codistaging.dp.freedomfi.com,8443] "POST /DPService/GetCBSDState
+Apr 21 11:57:55 FreedomFi-Gateway control_proxy[1220289]: 2022-04-21T11:57:54.991Z [127.0.0.1 -\> dp_service-controller.codistaging.dp.freedomfi.com,8443] "POST /DPService/GetCBSDState
+Apr 21 11:57:50 FreedomFi-Gateway control_proxy[1220289]: 2022-04-21T11:57:50.044Z [127.0.0.1 -\> dp_service-controller.codistaging.dp.freedomfi.com,8443] "POST /DPService/GetCBSDState
+Apr 21 11:57:45 FreedomFi-Gateway control_proxy[1220289]: 2022-04-21T11:57:45.002Z [127.0.0.1 -\> dp_service-controller.codistaging.dp.freedomfi.com,8443] "POST /DPService/GetCBSDState
 ```
 
 `control_proxy` logs will show if gRPC calls from `enodebd` towards Domain Proxy are made. Since gRPC is binary coded, there isn't much information from tcpdump capture on this end of communication.
@@ -117,7 +117,7 @@ no transmission and the radio transmission must be disabled.
 
 ![DP Logs AGW](../assets/dp/dp_logs_agw_enodebd.png)
 
-## Domain Proxy <-> SAS
+## Domain Proxy \<-\> SAS
 
 Domain Proxy logs of communication with Spectrum Access System (SAS) are visible in NMS: `[Metrics]` menu, `[DP Logs]` tab
 
@@ -147,11 +147,11 @@ domain-proxy-radio-controller-5c868696d9-s7vgg          1/1     Running     0
 To view logs from individual Domain Proxy pods, execute `kubectl logs` with one of the pod names listed in the [previous chapter](#listing-domain-proxy-pods-in-kubernetes).
 
 - `Radio Controller` (RC) logs:
-    - logs related to AGW/enodebd <-> Domain Proxy communication
+    - logs related to AGW/enodebd \<-\> Domain Proxy communication
     - logs related to requests generated by Active Mode Controller (Domain Proxy logic, which generates appropriate SAS requests)
     - logs related with Database modifications, which were the result of incoming API calls (either from AGW or AMC)
 - `Configuration Controller` (CC) logs:
-    - logs related to Domain Proxy <-> SAS communication
+    - logs related to Domain Proxy \<-\> SAS communication
     - logs related with Database modifications, which were the result of processing SAS responses
 - `Active Mode Controller` (AMC) logs:
     - logs related to internal business logic of Domain Proxy functionality

readmes/faq/faq_magma.md

@@ -101,7 +101,7 @@ This section lists some of the commonly asked questions related to Magma operati
 
 ### Where can I get more information about services running in Magma?
 
-- <https://github.com/magma/magma/tree/master/docs/readmes/lte>
+- \<https://github.com/magma/magma/tree/master/docs/readmes/lte\>
 
 ### How can I detach/purge a subscriber from AGW?
 

readmes/feg/deploy_configure.md

@@ -148,7 +148,7 @@ APN will only be applied for the Gx interactions, as the config for Gy is empty.
 
 ### FeG
 
-- Here are the steps to test the FeG <-> Gx/Gy/S6a connections
+- Here are the steps to test the FeG \<-\> Gx/Gy/S6a connections
     - Exec into `session_proxy` container: `docker exec -it session_proxy bash`
     - Run `/var/opt/magma/bin/gx_client_cli`with the following parameters
         - --commands=IT
@@ -161,7 +161,7 @@ APN will only be applied for the Gx interactions, as the config for Gy is empty.
     - Run `/var/opt/magma/bin/gy_client_cli` with the following parameters
         - --commands=IT
         - --addr
-    - Run `/var/opt/magma/bin/s6a_client_cli air <IMSI>`
+    - Run `/var/opt/magma/bin/s6a_client_cli air \<IMSI\>`
         - Example: `/var/opt/magma/bin/s6a_cli air 001010000091111`
 
 ### AGW

readmes/feg/deploy_install.md

@@ -80,9 +80,9 @@ is provided below (please check `magma/feg/gateway/docker/.env` for the most
 # limitations under the License.
 
 COMPOSE_PROJECT_NAME=feg
-DOCKER_REGISTRY=<registry>
-DOCKER_USERNAME=<username>
-DOCKER_PASSWORD=<password>
+DOCKER_REGISTRY=\<registry\>
+DOCKER_USERNAME=\<username\>
+DOCKER_PASSWORD=\<password\>
 IMAGE_VERSION=latest
 GIT_HASH=master
 
@@ -139,7 +139,7 @@ registered with the Orchestrator. At this time, NMS support for FeG
 registration is still in-progress.
 
 To register the FeG, go to the Orchestrator's Swagger UI in your browser.
-(i.e. <https://controller.url.sample:9443/swagger/v1/ui/>).
+(i.e. \<https://controller.url.sample:9443/swagger/v1/ui/\>).
 
 Now, create a Federation Network. This is found at `/feg` under the
 **Federation Networks** section. If you have not registered any gateways before, you

readmes/general/upgrade_intro.md

@@ -12,7 +12,7 @@ This section walks through upgrading different components of the Magma topology.
 
 Orc8r and gateways both follow a SemVer-like versioning of `MAJOR.MINOR.PATCH`, with the following constraints
 
-- Gateway version must be <= Orc8r version
+- Gateway version must be \<= Orc8r version
 - Gateway can diverge at most 1 minor version from Orc8r
 
 For example
@@ -22,7 +22,7 @@ For example
 - ✅ Gateway 1.3.3, Orc8r 1.4.0
 - ✅ Gateway 1.3.3, Orc8r 1.4.10
 - 🚨 Gateway 1.2.0, Orc8r 1.4.0 (more than 1 minor)
-- 🚨 Gateway 1.4.1, Orc8r 1.4.0 (gateway > Orc8r)
+- 🚨 Gateway 1.4.1, Orc8r 1.4.0 (gateway \> Orc8r)
 
 ## Orc8r-gateway upgrade flow
 

readmes/howtos/troubleshooting/agw_unable_to_checkin.md

@@ -88,8 +88,8 @@ Sample control_proxy.yml file
     - Next, using the pod name get the logs from the pod with below command. Check if there is any problematic log for the related pod
 
         ```bash
-        kubectl -n orc8r logs -f <nginx podname>
-        kubectl -n orc8r logs -f <bootstrapper podname>
+        kubectl -n orc8r logs -f \<nginx podname\>
+        kubectl -n orc8r logs -f \<bootstrapper podname\>
         ```
 
         For example: `kubectl -n orc8r get logs orc8r-bootstrapper-775b5b8f6d-89spq`
@@ -100,4 +100,4 @@ Sample control_proxy.yml file
     AGW$ sudo service magma@magmad restart
     ```
 
-11. If issue still persists, please  file github issues or ask in our support channels <https://magmacore.org/join-the-open-source-community/>
+11. If issue still persists, please  file github issues or ask in our support channels \<https://magmacore.org/join-the-open-source-community/\>

readmes/howtos/troubleshooting/analyze_service_crashes_in_agw.md

@@ -17,23 +17,23 @@ to an AGW service crash.
 **1.  Identify and quantify the impact.** Verify if there is any temporary or permanent drop in metrics related to
 service:
 
-- Number of Connected eNBs (Grafana -> Dashboards -> Networks)
+- Number of Connected eNBs (Grafana -\> Dashboards -\> Networks)
 
-- Network of Connected UE (Grafana -> Dashboards -> Networks)
+- Network of Connected UE (Grafana -\> Dashboards -\> Networks)
 
-- Network of Registered UE (Grafana -> Dashboards -> Networks)
+- Network of Registered UE (Grafana -\> Dashboards -\> Networks)
 
-- Attach/ Reg attempts (Grafana -> Dashboards -> Networks)
+- Attach/ Reg attempts (Grafana -\> Dashboards -\> Networks)
 
-- Attach Success Rate (Grafana -> Dashboards -> Networks)
+- Attach Success Rate (Grafana -\> Dashboards -\> Networks)
 
-- S6a Authentication Success Rate (Grafana -> Dashboards -> Networks)
+- S6a Authentication Success Rate (Grafana -\> Dashboards -\> Networks)
 
-- Service Request Success Rate (Grafana -> Dashboards -> Networks)
+- Service Request Success Rate (Grafana -\> Dashboards -\> Networks)
 
-- Session Create Success Rate (Grafana -> Dashboards -> Networks)
+- Session Create Success Rate (Grafana -\> Dashboards -\> Networks)
 
-- Upload/Download Throughput (Grafana -> Dashboards -> Gateway)
+- Upload/Download Throughput (Grafana -\> Dashboards -\> Gateway)
 
     Note: Number of sites(enodeb) down, users affected, and outage duration are key indicators of service impact.
 
@@ -60,7 +60,7 @@ service:
   Dec 5 22:25:59 magma systemd[1]: [email protected]: Main process exited, code=killed, status=11/SEGV
   ```
 
-- Service crashes with a segmentation fault will create coredumps in `/var/core/` folder. Verify if coredumps have been created and obtain the coredump that matches the time of the outage/crash. Depending on the type of service crash the name of the coredump will vary. More detail in <https://magma.github.io/magma/docs/lte/dev_notes#analyzing-coredumps>
+- Service crashes with a segmentation fault will create coredumps in `/var/core/` folder. Verify if coredumps have been created and obtain the coredump that matches the time of the outage/crash. Depending on the type of service crash the name of the coredump will vary. More detail in \<https://magma.github.io/magma/docs/lte/dev_notes#analyzing-coredumps\>
 
 **5. Get the backtrace using the coredumps**. To analyze the coredumps, you need 3 requirements.
 
@@ -80,20 +80,20 @@ an output like this:
 [Current thread is 1 (process 13887)]
 (gdb) bt
 #0  get_nas_specific_procedure_attach (ctxt=ctxt@entry=0x6210000d64b0) at /home/vagrant/magma/lte/gateway/c/oai/tasks/nas/nas_procedures.c:203
-#1  0x000055b0080c2aa8 in emm_proc_attach_request (ue_id=ue_id@entry=2819, is_mm_ctx_new=is_mm_ctx_new@entry=true, ies=<optimized out>, ies@entry=0x608000054280)
+#1  0x000055b0080c2aa8 in emm_proc_attach_request (ue_id=ue_id@entry=2819, is_mm_ctx_new=is_mm_ctx_new@entry=true, ies=\<optimized out\>, ies@entry=0x608000054280)
     at /home/vagrant/magma/lte/gateway/c/oai/tasks/nas/emm/Attach.c:318
-#2  0x000055b0080e5e1f in emm_recv_attach_request (ue_id=<optimized out>, originating_tai=originating_tai@entry=0x7f529e6c24d2, originating_ecgi=originating_ecgi@entry=0x7f529e6c2660,
-    msg=msg@entry=0x7f529e6c1e10, is_initial=<optimized out>, is_mm_ctx_new=<optimized out>, emm_cause=<optimized out>, decode_status=<optimized out>)
+#2  0x000055b0080e5e1f in emm_recv_attach_request (ue_id=\<optimized out\>, originating_tai=originating_tai@entry=0x7f529e6c24d2, originating_ecgi=originating_ecgi@entry=0x7f529e6c2660,
+    msg=msg@entry=0x7f529e6c1e10, is_initial=\<optimized out\>, is_mm_ctx_new=\<optimized out\>, emm_cause=\<optimized out\>, decode_status=\<optimized out\>)
     at /home/vagrant/magma/lte/gateway/c/oai/tasks/nas/emm/sap/emm_recv.c:384
 #3  0x000055b0080e27b4 in _emm_as_establish_req (msg=msg@entry=0x7f529e6c25e0, emm_cause=emm_cause@entry=0x7f529e6c257c)
     at /home/vagrant/magma/lte/gateway/c/oai/tasks/nas/emm/sap/emm_as.c:802
 #4  0x000055b0080e4460 in emm_as_send (msg=msg@entry=0x7f529e6c25d8) at /home/vagrant/magma/lte/gateway/c/oai/tasks/nas/emm/sap/emm_as.c:185
 #5  0x000055b0080d1720 in emm_sap_send (msg=msg@entry=0x7f529e6c25d0) at /home/vagrant/magma/lte/gateway/c/oai/tasks/nas/emm/sap/emm_sap.c:105
-#6  0x000055b0080b7037 in nas_proc_establish_ind (ue_id=ue_id@entry=2819, is_mm_ctx_new=<optimized out>, originating_tai=..., ecgi=..., as_cause=<optimized out>, s_tmsi=...,
+#6  0x000055b0080b7037 in nas_proc_establish_ind (ue_id=ue_id@entry=2819, is_mm_ctx_new=\<optimized out\>, originating_tai=..., ecgi=..., as_cause=\<optimized out\>, s_tmsi=...,
     s_tmsi@entry=..., msg=0x629000302036) at /home/vagrant/magma/lte/gateway/c/oai/tasks/nas/nas_proc.c:185
 #7  0x000055b007ebbf87 in mme_app_handle_initial_ue_message (mme_app_desc_p=mme_app_desc_p@entry=0x60800000b500, initial_pP=initial_pP@entry=0x629000302026)
     at /home/vagrant/magma/lte/gateway/c/oai/tasks/mme_app/mme_app_bearer.c:727
-#8  0x000055b007ebab98 in handle_message (loop=<optimized out>, reader=<optimized out>, arg=<optimized out>) at /home/vagrant/magma/lte/gateway/c/oai/tasks/mme_app/mme_app_main.c:182
+#8  0x000055b007ebab98 in handle_message (loop=\<optimized out\>, reader=\<optimized out\>, arg=\<optimized out\>) at /home/vagrant/magma/lte/gateway/c/oai/tasks/mme_app/mme_app_main.c:182
 ```
 
 **6. Obtain event that triggered the crash**. Every time a service restarts it will generate a log file (i.e. mme.log). Inside the coredump folder you will find the log (i.e. mme.log) that was generated just before the crash. In order to understand what was the event that triggered the crash, get the last event (Attach Request, Detach, timer expiring, etc.) in the log file.