<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><pre>How do you receive the data? If that comes with anything that you can<br>wait for with select() (or poll/epoll), it should be easy to integrate<br>with eloop. If it is something else, I'd consider converting it to a<br>socket operation within the process to make this work cleanly with<br>eloop.<br><br></pre>I think you have solved my problem here! After your suggestion, I researched more about socket operations and found out AF_UNIX socket domain. I think it would work find for transferring my data between the Openflow interface and eloop.<br><br>Let me give this a go and find out how it goes.<br><br>Thanks again!<br><br>Sadiq<br><br><div>> Date: Sun, 14 Dec 2014 17:21:50 +0200<br>> From: j@w1.fi<br>> To: hostap@lists.shmoo.com<br>> Subject: Re: hostAPd with Openflow<br>> <br>> On Fri, Dec 12, 2014 at 08:49:19PM +0000, Sadiq Yakasai wrote:<br>> > Now, because I am planning on receiving data from an openflow switch, I have a challenge with how the data is relayed to the handler function. These are 2 options I am considering:<br>> > <br>> > 1. When I receive data from the openflow switch (and decapsulate it) - I then pass it directly to the handler function (handle_openflow_data for example) which then passes it on to the wpa_supplicant_event(). But my challenge here is how do I include the eloop_ctx and sock_ctx information? Since I am by-passing eloop altogether to send the data to the driver function that handles the data. I have attempted to not include these pieces of information and the program crashes (expected)!<br>> <br>> How do you receive the data? If that comes with anything that you can<br>> wait for with select() (or poll/epoll), it should be easy to integrate<br>> with eloop. If it is something else, I'd consider converting it to a<br>> socket operation within the process to make this work cleanly with<br>> eloop.<br>> <br>> > 2. The second option I am considering is to register the callback handler function with eloop_register_read_sock (as normally would be done). When data is received from my openflow switch, I then find a way to make eloop callback the handler function (with eloop_ctx and user_data), just as is the case for normal socket reading. But the challenge here is that the socket table, for readers/writers/exception requires an open socket context information passed across, which i dont have because I am not receiving my data from a socket!<br>> <br>> So where are you receiving it from? It is a bit difficult to comment on<br>> the best approach without that key point being described in more detail.<br>> <br>> -- <br>> Jouni Malinen PGP id EFC895FA<br>> _______________________________________________<br>> HostAP mailing list<br>> HostAP@lists.shmoo.com<br>> http://lists.shmoo.com/mailman/listinfo/hostap<br></div> </div></body>
</html>