Project

General

Profile

Configuring the ipaccess nano3G » History » Version 24

neels, 12/10/2017 12:30 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 24 neels
Furthermore, the ciphers supported by the nano3G may be disabled by default. To enable both manually:
87 9 roox
<pre>
88 24 neels
ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc root@192.168.0.124
89 9 roox
</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.
Add picture from clipboard (Maximum size: 48.8 MB)