wifi_loopback problem

[sollo123]

when I run wifi_loopback

Generating: "/home/sollo/gr-ieee802-11/examples/wifi_loopback.py"

Warning: This flow graph may not have flow control: no audio or RF hardware blocks found. Add a Misc->Throttle block to your flow graph to avoid CPU congestion.

Executing: "/home/sollo/gr-ieee802-11/examples/wifi_loopback.py"

linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.git-217-g012381d9

Using Volk machine: avx_32_mmx_orc
OFDM MAPPER: encoding: 0
set_min_output_buffer on block 31 to 96000
set_min_output_buffer on block 33 to 96000
set_min_output_buffer on block 35 to 96000
set_min_output_buffer on block 36 to 96000
set_min_output_buffer on block 39 to 96000
set_min_output_buffer on block 50 to 96000

Done

this doesn`t give me any figure graph.

I also use debug command and found that :

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x82c5eb40 (LWP 4482)]
0xb0796e30 in ofdm_decode_signal_impl::print_signal() ()
from /usr/local/lib/libgnuradio-ieee802_11.so
(gdb) backtrace
#0 0xb0796e30 in ofdm_decode_signal_impl::print_signal() ()

from /usr/local/lib/libgnuradio-ieee802_11.so
#1 0xb0797615 in ofdm_decode_signal_impl::general_work(int, std::vector<int, std::allocator >&, std::vector<void const*, std::allocator<void const*> >&, std::vector<void*, std::allocator<void*> >&) ()

from /usr/local/lib/libgnuradio-ieee802_11.so
#2 0xb6fd67f7 in gr::block_executor::run_one_iteration (this=0x82c5e270)

at /home/sollo/gnuradio/gnuradio-runtime/lib/block_executor.cc:438

#3 0xb7012a19 in gr::tpb_thread_body::tpb_thread_body (this=0x82c5e270,

block=..., max_noutput_items=10000000)
at /home/sollo/gnuradio/gnuradio-runtime/lib/tpb_thread_body.cc:122

#4 0xb7008373 in operator() (this=0x927b9c8)

at /home/sollo/gnuradio/gnuradio-runtime/lib/scheduler_tpb.cc:44

#5 operator() (this=0x927b9c8)

at /home/sollo/gnuradio/gnuradio-runtime/include/gnuradio/thread/thread_body_wrapper.h:51

#6 boost::detail::function::void_function_obj_invoker0gr:🧵:thread_body_wrapper<gr::tpb_container, void>::invoke (function_obj_ptr=...)

at /usr/include/boost/function/function_template.hpp:153

#7 0xb6fbe09d in operator() (this=0x92f263c)

at /usr/include/boost/function/function_template.hpp:767

#8 boost::detail::thread_databoost::function0::run (this=0x92f2520)

that means Segmentation fault

but how can I fix the problem? Could you please give me any tips since I am a beginner with gnuradio. Thanks a lot.

[bastibl]

Several people see this problem, but unfortunately I was not able to reproduce it yet. Therefore, it would be great if we could track this down.

Could you check if GNU Radio is installed with log4cpp support?

[sollo123]

I have intalled log4cpp by your steps also set the memory.

[bastibl]

OK, could you please replace this line
https://github.com/bastibl/gr-ieee802-11/blob/master/lib/ofdm_decode_signal.cc#L197

with something like

std::string temp = (boost::format("encoding: %1% - length: %2% - symbols: %3%")
    % d_encoding % d_len % d_copy_symbols).str();
//mylog(temp);

and recompile. It would be very interesting if it's the boost::format or the logging...
If you use the mylog(temp) it should be equivalent.
However, try it with the commented out version first. Then you can check if already the boost::format seg faults.

[sollo123]

it works . I get the same results with my classmates. Thanks a lot.

[bastibl]

what do you mean? The commented out version did not seg fault?
...or it works even with mylog(temp);

[sollo123]

no, I just change that file which you mentioned and rebulid again. Now I can get the results and figure graph.

the result like this:

inux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.git-217-g012381d9

Using Volk machine: avx_32_mmx_orc
OFDM MAPPER: encoding: 0
set_min_output_buffer on block 31 to 96000
set_min_output_buffer on block 33 to 96000
set_min_output_buffer on block 35 to 96000
set_min_output_buffer on block 36 to 96000
set_min_output_buffer on block 39 to 96000
set_min_output_buffer on block 50 to 96000

new mac frame (length 524)

duration: 00 00
frame control: 00 08 (DATA)
Subtype: Data
seq nr: 0
mac 1: 42:42:42:42:42:42
mac 2: 23:23:23:23:23:23
mac 3: ff:ff:ff:ff:ff:ff
instantaneous fer: 0
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

new mac frame (length 524)

duration: 00 00
frame control: 00 08 (DATA)
Subtype: Data
seq nr: 1
mac 1: 42:42:42:42:42:42
mac 2: 23:23:23:23:23:23
mac 3: ff:ff:ff:ff:ff:ff
instantaneous fer: 0
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

new mac frame (length 524)

duration: 00 00
frame control: 00 08 (DATA)
Subtype: Data
seq nr: 2
mac 1: 42:42:42:42:42:42
mac 2: 23:23:23:23:23:23
mac 3: ff:ff:ff:ff:ff:ff
instantaneous fer: 0
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Is that means the code can be run properly?

[bastibl]

...that means the flow graph works, but I still don't know the source of the problem.

Does it also work with

mylog(temp);

or only with

//mylog(temp);

[sollo123]

I just copy the code which you provide
"std::string temp = (boost::format("encoding: %1% - length: %2% - symbols: %3%")
% d_encoding % d_len % d_copy_symbols).str();
//mylog(temp);"

to change into the ofdm_decode_signal.cc# L197&L198
"mylog(boost::format("encoding: %1% - length: %2% - symbols: %3%")
% d_encoding % d_len % d_copy_symbols);"

save and rebuild .

[bastibl]

that's really strange. so it seems to be related to logging. But I see no problem here...
It would be interesting if you could post you GNU Radio config.

It's most likely at /usr/local/include/gnuradio/config.h

Anyhow, I will close this for now.

[tfcollins]

I came across this error as well. Uncommenting //mylog(temp) causes the flowgraph to quit early, so I'm guessing the problem is there. Here is my config:
https://gist.github.com/travisfcollins/e80ace96673b7422d043

[bastibl]

To me it looks like GNU Radio was compiled with logging, but without log4cpp support.
However, log4cpp is (now) available on your system and gr-ieee802-11 assume that it's also linked in GNU Radio.

The problem might be that the module uses GNU Radios cmake module to check for logging, but should actually rely on config.h.

Could you do me a favor and delete these two lines
https://github.com/bastibl/gr-ieee802-11/blob/master/CMakeLists.txt#L104
delete the build directory and rebuild?

That would be great.

[tfcollins]

Removing the logging options from the CMakeLists file and uncommenting mylog(temp) did the trick. Everything is working fine now.

[bastibl]

great news, thanks for trying it out! I will push a fix asap