I've been trying write an application which will be able to connect to a network device via rndis or over wifi and perform some simple operations.
The kicker is that I want to be able to find a device I've connected to before, through either connection method. I initially figured I'd just check for a previously seen mac address, but I discovered that the rndis mac address and the wifi mac address don't match. I'm on windows so the next thing I tried was to use nbtstat -A and ping -a, but those didn't turn up anything unique either (I figured I might get a device name, but it doesn't seem to have one).
So my question is, is there any tool (ideally available for windows), which will allow me to retrieve some sort of unique information about a network device that will allow me to find it again? I don't have a huge amount of experience in this field so I'm not sure exactly what that would be, but I hoped that there may be a way to get the mac addresses for both network adapters while only connected to one, or perhaps use a different tool to find a device name that I'd missed.
Thank you for any advice you might give, I really appreciate it. Sorry if I'm overly wordy.
EDIT: In case I've been ambiguous. I am connecting repeatedly to an external device via RNDIS or WIFI from my desktop PC. My goal is to be able to consistently recognize the network device regardless of the connection method used.
EDIT: By networked device, I mean that I have small independant devices (such as cell phones or tablets) running a unix os, which I access from my Windows desktop via wifi or rndis, and that I would like to be able to consistently identify. So for example I might want to use this tool to connect to one of two cell phones and be able to recognize which one it is so I can recall previous operations performed with that device. So what I'm looking for is a unique (or semi unique) attribute of the cellphone available to me that is consistent when accessed via rndis or wifi.
You can get MAC address (and bunch of other network interface info) with built-in ipconfig command and parse its output later:
ipconfig /all
Alternatively, if MAC address is all you need, try getmac.
Related
I have a piece of equipment at work that has a USB output, that then requires to be connected to a specific USB-to-Ethernet adapter in order to send TCP packets. I am trying to cut the Ethernet adapter out of the equation, and connect the USB output directly to the computer.
A Windows machine does not detect hardware changes when it's connected, so I'm thinking about using a Ubuntu device since it might have better network tools.
What are the ways I can test the device to figure out what it actually is? Is it even possible to remove the adapter from the equation in this situation?
PS. The device is a very specific ECU used in cars. It is not something I can download drivers for. It also uses a Class C IP address.
I have an usb device (pole display), which i don't have driver for.
I installed generic usb driver and opened the port for sending(I use bulk transfer) data to device.
With usb monitoring software i see my data gets to device, but nothing much happens on device side.
The device commands(ESC/POS) work when transfered over (virtual) com port, but not over usb port.
Shouldn't device process commands the same way regardless connection type (com vs usb)?
How can i figure out what commands work with the device (for example, if i send some text, i want it to show on display)?
Any help is appreciated!
Look at the USB descriptors the device reports in order to determine its class. If it is a custom device and not a standard class then you'll likely not be able to work with it. There is a big difference between old RS-232 COM protocol and USB. USB devices can have multiple configurations and endpoints, each responding to data in different ways. Many classes exist and are pretty standard (CDC-ACM is typically used for virtual serial ports.) However, it's not uncommon for device manufacturers to include OEM specific configurations and endpoints which can be used for their own custom interfaces, firmware loading, etc.
Is there any initialization data transmitted through the COM port when connecting the device? The device surely can treat COM and USB different, but another possible thing that goes wrong is that the device needs to hear some sort of "I'm going to start sending commands"-signal from you first, and that signal may be different between COM and USB.
So what I would recommend is first (if you have not done that yet) see what data is sent to initialize the COM connection, and if that doesn't have an obvious USB counterpart, connect it to a PC where you do have drivers (assuming that is available somewhere and somehow, which is possible if e.g. you ask this due to OS incompatibility) and see how the connection is initialized there.
If the first doesn't work and the second is unavailable to you, then I'm afraid there's little I can do to help you, since it's usually not visible for you what commands the device wants to hear other than by guesswork, documentation, or comparing to similar devices where you do have that data available.
I'm using a Macbook to interface with an ARM development board (Beagleboard xM) over SSH and I use a direct Ethernet connection from the board to my mac. I know I can connect to the board just fine if I know the IP. Usually it will take the next address in line from the last time I connected (e.g. 192.168.2.x -> 192.168.2.x+1), however, sometimes it does not. To find the device on my network I've tried using nmap -sP and -PN, both will return with only the IP of, what I think is, the virtual router on my mac. I have also tried the usual ping 192.168.2.255, this will either return no devices connected or, as mentioned previously, the virtual router.
Does anyone know why it does this or if there is a way for a mac to list all the IPs it is directly connected to over Ethernet (no router, computer to computer)? If I need to I also run Ubuntu 13.04 on my Macbook, so that is an option.
Any suggestions would be greatly appreciated, randomly guessing in the dark at the IP is driving me crazy and scripts I've attempted to make have had no avail.
Thanks!
If you install the avahi daemon on the Beagleboard you should be able to see it between the other Zeroconf devices, thus allowing you to connect to with the name hostname.local, where hostname is the host name of the board.
I had a similar issue, I used the app WaterRoof to figure out what IPs were connected and look for something like what I thought it should be. You may see lots of stuff from places you did not know were connecting to your computer, but I was able to at least narrow it way down and try the few IPs that looked possible, and I got it going. You may try disconnecting/reconnecting the ethernet so it has to renegotiate a connection, and from that you should see it in WaterRoof.
Or maybe this give it to you:
How to determine the IP of the computer that connects to me?
I wonder if anyone can help at all, a bit of a specialist problem this.
I have an application that needs to read and analyse a number of USB devices (not simultaneously, they are each run in seperate tests and could in theory be run on different machines).
Each of the USB devices is based on the USB HID class, and are manufactured by different companies, none of these USB devices are designed to be run on PC, but are meant for a different platform, however for the purposes of testing the devices the client has requested that the test application is run from a PC.
Some of the devices will start up, be recognised by windows which will initialise and start them correctly using the generic HID class driver built into windows, the devices will then start sending correct data packets of the data to be tested.
Some of the devices will start up, be recognised by windows which will try to start them but fail to fully to initialise them leaving them in a half initialised state. This is fine, as I can use my beagle protocol analyser to capture the initialisation packets from the genuine platform and then use the LibUSBDotNet library to replicate the remaining packets in the initialisation sequence and get them to start sending the packets correctly.
The problem I have is with one particular device (though there are some more I haven't tested yet so it's quite possible one of those may also exhibit the same problem). The issue is the the Windows HID class driver recognises the device and trys to initialise and start it, this works after a fashion and the device starts sending data.
The problem is that the data being sent is different to that which is sent to the genuine platform (containing only a subset of the full data). It's as though windows has initialised the device into a different mode.
When I capture the initialisation packets from both the PC and the genuine platform using my USB protocol analyser I see that Windows is sending some slightly different initialisation packets. Using LibUSBDotNet to resend the correct packets once Windows has already started the device seems to have no effect.
My problem is that I need to stop windows from trying to initialise the device using the standard HID class driver, I've tried removing the driver in Device Manager but it still initialises it (and the driver is magically reassigned in device manager). I've done some investigation and there are possible alternatives:
Create a specific driver which windows will assign to the particular VID/PID of the device but that does nothing, then I can use LibUSBDotNet to send the correct initialisation sequence to the device from within my own code.
Use something like WinUSB to create a proper driver for the device (or possibly to create a "dead" driver like 1.
Will a driver with a specific VID/PID defined be used by windows in preference to it's inbuilt USB HID class driver? If not then I would be wasting my time going down this route?
Note, my mac initialises the problem device correctly, and I've asked the question of the client whether the application can be developed for Mac and their answer was frustrating Windows only.
I've no experience in writing proper Windows drivers, though I have experience in talking to USB at a relatively low level (so that part doesn't worry too much). Can anyone suggest a good course of action (before I potentially waste weeks investigating how to write drivers for the PC only to find my selected course of action can't deliver what I required).
Any help or suggest much appreciated.
Thanks,
Rich
Added after trying suggestions below:
I tried using the LibUsbDotNet inf wizard to create the necessary files and install them and this appeared to work - certainly the device was now appearing in Device Manager as a libusb-win32 device - not HID device and the associated driver was libusb driver. Even after doing this the device still seems to become initialised and start sending the wrong type of data packets although now those packets are no longer handled by the class driver and are just lost.
I also came across Zadig which has a similar inf creation wizard for WinUSB and this had exactly the same result.
A colleague has suggested that it might not be windows itself that is switching the device into this mode, rather the device identifying that it is connected to a windows machine and switching itself into this mode. I suspect this is the case, in which case I am stuck - time to have another conversation with the client.
Many thanks for the help.
You're using libusb-win32 as a filter driver; that is, the HidUsb device driver is assigned and loaded for your device, but then the libusb-win32 driver is loaded on top and gives you unobstructed access to the hardware.
If you don't want a HidUsb (or any other class driver) to perform any communication "on your behalf", simply associate libusb-win32 as a device driver with your hardware. For this, you'd have to create an .INF file associating it with the VID/PID/Revision of each USB device. If I recall correctly, libusb-win32 even comes with a utility to generate such .INF files.
If you install this .INF file e.g. with PnpUtil.exe (available on Vista or higher), you might still run into issues where, although you're a better match than the generic HID driver, the HID driver is still selected.
The generic HID driver matches devices by their Compatible IDs (i.e. by a USB interface class) while you'd be matching by Hardware IDs (which have higher priority). However, Windows might give priority to other aspects, such as your driver being unsigned. Read: How Windows Selects Drivers
Luckily, even in that scenario, signing drivers with a self-generated certificate (use CertUtil.exe, MakeCat.exe and SignTool.exe) is not too difficult.
Do you know a way to use the Windows XP API to reset the USB bus? In other words, I'd like the OS to kick out any USB devices that are currently connected, and then auto-detect everything anew.
I'm aware of devcon, and I suppose I could do system calls out to it, but I'm hoping for a direct call into the API.
From kernel mode: You can force a specific USB device to be re-connected, as if it was unplugged and replugged again, by sending an IOCTL_INTERNAL_USB_CYCLE_PORT to its PDO. (This can only be done from a kernel mode, e.g. through a helper driver.) This 'cycle' operation will cause a USB reset to occur, after which the device would be re-enumerated. For example, if the device comes back with a different USB device descriptor, a different driver may be matched for it.
From user mode: You can do this by ejecting the device through the CfgMgr API. For example, to go over all USB hubs and eject all devices:
Find all devices having device interface GUID_DEVINTERFACE_USB_HUB with SetupDiGetClassDevs(... DIGCF_DEVICEINTERFACE).
Enumerate over the returned device information set (SetupDiEnumDeviceInfo).
For each device, get the DevInst member:
Invoke CM_Get_Child(DevInst) and then CM_Get_Sibling repeatedly to go over all child nodes of the hub (i.e. the USB devices).
For each child node, call CM_Request_Device_Eject.
Well, use can use the Setup API (SetupDiXXX functions) to enumerate the USB devices in the system, and then call WinUsb_ResetPipe on each one, but I'm not sure if that's what you're looking for. It's been a while since I worked with USB devices, but as I recall, there is no standard way to reset a device (i.e. simulate a power off/power on cycle). If it's possible for a particular device, you'd have to send an appropriate IOCTL (using DeviceIOControl) to the driver. The IOCTL would vary from manufacturer to manufacturer.
It's possible to cycle the parent port on the USB hub the device is attached to, as well. This will result in, among other things, apparrent unplug/replug actions, as you will see a balloon popup when this occurs.
Much of this is poorly documented, and honestly, I've gotten the impression there are only a handful of people at Microsoft who really understand it well. The design decision I've made for future devices I design is that I intend to include watchdog functionality on both sides, as well as a device-side full reset function. That way, if the device figures out it is confused, it can just cut its own power for a second and fully reset, if the host can't communicate with it, it could do the same thing, and if the device thinks everything is fine but the host knows better, the host could order it to reset.
There are at least three APIs worth looking into for this problem: the Setup API, the Config Manager API, and various WMI extensions. However, be cautious about diving into WMI if you intend to use an Embedded XP target, as you will have to include a lot of other things in your OS image you might otherwise not need.
As far as I know, there is no way to do this - you can issue a command to have PnP rescan the bus for new devices, but that isn't the same as issuing a bus reset.
Furthermore, just because from a hardware perspective you issued a bus reset doesn't mean that Windows will remove the PDOs that represent the children of the hub and redetect them; the USB bus driver can (and does) do just what I describe (i.e. issue hardware bus resets without disturbing the device tree), and only after the device doesn't respond does it issue the surprise removal and yank it from the tree.