Indy getting all local interface information (cross platform) - delphi

I am converting a unit that holds a network interface list to be cross platform. The current version uses raw winsock to obtain the address, mask and broadcast address for each network interface in the system.
I figure the easiest way to make this cross platform is to use Indy. I have found that AddLocalAddressesToList is a nice simple way to get the IP address of all the interfaces but I cannot find out how to get the other information I need (mask and broadcast address).
I think I can calculate the broadcast address so its really just the mask that I cant figure out.
FYI. This is the code I found to get the IP addresses of all interfaces.
TIdStack.IncUsage;
try
GStack.AddLocalAddressesToList(Memo1.Lines);
finally
TIdStack.DecUsage;
end;

WinSock does not support reporting that kind of info. You have to use OS-specific APIs instead. On Windows, that means using the Win32 API GetAdaptersInfo() and GetAdaptersAddresses() functions. On other platforms, you can use the getifaddrs() function where available.
Indy does not currently support what you are asking for. Also, do note that at this time, AddLocalAddressesToList() only supports IPv4 addresses on most platforms, including Windows.
Support for retreiving local IPv6 addresses, as well as other info like subnet masks, is currently in the works, but there is no ETA on its availability yet.

Related

Does ESP-CoAP library to implement CoAP protocol on ESP8266 still work?

I have tried using ESP-CoAP but the coapclient.ino example does not work for me. The server in this example is 129.132.15.80. Is there any other server I can use to test my code? I have also tried coap.me but this code only accepts IP addresses. Are there any alternatives to this library that are regularly maintained?
About the question for test-servers:
Many OS offers you a way to resolve a address as "coap.me" to their numeric address (e.g. unix nslookup coap.me => 134.102.218.18). The open source project Eclipse/Californium offers a sandbox as well (nslookup californium.eclipseprojects.io => 104.196.15.150). You may also try to run Californium's Plugtest Server locally (requires installed java).
In all cases, it's a good idea to get common with ip-capture tools as tcpdump or wireshark. A very first introduction may be found here
About the question for maintained c-implementations:
libcoap is a very common one. But I don't know, if there is a "out of the box" ESP 32 port available.

How to get Adapter Name with Indy?

I can get all local IP addresses using this code with indy:
uses IdStack;
var
IPs: TStringList;
begin
IPs := TStringList.Create;
try
GStack.AddLocalAddressesToList(IPs);
listbox_localIPs.Items.Assign(IPs); //My listbox
finally
IPs.Free;
end;
end;
How can I get Adapter Name for each IP I find with Indy?
Indy doesn't provide such info. You must use WinApi (GetAdaptersInfo, GetAdaptersAddresses) or WMI (Win32_NetworkAdapter).
Indy is primarily just a wrapper around standard socket APIs that do not expose adapter information. AddLocalAddressesToList() uses platform-specific APIs to get the local IPs, and some of those APIs may report adapter names (or expose ways to look up those names through other APIs), but AddLocalAddressesToList() simply fills a TStrings with IP address strings, so it has no way of reporting adapter names even if it wanted to.
With that said, AddLocalAddressesToList() has recently been deprecated in favor of a new GetLocalAddressList() method, which returns a collection of TIdStackLocalAddress-derived objects containing additional information (IP version, subnet mask). So it is feasible that a future release might add adapter names, but that would still be implemented on a platform-specific basis and thus may not be available on all platforms. Indy itself does not need adapter names, so you are best off simply using platform-specific APIs directly to get whatever adapter information you need.

Sending a UDP packet within a kernel module

Background: I'm a fourth year computer engineering major at UCSB. I've taken networking and operating systems courses. I created a program in userspace that broadcasts UDP packets onto the subnet and receives UDP packets in an adhoc network. What I'm trying to accomplish is to convert this program into a kernel module that will work on an ARM embedded system with Angstrom Linux, kernel version 2.6.39 (the x86 to ARM architecture cross compilation is an issue for another day). The reason for this move to the kernel is to shed some of the overhead of userspace functions and to make the sending and receiving part as quick as possible.
I've never done anything like this before in any of the courses I've taken, so please tell me if anything I am saying is incorrect, useless or inefficient!
After research with Google, I've concluded the typical way is to do away with sockets entirely and work with the sockbuf structure and fill in the necessary headers myself. Would this have an effect on the ability to broadcast packets on the subnet?
I am currently trying to follow the code here:
UDP packet send with linux-kernel module without using sockets
I've figured out the reasoning behind most of the code, but the last part is what confuses me:
eth = (struct ethhdr *) skb_push(skb, ETH_HLEN);
skb_reset_mac_header(skb);
skb->protocol = eth->h_proto = htons(ETH_P_IP);
memcpy(eth->h_source, dev->dev_addr, ETH_ALEN);
memcpy(eth->h_dest, remote_mac, ETH_ALEN);
skb->dev = dev;
dev_queue_xmit(skb);
All of the ethernet header seems to be constructed purely out of headers defined in the kernel besides the source MAC address, is this correct? I am going to be broadcasting my packets, so what exactly should be put into the destination MAC address field?
More importantly, what is dev in the skb->dev = dev; line? From my investigation, it is a pointer to the device driver it is associated with. From my understanding, I would want this to point to the wireless chip device driver as I am using 802.11 to communicate. Do I have to create my own dev struct for the wireless driver? If so, there any guidance on how to accomplish this? If not, how can I access the existing device driver and use this in a kernel module?
I've tried commenting out the dev line and running the code but unsurprisingly I get a kernel panic once it executes dev_queue_xmit(skb);.
Again, I've never done anything like this before, so any advice would be helpful, even if it means changing my approach entirely! I also understand that this could be a niche of a question, but any sort of guidance is appreciated!
Thank you in advance!
The best way is not to interfere with the protocol if you are not trying to modify one. Work on a higher (socket) layer. This API can be found in net/socket.c
This will help: (open in new browser tab/window to zoom)

Writing data to I/O address

i have a device (cash drawer) and i would like to directly communicate with the device. I know that its on address f1. Also openbit is 01.
As i've understood so far, i'd need to send 1 to memory address f1 and the cash drawer should open. Though using asm, i get access violation. Then again i've read that windows does not let you communicate directly to device i/o addresses (need to use win). What would be the correct way to send the data to that address.
Note that i cannot use drivers, because i can't communicate with the driver inside my application.
Op. system is win7.
Thanks in advance!
There was a library called inpout32.dll that allowed direct port access you can find it here
http://logix4u.net/Inpout32.dll_Discussion/write_DELPHI_for_inpout32.dll.html
But i don't know if supports windows 7.
In addition to the excellent suggestions above, check out this delphi code for writing and reading I/O. We have used the GWIOPM to do what you are asking, but note that it will be ok for 32-bit versions of Windows up to W7 etc (as is the case for most 'free' drivers). For 64-bit Windows you need a signed kernel driver. For this there are few things available at the moment. We had to write our own.
Why can't you communicate with the driver from your application? It's the best way for ring 3 application to talk with hardware in a safe manner.
However, if you really insist using drivers, you can try going to ring 0 and do direct access. It's much harder than in previous Windows versions (XP and before) but it's possible. I haven't done it myself since I don't have Windows 7, but you can try asking in asm programming forum anywhere.

Broadcast a UDP message in LAN with fake source IP with delphi

I want to broadcast a UDP message in my LAN with fake source IP ( spoofing )
1. Do winpcap able to do this ?
2. Do this work on winxp, win7 ?
3. i'm using delphi, is there any good components available ?
Thanks.
Yes, you can do this with winpcap. It should work on Windows 7 (though you may have to get a beta version of it). This is all I could find for doing it in delphi:
http://www.magsys.co.uk/delphi/magmonsock.asp
I don't know how well that works with the latest version of winpcap though. I'd seriously consider just doing it in C or C++.
Since your goal is to allow UDP broadcast in the VPN I suggest to take a look at VPN solutions that does not drop those packets such as Hamachi or Gamer's Internet Tunnel instead of creating your own solution.

Resources