Since DLEP is still a draft RFC, its current implementation I believe is limited.
In the one below, it looks like it's only targeted at nl80211 for OpenWRT. http://wiki.confine-project.eu/soft:dlep http://wiki.confine-project.eu/soft:confine-dist https://github.com/confine-project/confine-dist/tree/master/packages/confine(as packaged into Confine) http://olsr.org/git/?p=dlep_app.git;a=tree (the current repo) Besides that, inspecting the nl80211listener code does indicate this DLEP implementation has dependencies on the OLSR implementation, suggesting the OLSRd daemon would have to be running. This doesn't necessarily require the radio have an active adhoc interface, tho, just that OLSRd be running. Henning's underlying motivation for DLEP is to support situations where a wired router with substantial CPU resources could receive hardware-level details about a collection of lightweight wireless bridges (with very limited CPU) connected to its ports. That said, I believe the use case Henning had in mind does NOT have the DLEP daemon transmitting its layer 2 wireless link info over any wireless link itself (it is assumed the wireless bridges and router sit on the share wired LAN). However, the implementation for Confine mentioned above includes a DLEP relay tool that could presumably be used to forward messages over whatever interface one desires. On Thu, Mar 21, 2013 at 10:11 AM, Jack Bates <[email protected]>wrote: > Cool, thanks for pointing out Dynamic Link Exchange Protocol! Could it be > used to monitor access points, or is it specifically for ad-hoc radios? > > > On 20/03/13 02:28 PM, Ben West wrote: > >> I realize this runs a bit parallel to the SNMP-based implementation >> being discussed here, but you might be interested to know that Henning >> Rogge, one of the primary developers behind OLSR.org, has a >> draft/proposal RFC for sharing hardware level radio metrics with a >> layer-3 router: >> >> https://tools.ietf.org/html/**draft-rogge-stateless-rfc5444-**dlep-00<https://tools.ietf.org/html/draft-rogge-stateless-rfc5444-dlep-00> >> >> "Stateless RFC5444-based Dynamic Link Exchange Protocol (DLEP)",Henning >> Rogge, 4-Nov-12, <draft-rogge-stateless-**rfc5444-dlep-00.txt> >> >> This document provides material for the discussion in the MANET WG >> about the Dynamic Link Exchange Protocol (DLEP). This document >> reflects the authors' thoughts about how a stateless DLEP protocol >> compliant with RFC5444 could look like. >> >> ... >> >> Dynamic Link Exchange Protocol (DLEP, as defined in [dlep02 < >> https://tools.ietf.org/html/**draft-rogge-stateless-rfc5444-** >> dlep-00#ref-dlep02<https://tools.ietf.org/html/draft-rogge-stateless-rfc5444-dlep-00#ref-dlep02>>]) >> is a >> >> proposal for a cross-layer protocol between a layer-2 entity like a >> radio and a layer-3 router to transport layer-2 metric, statistic and >> status data from the radio to the router. In addition, it allows the >> router to control and configure aspects of the radio, such as radio >> status, channel or link speed. >> >> >> On Wed, Mar 20, 2013 at 2:09 PM, Jack Bates <[email protected] >> <mailto:ad25kw@nottheoilrig.**com <[email protected]>>> wrote: >> >> On 19/03/13 02:58 PM, David Lang wrote: >> >> # of clients connected to the SSID (associations) >> >> information on each connection >> signal strength >> MAC >> >> Radio airtime info >> how much time was spend recieving (unable to transmit) >> how much recieved traffic was corrupted by interference >> how much good recieved traffic was there >> how much time was spent transmitting >> how much idle airtime was there (time that transmissions >> could have >> occured) >> >> going beyond the simple metrics that I want to graph into overall >> network management issues >> >> some method (ideal something better than trying to sniff packets >> and >> correlate them in userspace) to try and figure out how much >> airtime a >> given station is eating up (especially something that can do >> this even >> if the station gets trompted on and so the transmitted packet >> cannot be >> fully received) >> >> some method of being able to figure out what other SSIDs are >> broadcasting on the frequency that I'm currently tuned to and >> how much >> airtime each SSID is eating up (including ones that don't send >> beacons) >> >> >> Thanks David, I am interested in implementing this. If you already >> know how to get some of this data manually, can you please send me >> what you know? For example, do you have any thoughts on options for >> accessing the MAC address and signal strength for each connection >> (from such as mini_snmpd)? >> >> ______________________________**___________________ >> openwrt-users mailing list >> [email protected].__**org >> >> <mailto:openwrt-users@lists.**openwrt.org<[email protected]> >> > >> >> https://lists.openwrt.org/__**mailman/listinfo/openwrt-users<https://lists.openwrt.org/__mailman/listinfo/openwrt-users> >> >> >> <https://lists.openwrt.org/**mailman/listinfo/openwrt-users<https://lists.openwrt.org/mailman/listinfo/openwrt-users> >> **> >> >> >> >> >> -- >> Ben West >> http://gowasabi.net >> [email protected] <mailto:[email protected]> >> 314-246-9434 >> >> >> >> ______________________________**_________________ >> openwrt-users mailing list >> [email protected].**org <[email protected]> >> https://lists.openwrt.org/**mailman/listinfo/openwrt-users<https://lists.openwrt.org/mailman/listinfo/openwrt-users> >> >> -- Ben West http://gowasabi.net [email protected] 314-246-9434
_______________________________________________ openwrt-users mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-users
