I want to send/receive out some data from a raspberry pi using the WLAN protocol IEEE-802.11n. I tried searching a lot but could not find any library in any language which can send/receive data sent through the ieee 802.11n protocol. My receiver is also a raspberry pi.
Basically, the sender is connected to some devices and is supposed to send out some data which is to be sent through the wifi (ieee.802.11n) to another raspberry pi. And to add to my problems how is the data sent from the sender is not known. All I know is that it is sent through the ieee.802.11n protocol.(There is a wifi dongle attached to the senders raspberry pi.)
So if someone could point me to a library or any solution as to how to read that data sent through this protocol.
You need to research this more so that you can ask more specific questions. I doubt any answer is worth an upvote except for the effort put in.
I'll give it a try, and hope this "puts you" in the right direction.
If you manage to setup the RPi-sender as an access point and manage to connect the RPi-receiver to that network, you are well on your way. Since beacons and probe request will start being sent automagically from the sender to the receiver. From there you can start injecting, injecting or in some other way sending packets from sender to receiver. Easiest first step is of course pinging (this can go either way. sender->receiver and vice versa)
If you manage to setup an ad-hoc network, then there is no real "sender" and/or "receiver", but injecting/sending packets work the same way.
Here is a similar question on SO.
Also mentioning libraries
Related
I am working on edge computing for IoT applications and expected to create a system that acts as a near edge computer with the use of a raspberry pi hooked up to a dht11 sensor. How do I send this data over to a computer that is at the edge? Ideally I want to use my PC as this device but I have no clue how to send this data over in real time.
So far I have created the circuit and can view the temperature and humidity readings on the raspberry pi in python. Unsure of what the next steps are - I don't want to send this data over to the cloud just yet.
Side note: I believe i may be missing knowledge regarding this but is the raspberry pi an edge device because it is hooked up to the sensor directly?
Any help is greatly appreciated.
You need to think this through a bit more. What will you do with the temperature and humidity data that you receive?
For example, if you're just experimenting and want to just see the readings in a console on your PC, you can use netcat to send the console output of your Python program from the RPi to PC. No SW development needed, they just have to be in the same network. Not particularly useful for anything else, either.
Otherwise you need to set up some client-server solution between the RPi and your PC. There's a ton of possible solutions, all depending on what you plan to do with the data. You can use MQTT, HTTP, a straight database connection (MySQL, PostgreSQL), etc. You have to supply both sides of the connection. The Python code on client side which connects and sends data; and the server side thing that accepts the samples and stores them somewhere. Plus all the networking, authentication etc.
Or you can just download the Python client libraries for your favourite cloud solution and set that up according to a tutorial. TBH, this sounds a lot less work to me.
I'm interested in writing an app that send messages over IP (using 3g, not neccesarily on the same WiFi network as the receiving end) to a PIC microcontroller connected to a router (via ethernet or wifi)
I saw some descriptions and examples on how to send messages on the same network, not sure if just by giving a different IP it would work outside the network it self. I was wondering how can it be received by the PIC (still hasn't decided which PIC, depends on the possibility to perform this)
and in turn, depends on the msg received, the PIC will perform an action, for example, light a certain LED in a LED array.
I have the sending side (the app sending over IP), and receiveing side (the PIC which lights the LEDs)
I'm just not quite sure what to send, or if such "translation" is even possible.
I've searched the web but couldn't find any such thing except for made kit (for RC cars for example)
Thanks.
Carmel
Here's a UDP library I built for Mac/iOS wrapped in simple Cocoa that sends UDP packets to an IP address of your choice. Comes with sample server client app.
This is generic UDP packets so you just have to listen for them on the other end ( whatever that platform is ) and read the content. Let me know if you need help with that
https://github.com/Shein/Mac-UDP-Client-Server
Well, if the PIC can run a TCPserver, or maybe just UDP, then sure you can control a LED by sending an appropriate message. With an appropriate static IP address and routing, then you can use your iPhone to turn on the LED from anywhere you can get a connection.
PICs are not exactly renowned for having high performance and lots of RAM. If you do manage to get a server working, try to not use XML/SOAP
This looks more like a question for http://electronics.stackexchange.com.
If your familiar with SPI you could consider Microchip's MRF24WB0MA/RM module which
enables PIC to connect to a wireless network (either to an infrastructure wireless or
to AdHoc, or it can create its own AdHoc).
If you're using MCC compiler then you also have library available for this module
at Microchip Application Libraries.
TCP stack takes some memory space though. PIC18F would do but you'd be better of with PIC24F (they tend to be cheaper than 18F anyway).
I want to connect multiple devices through socket without any server implementation.I will use that only for getting the IP addresses of the devices that will register.
There are two major problems to peer-to-peer communications: discovery, and reachability.
First, you need to know the IP address of the other peers to connect to them. Once you're connected to a mesh of peers, they can all keep each other updated on the state of the network, suggesting better peers to each other, passing around notifications of new peers who've joined and left, etc. But you have to design and implement a mechanism for trading that information. More importantly, you need to jumpstart things in some way, because when a new peer starts up, it's in a mesh of just itself, and it has no information to give itself.
One possibility is to have a handful of well-known "superpeers" (that you run) that are always connected, and bake their addresses into the app. Or you can have "introduction servers" instead of peers, serving much the same function. Or you can have some external way of trading addresses (the simplest is that users trade them on a web forum or an IRC channel or in person and type them in manually), which can be automated to various degrees. There are also shortcuts that can help—Bonjour can get other peers onto the mesh as long as one peer on the LAN is already there; GameCenter/GameKit can be used as an automated external trading network; etc.
Once you've solved the discovery problem, you still have the reachability problem. Most iOS devices usually don't have publicly-accessible IP addresses; instead, they're behind routers that do Network Address Translation, whether they be a home WiFi router or a cell carrier's 3G network. This means you need some way to do NAT Hole Punching to get two iPhones talking to each other. Somebody who knows both the public address and the internal address of each device can arrange for them to set up a connection to each other. You can have either normal peers do this (although that makes the jumpstart problem even bigger) or have your superpeers/introduction servers/etc. do it.
If you want to build all of this yourself, you probably want to look at other implementations. BitTorrent (including trackers and DHT) is well-understood and documented at a continuum of levels ranging from "lies-to-children" for curious end users to detailed protocol specs and open source implementations. And then look at some other P2P networks, because BitTorrent is not perfect, and doesn't try to do everything that everyone's come up with.
You can use GameKit. It has the matchmaking api that can help you.
It can be used for non game apps.
I've been working on something similar and it's a giant pain in the ass. There are 3 considerations: 1) Reachability 2) Discovery 3) The connection itself.
1) Don't even consider using 3g/4g, it just won't work well for keeping an open socket connection.
2) I'd use some sort of broker service between the two on the internet to connect the two. For discovery, you can just list what devices are available on the service.
3) For the connection, I find the IOS socket libraries to be rather painful to use, but if you go down to the BSD socket level it's not as bad. I think it'd be very interesting to use zmq sockets; that might simplify writing the broker service.
You can't. If the device is all online with wifi, it maybe possible and rely on the router setting just like pc connect. If some device is connected with 3g or gprs protocal , they may have no ip address at all.
I am implementing an iPhone/iPad app that allows users to send each other messages using the bonjour protocol. Basically, a server publishes his service over bonjour and the clients connected to the same wifi can discover his service and connect to it to start sending messages. The problem I've found is that some routers seem to have problems with Bonjour. When running my app at home or at some other places it works perfectly. The publishing and discovering of the bonjour services works flawlessly. However when I tried my app at one of my friend's apartments, some (not all) of the clients were not able to discover the published bonjour service. I also noticed that other apps that use Bonjour (such as Apple's Remote app) were also having trouble on said network. After doing some digging I've found that other people have had similar problems with bonjour and some routers. Therefore I have 2 questions:
1) Does anyone know if this problem with Bonjour that some routers seem to have is a widespread issue? In other words, if my app relies on Bonjour in order to function at all, do I have to be worried that it won't work in 50% of the WLAN networks or do most routers not have any issues with bonjour. Obviously I can't expect anyone to know how every router out there deals with bonjour packets but maybe there are some Networking gurus that can point me in the right direction :-p.
2) Second, if bonjour is too risky of a protocol to build my app on, what are some alternatives with similar features? The features I would (preferably) need would be service publishing and discovery without users having to manually enter IP addresses of other phones.
Ok thanks for your help! I understand that this is kind of a broad question but any help is appreciated! :)
This is potentially a tough nut to crack. The problem causing devices not to find each other on certain networks is related to the underlying transport (i.e. multicast UDP) and not Bonjour (or mDNS or whatever else you wanna call it).
In high-level, non-rigorous terms, multicast data puts more load on routers. Large corporate and university networks sometimes like to drop Bonjour messages (i.e. UDP packets sent to the multicast group 224.0.0.251 on port 5353) because it means the network isn't inundated with thousands of clients advertising their iTunes libraries or whatever, and at scale this can improve general performance. At the other end of the spectrum, some domestic routers drop multicast packets out of the box for reasons known only to the manufacturer. There's not a whole lot you can do about either situation.
Try running a tcpdump on the network to see if the packets are actually coming through. I've not come across a home router that doesn't forward them for a while. If they're not, you'll have to come up with some central [internet-facing, perhaps?] lookup facility. If they're visible, then there's something up with your implementation.
There's nothing stopping you from writing your own simpler protocol for service discovery to be sent over multicast- it's just that there are loads of Bonjour clients in a ton of different languages already written and tested.
I would like to send a messages to all iphones or blackberries or androids that are using my local wifi. Whether it be a bbm or a flash sms etc.... I am even willing to pay for texting etc....
Can I do so without knowing their number? Can I determine their number from their information (ie: mac address and or phone id) being sent a request for phone information?
I appreciate any help. I have a feeling like it is not possible for many reasons, but I am curious....
Overall there is a way to do it, it's called "broadcasting" (or UDP broadcasting). Your wi-fi AP should support and allow it. You also must make sure Android, iOS and BB support this (but there is no reason why they shouldn't).
It looks something like this:
Install your custom app on all devices.
When device is connected to specific wi-fi access point, you send broadcast message "device X is connected, my address is XA, send messages to port XP" every several minutes. You also start listening for such notifications from other device.
If another device is connected, it will send "device Y is connected, my address is YA, send messasges to port YP". Device X will receive message from device Y, and device Y will receive message from device X.
When third device is connected, it sends "device Z is connected, my address ZA, send messsages to port ZP". This Z device will eventually receive messages from X and Y, while X and Y will become aware of Z device as well.
You'll probably need to implement simple TCP protocol in order to actually send messages from one device to another.
To summarize, you'll need to make discovery via UDP and communication via TCP. Those would be two different custom protocols. And it shouldn't be hard to implement. But you'll need to implement this for all mobile platforms you are interested in.
No, it's not possible (not for the Blackberry at least unless you're the NSA, since the BBMs are encrypted and operate on RIMs internal proprietary network before they even get out to any other carriers).
For the iPhone and the non-military Android phones, you'd just need to purchase your own private cell phone repeater/tower. That at least is feasible (although quite unpractical and highly risky), one guy did it successfully at a security conference with every participant's signed consent and with an independent auditor present, but he was lucky he didn't get himself arrested.
You see, by saying that you want to send an SMS, you're automatically implying that you wish to use the SMS infrastructure (which by definition doesn't even operate on wifi, it operates on the cell phone infrastructure).
That being said, if you control the wifi hot spot, you could do something else that might get you 60% of the way there. You could force everyone who utilizes your hot spot to go through an initial web page, and through that, you could communicate to them (although, please be aware, this is highly annoying to the user, at least it is to me especially on a phone).