which IP Helper API interface to use? - c

•Managing Network Adapters Using GetAdaptersInfo
•Managing Interfaces Using GetInterfaceInfo
•Managing IP Addresses Using GetIpAddrTable
These are the three methods listed on the msdn IP Helper API. Why would I prefer one method over another?

They are mainly resulted from terminology differences, see http://msdn.microsoft.com/en-us/library/aa365798%28v=vs.85%29.aspx for the explanation regarding "adapter" and "interface". In short, an adapter is a data-link level abstraction while an interface being IP-level abstraction.
It will depend on the situation that you want to solve to determine what API to use. For example, link speed or tunnel type can only be acquired from adapters.

Related

What's the relationship between AT commands and device vendor's C API?

I'm doing an embedded-system project now. From my view, AT commands can be sent to a device to retrieve 4G information, dial and so on. On the other hand, we can also do that by calling APIs provided by the 4G vendor.
My question is what's the relationship between them? Is the API a wrapper for the AT commands?
TL;DR
Vendor's API (not only C, but also C++, Java or Python depending to the vendor and the modem model) can both be wrappers for AT commands and a wider, more powerful set of API were the user can port complex applications.
It depends on the vendor and on the model.
A jungle of modems produced by different vendors
It is impossible to define a general "rule" about API provided by a Cellular Module (not necessarily a 4G module).
First of all every vendor usually implements standard AT Commands (both Hayes commands and extended standard commands for cellular devices). In the same way every vendor has it's own implementation of the user application area where the customers can store their own application to control the modem's functionalities and to use them according to their own application requirements.
AT commands remain the interface to be used when the modem needs to be connected (and driven) by an external host. When the user application area is used, instead, a wider set of API is usually provided. They may include:
A library exporting a subset of the OS capabilities (threads management, events, semaphores, mutexes, SW timers, FS access and so on)
A library offering the capability to manage the specific HW of the device (GPIOs, SPI, I2C, ADC, DAC and so on)
A library offering a programmatical way to perform action, related to connectivity, that would normally be executed through AT commands (registration status check, PIN code insertion, PDP context activation, SMS management, TCP/UDP/TLS sockets)
The latter usually access a base layer involving all the functionalities provided by the modem. Usually this is the same layer invoked by the AT commands sent through modem's serial interface.
Sending AT commands... from the vendor's API?
Of course it often happens that the library mentioned above provides just a subset of the functionalities usually exported with the AT commands set so, in order to "fill the gap", a further set of APIs is usually exported as well:
A set of functions that allow the simulation of AT commands sent to the modem's serial port. Sending them and parsering the responses they send in the vitual internal serial/USB interface allow the user to port in the internal user application area the the application they previously run on an external host processor (with obvious BOM benefits).
As an example, please check Telit Appzone here and here. It was the inspiration of my answer because I know it very well.
I don't know why you name the title that there's a relationship between AT command and Linux-C API.
Regarding AT command, you can take a look at this wiki article for general information.
Each module has a specified AT command sets. Normally, the module manufacture just offers AT command set and what return values are.
Is API a wrapper of AT command?
If you can use the API provided by the manufacturer, then yes, it's a wrapper of the AT command handler.
My question is what's the relationship between them? Is the API a wrapper for the AT commands?
It is impossible to be sure without having any details of the device, but probably any C API for it wraps the AT command set, either by communicating with the device directly over an internal serial interface or by going through a device driver that uses AT commands to communicate with it.
However, it is at least conceivable, albeit unlikely, that the 4G device offers an alternative control path that the C API uses (definitely via a driver in this case).
I'm not quite sure what the point of the question is, though. If you are programming the device and its 4G component in C, and the manufacturer has provided a C API, then use it! If you are programming in some other language then at least consider using the C API, which you should be able to access from most other languages in some language-specific way. You should not expend effort on rolling your own without a compelling reason to reject the API already provided to you.

Binding getaddrinfo to particular interface (source IP)

I use getaddrinfo() to get IP Address corresponding to a server using a URL. It essentially sends DNS query to the DNS server. I want to be able to send that query from a particular outbound interface. Basically I have multiple interfaces through which DNS query could be sent out. Currently, getaddrinfo() doesn't have a way to dictate which interface it should use to send out the DNS query. Is the only option to change getaddrinfo() routine? Does anyone know of any other way to achieve this?
The fundamental issue with the question is that you seem to expect getaddrinfo to work with DNS only, and then to be able to fine-tune the specifics of that DNS lookup. However, that is not what it does - it will use all name-resolving facilities on the system, which typically means it will do a hosts file lookup, and whatever else is configured in nsswitch.conf, which is usually DNS. For some of these non-DNS lookups, a source address binding may not make any sense, so it's not part of the least-common-denominator interface.
If you know that for your specific purpose you will never need the response of a name lookup from anywhere other than DNS, then you can use a DNS-specific function instead, one that will enable you to do this kind of fine-tuning.
There are several examples of DNS C libraries listed at gethostbyname dual network interfaces, select which one to use
The interface chosen to access a given IP address is dictated by the routing tables.
Since you presumably have the IP of the DNS server, it will be accessed by whatever interface the routing table says to use for that IP address, regardless of which application sends the request.
You would need to modify the routing table to force traffic over a particular interface. If it's only the DNS server that should use a fixed interface, you would add a route for that specific IP to the routing table for the interface you want.
On Linux, you can modify the routing table via the ip route command line tool.
rfc 3484 details an algorithm of which source addr (i.e. interface) to use when none is specified, but this works I think only for ipv6...
see /etc/gai.conf

Resolve remote host names into ip addresses in codename one

I'm interested in the ip address of remote hosts. Is there an easy way to resolve a host name into its ip address?
After searching in the codename one source code and reading through the documentation, the only way to achieve this seems by implement android/ios native features (e.g. using the InetAddress class).
Yes you would need to implement this using native code or thru the Socket API by implementing the DNS protocol calls.
The InetAddress class can be used in the Android/Desktop ports but other platforms (e.g. iOS) would need the Objective-C/C equivalent of that.

Pass the frame from the Link layer to the Physical Layer

I'm trying to create a simple Link layer protocol for school.
I've been searching and googling and I understand that Link layer has pas the frame I create to the Physical layer, but how to do in Programming (language c)
is there a function or library that I can use to send my frame directly using Physical layer ? or how should it be done ?
The most common design patterns to develop communication protocols are the Protocol Stack Design Pattern and the Protocol Layer Design Pattern. Take a look at it. The links have some example code.
In summary it works as following:
Communication Upper Layer to Lower Layer: use function parameters
Communication Lower Layer to Upper Layer: use callback functions
Designing protocols is not trivial and you should keep it simple in the first approaches.
you need to use a sockets code ,A socket is one end-point of a two-way communication link between two programs running on the network link. Socket classes are used to represent the connection between a client program and a server program. you do not need to program the physical layer, the OS care with .
http://www.tutorialspoint.com/java/java_networking.htm

emulating a network interface

Can someone possibly explain (within the size of a stackoverflow answer) the code required in order to emulate a network interface? I just know that there is virtualization software out there like Qemu that does this specific type of hardware emulation, but have no idea how this would work. Lots of books will show you how to create a program that listens on a TCP socket, but not create a host that gets its own IP address.
VirtualBox is open source. As a VM, with networking support, it should be sufficient to demonstrate to you what to do, along with a working implementation. https://www.virtualbox.org/wiki/Downloads
It's really depends what do you mean and what do you want to achieve. If you want emulate some real hardware you need via hypervisor's primitive emulate the most aspects mentioned in datasheet of corresponding adapter, if you want introduce some service, e.g. DNS or HTTP service visible in internal network: you need port teach some user land stack (e.g. LWIP or Slirp, or part if you need UDP only or lower) to communicate with hypervisor's internal network.

Resources