Updated troubleshooting document
Change-Id: I9bcf24cba079aaf27a6cb2fbf5ed55e0ead0b6e8
diff --git a/developer/aiabhw5g.rst b/developer/aiabhw5g.rst
index 91dd24c..8a9130c 100644
--- a/developer/aiabhw5g.rst
+++ b/developer/aiabhw5g.rst
@@ -303,6 +303,12 @@
Recall that AiaB assumes that the eNodeB is on the same subnet as DATA_IFACE, so in this case it also has an
IP address in the 128.105.144.0/22 range.
+Note that If you are not finding ``access`` and ``core`` interfaces on **outside the UPF**, following commands
+can be used to create these two interfaces manually::
+
+ $ ip link add core link <DATA_IFACE> type macvlan mode bridge 192.168.250.3
+ $ ip link add access link <DATA_IFACE> type macvlan mode bridge 192.168.252.3
+
gNodeB setup
------------
diff --git a/developer/troubleshooting.rst b/developer/troubleshooting.rst
index af7e1b3..0815c2b 100644
--- a/developer/troubleshooting.rst
+++ b/developer/troubleshooting.rst
@@ -208,6 +208,11 @@
tcpdump -i access -n udp port 2152
+In case packets are not forwarded from ``DATA_IFACE`` to ``acccess`` interface, the following command
+can be used to forward the traffic which is destined to 192.168.252.3::
+
+ iptables -A FORWARD -d 192.168.252.3 -i <data-iface> -o access -j ACCEPT
+
If they don't make it to ``core`` then they are being dropped by the UPF for some reason. This
may be a configuration issue with the state loaded in the ROC / SD-CORE -- the UPF is being told
to discard these packets. You should check that the device's IMSI is part of a slice and that