Prev: USB 3.0 implementation on FPGA
Next: Call for papers (Deadline Extended): HPCS-10, USA, July 2010
From: Didi on 25 Mar 2010 17:54 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! There are some utilities which can be used to ping the entire subnet; then list the arp cache, locate the known MAC address and see its IP. But these are far from something one would want to ask customers to deal with, long lists, necessity to search etc. , heck, it will generate more calls to me than if I do it for them every time. 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. How on Earth is that possible?! I can understand how many things are retarded as one would expect them to be on a x86 based thing, but this is too simple even for the x86 world. Any ideas? I have not faced the issue in real life yet (users tend to have internet) but this is bound to happen and I am looking for some solution. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
From: Nobody on 25 Mar 2010 18:38 On Thu, 25 Mar 2010 14:54:42 -0700, 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). > > Turned out there is nothing like an easy way to do that! > > There are some utilities which can be used to ping the entire subnet; > then list the arp cache, locate the known MAC address and > see its IP. But these are far from something one would want to ask > customers to deal with, long lists, necessity to search etc. , heck, > it > will generate more calls to me than if I do it for them every time. > > 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. I think that you may misunderstand what RARP is. It's similar to BOOTP or DHCP, but implemented at the link layer (Ethernet) rather than the network layer (IP). RARP allows a client to determine its own IP address at boot. It has largely fallen out of favour due to its lack of functionality compared to BOOTP or DHCP, and the difficulty of implementation (it requires "raw" ethernet access, cannot be routed, etc). Essentially, a client broadcasts a RARP request, the RARP server notices the request, looks up the source MAC address to obtain an IP address, and sends a RARP reply back to that MAC address. "Inverse ARP" (InARP) appears to be the reverse of ARP, but it isn't widely used (I've only just found out about it now, in spite of having performed a significant amount of both TCP/IP programming and administration of TCP/IP networks and servers). InARP is an extension to the ARP protocol, which is normally implemented within the kernel's networking stack. You may be able to use e.g. netcat to issue an InARP request and receive the response, provided that you have sufficient privilege (raw/packet sockets typically require root or Administrator privilege) and any firewalls don't get in the way. > Any ideas? I have not faced the issue in real life yet (users tend > to have internet) but this is bound to happen and I am looking for > some solution. If you want to find a device on the network, one option is a NetBIOS-style "sonar", sending a UDP packet to a specific port on the broadcast address and listening for replies. But that will only work if the device is on the same network segment (routers don't normally pass broadcast packets). You're probably better off just asking the DHCP (or DNS) server where the device is. Anything else is likely to run afoul of firewall rules or the like. Nowadays, anything beyond HTTP, SMTP and Windows' own protocols is likely to be considered suspicious.
From: David Schwartz on 25 Mar 2010 18:48 On Mar 25, 2:54 pm, Didi <d...(a)tgi-sci.com> 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). > > Turned out there is nothing like an easy way to do that! There are, actually, a lot of ways. In the Windows world, NMB provides a naming service that maps local host names to IP addresses. If the computers are set up with NetBIOS over TCP/IP and you know the host name, you can get the IP address easily. On Windows, 'gethostbyname' will use the local browse table. Apple's Bonjour protocol also does this. You can make your service a zeroconf advertised service. This technology uses multicast DNS. You can also use your own multicast or broadcast based location service. A server running your software listens on a UDP broadcast/ multicast port for service discovery requests. A client can then send a service request and wait for the server to reply. I don't recommend doing periodic service availability broadcasts for your custom protocol unless there's a real need. Another solution is dynamic DNS. Most operating systems support the ability to register their dynamically-assigned IP addresses in a dDNS server. Most platforms provide servers with dDNS capability as well. And, of course, you can just punt on this. Simply state "You need the IP address of the server to access it. Either configure it statically or arrange for it put it someplace you can get it." (This is what pretty much every server already does.) There are also all kinds of tricks you can do. For example, you can run a local proxy and use a fixed IP address and port (say 127.1.2.3:8000 or something like that). The proxy binds to that IP and port and forward requests to the server's current IP addresses, determining it using any of the above methods. Is the client running special client software? Or do you need the IP address to enter into a browser or something like that? DS
From: Didi on 25 Mar 2010 19:19 On Mar 26, 12:48 am, David Schwartz <dav...(a)webmaster.com> wrote: > .. > And, of course, you can just punt on this. Simply state "You need the > IP address of the server to access it. Either configure it statically > or arrange for it put it someplace you can get it." (This is what > pretty much every server already does.) Well yes but many of the customers have no clue beyond basic browser usage. They will have network support etc. and call them but I want to prevent the initial frustration they will face when they don't know how to connect to the device. It comes with a fixed fallback IP address which they can subsequently change (I ship it with 192.168.100.last MAC address byte - not sure why for any part of it, did not give it a long thought) - but they have to set a static IP address on the windows system in most cases to be able to access that. In fact they do and some have reported success, but others would not even dare to try it out. > ... > There are also all kinds of tricks you can do. For example, you can > run a local proxy and use a fixed IP address and port (say > 127.1.2.3:8000 or something like that). The proxy binds to that IP and > port and forward requests to the server's current IP addresses, > determining it using any of the above methods. That's too complex... If they can do that they will likely be able to figure out the IP address the device has, loop ping/ do arp -a or look into the router tables and see what IP it gave to this MAC etc. > Is the client running special client software? Or do you need the IP > address to enter into a browser or something like that? Pretty much the latter, although usually it is not a browser but an RFB (VNC) client. If only there were a command line in the MSDOS window like arp -r <MAC address> which would then do inverse ARP and list the result I guess I would be fine but... Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/ Original message: http://groups.google.com/group/comp.arch.embedded/msg/df514407e21d7002?dmode=source
From: Didi on 25 Mar 2010 19:35
On Mar 26, 12:38 am, Nobody <nob...(a)nowhere.com> wrote: > ... > I think that you may misunderstand what RARP is. Well no, I read the related RFCs, and I read about inarp too. I think rarp also allows doing what I want (not quite sure) but even if it does not there is no problem misusing it for the purpose. Then I could include inarp reply as well, it is almost the same thing. The packet is the same as ARP only with a different type field; and only the known/unknown fields are the other way around, that is, the replying host fills in the IP field (which has come as 0) rather than its MAC field (which has come valid - non broadcast and non-0). That's all, adding the reply took me just a few minutes (4-5 lines of code... :-) ). But there is just no simple to use utility which would trigger that response from my device and list the result... > You're probably better off just asking the DHCP (or DNS) server where the > device is. Anything else is likely to run afoul of firewall rules or the > like. Nowadays, anything beyond HTTP, SMTP and Windows' own protocols is > likely to be considered suspicious. Oh no, no firewall issues. Or if there are any I would just not go into that, I'll say "if you have no internet disengage your firewall before you proceed" and that's it. This is only about the local subnet, if there is internet I am fine, they use a bookmark in their browser and see the IP of interest (which the device has written there on boot time over the internet). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/ Original message: http://groups.google.com/group/comp.arch.embedded/msg/0d9a6b277ddf7039?dmode=source |