broadcast UDP to 255.255.255.255 with synapse lazarus / 38-Networking and Web Programming ---------------------------------------------------------------------- bd4kc · 2021-01-02 11:14 I think I should have a common problem: I made a small device that didn't have a keyboard or screen, and it transferred data to the computer via an Ethernet interface and configured it. The problem came when I moved this device to another network and their network addresses didn't match, and I needed to "broadcast and find" the device. So I wrote the broadcast code with synapse and lazarus, and broadcast an instruction to the address of 255.255.255.255 with udp. When the first "connection" (udp is not actually connected, just some initialization), it is ability to "broadcast" and then the connection must be destroyed and recreated before it can be "broadcasted" again, and an additional delay is required. Excuse me, why is that? At the time of the experiment, the computer was at 192.168.2.10, and the device was at 192.168.1.200.  A cable is directly connected, no router switches, etc. I can only see once a network package for 255.255.255.255 with the wireshark tool. As in the code, button2 does, destroy and re-create once before it can be broadcast again. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure TForm1.Button2Click(Sender: TObject);var   sb:string;beginsb:='255.255.255.255';client.Disconnect;while ServerThreads + ClientThreads > 0 do  begin  application.ProcessMessages;  sleep(10);  end;//showmessage(rcs003); //  if client <> nil then  begin  client.Free;  client:=nil;//  end; client:=TClient.CreateUDPClient(sb,'50000');    //client.onEvent := @ClientEvent;client.onData := @ClientData;client.Connect;sleep(1000); //！！！！！！！！！！！！！！！！！！！！！！！！！！！！ ！！！！！client.Send(ch9126ask,367); end; procedure TForm1.Button3Click(Sender: TObject);begin  client.Send(ch9126ask,367);end; procedure TForm1.FormClose(Sender: TObject; var CloseAction: TCloseAction);begin client.Disconnect;while ServerThreads + ClientThreads > 0 do  begin  application.ProcessMessages;  sleep(10);  end;showmessage(rcs003);   //if client <> nil then  begin   client.Free;   client:=nil;//  end; end; procedure TForm1.FormCreate(Sender: TObject);varsb,sc,s:string;beginsb:='255.255.255.255';s:= '192.168.1.1 0';sc:='192.168.1.255'; client:=TClient.CreateUDPClient(sb,'50000');  client.onEvent := @ClientEvent;client.onData := @ClientData; client.C onnect;Memo1.Append(rcs010);memo1.Append(client.MyIP);memo1.Append(cli ent.Port);end; ---------------------------------------------------------------------- MarkMLl · 2021-01-02 11:18 Irrespective of any Synapse issue, remember that UDP broadcasts are not normally propagated between subnets so what you're doing might not be a good idea. MarkMLl ---------------------------------------------------------------------- bd4kc · 2021-01-02 11:30 Quote from: MarkMLl on January 02, 2021, 12:18:12 pmIrrespective of any Synapse issue, remember that UDP broadcasts are not normally propagated between subnets so what you're doing might not be a good idea. MarkMLl THX！ What am I going to do? If I forget the ip address of my device, or if my device is commoditized to go on sale, I need to adapt to various network addresses, or if the address label is lost. I want to find a possible solution. ---------------------------------------------------------------------- bd4kc · 2021-01-02 11:42 Quote from: MarkMLl on January 02, 2021, 12:18:12 pmIrrespective of any Synapse issue, remember that UDP broadcasts are not normally propagated between subnets so what you're doing might not be a good idea. MarkMLl Whether the orthodox solution is like a commodity router, with a label at the bottom that says the factory default address and a button on the side that resets it to the factory setting. I don't need to develop a Broadcast application. ---------------------------------------------------------------------- MarkMLl · 2021-01-02 12:26 A lot depends on what OSes you're using: which you have spectacularly omitted telling us :-) That's not so much because it affects the behaviour of devices on the network (the firmware in local routers etc. is obviously outside your control), but because it affects what tools you have available and your skillset. See a recent discussion which I think was titled "Korg remote desktop", but also consider that for something clever/non- standard like this you might be better going directly to the (Berkeley) sockets API. In the general case, there's nothing to stop your headless device broadcasting its identity now and again, perhaps using a zero-length UDP packet. You obviously can't rely on everything else seeing that because of the way that routers (including "multihomed hosts") will partition your network, but (a) systems on the same subnet might be able to note what they see and pass it on and (b) in extremis you will be able to sniff it using Wireshark etc. I've put a lot of work over the last few months bringing a 20-year-old piece of monitoring software that shares its status using UDP up to date without breaking backwards compatibility. It uses a low-numbered UDP port (which implies that unix code has to be "clever" to listen for messages) and every cooperating system in particular the ones connected to multiple subnets builds up and retransmits a table seeing when activity was seen from any other host... it sounds simple, but because of legacy constraints it wasn't. MarkMLl ---------------------------------------------------------------------- bd4kc · 2021-01-02 23:42 I used an office computer that ran win10 and wrote a few lines of code to do the experiment. Seeing your advice, I decided to add a button and a label to the device to make it look more like a commercialized device on sale. ---------------------------------------------------------------------- MarkMLl · 2021-01-03 08:40 The button's definitely a good idea IMO. But I've also been frustrated by things like webcams and for that matter network switches in the past which had an unknown factory-reset address or which for some reason I didn't want to wipe. If a device like that get its address using DHCP/BOOTP then the handshake can be monitored or the allocated address found in a log, but in all cases having /some/ unobtrusive announcement would be useful... perhaps a zero-length UDP message or an ICMP echo request with a recognisable payload. MarkMLl