This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
arvind.sirsikar gerrit-no-reply at lists.osmocom.orgPatch Set 3: (6 comments) Please describe your manual test setup >> The test is done with continuous traffic(Ping with larger packets or browsing or Iperf) on UL direction with initial MCS being higher MCS(Ex:MCS6). During this traffic we manually drop the packets at the receiver(PCU) and trigger the MS to do re segmentation with commanded MCS(for HeaderType3 MCS, Ex:MCS3 ) in PUAN message(also indicating the BSNs being dropped). This triggers the MS to re segment the BSNs already sent. Then the PCU and SGSN(proper decoding of LLC pdus) behavior is analysed. Maybe introduce a KPI for counting how often we resegmented (or failed) >> We have finalised the KPIs for SPB DL/SPB UL. Which will be submitted after SPB DL pushed to master. See if OSMO_ASSERT is not triggerable by a rogue MS >> We have tested SPB UL with commercial MS. Any specific MS you are referring to? https://gerrit.osmocom.org/#/c/537/3//COMMIT_MSG Commit Message: Line 13: in NuRAN 1.0 hardware thoroughly. The scope of Unit testing is limited. > How did your manual test look? How did you trigger the downgrade? The test is done with continuous traffic(Ping with larger packets or browsing or Iperf) on UL direction with initial MCS being higher MCS(Ex:MCS6). During this traffic we manually drop the packets at the receiver(PCU) and trigger the MS to do re segmentation with commanded MCS(for HeaderType3 MCS, Ex:MCS3 ) in PUAN message(also indicating the BSNs being dropped). This triggers the MS to re segment the BSNs already sent. Then the PCU and SGSN(proper decoding of LLC pdus) behavior is analysed. https://gerrit.osmocom.org/#/c/537/1/src/tbf_ul.cpp File src/tbf_ul.cpp: Line 442: > can we get the tbf in the log message (and for the other segment as well)? I will add the TBF info here. Line 520: } > In general OSMO_ASSERT(false) should not be used for input coming from the I agree. I will remove the assert and keep error log. https://gerrit.osmocom.org/#/c/537/3/src/tbf_ul.cpp File src/tbf_ul.cpp: Line 400: LOGP(DRLCMACUL, LOGL_DEBUG, > Please put the info about the tbf into the log as well. I will add the tbf info here. Line 413: "--- Second seg is received " > ditto I will add the tbf info here. Line 517: OSMO_ASSERT(false); > The main question I have is: Is rlc->cs controlled by the MS >> yes. this cs is controlled by MS. Can it force resegmentation even if it would not be needed (e.g. use MCS9 but send a different header type meant for lower mcs) >>Yes. I will remove the assert here and keep error log instead. -- To view, visit https://gerrit.osmocom.org/537 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I39ca53218b6e0982abc2ab9c703c24c8bf0a09c0 Gerrit-PatchSet: 3 Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Owner: arvind.sirsikar <arvind.sirsikar at radisys.com> Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org> Gerrit-Reviewer: Holger Freyther <holger at freyther.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: arvind.sirsikar <arvind.sirsikar at radisys.com> Gerrit-HasComments: Yes