Certain flags (for example, NLA_F_NESTED) are ORed with the netlink
attribute type identifier prior to being sent on the wire. Such flags
need to be masked off and not taken into consideration when attribute
type is being compared against known values.
l_genl class has nice ways of discovering and requesting families. The
genl functionality has been added after the iwmon skeleton was created,
but it is now time to migrate to using these APIs.
This attribute is actually an array of signed 32 bit integers and it
was being treated as a single integer. This would work until more
than one threshold was set, then it would fail to parse it.
This was changed from too large of a mask (0xff) in an earlier
commit but was masking 5 bits instead of 6.
Fixes: 121c2c5653 ("monitor: properly mask HE capabilities bitfield")
This fixes a build break on some systems, specifically the
raspberry Pi 3 (ARM):
monitor/main.c: In function ‘open_packet’:
monitor/main.c:176:3: error: implicit declaration of function ‘close’; did you mean ‘pclose’? [-Werror=implicit-function-declaration]
176 | close(fd);
| ^~~~~
| pclose
To support multiple nlmon sources, move the logic that reads from iwmon
device into main.c instead of nlmon. nlmon.c now becomes agnostic of
how the packets are actually obtained. Packets are fed in via
high-level APIs such as nlmon_print_rtnl, nlmon_print_genl,
nlmon_print_pae.
The current implementation inside nlmon_receive is asymmetrical. RTNL
packets are printed using nlmon_print_rtnl while GENL packets are
printed using nlmon_message.
nlmon_print_genl and nlmon_print_rtnl already handle iterating over data
containing multiple messages, and are used by nlmon started in reader
mode. Use these for better symmetry inside nlmon_receive.
While here, move store_netlink() call into nlmon_print_rtnl. This makes
handling of PCAP output symmetrical for both RTNL and GENL packets.
This also fixes a possibility where only the first message of a
multi-RTNL packet would be stored.
nlmon_print_genl invokes genl_ctrl when a generic netlink control
message is encountered. genl_ctrl() tries to filter nl80211 family
appearance messages and setup nlmon->id with the extracted family id.
However, the id is already provided inside main.c by using nlmon_open,
and no control messages are processed by nlmon in 'capture' mode (-r
command line argument not passed) since all genl messages go through
nlmon_message() path instead.
This mispelling was present in the configuration, so I retained parsing
of the legacy BandModifier*Ghz options for compatibility. Without this
change anyone spelling GHz correctly in their configs would be very
confused.
Adds a handler for the HE capabilities element and reworks the way
the MCS/NSS support bits are printed.
Now if the MCS support is 3 (unsupported) it won't be printed. This
makes the logs a bit shorter to read.
The country IE can sometimes have a zero pad byte at the end for
alignment. This was not being checked for which caused the loop
to go past the end of the IE and print an entry for channel 0
(the pad byte) plus some garbage data.
Fix this by checking for the pad byte explicitly which skips the
print and terminates the loop.
The -F option is undocumented but allows you to pass a nl80211
family ID so iwmon doesn't ignore messages which don't match the
systems nl80211 family ID (i.e. pcaps from other systems).
This is somewhat of a pain to use since its unclear what the other
system's family ID actually is until you run it though something
like wireshark. Instead iwmon can ignore the family ID when in
read mode which makes reading other systems pcap files automatic.
Expand nlmon_create to be useful for both pcaps and monitoring. Doing
this also lets iwmon filter pcaps based on --no-ies,rtnl,scan etc
flags since they are part of the config.
Commit c7640f8346 was meant to fix a sign compare warning
in clang because NLMSG_NEXT internally compares the length
with nlmsghdr->nlmsg_len which is a u32. The problem is the
NLMSG_NEXT can underflow an unsigned value, hence why it
expects an int type to be passed in.
To work around this we can instead pass a larger sized
int64_t which the compiler allows since it can upgrade the
unsigned nlmsghdr->nlmsg_len. There is no underflow risk
with an int64_t either because the buffer used is much
smaller than what can fit in an int64_t.
Fixes: c7640f8346 ("monitor: fix integer comparison error (clang)")
The ATTR_ARRAY type was quite limited, only supporting u16/u32 and
addresses. This changes the union to a struct so nested/function
can be defined along with array_type.
Though the documentation for NLMSG_OK uses an int type for the length
the actual check is based on nlmsghdr->nlmsg_len which is a 32 bit
unsigned integer. Clang was complaining about one call in nlmon.c
because nlmsg_len was int type. Every other usage in nlmon.c uses
a uint32_t, so use that both for consistency and to fix the warning.
monitor/nlmon.c:7998:29: error: comparison of integers of different
signs: '__u32' (aka 'unsigned int') and 'int'
[-Werror,-Wsign-compare]
for (nlmsg = iov.iov_base; NLMSG_OK(nlmsg, nlmsg_len);
^~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/linux/netlink.h💯24: note: expanded from macro 'NLMSG_OK'
(nlh)->nlmsg_len <= (len))
ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000512c08 at pc 0x00000041848d bp 0x7ffcdde71870 sp 0x7ffcdde71860
READ of size 8 at 0x000000512c08 thread T0
#0 0x41848c in print_attributes monitor/nlmon.c:6268
#1 0x42ac53 in print_message monitor/nlmon.c:6544
#2 0x438968 in nlmon_message monitor/nlmon.c:6698
#3 0x43d5e4 in nlmon_receive monitor/nlmon.c:7658
#4 0x4b3cd0 in io_callback ell/io.c:120
#5 0x4b085a in l_main_iterate ell/main.c:478
#6 0x4b0ee3 in l_main_run ell/main.c:525
#7 0x4b0ee3 in l_main_run ell/main.c:507
#8 0x4b13ac in l_main_run_with_signal ell/main.c:647
#9 0x4072fe in main monitor/main.c:811
