Reverse or inverse ARP from windows/linux - no way (!?!?)
in [Embedded]
|
Prev: USB 3.0 implementation on FPGA
Next: Call for papers (Deadline Extended): HPCS-10, USA, July 2010
From: Didi on 26 Mar 2010 14:32 On Mar 26, 5:52 pm, "Boudewijn Dijkstra" <sp4mtr4p.boudew...(a)indes.com> wrote: > Op Thu, 25 Mar 2010 22:54:42 +0100 schreef Didi <d...(a)tgi-sci.com>: > > > I tried today to figure out a simple way to give users of our > > new netmca (http://tgi-sci.com/tgi/nmcatb.htm) to locate its > > IP address once it gets one via dhcp when there is no internet > > at the moment (when there is the device posts its IP to our domain > > and customers can see it using a browser). > > > Turned out there is nothing like an easy way to do that! > > Sending a UDP echo (port 7) to a broadcast address and subsequently > receiving information about all of the connected netmca's, is not easy? A > Java applet could do it. Well "easy" implies no necessity to program the alien system (windows). But I may look into the java option, I may have to do it this way. But I can see mass programming has gone higher level than practical. Clearly it is a hard thing to do for utility programmers, otherwise there would be some ARP variety tools out there. Dimiter
From: Didi on 26 Mar 2010 14:57 On Mar 26, 7:07 pm, D Yuniskis <not.going.to...(a)seen.com> wrote: > Hi Dimiter, > > Didi wrote: > > I tried today to figure out a simple way to give users of our > > new netmca (http://tgi-sci.com/tgi/nmcatb.htm) to locate its > > IP address once it gets one via dhcp when there is no internet > > at the moment (when there is the device posts its IP to our domain > > and customers can see it using a browser). > > OK, to be clear: > - device uses DHCP to acquire an IP from server (somewhere); > - user uses this IP to access web server within device; BUT > - device has no way of conveying that IP to the user. Yes, although usually a VNC server is accessed rather than a webserver. But there is a small webserver as well, part of the functionality is accessible via http. And yes, if there is no internet the device cannot access its (configurable) home domain to post its IP address there for user visibility and it has no other means to do that at the moment. > Presumably, user's aren't smart enough to configure DHCP > server to assign a *known* address to the device? It is not about them being smart enough, many of them just won't be bothered, have never dealt with that sort of thing etc. > BOOTPd is not available on the server (same issue)? > > Can your device register a name with a DynDNS service? > > Assuming you are dealing with Windows users, can you > broadcast a name that folks could access? E.g., > DimiterXXXX where XXXX is related to the device's > MAC in some obvious way? I could do some of these, sure. Have not implemented any dyndns so far, just the normal DNS thing I needed for the stack, but it can't be a lot. May be some way out. Although if it is not widely deployed I will still be facing the same issue on many locations. > (i.e., folks browse the network and then connect to > the "obvious" host that shows up) Well that's what I tried today at a customer and it worked. Without having a name for my netMCA; their network guy had installed there an "Angry IP scanner" (or similar name) which pinged the subnet in a loop and listed 6-7 responders; those with names were obvious (carried the names of people around the lab) and the two without the names were also obvious, one was the gateway and the other was the netmca. Even if not obvious if there are just a few hosts they can find out which is which by trial and error :-). So may be I don't have such a huge issue after all, I'll see how it works out over time before rushing into it. That's the strategy for now, at least, before someone screams over the phone "can't see the netmca"... Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
From: glen herrmannsfeldt on 26 Mar 2010 16:01 In comp.protocols.tcp-ip Didi <dp(a)tgi-sci.com> wrote: (snip) > In an attempt to solve it I spent 10 minutes adding RARP reply > to our device Ethernet related stuff - so it would reply to an ARP > inquiry #3 by sending its IP address (it only has one); and then spent > perhaps 3 hours googling, moogling, you name it, searching for some > piece of code to do that at the wintel side. Even rebooted the wintel > laptop to ubuntu to try it out from there (thought arp -r or something > would just work), oh no. No way. Spent perhaps half an hour of > moogling for linux rarp, same thing. Yesterday, not long after reading this, I was reading about a device that offers RARP, ARP, BOOTP, and DHCP as ways of assigning it an IP address. Looking at the list, I didn't see how they would do it with ARP, but... (This was suggested for Windows 98.) arp -s (desired IP address) (device MAC address) ping (desired IP address) The device is designed such that when no IP address is assigned that it looks for such ICMP packets. They could only arrive from hosts configured with such static ARP entries. Once an address is assigned (this way, or any other) the device ignores such. That avoids the problem of no RARP, BOOTP, or DHCP on W98. -- glen
From: David Schwartz on 26 Mar 2010 16:12 On Mar 26, 11:25 am, "markp" <map.nos...(a)f2s.com> wrote: > That is what I was going to suggest. Just regularly send your aquired > address via a UDP broadcast packet (say once a second), the bandwidth that > would use is very low. Please don't do that. Instead, listen on a UDP broadcast port for a UDP broadcast query. You can reply to that query either broadcast or unicast (just to the querier). DS
From: markp on 26 Mar 2010 18:52
"David Schwartz" <davids(a)webmaster.com> wrote in message news:ec062dee-e5d8-49f2-8ca1-7cd02a7b54e7(a)u15g2000prd.googlegroups.com... On Mar 26, 11:25 am, "markp" <map.nos...(a)f2s.com> wrote: >> That is what I was going to suggest. Just regularly send your aquired >> address via a UDP broadcast packet (say once a second), the bandwidth >> that >> would use is very low. > Please don't do that. Instead, listen on a UDP broadcast port for a > UDP broadcast query. You can reply to that query either broadcast or > unicast (just to the querier). > DS Of course, had a bit of a mind freeze there. That's a much more sensible way of doing it. You still have the question of how often to update the info because the DHCP server could potentially re-allocate addresses, but with your enquiry approach an update could be done on demand when needed. Mark. |