The Border Router setup guide spells out how to connect a USB-based network coprocessor. As I understand it, it is easy to use a serial connection of the host to connect to an NCP. Is it just a matter of changing the configuration of wpantund?
Configurating wpantund for serial communication is all done through the Config:NCP:SocketPath option. The NCP connection in the USB-based example is presented as a standard linux tty device. If your specific NCP configuration also presents the connection as a tty device, then you likely just need to change the /dev/tty* path.
If you are planning to use an SPI connection, take a look at spi-hdlc-adapter, which allows using the SPI connection as if it were a serial stream.
Related
We have a system that implements reverse ssh tunnel to enable remote port forwarding.
This enables to expose devices on local network via a Public IP.
However, we're achieving this by a static port allocation, i.e. We've mapped Serial No.s of devices to Ports and each time a request comes to our server with Serial No. , we forward it to the designated port.
Obviously this design isn't scalable and we want to replace it with dynamic port allocation, such that the server itself takes care of allocating the port and freeing it once the device goes offline.
It'd be great to have suggestions on how this can be achieved.
Thanks in anticipation and apologies for my lack of knowledge in case I didn't explain it better (I'm new to this)
This can be solved by using a ssh command script in ~/.ssh/authorized_keys on your server.
command="reverse_server.py" ssh-rsa <publicKey>
First, a client has to connect to the script and send it's own serial (in my case a use the MAC-adress of one NIC).
The server looks into a database and tell the assigned port number or creates a new one for an unknown serial.
In the next step, the client can connect, using the reported port number as reverse port.
Btw. You should add some logic to monitor and recreate the tunnel if it disconnects or get stuck.
I am connecting my controller PC to a Pica8 white switch via the Management port. I can SSH into the switch and ping the controller PC, however I cant ping the hosts through the standard ports. I have created a bridge of the first four ports and have successfully pinged from host to host after I installed a flow that allowed it.
My question is, is there some kind of mechanism separating the controller port from all of the data ports, I would think I should be able to ping from the switch to the hosts.
I'm not sure this answers your question, but before pinging the management port I believe you need to set an IP for it via the console port.
I use minicom per the instructions located here. However, I am using the RJ45 to DB9 adapter cable -> USB Serial port connection. That looks like so.
Unfortunately, that creates a problem with minicom, since the instructions tell you to simply power up the switch and observe the received data. There is actually a little more to it than that. You have to configure minicom's serial port. Fortunately, there is a tech blog that I found very helpful. If you follow the provided instructions, it will walk you through changing ports. Once you modify the port that minicom is listening on (For me it is Port /dev/ttyUSB0), you should be able to configure your management port.
I normally use MOBAXterm to SSH into my work pc, but when I use my gf's internet connection, it works for only a little while before giving me the above error message.
It also happens when I ssh into other external machines and it also happens when I use putty. I already implemented all the in-build steps MOBAXterm offers that could potentially fix this problem.
My suspicion is that it's related to the internet connection cutting out temporarily, but I don't see why that should be such an issue.
Any advice would be appreciated.
Two possibilities here, the nefarious and the irritating. If you know how to sniff traffic, a pcap dump of the session dying would be extremely useful. Grab it using the stable version of Wireshark.
The nefarious possibility
Traffic shaping. SSH can be used to tunnel VPN traffic. If the ISP is difficult about it (more likely if they're a big ISP) they could happily send RSTs to long-lived sessions.
The irritating possibility
Sketchy home router. If the NAT table is too full, the router's memory is overloaded, or there's a bug in the firmware, the NAT table could drop sessions which would cause what you describe.
Solutions
Try mosh. It uses SSH for session setup, then its own protocol over UDP for the actual session. It's UDP-based so there's no TCP connection to RST, and mosh is designed to survive a nuclear strike. It doesn't even care if your IP address changes mid session.
The problem is likely to be solved using mosh - even if it's the home router, mosh's session continuity will mask the NAT table resetting.
If you want to replace the home router (for example if the same thing is happening to other protocols), and you can get the authentication details for the Internet connection, try swapping it out for another one - preferably a recent high-end SOHO model.
If the connection presents as Ethernet (for example a cable modem, like Virgin) then my standard known-good is the TP-Link Archer C7.
If the connection is DSL-based (copper phone line, or BT fibre), you'll also want a 1-port VDSL (for fibre) or ADSL/ADSL2+ (for copper) modem capable of bridge mode. You'll need this in addition to the Ethernet router.
For VDSL, I'd probably recommend the ZyXEL VMG1312-B. For ADSL/ADSL2+ I'd suggest the ZyXEL P660-R.
Are there limitations that would prevent from establishing a tcp/ip socket connection between two distant devices? (Not on the same WiFi LAN.)
[Edit]
I missed this one: http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202858(v=vs.105).aspx
I'll try it as it seems like the usual client/server snippet, but for WP, so that looks promising.
I don't think you can do this directly device to device due to dynamically assigned IP address visibility etc. You might have to expose a web service on the public internet for this purpose. Basically a web service both devices can see and communicate with. (ex. Heroku, Amazon AWS). One device can keep a blocking connection ("Comet") while the other device initiates connections.
I have several smart devices that run Windows CE5 with our application written in .NETCF 3.5. The smart devices are connected to the internet with integrated GPRS modems. My clients would like a remote support option but VNC and similar tools doesn't seem to be able to do the job. I found several issues with VNC to get it to work. First it has severe performance issues when ran on the smart device. The second issue is that the internet provider has a firewall that blocks all incoming requests if they didn't originate from the smart device itself. Therefore I cannot initiate a remote desktop session with the smart devices since the request didn't originate from the smart device.
We could get our own APN however they are too expensive and the monthly cost is too great for the amount of smart devices we have deployed. It's more economical for us if we could add development costs to the initial product cost because our customers dislike high monthly costs and rather pay a large sum up front instead. A remote support solution would also allow us to minimize our onsite support.
That's why we more or less decided to roll our own remote desktop solution. We have code for capturing images on the smart device and only get the data that has changed since the last cycle. What we need is to make a communication solution like logmein.com (doesn't support WinCE5) where the smart devices connect to a server from which we then can stream the data to our support personnel's clients. Basically the smart device initiates a connection to our server and start delivering screen data when the server requests it. A support client connects to the server and gets a list of available streams and then select one to listen in on.
Any suggestions for how to do it considering we have to do the solution in .NETCF 3.5 on the smart devices? We have limited communication experience beyond simple soap web-services.
Since you're asking for a suggestion, I'll suggest this:
Don't reinvent. Reuse whatever you can. You can perform tunneling with SSH, so make an SSH connection (say, a port of PuTTY or plink, inside a loop) out via GPRS on your smart device; forward remote ports to local ports, bound to the SSH server's local address (127.0.0.1 (sshd):4567 => localhost (smart_device_01):4567). Your clients connect to your SSH server and access the assigned port for each device.
With that said, that's probably not the answer you're looking for. Below - the answer you're probably looking for.
Based on my analysis of how LogMeIn works, you'll want to make an HTTPS or TLS server where your smart devices will push data. Let's call it your tunnel server.
You'll probably want to spawn a new thread that repeatedly attempts to make connections to the tunnel server (outbound connections from smart device to the server, per your specified requirement). With a protocol like BEEP/BXXP, you can encapsulate and multiplex message-oriented or stream-oriented sessions. Wrap BXXP/BEEP into TLS, and tunnel through to your tunnel server. BEEP lets you multiplex streams onto one connection -- if you want the full capabilities of an in-house LogMeIn solution, you'll want to use something like this.
Once a connection is established, make a new BEEP session. With the new session, tell the tunnel server your system identification information (device name, device authentication signature). Write heartbeat data (timestamp periodically) into this new session.
Set up a callback (or another thread) which interfaces to your BEEP control session. Watch for a message requesting service. When such a request comes in, spawn the required threads to copy data from your custom remote-display protocol and push this data back through the same channel.
This sets the basic premise for your Smart Device's program. You can add functionality to this as you desire, say, to match what LMI's IT Reach subscription provides (remote registry, secure tunneled Telnet, remote filesystem, remote printing, remote sound... you get the idea)
I'll make some assumptions that you know how to properly secure all this stuff for authentication and authorization for your clients (Is user foo allowed to access smart device bar?).
On your tunnel server, start a server socket (listening for inbound connections, or from the perspective of smart devices, smart device outbound connections) that demultiplexes connections and sessions. Once a connection is opened, fire up BEEP and register a callback / start a thread to wait for the authentication/heartbeat session. Perform the required checks for AAA to smart devices -- are these devices allowed, are they known, how much does it cost, etc. Your tunnel server forwards data on behalf of your smart devices. For each BEEP session, attach a name (device name) to the BEEP session after the AAA procedures succeed; on failure, close the connection and let the AAA mechanism know (to block attackers). Your tunnel server should also set up what's required for interacting with the frontend -- that is, it should have the code to interact with BEEP to demultiplex the stream for your remote display data.
On your frontend server (can be the same box as the tunnel server), install the routine for AAA -- check if the user is known, if the user is allowed, how much the user should be charged, etc. Once all the checks are passed, make a secured connection from the frontend server to tunnel server. Get the device names that the tunnel server knows that the user is allowed to access. At this point, you should be able to get a "plaintext" stream, based on the device name, from the tunnel server. Forward this stream back to the user (via TLS, for example, or again via BEEP over TLS), or send the required configuration for your remote display client to connect to your tunnel server with the required parameters to access the remote display protocol's stream.