The docs provides 2 methods on how to connect to development server: using adb reverse and via wifi. It also says the former is recommended.
Is there a reason why (aside from maybe being easier to setup)? Just curious if there's any disadvantage to connecting via wifi, which I prefer.
There's no disadvantage to using WiFi. Go for it. I think they recommended only because it's easier to set up, so they get less questions about it.
Related
I have a series of RPi's running Raspian which need to deployed in various location around the world.
They will have internet access, but will all be behind a router. Is there an off-the-shelf solution to keep the possibility to create a SSH connection to them? I am thinking about solving problems, upgrading etc.
I am thinking of a 'server' solution where a 'client' on the RPi keep an active connection so a SSH connection can be established when required. Any suggestions will be much appreciated!
I have experimented with several services including LogMeIn Hamachi and Weaved among others. I would highly recommend using Weaved because it allows you to meet your goal (SSH to pi behind a router), and the setup is painless. You may even find some other uses that are quite handy.
See the installation details at https://developer.weaved.com/portal/members/betapi.php
Steps to be up and running:
Go to http://www.weaved.com and sign up.
Install weaved on your pi, and follow the prompts for SSH (Instructions at https://developer.weaved.com/portal/members/betapi.php).
Go to "My Devices" at weaved.com and get the new internet accessible proxy address for your pi.
Enjoy!
Is it possible to use MirrorLink and Android Debug Bridge in parallel?
I'm working on a third party MirrorLink application and want to debug it with ADB/logcat.
Actually I've tried to use ADB over wifi and it works very good. But when I started the MirrorLink session, the connection got lost and couldn't be established again until the MirrorLink session was over.
We actually use the ADB when testing some ML devices, but I don't think we actually use it while in in an active MirrorLink session. There is nothing explicitly preventing it within MirrorLink that prevents it - but there may be some interaction vai UPnP or the MirrorLink attestation mechanism.
I've talked to some of the ML server (phone) device makers about this. You should be able to run ADB during a ML session via the WiFi connection. You have to do some work to enable ADB over wifi, but there is a handy guide on doing so here: https://developer.android.com/guide/topics/connectivity/usb/index.html
ADB and MirrorLink use different USB drivers and application software stacks. The capability is depends on the design of host and device side in terms of USB role. Some of the devices can run more than one driver and application at a time. However, some of them are limited to run one and exclusive from other drivers.
You may try use the method from the answer provided by Ed P. ADB forward through Wi-Fi is an alternative.
I'm starting a new project, a cross-platform C++ program that will need to connect to servers of the user's choice using SSH code built into the program. I'm trying to decide between libssh and libssh2. (Licensing is not an issue; libssh's LGPL is fine.)
libssh2 seems, from this page, to be the way to go -- with one possible exception. It doesn't support SSH v1. I have no idea what percentage of servers out there might only support SSH v1 these days. Does anyone have experience in this area, or could point me to something that would answer that?
Alternatively, can anyone point out another SSH library with SCP capability that supports both SSH v1 and v2? Preferably one that is thread-safe and can also support non-blocking operations?
There still exist some hardware devices which only offer SSH1, but when it comes to software, locking to SSH1 is dangerous as SSH1 has security flaws. Consequently if you don't plan to connect to hardware, omitting SSH1 completely is a good idea.
SSHv1 has already been outdated in the times when I became familiar with Linux, back in 2004. SO I don't think that many servers will support SSHv1 only nowadays.
If a server does only support v1, it is to be considered in a very bad state, IMO.
I don't know if anybody have issued this, but I wan't to ask. My problem was like this:
I could use video chatting from apprtc.appspot.com using two Chrome tab (which means I call myself). Everything worked well.
I could use apprtc with two different laptop as well, if those laptop were on the same network. I used my university's network behind proxy.
However, apprtc didn't work if I used it with one laptop on modem, and the other on LAN.
Can anybody explain what happened? Is this STUN/ICE problem? Or JSEP?
The public demo includes a STUN server but does not provide a TURN sever because the bandwidth to run a free TURN server is expensive. STUN get thought lots but not all NATs / firewalls but not anywhere near as many as TURN. You might be in a situation where TURN would work (but you don't have a TURN server) but STUN does not.
I've been able to use the demo at http://apprtc.appspot.com/ from behind two different NAT's. So it can at least work in theory; but it's also fairly well known that STUN, TURN and ICE aren't infallible. For starters, if someone has blocked access to the port 19302 (the port of the STUN server that the apprtc demo uses), the firewall traversal will never be able to get started.
The basic troubleshooting step would be to open up the Chrome developer tools (ctrl-shift-i) and look to see if there are any errors in the console. Failing to observe anything interesting there, you'd need to write up your own version of the demo app, this time with better error handling. For instance, the apprtc demo assumes certain things that can't really be taken for granted, for instance, that peerConnection.setLocalDescripton() and peerConnection.setRemoteDescription() will succeed. In production code, you'd really need to implement both success and failure callbacks on those - and that would give you better information about what might be going wrong.
AppRTC uses stun by default. TURN is 'better' (from my understanding), but I recall Justin Uberti saying public TURN servers will likely be misused (or something to that effect).
STUN often fails on enterprise grade subnets because it can't 'cope' with unfriendly NAT addressing.
I writing a mac application and i need to discover other Macs/PCs/iPhones/iPads connected to the same WIFI network.
Bonjour seems to be the most reasonable choice, but it turned out that it has problems on many types of routers (on mine for example, is not working as it blocks Bonjour services).
I just need to find iPs of devices, then i will try to connect to an application-specific port to determine if my process is running there.
What is the best approach to accomplish this task, without violating the App store Sandboxing?
ARP was the first answer which came to my mind. Does your network-setup allows this?