I have a IdTCPClient on my application and my firewall inform me about an outgoing connection to 224.0.0.252:5355. In the connection properties the used protocol is UDP.
I've searched for "224.0.0.252" and found that it's an IP multicast address (Link-local Multicast Name Resolution)
Q: Why IdTCPClient try to do that?
As its name suggests, TIdTCPClient only supports TCP not UDP.
UDP 224.0.0.252:5355 is used by Microsoft in modern Windows versions for Link Local Multicast Name Resolution (defined in RFC 4795) as part of their hostname-to-IP lookups when conventional DNS is not available.
When you ask TIdTCPClient to connect to a hostname, it asks the OS to resolve the hostname to an IP address before then connecting to it. Your Windows version is obviously utilizing LLMNR as part of that resolution, and your firewall is picking up on that. That is happening outside of Indy.
The connection to 224.0.0.252:5355 with protocol UDP is used by recent versions of Windows for Link Local Multicast Name Resolution (LLMNR) searching for local network computers.
If you have no local network you may disable LLMNR with a peculiar registry setting.
Create and execute the file "disable-LLMNR.reg" containing:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient]
"EnableMulticast"=dword:00000000
Related
I'm using Delphi 10.2 Tokyo. I have 4 internet sources with 4 LANs. I want to make a program using TNetHttpClient. How do I direct it to use a specific internet source?
Unfortunately, TNetHttpClient does not provide the ability to bind it to a specific LAN. If you need this capability, you will have to find another HTTP library that can do this.
UPDATE:
After doing some reading, it turns out that on Windows at least, binding a socket for an outbound connection only sets the source IP for the socket's packets, but prior to Vista the actual adapter used for making an IPv4 connection is determined solely by Windows' routing tables, the application can't force a specific IPv4 adapter to be used. But for IPv6 traffic, and for IPv4 traffic on Vista+, binding a socket to a specific adapter should work in most cases.
Q175396: Windows Socket Connection from a Multiple-Homed Computer
Strong and Weak Host Models
Using a specific network interface for a socket in windows
For instance, Indy's TIdHTTP has a public BoundIP property for binding its socket to a network interface's IP (on platforms that require an interface name instead, you can use the TIdHTTP.OnSocketAllocated or TIdHTTP.OnAfterBind event to call the TIdHTTP.Socket.Binding.SetSockOpt() method, such as for using the SO_BINDTODEVICE option on Linux).
We are using Delphi Berlin 10.2
We have an application that runs on devices with 2 or more ethernet adapters. It's mandatory for us to choose a specific network adapter.
I researched and failed to find a way to do this using Indy, Synapse, or even Winsock.
The connect methods don't offer this option, they offer only destination IP and port.
Is there a way to do this?
You need to bind() the client socket to the local IP address of the desired network interface, then connect() will reach out to the server's IP:port using the network that the interface is attached to.
Indy has properties for that purpose, for instance the BoundIP property of TIdTCPClient.
I'm sure Synapse (and most other networking libraries) has its own equivalent for this, too.
I am developing an P2P application in Delphi XE5 with a PHP remote server as a tracker to make a list of the clients sockets. I am afraid that using UDP Hole Punching would fail at some point if client's NAT decides to close/block that random port it created with in the first message sent to the PHP remote server.
So I with to know How to make a more time persistent port configuration with NAT from the Client (which is written in Delphi). I do not want my user to need to know how to access a router and configure port forwarding himself.
Could I do that and use the server just to store the socket without the PHP-P-H and be sure that at least while the Delphi's application is running the port will remain opened?
If I do decide to use UDP hole punching from remote server, Will the NAT maintain the port opened to user's local PC if no other users connect to it directly (P2P) soon enough?
If I open that port with UDP, may I use TCP after?
Obs: Delphi XE5 to compile to Windows 32 and Android, so I need a non-Windows Only solution.
Microsoft has an API for working with NATs via uPNP, especially for assigning port mappings in particular. Look at the IUPnPNAT interface and its StaticPortMappingCollection property. Use IStaticPortMappingCollection.Add to assign ports in the NAT.
Of course, this only works with routers that have uPNP turned on. Not all routers support uPNP at all, or have uPNP enabled.
There is a lot of other answers related to this issue, however I believe this is specific.
I am using Delphi XE2 and Indy 10.5.8 and TIdUDPServer
In my local development network I have everything on the same network ip subrange and all connected to the very same Access Point (LinkSys)
I have Androids sendind UDP Broadcast to 255.255.255.255 to request the server ip address that is written in Delphi listening using TIdUDPServer on the port 44444.
The requests get there fine and I can answer back no problem. Works exactly as expected.
However I have noted that in some networks it does not work! It is always simple networks based on an access point, I am not sure but seems that where the problem happens the server PC is connect to the LAN port while the devices are using the wifi, all in the same access point.
Could be the case that the access points do not broadcast the UDP packet by the both LAN and wifi? I know that this kind of broadcast is very limited, but I have not found any information that tell me that in the same access point there is limitations like that.
Is there are ways to test, or workaround?
This solution needs to be strong enough to deal with the many AP out there.
EDIT: For those that want to get the source code for retrieving more information from the network including the broadcast ip as mentioned on the answer below follow this solution, it is all there.
http://www.code10.info/index.php?option=com_content&view=article&id=54:articleretrieve-network-adapter-information&catid=47:cat_coding_algorithms_network&Itemid=78
255.255.255.255 is not the best option for sending UDP broadcasts, and some routers/firewalls do block it unless configured otherwise. The better option is to use the NIC's actual subnet broadcast IP instead. For example, if a UDP socket is bound to local IP 192.168.0.1 with a subnet mask of 255.255.255.0, then the broadcast IP for that subnet is 192.168.0.255.
Most platforms have OS-specific APIs for retrieving a NIC's actual broadcast IP, such as getifaddrs() on POSIX systems, or at least for retrieving the NIC's subnet mask, such as GetAdaptersInfo() and GetAdaptersAddresses() on Windows, so you can calculate the broadcast IP manually.
Retrieving the local broadcast IP(s) may be added to Indy in a future version.
Is it possible to connect to remote host with indy client and send data to the local server.
i try something like this and i don't receive anything:
Server:=TIdUDPServer.Create;
Server.OnUDPException:=UDPException;
Server.OnUDPRead:=UDPRead;
Server.Bindings.Add.Port:=10;
Server.Active:=true;
//Server is listening to local IP
Client:=TIdUDPClient.Create;
with Client do begin
Host:= '130.204.159.205'; //My IP
Port:=10;
Send('Hello');
end;
My goal is to create client/server applications that will communicate with UDP over internet
UDP is a connectionless transport. It does not guarantee data deliver like TCP does, especially over a large network like the Internet. If TIdUDPServer is not receiving data, then either the packets are not reaching the machine to begin with, or are being blocked before TIdDUPServer can see them. Use a packet sniffer, such as Wireshark, to verify that the packets are reaching the NIC(s) that TIdUDPServer is listening on. If they are not, then you have a networking issue. If they are, then you have an OS issue.
Yes it is possible. Let's bypass some questions and try this instead:
Host := '127.0.0.1'
If that doesn't work, check to see if your Windows Firewall allows your test application to connect to itself. (Turn off local software based firewalls and try it again.)