Could not connect callback to /NodeList/*/DeviceList/*/$ns3::LteUeNetDevice"

[bouchrit leila]

Hello,

Please can someone help me to resolve this error, i spent many hours but I can't find a solution.

I went to use config::connect to trace PDCP transmit and received

 when i compile my file lte.cc i got this error:

msg="Could not connect callback to /NodeList/*/DeviceList/*/$ns3::LteUeNetDevice/LteUeRrc/Srb1/LtePdcp/TxPDU", +0.000000000s -1 file=../src/core/model/config.cc, line=925

i use gdb i got this:

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff1e1b859 in __GI_abort () at abort.c:79
#2  0x00007ffff2218911 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff222438c in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff22243f7 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff2843e7f in ns3::Config::Connect (
    path="/NodeList/*/DeviceList/*/$ns3::LteUeNetDevice/LteUeRrc/Srb1/LtePdcp/TxPDU", cb=...)
    at ../src/core/model/config.cc:925
#6  0x00005555555721fb in main (argc=1, argv=0x7fffffffd8e8) at ../scratch/lte.cc:433

Another question: I want to get the sequenceNumber of the packet, can i use the trace RX of PDCP to recuperate the sequenceNumber?

Can anybody help me?

[Tom Henderson]

On 6/4/22 08:44, bouchrit leila wrote:
> Hello,
> Please can someone help me to resolve this error, i spent many hours but
> I can't find a solution.
> I went to use config::connect to trace PDCP transmit and received

There are typically a few reasons why this might fail.

1) The path string is incorrect.

2) You specified a wildcard in the path name, but the object being
connected to does not exist on all nodes (or all devices on all nodes).
In the path you specified below,

/NodeList/*/DeviceList/*/$ns3::LteUeNetDevice/LteUeRrc/Srb1/LtePdcp/TxPDU

This path must exist on _all_ nodes and _all_devices in the simulation,
when Config::Connect() is used.

3) The path is correct but the object does not yet exist when the trace
connection is attempted. TCP sockets are a good example of this; they
typically are instantiated after the simulation starts.

I think in your case, it is probably 2), because I doubt that all nodes
are UEs in your scenario, and therefore I doubt that LteUeRrc exists on
all nodes.

You have two choices:
1) use Config::ConnectFailSafe() instead of Config::Connect(). The
first method will not raise an error if the path string does not match
everywhere.
2) Do not use wildcards in your path strings but instead explicitly
identify with node index and device index the exact paths you want to trace.
My first option would typically be to call ConnectFailSafe(), and if
nothing is traced, then I would suspect I had a path string problem.

In general, when I want to debug incorrect paths, I borrow some code
from the example program
`src/config-store/examples/config-store-save.cc`. Starting on line 103
of that program, you can see these statements:

Config::SetDefault ("ns3::ConfigStore::Filename", StringValue
("output-attributes.txt"));
Config::SetDefault ("ns3::ConfigStore::FileFormat", StringValue
("RawText"));
Config::SetDefault ("ns3::ConfigStore::Mode", StringValue ("Save"));
ConfigStore outputConfig2;
outputConfig2.ConfigureDefaults ();
outputConfig2.ConfigureAttributes ();

I paste these just before my call to Simulator::Run (). I also include
the header "#include "ns3/config-store-module.h". This will dump a text
file of all of the instantiated object paths in the config namespace
just before the simulation starts, into a text file
'output-attributes.txt'. I can then check my path strings against this
file.

In the case of 3) above, the objects may not exist yet just before
simulation time 0, so I would create a function including those
statements and schedule that function for some future simulation time.

- Tom

>
>  when i compile my file lte.cc i got this error:
> msg="Could not connect callback to
> /NodeList/*/DeviceList/*/$ns3::LteUeNetDevice/LteUeRrc/Srb1/LtePdcp/TxPDU",
> +0.000000000s -1 file=../src/core/model/config.cc, line=925
> i use gdb i got this:
> Program received signal SIGABRT, Aborted.
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> 50 ../sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type.
> (gdb) bt
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x00007ffff1e1b859 in __GI_abort () at abort.c:79
> #2  0x00007ffff2218911 in ?? () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #3  0x00007ffff222438c in ?? () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #4  0x00007ffff22243f7 in std::terminate() () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #5  0x00007ffff2843e7f in ns3::Config::Connect (
>
> path="/NodeList/*/DeviceList/*/$ns3::LteUeNetDevice/LteUeRrc/Srb1/LtePdcp/TxPDU",
> cb=...)
>     at ../src/core/model/config.cc:925
> #6  0x00005555555721fb in main (argc=1, argv=0x7fffffffd8e8) at
> ../scratch/lte.cc:433

> *Another question:* I want to get the sequenceNumber of the packet, can

> i use the trace RX of PDCP to recuperate the sequenceNumber?
> Can anybody help me?
>

> --
> Posting to this group should follow these guidelines
> https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
> <https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting>
> ---
> You received this message because you are subscribed to the Google
> Groups "ns-3-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ns-3-users+...@googlegroups.com
> <mailto:ns-3-users+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ns-3-users/CAOuYX_5%2BTS_5sOwzbWvnY_Y%3DYnj7-mYCFUJaB%2BAWp5Ok0sC4sA%40mail.gmail.com
> <https://groups.google.com/d/msgid/ns-3-users/CAOuYX_5%2BTS_5sOwzbWvnY_Y%3DYnj7-mYCFUJaB%2BAWp5Ok0sC4sA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[bouchrit leila]

Thank you Tom for the reply

first of all , yes all nodes are UEs and i change wildcard with index of sender and device(lte=0)

1) when i used Config::ConnectFailSafe(), the program work but when i enabled lteHelper->EnablePdcpTraces (), it raise an error :

msg="Could not connect callback to /NodeList/*/DeviceList/*/LteEnbRrc/NewUeContext",

i addes this path also Config::ConnectFailSafe("/NodeList/10/DeviceList/0/LteEnbRrc/NewUeContext",MakeBoundCallback (&NotifyNewUeContextEnb, stream3)); i changed the path but didn't work

2) I added 3 lines of config::default before Simulator::Run (), i got the file output-attributes.txt

3) PLease can you explain to me  the third point, (in the case of 3) above, the objects may not exist yet just before  simulation time 0, so I would create a function including those  statements and schedule that function for some future simulation time.)

[Tom Henderson]

On 6/4/22 16:08, bouchrit leila wrote:
> Thank you Tom for the reply
> first of all , yes all nodes are UEs and i change wildcard with index of
> sender and device(lte=0)
> 1) when i used Config::ConnectFailSafe(), the program work but when i
> enabled lteHelper->EnablePdcpTraces (), it raise an error :

> *msg="Could not connect callback to
> /NodeList/*/DeviceList/*/LteEnbRrc/NewUeContext",*
> i addes this path
> also*Config::ConnectFailSafe("/NodeList/10/DeviceList/0/LteEnbRrc/NewUeContext",MakeBoundCallback
> (&NotifyNewUeContextEnb, stream3)); i changed the path but didn't work*

It probably doesn't connect to anything in an all-UE network (note the
'LteEnbRrc' in the path name). You probably cannot use the helper in
that scenario-- it seems designed for a conventional cellular architecture.

You may have to write your own custom trace sinks.

> 2) I added 3 lines of config::default before Simulator::Run (), i got
> the file output-attributes.txt
> 3) PLease can you explain to me  the third point, (in the case of 3)
> above, the objects may not exist yet just before  simulation time 0, so
> I would create a function including those  statements and schedule that
> function for some future simulation time.)

See, for example, the example program
`examples/tcp/tcp-variants-comparison.cc`. It contains a function
`TraceCwnd()` on line 170. This performs a Config::Connect() to a trace
source, but if you were to call this at simulation time zero (i.e.,
before Simulator::Run()), the TCP socket object would not yet exist.

Instead, you can see on line 458 of this program that this function is
scheduled for some simulation time in the future, when the socket will
exist:

Simulator::Schedule (Seconds (start_time * index + 0.00001), &TraceCwnd

- Tom

[王小胜]

Sorry, Tom, I'm a newbie, I don't quite understand what you mean in 2), can you elaborate on that?I don't know why my reply to the original post was deleted immediately, so I contacted you through this post.

[Tom Henderson]

The problem is that the code doesn't find any LtePdcp object to connect
to from the provided path, at the time that you specified (100 ms). The
fact that you can make it run without a fatal error by instead using
Config::ConnectWithoutContextFailSafe() demonstrates this. If you check
the return value of Config::ConnectWithoutContextFailSafe(), and the
value returned is false, it confirms that there was no LdePdcp object
found on that (wildcarded) trace path, at the time that it was checked.

By 2) in that previous message, I mean to use the ConfigStore system to
find out what objects actually exist in the system at that time.
ConfigStore can dump all of the active attribute paths (without
wildcards) and you could inspect the output to see what paths are valid.
In your case, you'd have to schedule the print of the attributes at
the time you are calling Connect() (since the PDCP doesn't exist at
simulation start time). More details are here:

https://www.nsnam.org/docs/release/3.43/manual/html/attributes.html#configstore

> --
> Posting to this group should follow these guidelines
> https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
> <https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting>
> ---
> You received this message because you are subscribed to the Google
> Groups "ns-3-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ns-3-users+...@googlegroups.com
> <mailto:ns-3-users+...@googlegroups.com>.

> To view this discussion visit
> https://groups.google.com/d/msgid/ns-3-users/c2f9abec-cbf8-4bda-9910-8cfd150e65bfn%40googlegroups.com <https://groups.google.com/d/msgid/ns-3-users/c2f9abec-cbf8-4bda-9910-8cfd150e65bfn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[王小胜]

Tom, thank you very much for your reply, but I have another problem, I followed your method to find the path, but according to this path still reported an error, can you help me look at it again, thanks again!

0.0212143 UE IMSI 1: connected to CellId 1 with RNTI 1 context 0
The following error message is displayed：msg="Could not connect callback to /NodeList/3/DeviceList/0/$ns3::LteNetDevice/$ns3::LteEnbNetDevice/LteEnbRrc/UeMap/1/DataRadioBearerMap/1/LtePdcp", +0.121214285s 4 file=../src/core/model/config.cc, line=906
terminate called without an active exception