madhuresh wrote:
Yes you are right. I was mentioning about hostap-driver-0.4.7 which
works as a module with linux kernel.
(The linux-2.6.17.3 kernel has a drivers/net/wireless/hostap directory.
What's the difference between that driver - or any versions from later
Linux kernels - and the hostap-driver-0.4.7 driver?)
So is it a netlink socket ?
No.
It's a PF_PACKET socket. Netlink sockets are PF_NETLINK sockets and are
implemented by the code in net/netlink; PF_PACKET sockets are
implemented by the code in net/packet. PF_PACKET sockets are the right
mechanism for supplying raw link-layer packets to an application and for
allowing applications to send raw link-layer packets.
Why do you have to implement a separate interface?
I was thinking of copying the packets (with these extra details) to this
new interface from which libpcap can read. Say this interface is xyz0,
so when tcpdump is invoked like ./tcpdump -i xyz0, then libpcap should
read from the new interface.
I think some other wireless drivers do that - but libpcap reads from
those interfaces by reading from a PF_PACKET socket.
To supply information such as signal strength, have your new interface
type provide an ARPHRD value of ARPHRD_IEEE80211_RADIOTAP, and supply
radiotap headers with the information in question. If you do that, you
will have to make *ABSOLUTELY NO CHANGES* to modern libpcap (i.e.,
libpcap 0.9.x and later).
(Yes, a radiotap header is different from a Prism header. I'd like to
see radiotap headers conquer the Linux world they way they've conquered
the BSD world.)
Please let me know if i am thinking in the right direction.
Any other nice approach to get these extra details from kernel space to
user space ?
The correct approach for that in Linux is PF_PACKET sockets, as if you
do that right, you don't have to do *anything* to libpcap. (Changing as
few pieces of software as possible is, *ceteris paribus*, a Good Thing.)
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
