'architecture for interfacing with wpa_supplicant'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: hostap
Subject: architecture for interfacing with wpa_supplicant
From: Christian Scheid <cxscheid () gmail ! com>
Date: 2009-12-15 18:41:07
Message-ID: cea0138e0912151041g3f17243dlc6a044cf68a64e0e () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

Hi,

we would like to develop an interface between a C-based control program that
interfaces directly with the device drivers of a network device and the wpa
supplicant which would run as a service. This implementation would use
EAP-TLS and EAP-TTLS. I would like to ask for a recommendation on the
suggested architecture since I don't have much experience with the
wpa_supplicant.

My first question is about the interface to the device. In our architecture,
the control program already interfaces with the device driver, listens for
EAP packages, and can process them. I know the supplicant can be extended to
directly interface with the driver. Should I forward EAP packages from the
control program to/from the supplicant, or write an adapter to the
wpa_supplicant that reads/sends packages to the device driver directly? In
this second option how would I implement a notification mechanism to the
control program to report the EAP status?

My second question is about customization points to the wpa_supplicant for
the proposed architecture. So for example if the recommended architecture is
to write a device adapter for the supplicant, which files/functions should I
modify (or should I just use other device adapters as a sample)? And in this
architecture which files/functions should I modify to report status to the
secondary control program?

I appreciate any comments on this topic!

Thanks in advance!

dutch

[Attachment #5 (text/html)]

Hi, we would like to develop an interface between a C-based control =
program that interfaces directly with the device drivers of a network devic=
e and the wpa supplicant which would run as a service. This implementation =
would use EAP-TLS and EAP-TTLS. I would like to ask for a recommendation on=
 the suggested architecture since I don&#39;t have much experience with the=
 wpa_supplicant. 
 My first question is about the interface to the device. In our architec=
ture, the control program already interfaces with the device driver, listen=
s for EAP packages, and can process them. I know the supplicant can be exte=
nded to directly interface with the driver. Should I forward EAP packages f=
rom the control program to/from the supplicant, or write an adapter to the =
wpa_supplicant that reads/sends packages to the device driver directly? In =
this second option how would I implement a notification mechanism to the co=
ntrol program to report the EAP status? 
 My second question is about customization points to the wpa_supplicant =
for the proposed architecture. So for example if the recommended architectu=
re is to write a device adapter for the supplicant, which files/functions s=
hould I modify (or should I just use other device adapters as a sample)? An=
d in this architecture which files/functions should I modify to report stat=
us to the secondary control program? 
 I appreciate any comments on this topic! Thanks in advance! =
 dutch

_______________________________________________
HostAP mailing list
HostAP@lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap

[prev in list] [next in list] [prev in thread] [next in thread] 