I used the construct like f_rnd_octstring(f_rnd_int(100)) in a number
of places to generate random-length packets with randomized length.
The problem I didn't realize is that f_rnd_int() of course can also
return '0', which would generate zero-length packets. This may be
permitted in some protocols, but it leads to problems e.g. when trying
to send a UDP packet of zero length (which the kernel will not do).
So let's introduce
* f_rnd_int_nonzero() for returning non-zero randomized integers
* f_rnd_octstring_rnd_len() for returning a random-length random payload
octet string
* replace all f_rnd_octstring(f_rnd_int()) call sites with the new
function.
Change-Id: I818a113ff8d2a2f7cab2ec7d9c8661607c6331d6
Closes: OS#5528
Set the executable name in each regen_makefile.sh explicitly with -e,
instead of having it set indirectly from the first .ttcn file. Make it
consistent by placing the name on top of each of these files.
Fix for warning:
ttcn3_makefilegen: warning: File `BSC_Tests.ttcn' was given more than once for the Makefile.
Related: OS#5252
Change-Id: I5ed03f8f3ed905483620dc7bae33b617bbb8507f
Make all regen_makefile.sh more readable and diff friendly by moving
each entry in FILES and CPPFLAGS_TTCN3 into separate lines. Order
entries alphabetically.
Related: OS#5252
Change-Id: I6b6866eb9f6ec6232e4ae434517457a4c8c1c050
RAW_NS used previous a single TTCN3 port for a single UDP port
(source/listen side).
This has the limitation that only a single NSVC could be tested for a
local UDP port. However SNS tests require multiple NSVCs over a single UDP port.
NS_Provider_IPL4 already supports multiple NSVCs for the NS_Emulation.
Extend the support in NS_Provider_IPL4 to also allow RAW_NS to use
multiple NSVCs.
Related: OS#5036
Change-Id: Iafd9310e04066958914201da0cbdcd563bd5c976
There is quite a number of them, as we start 100 UE components
plus associated structure underneath. Let's avoid spamming the console.
Change-Id: I6621ac6094de310e974ce0438d01fca868719eb1
This allows us to test with a variety of packet sizes up to [close to]
the MTU of the underlying transport (configurable by modulepar)
Change-Id: I8e38ecf6b270c81bd73ee43b1fa0b259a999c14b
This test case tests NS-UL-UNITDATA transmit and expectes the exact same
LLC PDU to be sent back as NS-DL-UNITDATA.
This way we can verify that both uplink and downlink paths are working,
and that no messages are lost. It works stable here on my laptop,
showing that if we test the TTCN3 NS + BSSGP code over a E1 line
against another instance (fr against fr-net) works reliable.
Change-Id: Ic115af02207c9b9f4c84fa75890048acb6856c79
Rather than running in an endless loop (useful for manual tets),
terminate each UE_CT after sending 50 packets. Also adjust the ramping
and timeouts in a way that it manages to terminate ahead of the guard
timeout.
Change-Id: I7f40f5c59d399d528072986d067b5014fbd085c4
If send() on AF_PACKET returns ENOBUFS, usleep for 2ms and re-try
until it succeeds.
Change-Id: Id7bdd2c690eae3bec1df7634944cd73f0bf0b29a
Closes: OS#5343
Let's start a number of per-UE/TLLI component on each BVC, and generate
some uplink traffic with random-payload 512-byte LLC frames. The
FRNET(SGSN) side simply ignores all of those by means of a
CreateCallback.
Change-Id: I1b25b4a650d831bb07e9623b76e6c3dcdd71ac88
The existing BSSGP Code assumed that the TLLIs were always known "a
priori" by the test case. With the newly-introduced create_cb,
the user can provide a function to handle any incoming messages for an
unknown TLLL. The default handler behaves like before: fail +
terminate.
Change-Id: Ice0e145f5a6518ff79547dd851042b7965f38e00
When doing load simulatin, the amount of console printing becomes a
serious throttle factor. We don't need to see the decode of every
message.
Change-Id: Ic988d1e1d60c9d03d5b70e9b38f109b47569b89e
We don't want the number of NSE and the number of BVC to be a
compile-time choice, but rather something dynamic at rutime. This
allows configuration files to define those details.
Change-Id: I55b44481b5322deaf78619c1689462d716ddfcec
This is something we need to simulate more complex scenarios,
particularly in the context of frame relay.
Change-Id: If1220852785853f8a5d8de183d5053ddd6ccb958
Add frame relay testcase for BSS and SGSN side.
The test cases require hdlc interfaces (based on
dadhi with super channels and no lmi).
Change-Id: I95d64dc26a8d2ff02d6cf2bfcd22a97e5481f957