Illegal Network Name causes wpantund to crash about wpantund HOT 6 CLOSED

Such strings used to be sanitized before letting them on DBus. I'm guessing that code was somehow lost in a refactor at some point.

from wpantund.

I encountered the same issue, which for me was caused by a networkname of exactly 16 characters. Create any Thread network with a networkname of 16 characters, then scan with wpanctl. wpantund will crash:

wpantund[28027]: Scan -> Name:codelabacodelabb���z���z�, PanId:0xC0DE, Ch:11, Joinable:NO , XPanId:0xC0DE7AB5C0DE7AB5, HwAddr:0x62991E21E38AE4B5, RSSI:-39 , LQI:54 , ProtoId:3 , Version: 0, ShortAddr:0xFFFF
process 28027: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_check_is_valid_utf8 (*string_p)" failed in file ../../../dbus/dbus-message.c line 2753.
This is normally a bug in some application using the D-Bus library.
wpantund[28027]: DBUSIPCServer.cpp:194: Requirement Failed (dbus_connection_get_unix_fd(mConnection, &unix_fd))

On the wpanctl side:

wpanctl:utun7> scan
| Joinable | NetworkName | PAN ID | Ch | XPanID | HWAddr | RSSI
---+----------+--------------------+--------+----+------------------+------------------+------
scan: error: Server returned a bad response ('s')
Error 4 (0x04)

from wpantund.

Do you have an SNIFFER log of the network when this occurs?

In my case - it was another (rouge device - in a co-workers office) that was broadcasting a bad/INVALID network name over the air

Meaning - I saw the illegal network name comming from something not on my network.

from wpantund.

No I wasn't using a sniffer, and I had formed the network myself. A 16 character networkname like the one I used ("codelabacodelabb") should be valid, but is not. Any 16 character networkname I tried resulted in the same crash.

So seems to be two different scenarios causing this crash... wpantund needs to be updated to handle illegal and 16 character network names.

from wpantund.

Hmm - 16bytes is a often a magic number.

There's a funkyness with the strcpy() function if the two strings overlap each other by a certain amount that shows up in for example situations like this:

char buf[20];
strcpy( buf, "Xhello, world" );
/* goal here is to remove the X from the string */
/* this is the bug:  the strings overlap */
strcpy( buf, buf+1 );

Technically - this is not allowed - (go RTFM...) what happens is one of 2 things:

Option 1 - the string functions are simple C functions and not optimized.

Option 2 - the string functions are written in hand optimized assembly, and use funky opcodes for speed... (this is found in places like linux glibc) those funky opcodes and tricks do not work when the strings overlap each other - and depending upon the architecture often do things wrong in exactly 16byte increments.

And this is cpu architecture specific -

I've been writing C code for a very long time and I only learned about this in the last year or so... You learn something every day.

What you describe smells like this type of bug, but then I'm only guessing.

I would setup a sniffer and sniff your NCP/WPANTUND configuration and see if it is transmitting garbage or not {goal being to divide the problem in 2 ie: is this problem from the "set the network name" side, or is it in the "get the network name" side}

from wpantund.

Adressed by #420. Closing issue.

from wpantund.