Dear Sir,
Step 1: When making security decisions, you probably don't need a list of *all* neighbors - you only need an answer to "is *this* neighbor known or not". And that would be a different API.
If I am to get the information of known neighbors, which API should use in my kernel module. I searched this on Google for hours and that did not do any good. I am a novice at this, a reference/ example would be really great to point me in the right direction. Thank you very much sir, Best Regards, H. Hasitha Shan P.S. Thank you Mr. Valdis for pointing me that I should always reply beck to the kernennewbies mailing list.
To: hh_shan@live.com CC: kernelnewbies@kernelnewbies.org Subject: Re: Identifying neighbors within the LAN From: Valdis.Kletnieks@vt.edu Date: Sat, 3 May 2014 19:10:18 -0400
On Sat, 03 May 2014 11:01:19 -0700, Hettiarachchige Hasitha Shan said:
In the concept, it is required to obtain the list of neighbors within the LAN. I did some research online and I found out that I can obtain IPv4/ IPv6 neighbors by typing in "ip -4 neigh show" or "ip -6 neigh show" in the terminal where this feature is implemented by the module neighbour.
My query is , If I am to obtain these information programatically through my kernel module, which methods should I call.
Step 0: Figure out why a packet security module even *cares* what neighbors are known. Why do you care if a neighbor is known or not? First, figure out under what conditions a neighbor becomes known. What security decisions are you planning to make based on "IPv4 address is in ARP table"? Whether an address is in the ARP table is orthogonal to whether you should trust the host or not. A trusted host can fail to be in the neighbor table simply because the ARP entry has aged out. Or an untrusted host can be *in* your ARP table....)
Step 1: When making security decisions, you probably don't need a list of *all* neighbors - you only need an answer to "is *this* neighbor known or not". And that would be a different API.
(For bonus points, consider the case of a trusted host that has a longer ARP table timeout than yours - then you can receive a packet from the host without them ARP'ing for you first, but you still don't have a ARP entry for them.