Re: [OpenWrt-Devel] [RFC] commit message in YAML format for new devices
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Paul, On Sun, Jan 12, 2020 at 10:47 PM Paul Spooren wrote: > > Hi all, > > some time ago I created a (now outdated) device overview[0] based on > YAML meta data. This approach could simplify maintaining an device > overview and device specific pages[1]. > > All commits adding new devices already include most relevant information > for creating the overview. However it would be convenient if developers > would format their commit messages in a generic format, therefore I'd > propose the following: > > Every commit message for newly added devices must contain a number of > hardware information and steps for an initial installation. > The hardware information should contain at least the following > information, maybe more: > > SoC, flash, ram, wifi, LEDs, buttons, USB, serial, vendor, model, device > tree ID, Ethernet ports can we automate this somehow? the device tree files already contain most of that information. (I'm all for providing good data for the TOH but I'm challenging the idea of doing this manually) Martin --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH libubox 1/4] tests: include json script shunit2 based testing
Include shunit2 based tests into unit testing pipeline until
(eventually) it's converted to cram based unit tests.
Signed-off-by: Petr Štetiar
---
tests/CMakeLists.txt |1 +
tests/shunit2/CMakeLists.txt |7 +
tests/shunit2/shunit2/shunit2 | 1040 +
tests/shunit2/tests.sh| 287 +
4 files changed, 1335 insertions(+)
create mode 100644 tests/shunit2/CMakeLists.txt
create mode 100644 tests/shunit2/shunit2/shunit2
create mode 100755 tests/shunit2/tests.sh
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index 0cb33427e45a..6258beeb241e 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -1,4 +1,5 @@
ADD_SUBDIRECTORY(cram)
+ADD_SUBDIRECTORY(shunit2)
MACRO(ADD_UNIT_TEST name)
ADD_EXECUTABLE(${name} ${name}.c)
diff --git a/tests/shunit2/CMakeLists.txt b/tests/shunit2/CMakeLists.txt
new file mode 100644
index ..74c2134cf3c8
--- /dev/null
+++ b/tests/shunit2/CMakeLists.txt
@@ -0,0 +1,7 @@
+ADD_TEST(
+ NAME shunit2
+ COMMAND tests.sh
+ WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
+)
+
+SET_PROPERTY(TEST shunit2 APPEND PROPERTY ENVIRONMENT
"TEST_JSON_SCRIPT=$")
diff --git a/tests/shunit2/shunit2/shunit2 b/tests/shunit2/shunit2/shunit2
new file mode 100644
index ..eef19d410146
--- /dev/null
+++ b/tests/shunit2/shunit2/shunit2
@@ -0,0 +1,1040 @@
+# $Id: shunit2 189 2008-07-11 11:46:54Z kate.w...@forestent.com $
+# vim:et:ft=sh:sts=2:sw=2
+# vim:foldmethod=marker:foldmarker=/**,*/
+#
+#/**
+#
+# http://www.forestent.com/projects/shelldoc/xsl/2005.0";>
+#
+# shUnit 2.1.4
+# Shell Unit Test Framework
+#
+# http://shunit2.sourceforge.net/
+#
+# written by Kate Ward
+# released under the LGPL
+#
+# this module implements a xUnit based unit test framework similar to JUnit
+#
+#*/
+
+SHUNIT_VERSION='2.1.4'
+
+_shunit_warn() { echo "shunit2:WARN $@" >&2; }
+_shunit_error() { echo "shunit2:ERROR $@" >&2; }
+_shunit_fatal() { echo "shunit2:FATAL $@" >&2; }
+
+SHUNIT_TRUE=0
+SHUNIT_FALSE=1
+SHUNIT_ERROR=2
+
+# specific shell checks
+if [ -n "${ZSH_VERSION:-}" ]; then
+ setopt |grep "^shwordsplit$" >/dev/null
+ if [ $? -ne ${SHUNIT_TRUE} ]; then
+_shunit_fatal 'zsh shwordsplit option is required for proper operation'
+exit ${SHUNIT_ERROR}
+ fi
+ if [ -z "${SHUNIT_PARENT:-}" ]; then
+_shunit_fatal "zsh does not pass \$0 through properly. please declare \
+\"SHUNIT_PARENT=\$0\" before calling shUnit2"
+exit ${SHUNIT_ERROR}
+ fi
+fi
+
+# shell flags for shunit2:
+# u - treat unset variables as an error when performing parameter expansion
+__SHUNIT_SHELL_FLAGS='u'
+
+# save the current set of shell flags, and then set some for ourself
+shunit_shellFlags_="$-"
+for shunit_shellFlag_ in `echo "${__SHUNIT_SHELL_FLAGS}" |sed 's/\(.\)/\1 /g'`
+do
+ set -${shunit_shellFlag_}
+done
+
+#
+# constants
+#
+
+__SHUNIT_ASSERT_MSG_PREFIX='ASSERT:'
+__SHUNIT_PARENT=${SHUNIT_PARENT:-$0}
+
+# set the constants readonly
+shunit_constants_=`set |grep "^__SHUNIT_" |cut -d= -f1`
+echo "${shunit_constants_}" |grep "^Binary file" >/dev/null
+if [ $? -eq 0 ]; then
+ # deal with binary junk in 'set' output
+ shunit_constants_=`set |grep -a "^__SHUNIT_" |cut -d= -f1`
+fi
+for shunit_const_ in ${shunit_constants_}; do
+ shunit_ro_opts_=''
+ if [ -n "${ZSH_VERSION:-}" ]; then
+case ${ZSH_VERSION} in
+ [123].*) ;;
+ *) shunit_ro_opts_='-g' ;; # declare readonly constants globally
+esac
+ fi
+ readonly ${shunit_ro_opts_} ${shunit_const_}
+done
+unset shunit_const_ shunit_constants_ shunit_ro_opts_
+
+# variables
+__shunit_skip=${SHUNIT_FALSE}
+__shunit_suite=''
+
+__shunit_testsPassed=0
+__shunit_testsFailed=0
+__shunit_testsSkipped=0
+__shunit_testsTotal=0
+
+# macros
+_SHUNIT_LINENO_='eval if [ "${1:-}" = "--lineno" ]; then [ -n "$2" ] &&
shunit_message_="[$2]"; shift 2; fi'
+
+#-
+# assert functions
+#
+
+#/**
+#
+#
+# void
+#
+#
+#
+#
+# assertEquals
+# string [message]
+# string expected
+# string actual
+#
+#
+# Asserts that expected and
+# actual are equal to one another. The message is
+# optional.
+#
+#
+#*/
+assertEquals()
+{
+ ${_SHUNIT_LINENO_}
+ if [ $# -lt 2 -o $# -gt 3 ]; then
+_shunit_error 'assertEquals() requires one or two arguments'
+return ${SHUNIT_ERROR}
+ fi
+ _shunit_shouldSkip && return ${SHUNIT_TRUE}
+
+ [ -z "${shunit_message_:-}" ] && shunit_message_=''
+ if [ $# -eq 3 ]; then
+shunit_message_="${shunit_message_}$1"
+shift
+ fi
+ shunit_expected_=$1
+ shunit_actual_=$2
+
+ shunit_return=${SHUNIT_TRUE}
+ if [ "${shunit_expected_}" = "${shunit_actual_}" ]; then
+_shunit_testPassed
+ else
+failNotEquals "${shunit_message_}" "${shunit_expected_}"
"${shunit_actual_}"
+shunit_return=${SHUNIT_FALSE}
+ fi
+
+ unset shunit_message_ shunit_expected_ shunit_ac
[OpenWrt-Devel] [PATCH libubox 4/4] blobmsg: blobmsg_add_json_element() 64-bit values
From: Dainis Jonitis
libjson-c json_type_int values are stored as int64_t. Use
json_object_get_int64() instead of json_object_get_int()
to avoid clamping to INT32_MAX.
Signed-off-by: Dainis Jonitis
[fixed author to match SoB, added unit test results]
Signed-off-by: Petr Štetiar
---
blobmsg_json.c| 10 --
tests/cram/test_blobmsg.t | 32
2 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/blobmsg_json.c b/blobmsg_json.c
index aee7a64fbca7..aedc2da22ebc 100644
--- a/blobmsg_json.c
+++ b/blobmsg_json.c
@@ -66,9 +66,15 @@ bool blobmsg_add_json_element(struct blob_buf *b, const char
*name, json_object
case json_type_boolean:
blobmsg_add_u8(b, name, json_object_get_boolean(obj));
break;
- case json_type_int:
- blobmsg_add_u32(b, name, json_object_get_int(obj));
+ case json_type_int: {
+ int64_t i64 = json_object_get_int64(obj);
+ if (i64 >= INT32_MIN && i64 <= INT32_MAX) {
+ blobmsg_add_u32(b, name, (uint32_t)i64);
+ } else {
+ blobmsg_add_u64(b, name, (uint64_t)i64);
+ }
break;
+ }
case json_type_double:
blobmsg_add_double(b, name, json_object_get_double(obj));
break;
diff --git a/tests/cram/test_blobmsg.t b/tests/cram/test_blobmsg.t
index 84ec143d6ff1..74ad326931fe 100644
--- a/tests/cram/test_blobmsg.t
+++ b/tests/cram/test_blobmsg.t
@@ -46,8 +46,8 @@ check that blobmsg is producing expected results:
32767 (i32)
-2147483648 (i32)
2147483647 (i32)
- -2147483648 (i32)
- 2147483647 (i32)
+ -9223372036854775808 (i64)
+ 9223372036854775807 (i64)
133.70 (dbl)
}
Testdata: {
@@ -60,8 +60,8 @@ check that blobmsg is producing expected results:
\tbar-max : 32767 (i32) (esc)
\tbaz-min : -2147483648 (i32) (esc)
\tbaz-max : 2147483647 (i32) (esc)
- \ttaz-min : -2147483648 (i32) (esc)
- \ttaz-max : 2147483647 (i32) (esc)
+ \ttaz-min : -9223372036854775808 (i64) (esc)
+ \ttaz-max : 9223372036854775807 (i64) (esc)
\tworld : 2 (str) (esc)
}
@@ -109,8 +109,8 @@ check that blobmsg is producing expected results:
32767 (i32)
-2147483648 (i32)
2147483647 (i32)
- -2147483648 (i32)
- 2147483647 (i32)
+ -9223372036854775808 (i64)
+ 9223372036854775807 (i64)
133.70 (dbl)
}
Testdata: {
@@ -123,8 +123,8 @@ check that blobmsg is producing expected results:
\tbar-max : 32767 (i32) (esc)
\tbaz-min : -2147483648 (i32) (esc)
\tbaz-max : 2147483647 (i32) (esc)
- \ttaz-min : -2147483648 (i32) (esc)
- \ttaz-max : 2147483647 (i32) (esc)
+ \ttaz-min : -9223372036854775808 (i64) (esc)
+ \ttaz-max : 9223372036854775807 (i64) (esc)
\tworld : 2 (str) (esc)
}
@@ -172,8 +172,8 @@ check that blobmsg is producing expected results:
32767 (i32)
-2147483648 (i32)
2147483647 (i32)
- -2147483648 (i32)
- 2147483647 (i32)
+ -9223372036854775808 (i64)
+ 9223372036854775807 (i64)
133.70 (dbl)
}
Testdata: {
@@ -186,8 +186,8 @@ check that blobmsg is producing expected results:
\tbar-max : 32767 (i32) (esc)
\tbaz-min : -2147483648 (i32) (esc)
\tbaz-max : 2147483647 (i32) (esc)
- \ttaz-min : -2147483648 (i32) (esc)
- \ttaz-max : 2147483647 (i32) (esc)
+ \ttaz-min : -9223372036854775808 (i64) (esc)
+ \ttaz-max : 9223372036854775807 (i64) (esc)
\tworld : 2 (str) (esc)
}
@@ -235,8 +235,8 @@ check that blobmsg is producing expected results:
32767 (i32)
-2147483648 (i32)
2147483647 (i32)
- -2147483648 (i32)
- 2147483647 (i32)
+ -9223372036854775808 (i64)
+ 9223372036854775807 (i64)
133.70 (dbl)
}
Testdata: {
@@ -249,7 +249,7 @@ check that blobmsg is producing expected results:
\tbar-max : 32767 (i32) (esc)
\tbaz-min : -2147483648 (i32) (esc)
\tbaz-max : 2147483647 (i32) (esc)
- \ttaz-min : -2147483648 (i32) (esc)
- \ttaz-max : 2147483647 (i32) (esc)
+ \ttaz-min : -9223372036854775808 (i64) (esc)
+ \ttaz-max : 9223372036854775807 (i64) (esc)
\tworld : 2 (str) (esc)
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH libubox 2/4] tests: blobmsg/json: add more test cases
* add missing test with sanitizers
* add test case for blobmsg_add_json_from_string
* add test cases for all numeric types
* print types for each variable
Signed-off-by: Petr Štetiar
---
tests/cram/test_blobmsg.t | 255 +++---
tests/test-blobmsg.c | 47 +--
2 files changed, 275 insertions(+), 27 deletions(-)
diff --git a/tests/cram/test_blobmsg.t b/tests/cram/test_blobmsg.t
index 3a5801a5a0f4..9ab2acf6e2d8 100644
--- a/tests/cram/test_blobmsg.t
+++ b/tests/cram/test_blobmsg.t
@@ -1,32 +1,255 @@
check that blobmsg is producing expected results:
$ [ -n "$TEST_BIN_DIR" ] && export PATH="$TEST_BIN_DIR:$PATH"
+
$ valgrind --quiet --leak-check=full test-blobmsg
+ [*] blobmsg dump:
+ Message: Hello, world!
+ List: {
+ 0 (i8)
+ 100 (i8)
+ -128 (i8)
+ 127 (i8)
+ -32768 (i16)
+ 32767 (i16)
+ -2147483648 (i32)
+ 2147483647 (i32)
+ -9223372036854775808 (i64)
+ 9223372036854775807 (i64)
+ 133.70 (dbl)
+ }
+ Testdata: {
+ \tdouble : 133.70 (dbl) (esc)
+ \tfoo : 0 (i8) (esc)
+ \tpoo : 100 (i8) (esc)
+ \tmoo-min : -128 (i8) (esc)
+ \tmoo-max : 127 (i8) (esc)
+ \tbar-min : -32768 (i16) (esc)
+ \tbar-max : 32767 (i16) (esc)
+ \tbaz-min : -2147483648 (i32) (esc)
+ \tbaz-max : 2147483647 (i32) (esc)
+ \ttaz-min : -9223372036854775808 (i64) (esc)
+ \ttaz-max : 9223372036854775807 (i64) (esc)
+ \tworld : 2 (str) (esc)
+ }
+
+ [*] blobmsg to json: {"message":"Hello,
world!","testdata":{"double":133.70,"foo":false,"poo":true,"moo-min":true,"moo-max":true,"bar-min":32768,"bar-max":32767,"baz-min":-2147483648,"baz-max":2147483647,"taz-min":-9223372036854775808,"taz-max":9223372036854775807,"world":"2"},"list":[false,true,true,true,32768,32767,-2147483648,2147483647,-9223372036854775808,9223372036854775807,133.70]}
+
+ [*] blobmsg from json:
+ Message: Hello, world!
+ List: {
+ 0 (i8)
+ 1 (i8)
+ 1 (i8)
+ 1 (i8)
+ 32768 (i32)
+ 32767 (i32)
+ -2147483648 (i32)
+ 2147483647 (i32)
+ -2147483648 (i32)
+ 2147483647 (i32)
+ 133.70 (dbl)
+ }
+ Testdata: {
+ \tdouble : 133.70 (dbl) (esc)
+ \tfoo : 0 (i8) (esc)
+ \tpoo : 1 (i8) (esc)
+ \tmoo-min : 1 (i8) (esc)
+ \tmoo-max : 1 (i8) (esc)
+ \tbar-min : 32768 (i32) (esc)
+ \tbar-max : 32767 (i32) (esc)
+ \tbaz-min : -2147483648 (i32) (esc)
+ \tbaz-max : 2147483647 (i32) (esc)
+ \ttaz-min : -2147483648 (i32) (esc)
+ \ttaz-max : 2147483647 (i32) (esc)
+ \tworld : 2 (str) (esc)
+ }
+
+ $ test-blobmsg-san
+ [*] blobmsg dump:
+ Message: Hello, world!
+ List: {
+ 0 (i8)
+ 100 (i8)
+ -128 (i8)
+ 127 (i8)
+ -32768 (i16)
+ 32767 (i16)
+ -2147483648 (i32)
+ 2147483647 (i32)
+ -9223372036854775808 (i64)
+ 9223372036854775807 (i64)
+ 133.70 (dbl)
+ }
+ Testdata: {
+ \tdouble : 133.70 (dbl) (esc)
+ \tfoo : 0 (i8) (esc)
+ \tpoo : 100 (i8) (esc)
+ \tmoo-min : -128 (i8) (esc)
+ \tmoo-max : 127 (i8) (esc)
+ \tbar-min : -32768 (i16) (esc)
+ \tbar-max : 32767 (i16) (esc)
+ \tbaz-min : -2147483648 (i32) (esc)
+ \tbaz-max : 2147483647 (i32) (esc)
+ \ttaz-min : -9223372036854775808 (i64) (esc)
+ \ttaz-max : 9223372036854775807 (i64) (esc)
+ \tworld : 2 (str) (esc)
+ }
+
+ [*] blobmsg to json: {"message":"Hello,
world!","testdata":{"double":133.70,"foo":false,"poo":true,"moo-min":true,"moo-max":true,"bar-min":32768,"bar-max":32767,"baz-min":-2147483648,"baz-max":2147483647,"taz-min":-9223372036854775808,"taz-max":9223372036854775807,"world":"2"},"list":[false,true,true,true,32768,32767,-2147483648,2147483647,-9223372036854775808,9223372036854775807,133.70]}
+
+ [*] blobmsg from json:
Message: Hello, world!
List: {
- 0
- 1
- 2
- 133.70
+ 0 (i8)
+ 1 (i8)
+ 1 (i8)
+ 1 (i8)
+ 32768 (i32)
+ 32767 (i32)
+ -2147483648 (i32)
+ 2147483647 (i32)
+ -2147483648 (i32)
+ 2147483647 (i32)
+ 133.70 (dbl)
}
Testdata: {
- \tdouble : 133.70 (esc)
- \thello : 1 (esc)
- \tworld : 2 (esc)
+ \tdouble : 133.70 (dbl) (esc)
+ \tfoo : 0 (i8) (esc)
+ \tpoo : 1 (i8) (esc)
+ \tmoo-min : 1 (i8) (esc)
+ \tmoo-max : 1 (i8) (esc)
+ \tbar-min : 32768 (i32) (esc)
+ \tbar-max : 32767 (i32) (esc)
+ \tbaz-min : -2147483648 (i32) (esc)
+ \tbaz-max : 2147483647 (i32) (esc)
+ \ttaz-min : -2147483648 (i32) (esc)
+ \ttaz-max : 2147483647 (i32) (esc)
+ \tworld : 2 (str) (esc)
}
- json: {"message":"Hello,
world!","testdata":{"double":133.70,"hello":1,"world":"2"},"list":[0,1,2,133.70]}
$ test-blobmsg-san
+ [*] blobmsg dump:
+ Message: Hello, world!
+ List: {
+ 0 (i8)
+ 100 (i8)
+ -128 (i8)
+ 127 (i8)
+ -32768 (i16)
+ 32767 (i16)
+ -2147483648 (i32)
+ 2147483647 (i32)
+ -9223372036854775808 (i64)
+ 9223372036854775807 (i64)
+ 133.70 (dbl)
+ }
+ Testdata: {
+ \tdouble : 133.70 (dbl) (esc)
+ \tfoo : 0 (i8) (esc)
+ \tpoo : 100 (i8) (esc)
+ \tmoo-min : -128 (i8) (esc)
+ \tmoo-max : 127 (i8) (esc)
+ \tbar-min : -32768 (i16) (esc)
+ \tbar-max : 32767 (i16) (esc)
+ \tb
[OpenWrt-Devel] [PATCH libubox 3/4] blobmsg_json: fix int16 serialization
int16 blobmsg type is currently being serialized as uint16_t due to
missing cast during JSON output.
Following blobmsg content:
bar-min: -32768 (i16)
bar-max: 32767 (i16)
Produces following JSON:
{ "bar-min":32768,"bar-max":32767 }
Whereas one would expect:
{ "bar-min":-32768,"bar-max":32767 }
Signed-off-by: Petr Štetiar
---
blobmsg_json.c| 2 +-
tests/cram/test_blobmsg.t | 24
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/blobmsg_json.c b/blobmsg_json.c
index 18592111b4dd..aee7a64fbca7 100644
--- a/blobmsg_json.c
+++ b/blobmsg_json.c
@@ -249,7 +249,7 @@ static void blobmsg_format_element(struct strbuf *s, struct
blob_attr *attr, boo
sprintf(buf, "%s", *(uint8_t *)data ? "true" : "false");
break;
case BLOBMSG_TYPE_INT16:
- sprintf(buf, "%d", be16_to_cpu(*(uint16_t *)data));
+ sprintf(buf, "%d", (int16_t) be16_to_cpu(*(uint16_t *)data));
break;
case BLOBMSG_TYPE_INT32:
sprintf(buf, "%d", (int32_t) be32_to_cpu(*(uint32_t *)data));
diff --git a/tests/cram/test_blobmsg.t b/tests/cram/test_blobmsg.t
index 9ab2acf6e2d8..84ec143d6ff1 100644
--- a/tests/cram/test_blobmsg.t
+++ b/tests/cram/test_blobmsg.t
@@ -33,7 +33,7 @@ check that blobmsg is producing expected results:
\tworld : 2 (str) (esc)
}
- [*] blobmsg to json: {"message":"Hello,
world!","testdata":{"double":133.70,"foo":false,"poo":true,"moo-min":true,"moo-max":true,"bar-min":32768,"bar-max":32767,"baz-min":-2147483648,"baz-max":2147483647,"taz-min":-9223372036854775808,"taz-max":9223372036854775807,"world":"2"},"list":[false,true,true,true,32768,32767,-2147483648,2147483647,-9223372036854775808,9223372036854775807,133.70]}
+ [*] blobmsg to json: {"message":"Hello,
world!","testdata":{"double":133.70,"foo":false,"poo":true,"moo-min":true,"moo-max":true,"bar-min":-32768,"bar-max":32767,"baz-min":-2147483648,"baz-max":2147483647,"taz-min":-9223372036854775808,"taz-max":9223372036854775807,"world":"2"},"list":[false,true,true,true,-32768,32767,-2147483648,2147483647,-9223372036854775808,9223372036854775807,133.70]}
[*] blobmsg from json:
Message: Hello, world!
@@ -42,7 +42,7 @@ check that blobmsg is producing expected results:
1 (i8)
1 (i8)
1 (i8)
- 32768 (i32)
+ -32768 (i32)
32767 (i32)
-2147483648 (i32)
2147483647 (i32)
@@ -56,7 +56,7 @@ check that blobmsg is producing expected results:
\tpoo : 1 (i8) (esc)
\tmoo-min : 1 (i8) (esc)
\tmoo-max : 1 (i8) (esc)
- \tbar-min : 32768 (i32) (esc)
+ \tbar-min : -32768 (i32) (esc)
\tbar-max : 32767 (i32) (esc)
\tbaz-min : -2147483648 (i32) (esc)
\tbaz-max : 2147483647 (i32) (esc)
@@ -96,7 +96,7 @@ check that blobmsg is producing expected results:
\tworld : 2 (str) (esc)
}
- [*] blobmsg to json: {"message":"Hello,
world!","testdata":{"double":133.70,"foo":false,"poo":true,"moo-min":true,"moo-max":true,"bar-min":32768,"bar-max":32767,"baz-min":-2147483648,"baz-max":2147483647,"taz-min":-9223372036854775808,"taz-max":9223372036854775807,"world":"2"},"list":[false,true,true,true,32768,32767,-2147483648,2147483647,-9223372036854775808,9223372036854775807,133.70]}
+ [*] blobmsg to json: {"message":"Hello,
world!","testdata":{"double":133.70,"foo":false,"poo":true,"moo-min":true,"moo-max":true,"bar-min":-32768,"bar-max":32767,"baz-min":-2147483648,"baz-max":2147483647,"taz-min":-9223372036854775808,"taz-max":9223372036854775807,"world":"2"},"list":[false,true,true,true,-32768,32767,-2147483648,2147483647,-9223372036854775808,9223372036854775807,133.70]}
[*] blobmsg from json:
Message: Hello, world!
@@ -105,7 +105,7 @@ check that blobmsg is producing expected results:
1 (i8)
1 (i8)
1 (i8)
- 32768 (i32)
+ -32768 (i32)
32767 (i32)
-2147483648 (i32)
2147483647 (i32)
@@ -119,7 +119,7 @@ check that blobmsg is producing expected results:
\tpoo : 1 (i8) (esc)
\tmoo-min : 1 (i8) (esc)
\tmoo-max : 1 (i8) (esc)
- \tbar-min : 32768 (i32) (esc)
+ \tbar-min : -32768 (i32) (esc)
\tbar-max : 32767 (i32) (esc)
\tbaz-min : -2147483648 (i32) (esc)
\tbaz-max : 2147483647 (i32) (esc)
@@ -159,7 +159,7 @@ check that blobmsg is producing expected results:
\tworld : 2 (str) (esc)
}
- [*] blobmsg to json: {"message":"Hello,
world!","testdata":{"double":133.70,"foo":false,"poo":true,"moo-min":true,"moo-max":true,"bar-min":32768,"bar-max":32767,"baz-min":-2147483648,"baz-max":2147483647,"taz-min":-9223372036854775808,"taz-max":9223372036854775807,"world":"2"},"list":[false,true,true,true,32768,32767,-2147483648,2147483647,-9223372036854775808,9223372036854775807,133.70]}
+ [*] blobmsg to json: {"message":"Hello,
world!","testdata":{"double":133.70,"foo":false,"poo":true,"moo-min":true,"moo-max":true,"bar-min":-32768,"bar-max":32767,"baz-min":-2147483648,"baz-max":2147483647,"taz-min":-92233720
[OpenWrt-Devel] [PATCH libubox 0/4] more tests and fixes
Hi, this patch series increases unit test coverage and fixes int16/int64 JSON serialization. Dainis Jonitis (1): blobmsg: blobmsg_add_json_element() 64-bit values Petr Štetiar (3): tests: include json script shunit2 based testing tests: blobmsg/json: add more test cases blobmsg_json: fix int16 serialization blobmsg_json.c| 12 +- tests/CMakeLists.txt |1 + tests/cram/test_blobmsg.t | 255 +++- tests/shunit2/CMakeLists.txt |7 + tests/shunit2/shunit2/shunit2 | 1040 + tests/shunit2/tests.sh| 287 + tests/test-blobmsg.c | 47 +- 7 files changed, 1619 insertions(+), 30 deletions(-) create mode 100644 tests/shunit2/CMakeLists.txt create mode 100644 tests/shunit2/shunit2/shunit2 create mode 100755 tests/shunit2/tests.sh ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] commit message in YAML format for new devices
On Sun, 12 Jan 2020 11:47:29 -1000, Paul Spooren wrote: > All commits adding new devices already include most relevant information > for creating the overview. However it would be convenient if developers > would format their commit messages in a generic format, therefore I'd > propose the following: > > Every commit message for newly added devices must contain a number of > hardware information and steps for an initial installation. > The hardware information should contain at least the following > information, maybe more: > > SoC, flash, ram, wifi, LEDs, buttons, USB, serial, vendor, model, device > tree ID, Ethernet ports Having just pitched this idea to you a few minutes ago, of course I'll be the first to ACK. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] commit message in YAML format for new devices
Hi all, some time ago I created a (now outdated) device overview[0] based on YAML meta data. This approach could simplify maintaining an device overview and device specific pages[1]. All commits adding new devices already include most relevant information for creating the overview. However it would be convenient if developers would format their commit messages in a generic format, therefore I'd propose the following: Every commit message for newly added devices must contain a number of hardware information and steps for an initial installation. The hardware information should contain at least the following information, maybe more: SoC, flash, ram, wifi, LEDs, buttons, USB, serial, vendor, model, device tree ID, Ethernet ports An illustrative commit therefore: soc: Qualcomm IPQ4029 ram_mb: 512 flash: - size_mb: 128 type: SPI-NAND (Macronix) - size_mb: 4 type: SPI-NOR (Macronix MX25R3235F) usb: - version: 2 ports: 1 - version: 3 ports: 2 ethernet: - mbit: 100 ports: 4 - mbit: 1000 ports: 1 led_count: 3 serial: false vendor: Foobar model: Lorem Ipsum variant: v4 dt_id: foobar_lorem-ipsum_v4 target: ath79/generic Additionally stuff like cpu_mhz, cpu_cores and such could also be added, the OpenWrt hwdata offers some additional information which should be added if relevant[2]. To write a multi-line text for the installation or comments, a "|" can be used as the following: installation: | 1. Get the OpenWrt initramfs image. Rename it to ipq40xx.ari and put it into the TFTP server root directory. Configure the TFTP server to be reachable at 192.168.1.75/24. Connect the machine running the TFTP server to the E0 (!) ethernet port of the access point, as it only tries to pull from the WAN port. 2. Connect to the serial console. Interrupt autobooting by pressing Enter when prompted. ... comments: | VCC - NC D+ - TX D- - RX GND - GND Installation steps would be merged to templates as many devices share the same steps, only varying the TFTP binary name or IP. This could become part of the general information, like a variable called tftp_ip and tftp_bin. All info would be added to a metadata repository like openwrt/devices.git, which can then be updated by the community. To verify the YAML data a tool like yamllint[3] (Python) could be used. The main motivation is to have an simple and appealing overview which allows searching/filtering for devices, seeing the support status, retrieve firmware and having an easily maintained, up to date documentation. Please share your thoughts. Sunshine, Paul [0]: https://aparcar.github.io/openwrt-devices/ [1]: https://aparcar.github.io/openwrt-devices/devices/tp-link_tl-wdr4300/ [2]: https://github.com/aparcar/openwrt-devices/blob/master/_data/devices/open-mesh_a62.yml [3]: https://github.com/adrienverge/yamllint ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: add support for D-Link DIR-505
This commit adds support for the D-Link DIR-505, previously supported in
ar71xx.
Hardware
SoC: Atheros AR9330
FLASH: 8M SPI-NOR
RAM: 64M
WIFI: 1T1R 1SS Atheros AR9330
LED: Power green, Status red
BTN: WPS, Reset
Installation
Currently, installation is only possible by sysupgrading from an earlier
OpenWrt version, U-Boot TFTP or a modded U-Boot. I do not have the
original bootloader from D-Link on my device anymore, so i cannot test
the factory image.
Signed-off-by: David Bauer
---
.../linux/ath79/dts/ar9330_dlink_dir-505.dts | 149 ++
.../generic/base-files/etc/board.d/02_network | 4 +
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 +
target/linux/ath79/image/generic.mk | 10 ++
4 files changed, 164 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9330_dlink_dir-505.dts
diff --git a/target/linux/ath79/dts/ar9330_dlink_dir-505.dts
b/target/linux/ath79/dts/ar9330_dlink_dir-505.dts
new file mode 100644
index 00..6984176daa
--- /dev/null
+++ b/target/linux/ath79/dts/ar9330_dlink_dir-505.dts
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "ar9330.dtsi"
+
+/ {
+ model = "D-Link DIR-505";
+ compatible = "dlink,dir-505", "qca,ar9330";
+
+ aliases {
+ serial0 = &uart;
+ led-boot = &led_power_green;
+ led-failsafe = &led_status_red;
+ led-running = &led_power_green;
+ led-upgrade = &led_status_red;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ wps {
+ label = "WPS button";
+ gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ reset {
+ label = "Reset button";
+ gpios = <&gpio 12 GPIO_ACTIVE_HIGH>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&jtag_disable_pins>;
+
+ led_power_green: power {
+ label = "d-link:green:power";
+ gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
+ };
+
+ led_status_red: status {
+ label = "d-link:red:status";
+ gpios = <&gpio 26 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&uart {
+ status = "okay";
+};
+
+&gpio {
+ status = "okay";
+
+ led_enable {
+ gpio-hog;
+ output-low;
+ gpios = <1 GPIO_ACTIVE_LOW>;
+ line-name = "d-link:power:led";
+ };
+};
+
+&usb {
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usb_phy {
+ status = "okay";
+};
+
+ð0 {
+ status = "okay";
+
+ gmac-config {
+ device = <&gmac>;
+ switch-phy-addr-swap = <0>;
+ switch-phy-swap = <0>;
+ };
+};
+
+ð1 {
+ compatible = "syscon", "simple-mfd";
+ status = "okay";
+};
+
+&spi {
+ num-chipselects = <1>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <5000>;
+ reg = <0>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x1>;
+ read-only;
+ };
+
+ art: partition@1 {
+ label = "art";
+ reg = <0x1 0x1>;
+ read-only;
+ };
+
+ mac: partition@2 {
+ label = "mac";
+ reg = <0x2 0x1>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "nvram";
+ reg = <0x3 0x1>;
+ read-only;
+ };
+
+ partition@4 {
+ label = "language";
+ reg = <0x4 0x4>;
+ read-only;
+ };
+
+ partition@8 {
+ compatible = "denx,uimage";
+ label = "firmware";
+ reg = <0x8 0x78>;
+ };
+ };
+ };
+};
+
+&wmac {
+ status = "okay";
+ qca,no-eeprom;
Re: [OpenWrt-Devel] [PATCH] blobmsg: blobmsg_add_json_element() 64-bit values
Dainis Jonitis [2020-01-10 16:41:04]:
Hi,
next time please make sure, that your From: match the Signed-off-by: -- I've
fixed it this time.
> libjson-c json_type_int values are stored as int64_t. Use
> json_object_get_int64() instead of json_object_get_int()
> to avoid clamping to INT32_MAX.
>
> Signed-off-by: Dainis Jonitis
> ---
> blobmsg_json.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/blobmsg_json.c b/blobmsg_json.c
> index 1859211..394861a 100644
> --- a/blobmsg_json.c
> +++ b/blobmsg_json.c
> @@ -66,9 +66,15 @@ bool blobmsg_add_json_element(struct blob_buf *b, const
> char *name, json_object
> case json_type_boolean:
> blobmsg_add_u8(b, name, json_object_get_boolean(obj));
> break;
> - case json_type_int:
> - blobmsg_add_u32(b, name, json_object_get_int(obj));
> + case json_type_int: {
> + int64_t i64 = json_object_get_int64(obj);
> + if (i64 >= INT32_MIN && i64 <= INT32_MAX) {
This INT32_MAX should be UINT32_MAX, otherwise you're going to cast valid u32
values as u64, right?
If you agree, I can do this small fix myself directly in my tree, to spare you
from sending v2.
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [sdwalker/sdwalker.github.io] 38772e: This week's update
Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: 38772eae5e58f5b777a6981ce52618a20211de5c https://github.com/sdwalker/sdwalker.github.io/commit/38772eae5e58f5b777a6981ce52618a20211de5c Author: Stephen Walker Date: 2020-01-12 (Sun, 12 Jan 2020) Changed paths: M uscan/index-18.06.html M uscan/index-19.07.html M uscan/index.html Log Message: --- This week's update ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][libubox] blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Petr Štetiar [2020-01-12 12:43:07]: > Those checks are run now automatically by CI after each Git push. I don't know if it's obvious how to use the tests/fuzzing inside libubox (and other C projects), so I've written something small[1] about the CI checks and used libubox as example. 1. http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020831.html -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [19.07] ramips: add kmod-mt7615e to Xiaomi Mi Router 3 Pro
Hi Josef, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Josef Schlehofer > Sent: Sonntag, 12. Januar 2020 11:13 > To: openwrt-devel@lists.openwrt.org > Subject: [OpenWrt-Devel] [PATCH] [19.07] ramips: add kmod-mt7615e to > Xiaomi Mi Router 3 Pro > > From: Ozgur Can Leonard > > The package kmod-mt7615e was added to this router in the master branch > [1] to have working Wi-Fi, but it is not included in OpenWrt 19.07. It was > reported on OpenWrt forum [2] and tested that after installing this package > Wi-Fi works. > > [1] > https://github.com/openwrt/openwrt/commit/d7c082ba4f7de97b3708d1f4a > 064954ffc774778 > [2] https://forum.openwrt.org/t/xiaomi-r3p-no-wifi-with-latest-stable-19- > 07-0-after-upgrade/52299 > I'd actually prefer to just cherry-pick the referenced commit [1] from master to openwrt-19.07, so we do not have different patches in master and 19.07. I've put the backported version in my staging-19.07 branch: https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=refs/heads/staging-19.07 Are you fine with that? Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][libubox] blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
juraj.vijt...@sartura.hr [2020-01-12 12:26:18]:
Hi,
> @@ -35,10 +35,16 @@ static bool blobmsg_check_name(const struct blob_attr
> *attr, size_t len, bool na
> char *limit = (char *) attr + len;
> const struct blobmsg_hdr *hdr;
>
> + if (len < sizeof(struct blob_attr) + sizeof(struct blobmsg_hdr))
> + return false;
> +
why is this change needed? If I'm reading it correctly, then blobmsg_check_name
is only called from blobmsg_check_attr_len and there is already much stricter
guard:
bool blobmsg_check_attr_len(const struct blob_attr *attr, bool name, size_t
len)
{
if (len < sizeof(struct blob_attr))
return false;
if (!blobmsg_check_name(attr, len, name))
return false;
> hdr = blob_data(attr);
> if (name && !hdr->namelen)
> return false;
>
> + if (len < sizeof(struct blob_attr) + sizeof(struct blobmsg_hdr) +
> blobmsg_namelen(hdr) + 1)
> + return false;
Didn't checked it in detail yet, but isn't it almost the same as the check few
lines bellow, just written differently?
> if ((char *) hdr->name + blobmsg_namelen(hdr) > limit)
> return false;
...
> @@ -191,7 +197,11 @@ int blobmsg_parse(const struct blobmsg_policy *policy,
> int policy_len,
> }
>
> __blob_for_each_attr(attr, data, len) {
> + if (len < sizeof(struct blob_attr) + sizeof(struct blobmsg_hdr))
> + return -1;
If there is such problem, then this should be probably fixed directly in
__blob_for_each_attr so we possibly protect other __blob_for_each_attr
users[1].
> hdr = blob_data(attr);
> + if (len < sizeof(struct blob_attr) + sizeof(struct blobmsg_hdr)
> + blobmsg_namelen(hdr) + 1)
> + return -1;
It would be really nice to have blobmsg which could prove, that this check is
needed.
1. https://lxr.openwrt.org/ident?i=__blob_for_each_attr
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][libubox] blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
juraj.vijt...@sartura.hr [2020-01-12 12:26:18]: Hi, thanks for the fix. > Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The > out of bounds read happens because blob_attr and blobmsg_hdr have > flexible array members, whose size is 0 in the corresponding sizeofs. > For example the __blob_for_each_attr macro checks whether rem >= > sizeof(struct blob_attr). However, what LibFuzzer discovered was, > if the input data was only 4 bytes, the data would be casted to blob_attr, > and later on blob_data(attr) would be called even though attr->data was empty. > The same issue could appear with data larger than 4 bytes, where data > wasn't empty, but contained only the start of the blobmsg_hdr struct, > and blobmsg_hdr name was empty. The bugs were discovered by fuzzing > blobmsg_parse and blobmsg_array_parse with LibFuzzer. I don't know if you're aware, but there is already some LibFuzzer based fuzzing in tests/fuzz/test-fuzz.c and the corpus is in tests/fuzz/corpus. Those checks are run now automatically by CI after each Git push. It would be nice, if you could share the fuzz input (and mods to test-fuzz.c if any) leading to this OOB reads, so we can guard against future regression. BTW this is not mandatory, it's optional, but I'm going to do this anyway as I'm wondering why current fuzzing didn't catched this issue, so you're going to save me some time :-) Thanks! -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][libubox] blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The
out of bounds read happens because blob_attr and blobmsg_hdr have
flexible array members, whose size is 0 in the corresponding sizeofs.
For example the __blob_for_each_attr macro checks whether rem >=
sizeof(struct blob_attr). However, what LibFuzzer discovered was,
if the input data was only 4 bytes, the data would be casted to blob_attr,
and later on blob_data(attr) would be called even though attr->data was empty.
The same issue could appear with data larger than 4 bytes, where data
wasn't empty, but contained only the start of the blobmsg_hdr struct,
and blobmsg_hdr name was empty. The bugs were discovered by fuzzing
blobmsg_parse and blobmsg_array_parse with LibFuzzer.
Signed-off-by: Juraj Vijtiuk
CC: Luka Perkov
diff --git a/blobmsg.c b/blobmsg.c
index 1dd57e1..0988f60 100644
--- a/blobmsg.c
+++ b/blobmsg.c
@@ -35,10 +35,16 @@ static bool blobmsg_check_name(const struct blob_attr
*attr, size_t len, bool na
char *limit = (char *) attr + len;
const struct blobmsg_hdr *hdr;
+ if (len < sizeof(struct blob_attr) + sizeof(struct blobmsg_hdr))
+ return false;
+
hdr = blob_data(attr);
if (name && !hdr->namelen)
return false;
+ if (len < sizeof(struct blob_attr) + sizeof(struct blobmsg_hdr) +
blobmsg_namelen(hdr) + 1)
+ return false;
+
if ((char *) hdr->name + blobmsg_namelen(hdr) > limit)
return false;
@@ -191,7 +197,11 @@ int blobmsg_parse(const struct blobmsg_policy *policy, int
policy_len,
}
__blob_for_each_attr(attr, data, len) {
+ if (len < sizeof(struct blob_attr) + sizeof(struct blobmsg_hdr))
+ return -1;
hdr = blob_data(attr);
+ if (len < sizeof(struct blob_attr) + sizeof(struct blobmsg_hdr)
+ blobmsg_namelen(hdr) + 1)
+ return -1;
for (i = 0; i < policy_len; i++) {
if (!policy[i].name)
continue;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [19.07] ramips: add kmod-mt7615e to Xiaomi Mi Router 3 Pro
From: Ozgur Can Leonard The package kmod-mt7615e was added to this router in the master branch [1] to have working Wi-Fi, but it is not included in OpenWrt 19.07. It was reported on OpenWrt forum [2] and tested that after installing this package Wi-Fi works. [1] https://github.com/openwrt/openwrt/commit/d7c082ba4f7de97b3708d1f4a064954ffc774778 [2] https://forum.openwrt.org/t/xiaomi-r3p-no-wifi-with-latest-stable-19-07-0-after-upgrade/52299 Signed-off-by: Ozgur Can Leonard Signed-off-by: Josef Schlehofer [added commit message] --- target/linux/ramips/image/mt7621.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index 03ab9a4c37..6280a6246f 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -265,7 +265,7 @@ define Device/xiaomi_mir3p IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata IMAGE/factory.bin := append-kernel | pad-to $$(KERNEL_SIZE) | append-ubi | check-size (IMAGE_SIZE) DEVICE_PACKAGES := \ - kmod-usb3 kmod-usb-ledtrig-usbport wpad-basic uboot-envtools + kmod-mt7615e kmod-usb3 kmod-usb-ledtrig-usbport wpad-basic uboot-envtools endef TARGET_DEVICES += xiaomi_mir3p -- 2.24.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
