On Tue, 2025-08-05 at 01:12 -0700, Jeremy Fleischman wrote: > 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. I doubt looking for MSG_TRUNC makes sense as you cannot really do anything if you detect a truncated message. So I would suggest to just use a 4096 byte buffer for now. hostapd/wpa_supplicant hardcodes this size and will return an error it it is not sufficient. My take is that there is little point in trying to make this more future proof. Benjamin > > 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
