First, I need to know this in kernel space, so please take this into consideration.
No, I cannot use the IP address of the other device and ARP it(too long to explain why here) but I simply cannot use ARP, ARP won't work for the project I am working on.
Is there a function/utility I can use to know the MAC address of the other end in a connection attached to a given net_device I already have regardless of the IPs?
Thanks in advance, and if my question is not clear or makes no sense, leave a comment and I'll make sure to edit the question to explain/fill in the gaps
The standard protocol for "I need to speak to my neighbor" kind of problems is LLDP. At the moment, this is usually implemented via OpenLLDP (user-space) on Linux systems. However, there appears to be some kernel-space patches on the way that might help you:
Supposing you have the possibility to enable LLDP on the other end, you should be able to use it to discover that device.
Related
i am working in an ARM based media processor. I need to implement upnp for the device. Advertisement is only needed, i.e device discovery so IP address of the device can be found. I was able to implement the advertisement but i am failed when the IP of the device changes. Is there a way i could detect the change in IP and change the advertisement of device. Thanks in advance
There is nothing 'in UPnP' that will handle this for you -- that makes sense as UPnP is a media sharing protocol and finding out the current IPs is something quite unrelated to media sharing as well as entirely Operating System specific.
If you were using a decent UPnP-library, then I would expect the library to provide this sort of functionality to you. But since you are saying you are implementing UPnP yourself... well, then you get to implement all of it yourself.
My first suggestion is Don't implement UPnP yourself. It may look simple but it really isn't. Find libraries that "invent the wheels" for you and concentrate on actually solving the problem you're trying to solve. I understand that getting libraries on to an embedded device is not always easy, but I can guarantee that implementing UPnP in even a half-assed way is quite difficult.
Assuming the first suggestion is not viable: Take a look at how GUPnP handles this: There are ContextManagers (that handle network contexts) for Connman, NetworkManager and generic Linux. The latter might be a useful starting point for you: https://git.gnome.org/browse/gupnp/tree/libgupnp/gupnp-linux-context-manager.c : the "context-available" signal is emitted when a network interface is up. Note that the code is licensed under LGPL.
My apologies in advance if my question seems a little unprofessional... I am not much of a developer after all.
As part of my university project I need to develop a program that will listen on the network and tell whether the traffic is encrypted or not? What's important is only to know if the traffic coming to a network end is encrypted and it's not really important to know the type and the algorithm of the encryption.
I really have no clue where to begin. I'd appreciate it if anyone could give me some clues on what to look for.
Thanks in advance...
Although the answer of GregS is of course correct, the best way to distinquish encrypted text is to look at the protocol used by the application. For instance, if browsers encrypt anything, it's probably done by using SSL. Remote terminals use SSH.
Although the cipher text is mostly looking as random bytes, you can probably distinquish the encryption protocols. If this is enough depends on your use case. As a first step, many protocols use a specific server port by default; this can be used as a heuristic so you can check the most common protocols for that port first.
In testing certain network device driver receive features, I need to send special packets on the wire. I know I need to open a raw socket and push the bytes out. Is there some well-known example (C, perl, whatever) code already available for playing at this level?
(added later) I would prefer non-platform-specific answers, they'll be the most useful for everyone.
Look at the documentation for packet. Basically, you create a socket with SOCK_RAW or SOCK_DGRAM, then write to the socket using normal socket i/o. However, the data you send will be put directly on the line, rather than automatically getting the headers that are necessary for most network interop.
http://www.codeproject.com/KB/IP/sendrawpacket.aspx
There's already an existing project that may be able to help you with this.
Check out http://tcpreplay.synfin.net/wiki/tcprewrite#RewritingLayer2
and http://tcpreplay.synfin.net/
Seems to me you are looking for a tool to generate your own packets, Scapy is such a tool often used in the security industry (such as pentesters).
Demo is available: http://www.secdev.org/projects/scapy/demo.html
I can't think of any examples. But you should just be able to open up a UDP socket to any IP address you like and start writing data to it. Make sure its UDP or this will not work.
I found that there's a good C example here at Security-Freak, which only needed a little modification for flexibility. I'm hoping there are more answers in other languages.
How can I detect if another host is using the same MAC address as the current host, e.g. because the other host is spoofing?
I'm working in an embedded environment, so looking for answers on a protocol level, rather than “use such and such a tool”.
Edit: RARP does not solve this problem. For RARP to get any reply at all, there has to be at least one host on the segment which supports RARP. Since RARP is obsolete, modern operating systems don't support it. Furthermore, all RARP can do is tell you your own IP address - the response won't be any different if there’s another host on the segment with the same MAC, unless that host has itself used a different IP address.
This question is too interesting to put down! After several false starts I started thinking about the essential components of the problem and scoured the RFCs for advice. I haven't found a definitive answer, but here's my thought process, in the hope that it helps:
The original question asks how to detect another device with your MAC address. Assuming you're on an IP network, what's required to accomplish this?
The passive method would be simply to listen to traffic and look for any packets that you didn't transmit but have your MAC address. This may or may not occur, so although it can tell you definitively if a duplicate exists, it cannot tell you definitively that it doesn't.
Any active method requires you to transmit a packet that forces an impostor to respond. This immediately eliminates any methods that depend on optional protocols.
If another device is spoofing you, it must (by definition) respond to packets with your MAC address as the destination. Otherwise it's snooping but not spoofing.
The solution should be independent of IP address and involve only the MAC address.
So the answer, it seems, would be to transmit either a broadcast (ethernet) packet or a packet with your MAC address as its destination, that requires a response. The monkeywrench is that an IP address is usually involved, and you don't know it.
What sort of protocol fits this description?
Easy Answer:
If your network supports BOOTP or DHCP, you're done, because this authoritatively binds a MAC address to an IP address. Send a BOOTP request, get an IP address, and try to talk to it. You may need to be creative to force the packet onto the wire and prevent yourself from responding (I'm thinking judicious use of iptables and NAT).
Not-so-easy Answers:
A protocol that's independent of IP: either one that doesn't use the IP layer, or one that allows broadcasts. None comes to mind.
Send any packet that would normally generate a response from you, prevent yourself from responding, and look for a response from another device. It would seem sensible to use your IP address as the destination, but I'm not convinced of that. Unfortunately, the details (and, therefore the answer) are left as an exercise for the OP ... but I hope the discussion was helpful.
I suspect the final solution will involve a combination of techniques, as no single approach seems to guarantee a dependable determination.
Some information is available at http://en.wikipedia.org/wiki/ARP_spoofing#Defenses
If all else fails, you may enjoy this: http://www.rfc-editor.org/rfc/rfc2321.txt
Please post a follow-up with your solution, as I'm sure it will be helpful to others. Good luck!
You could send an ARP request for each possible ip in the subnet.
Of course the source address of the ARP request must be ff:ff:ff:ff:ff:ff, otherwise you might not see the response.
I forged a packet like this with bittwiste and replayed it with PReplay and all the hosts on the network got the response. (I don't know if these forged ARP packets are legal or not... some OSes might ignore them)
Here is what the forged package looked like:
Here is what the reply looked like:
If you watch the responses and see your MAC address in one of the packets (in the red rectangle) , than someone has the same MAC address as you do...
Unfortuantely I couldn't test the theory fully because none of my (Windows) machines care about me trying to set the nic's MAC address...
Two hosts using same MAC address on a single network segment would probably make switches go nuts and you could probably detect it by having an extremely unreliable network connection (as the switches would send some portion of packets that belong to your host to the second one, depending on which one of you sent the last packet in their direction).
This is very late, and a non-answer, but I wanted to follow up with exactly what I did in case anyone else is interested.
I was working with some very weird embedded hardware that doesn’t have a MAC address assigned at manufacture. That means we needed to assign one in software.
The obvious solution is to have the user pick a MAC address that they know is available on their network, preferably from the locally-administered range, and that’s what I did. However, I wanted to pick a reasonably safe default, and also attempt to warn the user if a conflict occurred.
In the end I resorted to picking a random-ish default in the locally-administered range, chosen by making some hardware readings that have moderate entropy. I deliberately excluded the beginning and end of the range on the assumption that those are moderately more likely to be chosen manually. The chances are that there will only be one of these devices on any given network, and certainly less than 20, so the chances of a conflict are very low, albeit not as low as they could be due to the somewhat predictable random numbers.
Given the low chances of there being a problem, and despite the excellent answers above, I decided to dispense with the conflict detection and make do with a warning to the user to look out for MAC conflict problems.
If I did decide to implement conflict detection, then given that I control the whole network stack, I would probably look out for excessive unknown or missing packets, and then trigger a change of MAC address or warn the user when that happens.
Hopefully that will help someone else somewhere – but probably not!
This is more a thought experiment than anything.
I'm wondering what it would take to detect everything I legally can about the laptops in a hotspot. My first thought was to grab every MAC address I can and extract the maker from the first 24bit.
The question is would this be illegal and what else could I legally scavenge, preferably passively?
P.S. This constitutes a pattern-recognition problem so it IS programming... I think.
nmap can do a reasonable job of guessing the operating system by the way the target system responds to various probes
For the brain dead answer: Quit typing and look around for a few minutes :-D
I guess the obvious one would be to sniff the user-agent out of their HTTP requests.
IIRC there are ways to detect what TCP/IP stack is being used by sniffing choices in port usage and sequence numbers.
Why does it matter, 90% of them will be apples ;-)
The people wearing black turtle necks will be using Macs, the rest will be using PC's and Windows (except for that one guy with long pony tail who is using Linux).
Packet sniffing is illegal without the network owners consent. At least that's the generally followed precedent. There has been very few tests of this in court. But your idea of how to do it, using the mac addresses, would work well. Wireshark is a good packet sniffer if you're looking.
GFI Languard gives a lot of info like this. Check it out.