Change IP address while LLMNR running

[adyr]

Hi,

I am using MQX via the KSDK 1.3 configured with PEx in KDS 3.0 and built with IAR 7.40.7. I have include an HTTP server, FTP server and LLMNR server from the MQX RTCS and the MQX shell feature.

I have found that if I try to change the IP address via the shell ipconfig command while the LLMNR server is running it upsets the LLMNR server so the name is no longer recognised from hosts. Once in this state no amount of stopping / starting the LLMNR server fixes the issue. The only fix is to reset the board.

However, if I shutdown the server then change the IP address and start the server again all is well.

This leads to a second issue where the shell does not detect an LLMNR server that was started outside the shell as it keeps it's own copy of the LLMNR handle in a static variable. I guess I can get around this by starting the LLMNR server by calling the Shell_llmnrsrv function from my code instead of starting a server using LLMNRSRV_init.

Having the LLMNR server will be a huge benefit if it works well with the dhcp feature so the user is not required to hunt down the assigned IP address of the target and can just use a friendly name instead.

Can anyone can suggest how I can fix the unbinding of the LLMNR server so it can remain running during an IP change?

Best regards,

Adrian.

[pmt]

Andy,

Thanks, that information is helpful.  Yes, I agree that the LLMNR needs to know about it's interface IPv4 address.  But there are two things we are talking about here, the LLMNR protocol, and the LLMNR Server MQX Task. 

My problem is that IPv4 addresses are run-time dynamic.  They change, come and go, and interfaces don't always have an address assignment.  So I would need to write a wrapper for the LLMNR Server Task to detect anytime an IPv4 address is bound, start LLMNR Task, and if an IP address changed or was unbound, shutdown and restart RTCS each and every time (according to the post above).  Do you see my issue?  This just isn't a workable solution.

The LLMNR Server Task itself should detect the dynamic assignment of an IPv4 address on an interface and join the multi-cast group upon that event.  The LLMNR Server Task also should not abort immediately and exit the task if the interface does not (yet) have an address bound.  It needs to start and wait for an IP address binding.

Thanks,

PMT

[Carlos_Musich]

Hi Adrian,

I think you need to restart the TCP/IP task. There are some variables that are not resetting or so. Kill your TCP/IP task and then run again your networking initialization code.

[pmt]

Carlos,

It looks like the LLMNR service is half baked.  I found the same issue.  Though you start the LLMNR service by giving it a handle to an ENET device, if there is no bound IP address already in place the LLMNR service aborts before it even starts. 

This is not a workable solution.  IP addresses might be assigned 20 minutes after my board boots, addresses can change; DHCP leases expire, network cables are plugged and unplugged, an enet device might be multi-homed (be bound to multiple IP addresses), etc. 

This is the kind of behavior I would expect if the service was bound to an IP address, but it's not.  It takes an ENET device handle, so darn-it, LLMNR should auto-magically work on all bound IP address to that device even if they come and go.

Short of this, a compromise solution would be to at least integrate LLMNR into the ipcfg link management task.  But really this needs to be fixed in the LLMNR service itself because it is simply not usable in its current implementation.

Best regards,

PMT

[butok]

Hi,

LLMNR service is working with multicast addresses. To join any IPv4 multicast group, an application must know about its interace IPv4 address. This is llimitation of BSD-socket API, as the interface to join is defined by its IPv4 address. The limitation was solved by IPv6, the interface is defined by its scope_id.

FYI: For example, you can try FNET 3.0, its Socket Multicast API was improved to avoid this issue (used interface scope-id for both IPv4 and IPv6).

If you need to run LLMNR on several interfaces, just run separate LLMNR instance on each interface.

Best regards,

Andrey Butok

[pmt]

Andy,

Let me ask my question another way:  How do I use the LLMNR service with IPv4 in the real-world?  Can you provide an example?

The shell example is a good start, but it's somewhat contrived.  You would not ask the user to interactively log into the shell to start the service after IP address binding, because if they already knew the IP address to log intot here would be no reason to run LLMNR. 

So in practice, how do I actually use it?  Can you give me an example where I am using the ipcfg service with the ipcfg link task, and booting DHCP, and have LLMNR start unconditionally sometime during or after network initialization?

Thanks,

PMT