Firstly full credit to Chris van Marle for his work on his CDPSniffino code, of which I have butchered (to be honest) to get it to work with ENC28J60 ethernet controllers. The packet info that is captured is slightly different, so it took a while debugging. This is also my first Arduino project (not including 3D printers). It has been a while since I have written C code… Enough excuses…
Anyway, I use a lot of Cisco equipment and I have found on many occasion that network wall ports are either not labeled or the labels have worn off. When that port needs to be reconfigured it can take time to work out which network cabinet it goes back too, then which switch, and then which switch port. Most of the information can be obtained from CDP (Cisco Discovery Protocol):
- The switch name gives a good indication of which cabinet and switch.
- Model: Helps when the hostname has no indications of what the device is.
- IP address: You can try to remotely access the switch (SSH/Telnet/Web interface).
- The switch port is given (E.g; FastEthernet0/1).
- VLAN: Good to know because it often determines what DHCP range is offered – I’m still working out if it’s the VLAN of the port or the “switch”.
The original code for CDPSniffino compiled fine on an Uno with a W5100 network shield (kudos again to Chris). I had always planned to make a few network enabled devices, and cost cuts are in effect. The ENC28J60 is significantly cheaper than the W5100, and the Arduino Mini Pro compatible boards have enough capacity to be a good substitute. Arduino Uno R3 + Wiznet W5100 shield >$20. Arduino Mini Pro + ENC28J60 = can be < $5 (shop around).
The ENC28J60 works with the Ethercard library. It took a while to find now to get the NIC to switch to promiscuous mode. When enabled the controller will process all packets it sees, and not filter multicast and broadcast packets.
To make it faster and easier to obtain the info, it needs a screen. The alternative is plugging it in and dragging out a laptop to read the info through a serial port. I tried a few no name LCD’s, but found (as many others have), that without correct information (datasheets or a driver name) it’s a huge time waster. Also most had 3.3v VCC and data lines (not 5v). Luckily I found a cheap supplier that did (after 3 failures). These have been pretty good, they can output text with basic commands using the Adafruit_ST7735 library. I mistakenly had 5V running to the LED line for a while (should be 3.3V) , after the LEDs cooled down, the blue tinge disappeared and all was fine.
The two test rigs shown below are both using ENC28J60 controllers, the larger on has a character LCD and Arduino Uno R3 board. The smaller one has an Arduino Mini Pro (compatible), and an ST7735 based color graphical LCD. During testing the larger one drained a 9V battery after about an hour of use. A goal was to make it small enough to join to this and use the phone charger battery for power.
What I found when testing:
- CDP is enabled by default on most Cisco devices.
- The default schedule for sending CDP packets is every 60 seconds – Although this can be changed or disabled.
- Wireless Access Points also have CDP enabled by default, which is good when tracing which WAP connects to which power injector (what out for POE!).
- Un-managed consumer grade switches will pass CDP packets, so the switch you see may not be the one that is connected directly to the port. Also the heavier the traffic on an un-managed switch, the longer it takes to detect the packets. I believe this is because the ENC28J60 doesn’t not have a lot of processing power, and the Arduino Mini can’t keep up, so it drops packets when under heavy load.
All code and STL’s for the case will be published when I’m happy with the smaller test unit.
UPDATE: Reprinted case in green and crudely added it too the wireless serial device. Time for a field test.
UPDATE [24-06-14]: I’ve reduced the overall size of the case by about 10% by using a smaller ENC28J60 PCB, and started working on extra features. One of the features I’m working on is getting it to check for open ports (80, 22, and 23) on the detected equipment (if it’s IP can be obtained). If the switch accepts a connection on any of those ports you can gain access to the remote switch using network rather than using a serial cable.
As requested below: Source Code (needs clean up)
Edited Ethercard Library ethercard_edited