Oh interesting! Today I learned that recv and recvmsg promise to return an entire "message". From `man recvmsg`: > For message-based sockets, such as SOCK_DGRAM and SOCK_SEQPACKET, the entire mes‐ > sage shall be read in a single operation. And interestingly: > If a message is too long to fit in the supplied buffers, and MSG_PEEK is not set in the flags argument, the > excess bytes shall be discarded, and MSG_TRUNC shall be set in the msg_flags member of the msghdr structure. So perhaps best practice would be for clients to use recvmsg and check for MSG_TRUNC? It looks like right now src/common/wpa_ctrl.c uses recv and therefor cannot check that flag. This was very helpful, thank you. On Tue, Aug 5, 2025 at 12:54 AM Benjamin Berg <benjamin@xxxxxxxxxxxxxxxx> wrote: > > Hi, > > On Mon, 2025-08-04 at 17:59 -0700, Jeremy Fleischman wrote: > > I'm a user of the wifi-presence openwrt package. It talks to hostapd > > over the control socket to know when people connect/disconnect from a > > given access point. > > > > My home networks recently grew to the point where the hostapd response > > to the STATUS message is larger than 1024 bytes, which causes > > wifi-presense to fail to parse the response. I filed a bug with > > details here: https://github.com/awilliams/wifi-presence/issues/30. > > > > What I don't understand is how to fix this bug. wifi-presence can > > increase its buffer size, but it seems to me that a better > > implementation would loop and keep reading until it gets to the end of > > hostapd's response. However, I haven't been able to find a mechanism > > in the protocol that allows a client to know if it has read a full > > response. I'd expect protocols like this to have a "content length" > > header, or a special delimiter that indicates the end of a response. > > > > I've read through the source code of the example program > > (hostapd/hostapd_cli.c), which hardcodes a buffer length of 4096 in > > _wpa_ctrl_command: > > > > static int _wpa_ctrl_command(struct wpa_ctrl *ctrl, const char *cmd, int print) > > { > > char buf[4096]; > > > > What's the correct way to handle this? > > It is a DGRAM socket (possibly UDP) and hostapd itself hardcodes > a maximum reply length of 4096 bytes. So you can simply do the same at > least for now. > > Some commands such as "BSS" in wpa_supplicant have an option to limit > the range and only return part of the result set. For "STATUS", I > suppose it is currently just assumed to be small enough so that it can > be returned in a single 4096 byte chunk. > > Benjamin > > > > > Thanks, > > Jeremy > > > > _______________________________________________ > > Hostap mailing list > > Hostap@xxxxxxxxxxxxxxxxxxx > > http://lists.infradead.org/mailman/listinfo/hostap _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
