Configuring the ipaccess nano3G » History » Version 23
neels, 12/10/2017 12:14 PM
1 | 2 | neels | {{>toc}} |
---|---|---|---|
2 | 1 | neels | |
3 | 2 | neels | h1. Configuring the ip.access nano3G |
4 | |||
5 | h2. IP address |
||
6 | |||
7 | 21 | neels | The ip.access nano3G will obtain an IP address from the DHCP server in your network. Ways to find out: |
8 | |||
9 | * Run @abisip-find@ (currently in the osmo-bsc.git repository), which should find the nano3G (despite no Abis interface being present). Find the @abisip-find@ output matching the MAC address printed on the sticker next to the power jack. |
||
10 | * Watch wireshark, filtering on 'BOOTP' while the nano3G starts up. |
||
11 | * Look it up in your DHCP server's list of leases. |
||
12 | |||
13 | 2 | neels | For this text, let's assume the IP address it obtained is 192.168.0.124. |
14 | |||
15 | h2. Initial Config |
||
16 | |||
17 | Once off, configure: |
||
18 | |||
19 | * the MCC + MNC, |
||
20 | * the UARFCN (i.e. the frequencies to transceive on) and |
||
21 | * the LAC and RAC. |
||
22 | |||
23 | You can do this on the _dmi_ console reachable by telnet: |
||
24 | |||
25 | <pre> |
||
26 | telnet 192.168.0.124 8090 |
||
27 | dmi> |
||
28 | </pre> |
||
29 | |||
30 | On the dmi, enter commands like these: |
||
31 | |||
32 | <pre> |
||
33 | # PLMN Id == MCC + MNC |
||
34 | set mcc="901" |
||
35 | set mnc="98" |
||
36 | |||
37 | # [uarfcnDownlink, 1900 MHz band], [scramblingCode], [dummyCellId] |
||
38 | set rfParamsCandidateList=({9800, 401, 1}) |
||
39 | |||
40 | # [lac], [rac] |
||
41 | set lacRacCandidateList=({10422, (99)}) |
||
42 | </pre> |
||
43 | |||
44 | These settings persist across nano3G power down. |
||
45 | |||
46 | 22 | neels | *All of the above settings require a reboot of the nano3G to take effect.* |
47 | |||
48 | 23 | neels | h2. After Every Boot: Starting Operation |
49 | 2 | neels | |
50 | Every time you boot the nano3G, you need to |
||
51 | |||
52 | * set the IP address the nano3G will find the HNB-GW at. |
||
53 | * 2061 = set cell parameters |
||
54 | * 1216 = unlock ap |
||
55 | * activate HNB-GW connection |
||
56 | * set csg to open access so that any IMSI can register |
||
57 | |||
58 | Enter the _dmi_... |
||
59 | <pre> |
||
60 | telnet 192.168.0.124 8090 |
||
61 | dmi> |
||
62 | </pre> |
||
63 | |||
64 | ...and issue commands like: |
||
65 | |||
66 | <pre> |
||
67 | set hnbGwAddress="192.168.0.132" |
||
68 | action 2061 |
||
69 | action 1216 |
||
70 | action establishPermanentHnbGwConnection |
||
71 | set csgAccessMode=CSG_ACCESS_MODE_OPEN_ACCESS |
||
72 | </pre> |
||
73 | |||
74 | h2. SSH Access |
||
75 | |||
76 | The nano3G come with a root password of 'newsys': |
||
77 | <pre> |
||
78 | ssh root@192.168.0.124 |
||
79 | password: newsys |
||
80 | </pre> |
||
81 | |||
82 | 9 | roox | In case you are using a recent version of the OpenSSH-client you'll get the following error message while trying to connect: |
83 | _Unable to negotiate with 192.168.0.124 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1_ |
||
84 | |||
85 | Starting with OpenSSH version 7.0 support for the 1024-bit diffie-hellman-group1-sha1 key exchange was disabled by default at run-time. |
||
86 | Use the following to connect to your nano3G in this case. |
||
87 | <pre> |
||
88 | ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@192.168.0.124 |
||
89 | </pre> |
||
90 | |||
91 | 10 | roox | h2. NTP |
92 | |||
93 | Be sure that the nano3G is able to resolve the DNS record _0.ipaccess.pool.ntp.org_ and can connect the the corresponding NTP servers. |
||
94 | Without syncronized NTP the nano3G does not bring up the TRX and it even do not try to connect to the hnbGw. |
||
95 | 9 | roox | |
96 | 20 | neels | A workaround is to edit the @/etc/hosts@ file on the nano3G (via SSH) and add an entry to resolve 0.ipaccess.pool.ntp.org to your local NTP server's IP address (which requires re-mounting the root file system in read-write mode...). |
97 | 19 | neels | |
98 | 2 | neels | h2. Logging |
99 | |||
100 | When logged in via SSH, you can view the live logging here: |
||
101 | <pre> |
||
102 | ls /tmp/iapclogs/trace_*.log |
||
103 | </pre> |
||
104 | |||
105 | h2. Closed Mode |
||
106 | |||
107 | You can also set csgAccessMode to closed and allow only specific IMSIs: |
||
108 | |||
109 | <pre> |
||
110 | 6 | neels | set csgAccessMode=CSG_ACCESS_MODE_CLOSED_ACCESS |
111 | 2 | neels | # IMSI, 1:allowed/2:not allowed, phone number (only for "Closed Access") |
112 | set accessControlList = ({"001010123456015", 1, "81084"},{"001010123456025", 2, "81025"}) |
||
113 | </pre> |
||
114 | |||
115 | (The phone number is actually not relevant) |
||
116 | |||
117 | h1. Peculiarities and Tips |
||
118 | |||
119 | 12 | neels | h2. Exiting the dmi while keeping it alive |
120 | |||
121 | When you exit the dmi telnet by hitting Ctrl-C, it will not be available anymore until you reboot the nano3G. |
||
122 | Every connection attempt will then end in |
||
123 | |||
124 | <pre> |
||
125 | dmi> Connection closed by foreign host. |
||
126 | </pre> |
||
127 | |||
128 | 13 | neels | However, if you end your session by the telnet escape character and quitting, the dmi remains open for further connections. Usually that means: hit Ctrl-] (Ctrl and closing square brace) and then enter 'quit': |
129 | 12 | neels | |
130 | <pre> |
||
131 | dmi> ^] |
||
132 | telnet> quit |
||
133 | </pre> |
||
134 | |||
135 | 2 | neels | h2. UE Register |
136 | |||
137 | The nano3G apparently passes the same identity received from the UE through to |
||
138 | the HNBAP UE Register Request message. This means that when the UE sends a |
||
139 | TMSI, the UE Register Request received by osmo-hnbgw contains no IMSI. |
||
140 | |||
141 | 7 | neels | In this scenario, the problem is that Paging apparently does not (always) work. |
142 | 1 | neels | So even though we have working code that allows HNBAP registration with |
143 | 7 | neels | a TMSI, that means that you can't (always) reach the UE from the CN. |
144 | This is not always the case, sometimes the nano3G can well page UEs that have |
||
145 | registered by TMSI. Vague idea: it may be that it needs to have seen the IMSI |
||
146 | once after power-cycling, e.g. after a closed-mode registration, and then |
||
147 | TMSI registration will not harm Paging. (TODO: clarify this) |
||
148 | 2 | neels | |
149 | 7 | neels | The VTY configuration option to allow TMSI-only attaching to HNBGW, which |
150 | possibly helps to shorten your dev cycle but may harm paging, is: |
||
151 | 2 | neels | |
152 | <pre> |
||
153 | hnbgw |
||
154 | iuh |
||
155 | 7 | neels | hnbap-allow-tmsi 1 |
156 | 2 | neels | </pre> |
157 | 1 | neels | |
158 | 2 | neels | Legacy workaround: connect the phone to a different network between retries (being |
159 | rejected suffices). That causes the UE to discard its TMSI and then use the IMSI |
||
160 | for the next registration. |
||
161 | |||
162 | 18 | neels | A [[Configuring the ipaccess nano3G#Closed-Mode|closed csgAccess]] with explicit IMSIs could help here to enforce that a UE |
163 | 7 | neels | indeed sends its IMSI to the nano3G and hence Paging should work. |
164 | 3 | neels | See also #1924. |
165 | |||
166 | h2. id-Reset |
||
167 | |||
168 | The nano3G seems to *not* send an id-Reset message upon connecting to the HNB-GW. |
||
169 | |||
170 | h2. Location Update failure due to timeout |
||
171 | |||
172 | If a UE seems to connect successfully at first but fails by timeout because the final |
||
173 | "TMSI Reallocation Complete" message is missing, this might be due to misconfiguration: |
||
174 | the CN is sending the wrong LAC or the PLMN-ID (NCC/MNC) is configured wrongly. |
||
175 | |||
176 | This might be confusing in the sense that a complete LU worked once but not after that; |
||
177 | GMM Attach may be successful; Security Mode Commands succeed; and so forth. |
||
178 | 8 | neels | Still the solution might be simply to fix the mobile network code in the osmo-msc.cfg. |
179 | 4 | neels | |
180 | h2. RAB Assignment needs IuUP ACK Initialization |
||
181 | |||
182 | IuCS uses UP encapsulated in RTP. The UP starts off by sending an Initialization, replied |
||
183 | upon by an ACK Initialization. |
||
184 | |||
185 | The nano3G seems to not reply with an ACK when it receives an IuUP Initialization frame. |
||
186 | Thus it is not possible to merely echo its own RTP packets back to itself; instead, the |
||
187 | first RTP frame received from the nano3G (that is an IuUP Initialization) can be changed |
||
188 | to an ACK Initialization by writing 0xe4 to the first payload byte. Sending this back to |
||
189 | the nano3G then results in successful RAB Assignment. |
||
190 | |||
191 | (With the SysmoCell5000, echoing its own Initialization back to itself results in an ACK |
||
192 | 1 | neels | being sent, which we can also echo back to itself, so mere echoing works there.) |
193 | 11 | neels | |
194 | 14 | neels | A hack to make the nano3G work is currently on the "3G master" (the vlr_3G branch), |
195 | because it does not seem to harm other femto cells: the commit's summary is |
||
196 | "mgcp: hack RAB success from nano3G: patch first RTP payload", see "cgit":http://git.osmocom.org/openbsc/log/?h=vlr_3G. |
||
197 | 15 | neels | |
198 | See also #1712#note-21 and the following two comments. |