In bits/socket.h of Linux systems, the address families macros are defined in terms of protocol families macros. there is a one-to-one correspondence among them with the form of
#define AF_something PF_something
Since the one-to-to mapping between the AF macros and the PF macros, they seem like unnecessary duplications.
My question is: is there a reason for this?
The original idea was to have address and protocol families independent. An address can potentially be used in various protocols. Authors expected that for example IPv4 address can be used by another hypothetical protocol different than IP. And vice versa - independent families are prepared to use a new kind of addresses in IP protocol.
So the only reason is that author of the socket API wanted to be future proof. As far as I know there is still one to one mapping between PF and AF.
It is a good habit to follow the original idea. That means have independent constant and use PF constants when working with protocol for example creating socket: s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) and use AF constant when working with addresses for example sa.sin_family = AF_INET.
Related
From RFC 1035:
Authoritative Answer - this bit is valid in responses,
and specifies that the responding name server is an
authority for the domain name in question section.
So, what happens if this bit is set in a DNS query (QD=0)? Do most DNS implementations treat the packet as invalid, or would the bit simply be ignored?
The same question applies to other bits that are specific to either queries or responses, such as setting the RD bit in a response.
My guess is that these bits are simply ignored if they aren't applicable to the packet in question, but I don't know for sure or how I would find out.
I'm asking because I'm writing my own DNS packet handler and want to know whether such packets should still be parsed or treated as invalid.
You either apply the Postel's law ("Be conservative in what you do, be liberal in what you accept from others") - which is often touted as one reason/condition of the success of interoperability of so many different things on top of the Internet - or if you strictly apply the RFC you deem it as invalid and you can reply immediately with FORMERR for example.
In the second case, as you will get deviating clients (not necessarily for your specific case, in the DNS world they are a lot of non conforming implementations on various points), you will need to define if you create specific rules (like ACLs) to accept some of them nevertheless because you deem them to be "important".
Note that at this stage your question is not really programming related (no code) so kind of offtopic here. But the answer also depends what kind of "packet handler" you are building. If it is for some kind of IDS/monitoring/etc. you need to parse "as much as possible" of the DNS traffic to report it. If it is to mimick a real world DNS resolver and just make sure it behaves like a resolver then you probably do not need to deal with every strange deviating case.
Also remember that all of this can be changed in transit, so if you receive some erroneous things it is not obviously always an error coming from the sender, it could be because of some intermediary, willingly or not.
To finish, it is impossible to predict everything you will get and in any wide enough experiment you will be surprised by the amount of traffic you can not undersand how it comes to exist. So instead of trying to define everything before starting you should instead iterate over versions, having a clear view of your target (parsing as much as possible for some kind of monitoring system OR being as lean/simple/secure/close to real world features for DNS resolution as possible).
And as for "how I would find out." you can study the source of various existing resolvers (bind, nsd, unbound, etc.) and see how they react. Or just launch them and throw at them some erroneous packets like you envision and see their reply. Some cases probably exist as unit/regression test and some tools like ZoneMaster could probably be extended (if not doing those specific tests already) to cover your cases.
I'm getting familiar with DHT and I mostly understand how it works. However, I don't quite understand what happens if you want to have separate DHTs with different entry types in each. Is this possible?
If I use a popular DHT library, does that mean I put and get entries using the same DHT as every user of said library? Or is DHT universal for everyone? How do you define an owner of a DHT, or how do you define a separate, contained DHT?
Yes, you can make separate DHTs. However you need to make the 'on the wire' protocols slightly diffrent so they can't speak to each other and get mixed up.
You can actually have unlimited numbers of DHTs using the same protocol as long as peers don't know each other.
This is the important part when you set up a network. You have to know a second peer to intitially create the network. The next peer would have to know one of the two initial nodes, the next one needs knowledge of one of the three above and so forth.
You are also able to be connected to multiple DHTs on the same host without the two interferring (at least in terms of data exchange, not in terms of local ressources). And you are also able to joins those two DHTs by telling one of them about the peers you are connected to in the other DHT. Though that might be not as easy as it sounds.
Can someone tell me about the difference between GY and RO interfaces used by diameter protocol ???
As per my understanding both of this interfaces looks pretty similar and the AVP's used too.
But still i understand that there is a difference..
Ro is a 3GPP reference point that describes the connection to the OCS from another functional component. It is a general term that covers multiple connecting components such as GGSN, P-GW, WLAN, IMS AS, MBMS server, etc.
Gy is an specific instance of the Ro reference point that connects a charging component from the packet-switched domain (PS domain) i.e. PCEF within a GGSN or P-GW to the OCS
For more details
There are different 3GPP specification for each of the interfaces.
You can read the differences and see the specifications here:
http://www.ietf.org/mail-archive/web/dime/current/msg05723.html
Is it possible to search for all iBeacons which are nearby? I know it's possible to search iBeacons by UUID. But i want to find all iBeacons nearby.
An iBeacon is a region, and has as defining property the UUID. Therefore, you can only search for the ones matching a UUID.
After you find one or more with a specific UUID, you can figure out which is closest using the delegate callbacks, where the beacons are stored in an array ordered by distance.
There is great sample code on this and also a pretty detailed WWDC video session: "What's new in Core Location"
iBeacons are higher-level constructs than regular BLE peripherals. From what can be determined from the Apple docs, beacons are tied to their service UUID. i.e., a family of beacons is a "region" and a you go into and out of a region based on the range and visibility of a beacon to YOU, not the other way around. Unfortunately Apple has used the term region, which most of us probably associate with MapKit, so this is adding to the general confusion
Here's the bad news: You can only scan for ProximityUUIDs that you know, there is no "wildcard" proximityUUID. Additionally, CLBeacons don't expose the much in the way of lower level CoreBluetooth guts so if you want to find all beacons that happen to be near you, you'll have to use CoreBluetooth, scan for peripherals, then look though the returned peripheries and query each one them to find beacons. Of course Apple has neither registered (with the Bluetooth SIG) or (yet) published the iBeacon characteristics so, you'll need a BT sniffer to reverse engineer what constitutes an iBeacon from any other BLE device.
each APP would use it's own specific UUID, using the "major" and "minor" integer values to differentiate between beacons.
for example, the UUID would be associated with a chain of shops, major would identify the shop, and minor the aisle, or even a group of products.
scanning for unknown UUID's would not be very useful, as your app would not know what to do with the information.
the UUID is generated once and for all, using the "uuidgen" command in the terminal.
sadly there is no protocol to actually communicate with beacons, hence there is no standard to get the location of a beacon, or any other useful info.
it would have been so much better if we could open a connection to a beacon, usually the closest one, and obtain additional data from it, without having to be on the same WIFI network.
you either have to use bonjour to communicate with the device over WIFI, or use the major and minor id to obtain data from a webservice of some kind.
Unfortunately you cannot at this time search for an arbitrary iBeacon without first knowing the proximityUUID value. I've tried writing directly to COREBluetooth and, although you can discover and connect to transmitting beacons in your area, what you get back is jibberish with no relation to the BLE UUID. So you can't even confirm that the peripheral you have connected to is in fact an iBeacon.
This does not appear to be a limitation of the BLE spec, rather it is a limitation that has been imposed by Apple. It also appears that this limitation does not exist for the Android platform.
Until this gap is closed, Android will have a significant advantage over iOS in this area.
I disagree with previous comments that scanning for UUIDs would be useless. On the contrary, if you knew the beacon UUID, you could create a map of beacon/location/subject in the cloud and use it to navigate (assuming the beacon was fixed) using a web service. You could crowd-source the data so that eventually a very rich database of beacon UUID/location pairs would be available to all who wanted to write location apps. Perhaps this is why Apple is hiding the info; they may be holding this back for their own purposes.
According to Radius Networks (authors of the AltBeacon spec and the android-beacon-library it's not possible to identify a beacon using CoreBluetooth
I'm working with a madwifi ath5k driver. basically what i'm trying to do is to change some things in the behavior of the MAC protocol in order to implement network coding.
in some parts of my project i need to add some field to the headers of the 802.11 MAC protocol, and my questions are:
is it possible to add fields in the middle of the frame headers, and extend the total frame length? i've tried to add 20 bytes after the sequence number field, but it cause some problems (pinging stop working).
if it's possible, which data structures should be changes and how?
thanks!
Omer!
You can't modify or add to 802.11 MAC headers, each field there has a specific size and location. If you change that, you're breaking the protocol. This doesn't mean it's wrong, it just means you're implementing a different protocol. In order to work it has to be implemented by all the parties participating in the communication (including mediators, such as APs). If you want to be 802.11-compliant, you need to add any proprietary information inside frame body, not inside the header. It's usually done via proprietary Information Elements that are parsed by the corresponding protocol extensions, such as CCX.