I am running Django on my raspberry-pi, and I am using avahi-daemon to access my rpi on raspberrypi.local . On my Django I have made APIs for my android application to access via HTTP protocol. For example one of my http request url is: http://raspberrypi.local/api/getUserNames/
The problem is that android is not accessing this url on my local wifi network, i have confirmed that my android device and rpi are both connected to same wifi network, but still the http://raspberrypi.local is not working on android. While it works fine on my PC & MAC.
I tried to find the solution and went through many Q&A explaining about bonjour, mDNS, jmDNS, android-multicast. But all are either too confusing to implement or doesn't work. Please help me, I'm stuck for a while.
NOTE: on my Rpi the avahi-daemon is broadcasting itself as "_workstation._tcp." service-type
--
My Solution:
http://www.dodgycoder.net/2015/02/setting-up-bonjourzeroconfmdnsnsd.html
Android NSD (Network Service Discovery) solved my problem. I used only Discovery Listener and Resolve Listener to solve my purpose.
I specifically used SERVICE_TYPE = "_workstation._tcp."; in order to search for raspberrypi.local with avahi-daemon
Android NSD (Network Service Discovery) solved my problem. I used only Discovery Listener and Resolve Listener to solve my purpose.
NOTE- You'll have to use SERVICE_TYPE = "_workstation._tcp."; in order to search for raspberrypi.local with avahi-daemon
here's link to the solution - http://www.dodgycoder.net/2015/02/setting-up-bonjourzeroconfmdnsnsd.html
Related
From an Android device, I'm attempting to set up a tunnel to a Gossip router on the local network. I'm using this as the config:
<config xmlns="urn:org:jgroups"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.4.xsd">
<TUNNEL gossip_router_hosts="${jgroups.tunnel.gossip_router_hosts:10.20.30.152[12001]}"/>
</config>
With code like this:
channel = JChannel(context.getAssets().open("jgroups.xml"))
channel.setReceiver(this)
channel.connect("MyGroup")
However, the app is attempting to connect via IPv6 by default, which doesn't appear to be working:
20096:connect(41, {sa_family=AF_INET6, sin6_port=htons(12001), inet_pton(AF_INET6, "::ffff:10.20.30.152", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
This occurs even when I remove any IPv6 addresses from the network interface. I understand that there is a JVM flag for favoring IPv4, but I believe this is not applicable to Android. Setting options via adb isn't going to be a good solution either.
Is there another way to force JGroups to use IPv4 for connecting? Or is there some other route to a fix?
I've tested this on Android 8.0 and see the behavior with JGroups versions 4.1.6 and 3.6.19.
This is a weird config! Are you sure, you want to have a protocol stack with only TUNNEL in it?
If so, then I guess gossip_router_hosts needs to point to an IPv6 address.
I'm trying to get TXT Records from Wifi Direct Printers nearby. So far, I can discover peers and establish a connection. But no luck with TXT Records.
I tried Wifi Direct Service Discovery, and I believe I did everything properly since I compared lots of codes from different resources including sample projects from Google and some open source Wifi Direct Wrappers in GitHub. But I couldn't make it work.
I've also seen some weird issues while trying to achieve that. e.g in some devices, when I start the peer discovery, Wifi Connection started to be turned off and on constantly.
Can someone explain how this actually works ? are DnsSdServiceResponseListener and DnsSdTxtRecordListener made for Android devices rather than Printers ?
I've also tried to listen the MultiCast DNS IP Address (224.0.0.251) with a MulticastSocket after establishing the connection between Android and Wifi Direct Printer, but I couldn't receive any data as well.
Thanks.
I used "DnsSdServiceResponseListener" and "DnsSdTxtRecordListener" successfully in my current project. Both listeners are associated to discovering local services nearby.
To use them properly, you have to do the following:
Implement your listeners
WifiP2pManager.DnsSdServiceResponseListener dnsListener = new WifiP2pManager.DnsSdServiceResponseListener() {
#Override
public void onDnsSdServiceAvailable(String instanceName, String registrationType, WifiP2pDevice device) {
// instanceName is service name and device is the print information
}};
WifiP2pManager.DnsSdTxtRecordListener txtListener = new WifiP2pManager.DnsSdTxtRecordListener() {
#Override
public void onDnsSdTxtRecordAvailable(String fullDomain, Map record, WifiP2pDevice device) {
// here we get the service published information in the record map object
}};
Add the listeners to your WiFiManager object
wifiP2PManagerObj.setDnsSdResponseListeners(mChannel, dnsListener, txtListener);
Add service request
WifiP2pDnsSdServiceRequest serviceRequest = WifiP2pDnsSdServiceRequest.newInstance();
wifiP2PManagerObj.addServiceRequest(mChannel,serviceRequest, actionListener);
Finally, discover services
wifiP2PManagerObj.discoverServices(mChannel,actionListener);
After discover services is executed successfully, the listeners should receive the nearby services information.
Hope this helps.
Goodluck.
Update
Wifi direct supported printers don't have any published services by default. To use them you have to connect to them via wifi direct and print normally as its a printer connected to your network. Note that those listeners are meant to capture published services (i.e will not capture anything for any device unless its publishing a service).
I think you will need to run Bonjour discovery once the connection is established. You can see NSD and look for "_ipp._tcp" as the service type. By the way,
for "I've also seen some weird issues while trying to achieve that. e.g in some devices, when I start the peer discovery, Wifi Connection started to be turned off and on constantly." if you're testing on a 7.1 device you might be seeing this issue, for which a patch should be coming soon.
I am into a new project which requires me to use a USBconnected "Webcam".
The whole fun should run on Android 4.4.
my little story was:
I try multiple apps which do this - all work on both my testing devices
adapting some NDK lib that directly uses /dev/video0. This didnt work due to read-permission that was not granted in a new File("dev/video0").canRead() check. Although my unix permissions are correct, this seems to not work due to some new check on Android 4.4. (the whole thing was suggested here: Connect Android phone to a USB Web camera )
next: discover the UsbAccessory API that supposedly easens a lot of the above.
´find no documentation or anything about how to correctly handle a webcam
I still try, but don't come further than finding no device via
usbManager.getAccessory();
I've also tried to discover devices by filtering for a USB_ATTACHED broadcast but nothing triggers.
So I am starting to ask myself how the hell do others find the devices & communicate with them to get the pictures?
Anyone has sources from which i could learn, or a tutorial or something?
Little update from my side:
- I've gotten access by using the Android USB Host API e.g. UsbDevice instead of UsbAccessory.
- I have the connection and everything setup fine, and can now send binary data to my webcam and supposedly receive.
I can now send controlCommands via connection.controlTransfer(...) or use a "UsbRequest" in order to receive data.
However, I couldn't find any documentation to "make the camera submit pictures" to me. My Endpoint is of type XFER_INT (=interrupts).
I am continuing to try sending out various commands (e.g. binary values) but haven't had any success so far.
To debug a web application, I used a web debugging proxy. And I found that android devices keep connecting to a VPN with the address:
https://scss-prod-ew1-notif-8.adobesc.com:443
Does anyone have an idea what is this?
Thanks
Seems to be a service from Adobe.
WhoIs: Adobe
Other Domain siblings they use:
scss-prod-an1-notif-8.adobesc.com
scss-prod-an1-notif-7.adobesc.com
scss-prod-ue1-notif-5.adobesc.com
scss-prod-ue1-notif-11.adobesc.com
scss-prod-an1-notif-2.adobesc.com
scss-prod-an1-notif-4.adobesc.com
scss-prod-an1-notif-3.adobesc.com
scss-prod-an1-notif-1.adobesc.com
scss-prod-an1-notif-5.adobesc.com
scss-prod-ue1-notif-10.adobesc.com
Alright here's the deal. I got two Galaxy Nexus phones both with bluetooth enabled.
I've written a bluetooth connection management app that I use for device discovery and connectivity. It also outputs all the available UUIDs the devices can support.
Looking from http://www.bluetooth.org/Technical/AssignedNumbers/service_discovery.htm the following standard UUIDs are exposed from Galaxy Nexus devices.
0x1116 - NAP
0x112f - PBAP (Phonebook Access Profile)
0x111f - HFP (Hands free)
0x1105 - OPP (Object Push Profile)
0x1112 - HSP (Headset Profile)
0x110c - AVRCP
0x110a - A2DP
I am trying to connect via the OPP profile (UUID 00001105-0000-1000-8000-00805F9B34FB) and push objects (files) between the devices. I've gone though the entire Android API documentation on how to discover, pair/bond (threading etc.) and manage all bluetooth connections. I've managed to successfully connect and talk to a legacy board device via the SPP (0x1101) profile.
However, when I try to use socket.connect() between the two galaxy nexus phones, the pairing dialog shows up and I click Pair button on both devices. After that, I immediately get a Connection Refused IOException. Note that after pairing has occurred once I never get asked again which makes sense since the secure link is cached.
If I can't connect to these standard profiles using these standard UUIDs why are they exposed? How can I connect from my app to any of these profiles and interact with them? Is it because my app is not somehow trusted? What's weird is that even the Share functionality on Android does not work at all either. Is this something completely broken on Android?
Please avoid giving me hints to use the "well known UUID SPP one 0x1101" like the docs say. This is not what I want. I have a fairly good understanding of how this stuff works and I am looking for a real solution or explanation of the problem.
I've seen the typical "reflection" solution but I do not understand why is this still a problem on Android? Why do people use reflection to make this work? Can we file a bug on Android to fix this?
If those UUIDs are standard any app should be able to connect and interact with them. Why is this an issue and why do I get this exception?
Thanks in advance.
UPDATE
So for some reason the object push in the Android system started working. I actually attempted to connect via my app and it was not working. Then, I went to the Contacts app and tried to share a contact which magically worked. Then, I went back to my app and it now it works...wow. That is very weird and there must be an explanation to this.
I ran into this same issue and managed to find a solution that worked for me.
In my case I using three different test devices (Nexus 5, Galaxy S4, Note 2) and for some reason, the Note 2 wouldn't connect to my Bluetooth module yet the other two would.
The reasoning I've found is that Bluetooth drivers vary, and slightly different connection methods are needed to create a connection between different devices.
The three methods I use are called 'Secure', 'Insecure' and 'Reflection method'/'hax'.
switch(connType)
{
case Secure:
tmpSocket = device.createRfcommSocketToServiceRecord(_uuid);
break;
case Insecure:
tmpSocket = device.createInsecureRfcommSocketToServiceRecord(_uuid);
break;
case Hax:
Method createSocket = device.getClass().getMethod("createRfcommSocket", new Class[] {int.class});
tmpSocket = (BluetoothSocket)createSocket.invoke(device, Integer.valueOf(1));
break;
}
In my case, the Secure mode worked for both the Nexus 5 and Galaxy S4 however it didn't work for the Note 2.
After some testing I discovered the Note 2 only works using 'Insecure' mode, so to cater to this, I basically attempt a connection and cycle through the different modes if necessary. When attempting a different connection mode I simply prompt 'retrying connection'. So, if the connection fails using secure, then I will attempt using Insecure and then using the reflection method.
I haven't run into the case where one of these three methods haven't worked.
Have you tried using a nonstandard profile? i.e. a custom UUID just for your app. This will also help you know your are (most likely) only connecting to your own app rather than some other app that is registered with the same profile.
From my experience, Bluetooth pairing is very buggy for the first pair attempt. However, using a custom UUID helps this somewhat.
The reflection method (I think) was originally an attempt to fix a bug with a specific device, however I think some people found success in using it elsewhere as well. The device was called the Spica or something similar.
As one of the comments also posted, I would also try connecting again after failing.
Basically write code that plans to fail the first attempt, but then the code tries to connect again in 5 seconds if there was a failure.
These are imperfect solutions but Bluetooth implementation on Android is also imperfect (IMHO). Hope that helps
EDIT
Based on the question update and comments:
I agree something is definitely buggy. Part of the problem I think is the BT drivers vary and each has a different BT stack with different quirks. I also found a question that makes use of both the reflection method AND custom UUID, AND other standard methods. This seems extreme to me but it does cover the most ground. Unfortunately as app developers we have no control over the low level stack/code/drivers.
I have found with my two Bluetooth sharing apps that the first pairing is always tricky.
I'm glad to know it's not just me.