- 17 Jan, 2024 15 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
Whether RU is enabled or disabled is controlled via per-ru ru.txrx_active
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
To run tapsplit we use plone.recipe.command with both command and update-command set to `tapsplit ...`. But tapsplit, when run, fully recreates and reinitializes subtap interfaces, which leads to interfering with running enb because subtap interfaces, that enb started to use, are removed. This is not desirable behaviour. What we need: 1) create subtap interfaces only once and keep them stable 2) until configuration changes which should lead to * subtaps recreated, and * enb restarted Carefully reading plone.recipe.command documentation shows: command Command to run when the buildout part is installed. update-command Command to run when the buildout part is updated. This happens when buildout is run BUT THE CONFIGURATION FOR THIS BUILDOUT PART HAS NOT CHANGED. (emphasis mine) So the fix looks to be to make update-command noop - this fulfills requirement "1". For "2" - I've verified that when configuration changes, e.g. number of RU changes, buildout reinstalls [vtap] section from scratch, and it also should restart enb, because generated enb.cfg changes. So the fix is fully correct because it satifies all needed requirements.
-
Kirill Smelkov authored
-
Kirill Smelkov authored
Dnsmasq insists on dhcp-range's prefixlen to be at most 64, which triggers the following error if original slaptap is wider than that: dnsmasq: prefix length must be at least 64 at line 5 of /srv/slapgrid/slappart6/etc/dnsmasq.cfg -> Fix it by capping provided range to /64 /reported-by @lu.xu
-
- 16 Jan, 2024 13 commits
-
-
Kirill Smelkov authored
After escaping strings with dumps (to avoid buildout breakage and code injection on "tricky" references, e.g. with spaces), promises started to be generated with !py! prefix in their filenames, e.g. as '!py!'\''RU1-sdr-busy.py'\''' instead of just RU1-sdr-busy.py The issue here is that our code set name = !py!'RU1-sdr-busy.py' and then monitor-promise-base from stack/monitor does output = ${directory:plugins}/${:name} which, I though, would be expanded to .../etc/plugin/RU1-sdr-busy.py but it did not deserialized the :name upon expansion. I feel like it is maybe a bug in nexedi/slapos.buildout@4e13dcb9 , but I'm not sure. Anyway, workaround the problem by generating :output ourselve also via escaped way.
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
urlparse does not handle raw IPv6 address the way I though it does - extracted hostname is not the whole address, but only the first part of it: In [3]: urllib.parse.urlparse('z://2a11:9ac1:6::5') Out[3]: ParseResult(scheme='z', netloc='2a11:9ac1:6::5', path='', params='', query='', fragment='') In [4]: _.hostname Out[4]: '2a11' Tests did not noticed this because previouslt we had e.g 4321::1 in the address, and netaddr thinks 4321 is valid ipv4 address: In [6]: netaddr.IPAddress('4321') Out[6]: IPAddress('0.0.16.225') However changing IPv6 addresses to use hex letter trigger the bug with e.g. raise AddrFormatError('failed to detect a valid IP ' \ netaddr.core.AddrFormatError: failed to detect a valid IP address from '2a11' -> Fix it by avoiding urlparse and doing ip/port splitting ourselves by hand. /reported-by @lu.xu
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
when serving symlinks via raw, lab returns link content (= readlink), not content of the target.
-
Kirill Smelkov authored
-
- 15 Jan, 2024 4 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
- 12 Jan, 2024 4 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
Else enb treats args="" unset and implicitly uses /dev/sdr0 by default. We do not want implicit default behaviour -> we want to see an error.
-
Kirill Smelkov authored
In 536b892c I've made a thinko: the documentation on Amarisoft says(*) that if those parameters are not given, their values are taken from the "serving cell". With that and after reading https://www.telecomhall.net/t/changing-allowedmeasbandwidth/13045, especially https://www.telecomhall.net/t/changing-allowedmeasbandwidth/13045/5 I've made the conclusion that if allowed_meas_bandwidth, and similarly antenna_port_1, are not provided, they will be extracted by UE from MIB of that peer serving cell. But I was wrong as eNB does not start if allowed_meas_bandwidth is not given for eautra-kind handover in NR cell. So after checking things in 36.331 we see that: allowed_meas_bandwidth is optional only in SIB3 (Intra Frequency Cell Reselection), but in SIB5 (Inter Frequency Neighbour Cell) it is mandatory, and that is the reason for why enb was complaining about that missing for NR->LTE handover. -> restore allowed_meas_bandwidth and antenna_port_1 in HO config. For intra-eNB HO things are clear, but for inter-eNB HO use conservative values and put a TODO for considering to extend peer/cell/lte schema with .allowed_meas_bandwidth and .antenna_port_1 . I think keeping the schemas minimal is better for now until we really need to do inter-RAT HO in practice. (*) https://tech-academy.amarisoft.com/lteenb.doc#prop.ncell_list.allowed_meas_bandwidth
-
Kirill Smelkov authored
* master: recipe/check_parameter: support multi lines values software/erp5/test: use short partition references stack/erp5: rename an internal parameter still mentioning apache
-
- 11 Jan, 2024 4 commits
-
-
Kirill Smelkov authored
This reverts commit 5a45624b.
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-