0

I'm developing an application on embedded linux. User has an option to change the IP address of the device from a web portal.

I have a windows application (built on C#) that can communicate with the device via API but for this I need to know the IP address of the device. I want to build a simple search utility so that the user is able to search for the device if it's connected to his PC via ethernet cable (The device IP and the PC's IP addresses can be on separate networks)

enter image description here

So suppose my Windows machine has ethernet IP address 192.168.20.45, and the Linux device has an IP 10.15.11.120, the windows software should still be able to search for it and show it.

On searching about this I found uPnP but all tutorials lead to media servers which I don't want.

Can anyone suggest me what would be the right approach for what I want?

1 Answer 1

0

The part of UPnP that's relevant to you would be SSDP, the service discovery protocol. (SSDP can be used standalone – it doesn't have to to be bundled with any of the media-related services nor with the IGD service that home routers call "UPnP".)

However, SSDP is probably unnecessarily complex if you're not required to use it specifically. (Everything in the UPnP family involves a lot of XML and SOAP.)

A simpler alternative would be mDNS/DNS-SD which is already widespread in full-size Linux environments – it's what avahi-daemon as well as macOS Bonjour implement for device and/or service discovery. Devices such as printers, smart speakers, or Chromecasts are already using mDNS for discovery as well.

Finally, if even mDNS is too heavyweight, you can just invent your own discovery protocol – pick a multicast group address and have the PC send "discovery" UDP packets to it, which your device will receive and reply with "yo I'm here and my address is" packets to the same multicast group. Then have the PC receive the device's advertisements on that multicast group. That's more or less how SSDP and mDNS work.

(Using broadcast (aka all-hosts multicast in IPv6) is also a possibility – a lot of vendor specific discovery tools use broadcast packets in this manner.)

4
  • 1
    Using the all hosts multicast group in IPv6 as a way to send all hosts a message is really bad practice
    – Ferrybig
    Commented Sep 26, 2022 at 14:17
  • How will these messages cross to other subnets?
    – harrymc
    Commented Sep 26, 2022 at 14:22
  • @Ferrybig: Yes, but not any worse than using broadcast in IPv4, which is also bad practice but vendors do it anyway. Commented Sep 26, 2022 at 14:32
  • @harrymc: If they're on the same link, just with mismatching IP configurations, they don't need to cross anything – link-local broadcasts and multicasts will be received by everything connected to that link (subject to multicast subscriptions) regardless of sender address. On the other hand, most discovery mechanisms in current use don't even try to handle situations when devices are not on the same link (i.e. if there's a router in between); many such as mDNS even explicitly prevent their packets from being forwarded even by willing routers. Commented Sep 26, 2022 at 14:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .