Raw sockets is the ability to bypass the encapsulation of the lower level OS. All you need to do is send a legitimate UDP broadcast 'enquire' packet and receive uni-cast replies, I can't see why you would want to create your own raw packets and why you can't just use the OS to encapsulate your data normally (?)
I may have got this wrong, but I thought you wanted to find the address of a newly connected web-server on a local network and be able to configure a browser to access it. In which case all that is needed is to do is run a small utility on the browser PC that sends a UDP broadcast packet, the data portion of which contains the PC's IP address. The client, which has been allocated an address by the DHCP server, sees the UDP broadcast packet, and responds by uni-cast to the given address with *its* adddress in the data portion. The utility displays that address, which the user can either copy into the browser or click as a hyperlink. Why do you need ARP??
Uhm, not so sure. Same level as UDP in that they both have the Ethernet protocol type set to "internet", perhaps; but the data inside a UDP packet are encapsulated into that level, whereas the ARP data are purely Ethernet encapsulated. This should put it one level lower - at least unofficially?
No no, you are correct on that. I was just looking for some readily available utility, I avoid wintel programming like the plague, just the thought of their APIs etc. stuff makes me sick.
ta
That "angry IP scanner" I found is doing something similar (uses ICMP echo) and does the job for small networks. For large ones it will be less practical to manually dig through a huge list, though...
Or may be I forgot that, $806 was ARP and $800 was internet so may be they are officially different - Oh no, I may be dealing with their hex dumps and I may have implemented them but I really would not argue about the official side of things :-) . I know my stack handles the ARP packets at the same level as IP packets, UDP is one level "higher".
Ahha, you're after some already existing software to map MAC addresses to IP addresses.
If you open a command box in XP and type 'arp -a' you get a list of MAC addresses and their associated IP addresses. Is that what you want? you could easily write a batch file to scan for a given MAC address or dump to a file to search.
Hmm, do you still think it is "simple" (just kidding :-)).
The necessity to poll, ping the entire subnet etc. nonsense summarizes what todays PC programming has become. Instead of simply sending a single packet to a known destination and use the single packet reply, why not send a few hundred or, better, a few thousand of them (the latter is the case when we would really need it to work, of course :-) ), then sift through the replies...
CDP comes to mind as one option with allows any connected device to advertise its identity and IP address on the local subnet. I'm aware that it has at least in theory been superceded by LLDP but I have no experience of that, and CDP is very simple whereas LLDP _may_ be more complex. It's primarily a Cisco protocol but it is documented and clients and viewers are available for Unix and Windows machines.
OK, the ARP way sounds like you've got to send a ping first to establish the route. However, since the only things you are worried about are your web-servers you can guarantee they respond to that as you would have programmed them too. As an aside, wouldn't the DHCP server when allocating addresses in the first place do that automatically?
The original idea of sending a UDP broadcast enquiry packet and getting replies is quite simple though. Only your servers would reply, and you could even send the desired server's MAC address in the enquiry packet so only one device that matches it would respond.
Nope. Just a single ARP packet type 3 (if RARP misused, not sure which it has to be for inarp - but same thing) to the known MAC destination, which will reply in a single packet to the originating MAC address. No loop, no broadcast involved.
g
If you mean would not everyone on the subnet be aware of everyone elses IP & mAC address data by snooping the dhcp, then no. Only the dhcp request is broadcast, the rest goes peer to peer (and may well be invisible to much of the subnet even in promiscuous mode).
uld
one
Yes, of course it is simple. I just want to use the wintel PC's as TV-sets (i.e. I am not delivering any software for them, my software runs under DPS on the device). In fact this works so far, I am just preparing for the day I have this issue at a customers site.
Dimiter
(the thread got lengthy, here is a third link to the device we are talking about:
An ARP packet looks absolutely nothing like an IP packet.
ARP, in most senses, is not technically part of the TCP/IP stack at all, except that it's needed by some types of links. No more than Ethernet is really a part of TCP/IP (although it is used by many implementations). While ARP is defined in an RFC, there's plenty of stuff in the RFCs that not really part of TCP/IP proper.
In any event, ARP, as defined in RFC826, supports non-Ethernet format MAC addresses, and non-IP format network addresses. In fact, the format of the hardware and network addresses, and their lengths, are specified in the ARP packet for each query and response.
And to the OP: does the OS on this box have any support for the Windows networking protocols (Samba, if this is *nix)? If you enable that, and ID the node as a workgroup node with some easily recognizable name, then the users should be able to find it in Explorer (somewhere under "My Network Places"). If you published a share on your node you could put a single html page with a link (or perhaps a redirect, or just a display =96 =93I=92m at IP 1.2.3.4=94) to the correct IP address (that redirect page would be recreated each time your device was assigned a new IP address).
No, DPS is not unix. But thanks for the hint, I'll look into that "Samba" thing. If not too complex I certainly could add some (probably partial) support so the name becomes visible in "my network places" or sort of, this would be perfect as a result.
I believe that, strictly speaking, that can't happen. If you have no internet at the moment, you don't have DHCP either. Remember that DHCP itself is a UDP service. UDP in turn works on top of IP, and that, for better or for worse, is "internet".
Well, the problem is nowhere near as easy as it appears at first sight. It's called a "network" because it's _work_ to set up a properly functioning net.
You'll want to look up "zero config networking". That's what the big guys came up with to address this very same issue. You'll see Apple mentioned rather a lot, for their "Rendezvouz"/"Bonjour" project.
And let me point out I'm completely flabbergasted that nobody mentioned this before me --- not over here in c.a.embedded, anyway. I mean, come on guys: not a single owner of an Apple Airport base station speaking up, wondering what all these people keep talking about for days, when a "normal" WLAN box just does the job???
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.