I'm trying to come up with a way to sync a sqlite database between two computers.
If this were on a machine with a public IP this would not be difficult but I'm trying to find a way to make this work for ANY two devices, and most computers don't have a static IP.
What are some of the ways I can tackle this problem?
Assuming you just need to find the peers IP address...
Broadcast a Udp packet onto Lan, if machines are same lan segment. You can also try using admin scoped multicast, but mileage will vary according to the network setup and gear in use.
If trying to find two machines across the internet (assuming you can solve the NAT address translation issue), you need to bounce off a node that will hold info for you. Eg write a packet to dweet.io or sparkfun or other website that will hold store and forward data. You can also read twitter feeds etc, basically you need a known reference point to both talk too. Look into how malware create command and control networks for some ideas. Or search for rendezvous servers and protocols.
If the address range is small, probe all possible addresses. But be careful as you might trigger anti virus or ISP action
If wanting more browser based, look at webrtc, not quite what you are after but some of the techniques for discovery might be interesting.
If you have access, you can play with your DNS records. Essentially this is a variation of (2).
There are more options too, but that get more special purpose or become a bit too stelthy for general use. Also see how mesh networks are formed.
Related
I am using libcurl with pthreads to do some POST requests to a single website. This website may change over time. I want this program to be as fast as possible. So one thing came to my mind was to first find the website IP address, then pass this IP instead of the website URLs to threads.
At first, do you think this is a good thing to do? As it removes the DNS lookup time in each connection (thread).
And how can I do this in libcurl? Is there any function to just find the IP of a hostname? Or is there any other simple way to do this in C language?
This is the problem that the DNS query system in your OS is supposed to solve.
The performance improvement you want by not doing an additional lookup is countered by the fact that the IP can change over time. Any queries should be cached presumably respecting some record timeout rules set by the DNS entry. Windows and OS X cache requests automatically out of the box as far as I can tell. On my debian box I found I had to enable the systemd-resolved service for this feature. Not knowing your needs, is probably the most sane general solution to what you're describing.
Doing this with getaddrinfo() and caching it yourself for some period of time within the bounds of your program (even to disk) is a valid solution if you want absolute control and don't want to hardcode it somewhere (in the app or something like the hosts file).
TL;DR available at the bottom
I've been trying to figure out a way to get two laptops (both running Ubuntu) to be able to pass basic messages back and forth without the need for them to be connected via a wireless network,either by an AP or ad-hoc. I want to reiterate here that ad-hoc networking is not what I'm looking for, I've seen many similar questions here with that as the answer.
I guess what I'm asking is: how do I achieve this? All I really need is for one computer to be able to send a packet, and then for another to pick it up via a packet sniffer of some kind.
Currently: I have both laptops in monitor mode (via a mon0 interface created from aircrack-ng's airmon-ng)so that they can sniff nearby traffic (with Wireshark, tcpdump,tcpcump.org's sample libpcap code, and opening a raw socket and just printing out all the packets. I tried each just because I thought one could be doing something differently/leaving something out). I also have a very basic program that consists of opening a raw socket to send crafted ethernet frames out to the air, but I can't get my two machines to see the other's packets. The sniffer running on each machine can only see the packets going out of that machine (in addition to nearby beacons/control traffic from wifi in the area).
Some things to note that might be important are:
-the packets I'm sending out appear in Wireshark (only on the sending machine) as malformed 802.11 packets (probably because I'm just filling them with junk data for now). I was under the impression that my other laptop would also see them as malformed packets, but it gets nothing
-the sockets I'm using are from a call to socket(PF_PACKET,SOCK_RAW,ETH_P_ALL). Raw sockets are something I just recently was aware of, so I could be misunderstanding how they work, but my impression is that I can craft a layer 2 packet by hand and ship out straight out to the wire/air.
If you're curious as to why I want to do something like this, it's part curiosity, part research for a project I'm working on. I want to streamline / automate the process of setting up an ad-hoc network, and what I'm trying to do here is for the laptops to do a small exchange to figure out the specifics of the adhoc network they are about to create and then make/join that network automatically, instead of either one person explicitly setting up the network OR having both people pre-decide the name, etc of the network and have both computers constantly trying to connect to that specific one.
I'm more interested if I'm going about this process in the right way rather than if my code works or not, if someone thinks me posting my (very basic, taken from another post on Stack Overflow) raw socket code will help, I can.
Edit: I am more than happy to post a complete set of code with instructions if I can get this working. I couldn't find much helpful info on this topic on the internet, and I'd love to put it up for future people trying to do the same thing.
TL;DR I want to send out a packet from one laptop and pick it up on another via a packent sniffer of some sort. No wifi network or ad-hoc network involved. Something akin to spoofing an AP's beacon frame (or similar) for the purpose of sending small amounts of data.
Edit 2:After some thought, perhaps what I'm looking for is some kind of raw 802.11 use? Having direct control of the wifi radio? Is such a thing possible?
I found out I was able to send packets out through my monitor mode interface as long as I had correct 802.11 with radiotap headers. I think the problem I was originally experiencing (not being able to sniff the packets) was because they were malformed and thus not actually getting sent out.
I was able to accomplish this by adapting the example code found here, courtesy of someone named Evan Jones, except I did not need to use an Atheros based card or Madwifi drivers, everything worked fine with the mon0 interface created with aircrack-ng.
I am certain that Apple Mac do this. Apple call it 'bonjour'. There may well be a proper IETF spec for it. This is an Article on Bonjour this is Wikipedia on an open component of bonjour which might help get you moving.
I'm using libpcap (and winpcap on Windows) in a C application to monitor network traffic. I need to differentiate between upload and download traffic on each network adapter, to produce connection speed stats, but the filter expressions used by the library don't seem to support this very easily (ie there are no 'incoming'/'outgoing' operators).
One approach that I have considered is to query the IP address of each adapter, and then use filters such as src host 1.2.3.4 (to measure uploads) and dst host 1.2.3.4 (to measure downloads).
My questions are:
Is there a better/simpler approach than the one above (something that would let me use the same filter expression for each adapter would be nice)?
If the above approach is the way to go, then is there any chance that a single adapter could have more than 1 IP address associated with it? The reason I ask is that the pcap_addr struct which holds the address details of a single adapter (in struct pcap_if) has a 'next' member suggesting that this is possible.
Firstly, remember, pcap sees only packets. It doesn't see "outgoing" or "incoming" - simply packets. So yes, you must filter using the src/dst in the ip headers. There is no other way to tell whether the packet is incoming or outgoing.
Secondly, yes, there is nothing stopping an adapter having multiple IP addresses. So you need to grab the IP addresses configured from that adapter. pcap_findalldevs() (WinPCap Documentation) ought to help you here, from which you should be able to deduce which devices you want to monitor.
Have you considered looking at pmacct - I have personally contributed to this in time past. This is a C tool that uses libpcap to passively monitor network traffic for accounting purposes.
Try tcpdump
I would like to create a wireless network from a laptop. If laptops come within range, I would like it to send them a welcome message and send them a goodbye message when they leave the wifi range. Is it possible to do this in C?
Please help me out with this.
It is possible, but it is a very complex task and I don't think that programming language choice is the first thing to look into.
As a start, you can read up on Wikipedia on Wireless ad-hoc networks.
How should your messages be received and displayed on the remote side? If you want to use some existing protocol over TCP/IP, or create your own (deploying custom applications on the remote machines), you will need to mess with networks and this is not always possible as one machine can be a part of only one network. So the machines need to be not connected to anything and somehow allow you to connect to them, it involves changing network settings on all that machines (for example, setting them to join the ad-hoc network with predefined name).
If all machines automatically join the existing network, this question has nothing to do with wireless (physical layer) but with Avahi, Netbios or whatever other services allowing you to get notifications and/or enumerate devices in the network.
Let's suppose you deploy a network-attached appliances (small form factor PCs) in the field. You want to allow these to call home after being powered on, then be identified and activated by end users.
Our current plan involves the user entering the MAC address into an activation page on our web site. Later our software (running on the box) will read the address from the interface and transmit this in a "call home" packet. If it matches, the server response with customer information and the box is activated.
We like this approach because it's easy to access, and usually printed on external labels (FCC requirement?).
Any problems to watch out for? (The hardware in use is small form factor so all NICs, etc are embedded and would be very hard to change. Customers don't normally have direct acccess to the OS in any way).
I know Microsoft does some crazy fuzzy-hashing function for Windows activation using PCI device IDs, memory size, etc. But that seems overkill for our needs.
--
#Neall Basically, calling into our server, for purposes of this discussion you could call us the manufacturer.
Neall is correct, we're just using the address as a constant. We will read it and transmit it within another packet (let's say HTTP POST), not depending on getting it somehow from Ethernet frames.
I don't think that the well-known spoofability of MAC addresses is an issue in this case. I think tweakt is just wanting to use them for initial identification. The device can read its own MAC address, and the installer can (as long as it's printed on a label) read the same number and know, "OK - this is the box that I put at location A."
tweakt - would these boxes be calling into the manufacturer's server, or the server of the company/person using them (or are those the same thing in this case)?
I don't think there's anything magic about what you're doing here - couldn't what you're doing be described as:
"At production we burn a unique number into each of our devices which is both readable by the end user (it's on the label) and accessible to the internal processor. Our users have to enter this number into our website along with their credit-card details, and the box subsequently contacts to the website for permission to operate"
"Coincidentally we also use this number as the MAC address for network packets as we have to uniquely assign that during production anyway, so it saved us duplicating this bit of work"
I would say the two obvious hazards are:
People hack around with your device and change this address to one which someone else has already activated. Whether this is likely to happen depends on some relationship between how hard it is and how expensive whatever they get to steal is. You might want to think about how easily they can take a firmware upgrade file and get the code out of it.
Someone uses a combination of firewall/router rules and a bit of custom software to generate a server which replicates the operation of your 'auth server' and grants permission to the device to proceed. You could make this harder with some combination of hashing/PKE as part of the protocol.
As ever, some tedious, expensive one-off hack is largely irrelevant, what you don't want is a class-break which can be distributed over the internet to every thieving dweep.
The MAC address is as unique as a serial number printed on a manual/sticker.
Microsoft does hashing to prevent MAC address spoofing, and to allow a bit more privacy.
With the only MAC approach, you can easily match a device to a customer by only being in the same subnet. The hash prevents that, by being opaque to what criteria are used and no way to reverse engineer individual parts.
(see password hashing)
From a security perspective, I know that it is possible to spoof a MAC, though I am not entirely sure how difficult it is or what it entails.
Otherwise, if the customers don't have easy access to the hardware or the OS, you should be fairly safe doing this... probably best to put a warning sticker on saying that messing with anything will disrupt communication to the server.