>> That looks more like a parse error then a real output...
>
> hmm.. how do I see the "real" configuration, then?
If I were to hazard a guess, I would say the first 2 lines are real,
and then it mis-parses some sort of end-of-message indicator and
starts mis-parsing the rest of the message.
Probably some sort of architecture+endianness+padding+alignment
compiler mismatch between kernel compilation and ip utility
compilation.
I guess you could run something like:
# strace -e socket,setsockopt,bind,getsockname,sendto,recvmsg,send -s
256 -vv ip -6 rule
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 3
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [1048576], 4) = 0
bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=13875, groups=00000000}, [12]) = 0
sendto(3,
"(\0\0\0\"\0\1\3\361\227\307T\0\0\0\0\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\35\0\1\0\0\0",
40, 0, NULL, 0) = 40
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=00000000}, msg_iov(1)=[{",\0\0\0
\0\2\0\361\227\307T36\0\0\n\0\0\0\377\0\0\1\0\0\0\0\10\0\17\0\377\0\0\0\10\0\16\0\377\377\377\3774\0\0\0
\0\2\0\361\227\307T36\0\0\n\0\0\0\376\0\0\1\0\0\0\0\10\0\17\0\376\0\0\0\10\0\16\0\377\377\377\377\10\0\6\0\376\177\0\0",
16384}], msg_controllen=0, msg_flags=0}, 0) = 96
0: from all lookup local
32766: from all lookup main
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=00000000},
msg_iov(1)=[{"\24\0\0\0\3\0\2\0\361\227\307T36\0\0\0\0\0\0", 16384}],
msg_controllen=0, msg_flags=0}, 0) = 20
+++ exited with 0 +++
# strace -e socket,setsockopt,bind,getsockname,sendto,recvmsg,send -s
256 -vv ip -6 rule
socket(PF_NETLINK, SOCK_RAW, 0) = 3
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0
bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=32375, groups=00000000}, [12]) = 0
send(3, "\24\0\0\0\"\0\1\3\330\230\307T\0\0\0\0\n\0\0\0"..., 20, 0) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=00000000},
msg_iov(1)=[{"$\0\0\0\2\0\0\0\330\230\307Tw~\0\0\352\377\377\377\24\0\0\0\"\0\1\3\330\230\307T\0\0\0\0\0\0\0\0\0\0\0"...,
16384}], msg_controllen=0, msg_flags=0}, 0) = 36
RTNETLINK answers: Invalid argument
Dump terminated
# strace -e socket,setsockopt,bind,getsockname,sendto,recvmsg,send -s
256 -vv ip -6 rule
socket(PF_NETLINK, SOCK_RAW, 0) = 3
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0
bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=27537, groups=00000000}, [12]) = 0
send(3, "\0\0\0\24\0\"\3\1T\307\232\212\0\0\0\0\n\0\0\0", 20, 0) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=00000000}, msg_iov(1)=[{"\0\0\0$\0
\0\2T\307\232\212\0\0k\221\n\0\0\0\377\0\0\1\0\0\0\1\0\10\0\17\0\0\0\377\0\0\0,\0
\0\2T\307\232\212\0\0k\221\n\0\0\0\376\0\0\1\0\0\0\0\0\10\0\17\0\0\0\376\0\10\0\6\0\0\177\376\0\0\0\0\0\0\0"...,
16384}], msg_controllen=0, msg_flags=0}, 0) = 80
0: from all lookup local
32766: from all lookup main
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=00000000},
msg_iov(1)=[{"\0\0\0\24\0\3\0\2T\307\232\212\0\0k\221\0\0\0\0\377\0\0\1\0\0\0\1\0\10\0\17\0\0\0\377\0\0\0,\0
\0\2T\307\232\212\0\0k\221\n\0\0\0\376\0\0\1\0\0\0\0\0\10\0\17\0\0\0\376\0\10\0\6\0\0\177\376\0\0\0\0\0\0\0"...,
16384}], msg_controllen=0, msg_flags=0}, 0) = 20
The first output is from an x86_64 fedora 21 'Linux eonwe.lan
3.17.7-300.fc21.x86_64 #1 SMP Wed Dec 17 03:08:44 UTC 2014 x86_64
x86_64 x86_64 GNU/Linux' box,
the second from a Kamikaze 8.09.2 'Linux router 2.4.35.4 #12 Wed Dec
30 19:27:21 UTC 2009 mips unknown' WRT54GL router,
and the third from a Backfire (10.03.1, r29592) 'Linux OpenWrt
2.6.32.27 #5 Wed Dec 21 01:59:33 CET 2011 mips GNU/Linux' WNDR3800
router.
You can see that the kamikaze kernel+ip utility are having trouble
talking to each other (possibly because it's 2.4?)
And then attempt to parse the data the kernel returns (recvmsg) by
hand and see where the utility gets it wrong.
First would probably make sense to check whether this still happens
with latest kernel and/or latest ip utility.
But that depends on what is easier on you.
_______________________________________________
openwrt-users mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-users
