Digi connect ME seems to be running with our own firmware, that means it doesn’t answer on the discovery tool.
How can I find out its IP-address?
Does anybody know a tool that helps me finding out the
IP-address, when I know the MAC address?
- If you still have the startup splash (digi calls it a “dialog”) it will be listed there.
- If not, check your appconf.h - if you don’t have it set to DHCP, it will be what you set it to.
- If you have it set to DHCP, then you are stuck. Use the diagnostic mode to load a new image. I put as the first line in my program a call to customizeGetIPParameters() and then print that to the serial port. Also note that you might want to use customizeMiiCheckLink() to see if the cable is plugged in.
-Erik
I have a related problem. In our case the serial port is hard wired (soldered) to a terminal device and is not available for any other uses. There is a web page that allows an authenticated user to assign the IP address, mask and gateway for their local network or enable DHCP. But when a unit comes into our repair depot, there is no way for the tech to determine what the current IP settings are.
I want to add a UDP broadcast or multicast based discovery feature similar to Digi’s, but don’t have any experience in that area. Has anyone else done that and have ideas or simple examples they could share?
With the development kit there are a number of method one could implement, in order to enable a ‘discovery’ or ‘recovery’ method.
-
Using UDP, broadcast and unicast, create a thread that listens for incoming broadcast, on some port of your choosing. This broadcast would carry some message, i.e. “Who is out there?”. The receiver would respond with “I am here”, via a unicast datagram. The discoverer could then elect to send out a unicast datagram containing the new TCP configuration for the device. The discovered device would save and enable its new configuration.
-
Create a thread that would monitor the GPIO PORTC5. On the ME and Wi-ME this would be the /INIT pin, re: pin 20 of the module itself). On the EM, Wi-EM and SP this would be the reset button on the device itself.
This thread could be setup to monitor this pin. Once it has been held low for a set period of time, you could have a secondary Ethernet device brought up with a set IP or reconfigure the currently assigned primary address (both of these methods would be temporary, unless changes were made elsewhere; i.e. via a web interface). -
With our -C connect modules you have control over the boot loader code. One could certainly create a command-line interface, activated by the pulling of /INIT low, during module power up. From this interface you could enable the ability to restore the application image, via TFTP, erase the NVRAM/application, or modify the stored development board parameters structure (devBoardParamsType). This option would likely be mean that you boot loader would have to increase from 64kb to 128kb, however, but this is not a significant problem.
-
Install and run a Ethernet sniffer package, such as Ethereal, filtering out all MAC addresses other than the device you are ‘looking’ for. Then manually add a route to your PCs route table, to enable network communication.
There are certainly many other, yet to be spoken, options out there, these are but a few that I thought up.
Cameron
> Does anybody know a tool that helps me finding out the
> IP-address, when I know the MAC address?
I want it to !
This specific need is usualy addressed by the ARP protocol / RARP protocol (Reverse ARP) : check “ARP protocol” with google. (Getting IP @ from MAC @ / getting MAC @ from IP @)
The problem is to know if the digi connect EM / ME dev kit allow us to use the ARP protocol… (We want the digi connect module to answer the broadcast RARP request if the MAC @ matches).
What I understood with the documentation & BSP sources is that there are functions embedded in the ACE module of the BSP (see below) to use ARP à bootup time, to acquire an IP when DHCP fail.
I’m currently looking at udp.c, ethernet.c, arp.c and arp.h BSP source files to see if I can find interesting materials there (ArpInitialize(), ArpIpToMac(), ArpReceive()…).
Seb
This is been a serious pain of mine also, and I have communicated the issue to several representatives and sales personal, hopping they are going to do something about it. It seems it felled to deaf ears so far.
There are two things you can do to circumvent this issue:
- Have a network administrator assign an IP address for exact MAC address;
- This I like better use the following sniffer/spoof (WinArpSpoof.exe) from this article to locate the device.
http://www.codeproject.com/internet/winarpspoof.asp
or
The required libraries for the packet capturing can be downloaded at:
Note that some networks do have a problem with this program, and you may not be able to locate the Connect ME device.
Hope this helps until Digi decides to either release the source we can use to utilize the Device Discover Utility or does something about this. I hate distributing third party tools to our customers, especially when we cannot support them. Digi has source examples with their proprietary library that locates the device, but this is only if it has the OEM firmware.
Message was edited by: ieftimovski
Option 1 is what I want to do. None of the others are possible or supportable. However, I have always avoided IP broadcasts like the plague, because we have had numerous bad experinces with noisy systems that primarily use broadcasts. So I have no idea how to configure a NIC to send and receive broadcasts when it either has no valid IP address or is plugged into the wrong subnet. My support staff wants to be able to find it even if they’re not plugged into the “foreign” subnet the device happens to get plugged into.