If rtsp_unlink_waiting(m) is called and actually destroys m, it's not
safe to pass it to rtsp_unlink_outgoing later.
We make rtsp_unlink_waiting and rtsp_unlink_outgoing return true if they
destroy the message, and in this case we make sure not to try freeing it
again.
The new option --lazy-managed will let miracle-wifid don't managed the
links automatically. Instead, the link will be managed only when the new
DBus property Managed was set to true. So this will be possible that
miracle-wifid could be coexists with other network tools like
networkmanager.
For example, unmanage the device in networkmanager with setting the DBus
property org.freedesktop.NetworkManager.Device.Managed to false and
manage it in miracle-wifid with setting
org.freedesktop.miracle.wifi.Link.Managed to true, then both them could
works and don't need to kill each other.
Besides, there is new command named make-managed in miracle-wifictl and
miracle-sinkctl.
closes#135, #75
Don't skip leading zeroes for MAC addresses. Some software cannot handle
this well.
Signed-off-by: Andrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
As it turns out, the C standard forbids passing va_list by value and then
continue using it in the parent function (C Standard, 7.16, paragraph 3).
Luckily, there's a footnote stating:
"It is permitted to create a pointer to a va_list and pass that
pointer to another function, in which case the original function may
take further use of the original list after the other function
returns."
Therefore, we're safe passing va_list by reference and thus can keep the
current coding style.
This fixes weird bugs on ARM32 which really doesn't allow passing va_list
by value.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
We need to drop the remote-cookie flag when matching replies. Otherwise,
we will never find the local request.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
WifiDisplay uses RTSP for stream-setups. This adds a basic rtsp-bus
implementations that we can use for sinks and sources.
Note that the implementation is optimized for usability, not speed. RTSP
is used for control-data, not streaming-data so there's no need to
over-optimize it. In case inlined RTP is used, we still provide proper
speed, even though that's usually not used by WifiDisplay implementations
(due to the TCP requirement).
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
We _must_ aggressively drain input queues before we signal any HUP. There
might be queued messages that tell us important information about the
termination of wpa_supplicant.
Therefore, if a write() operation fails, we only signal HUP if the input
queues are empty. However, we cannot rely on EPOLLIN to be set, as the
input data might have arrived in between epoll_wait() and write(),
therefore, always run the non-blocking read() in case write() failed.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
The shl_ring helpers manage a dynamically-growing ring-buffer. We need
that for the following RTSP stream parsers, so add them to src/shared/.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Add u64 helpers to shl_htable. They're fairly trivial and just copied from
unsigned-long, however, in case size_t is not 64bit wide we need to do
some trivial hashing.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
The wpas-helpers provide easy _asynchronous_ access to wpa_supplicant
control interfaces. Compared to the old wpa_ctrl_* stuff it's no longer
synchronous. Thus, it doesn't block our daemon while wpa_supplicant runs
some heavy work again..
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
