Sending web requests over LAN

In the scenario where an imp device needs to send web requests to another kind of device, on the same LAN, and that has no external (internet) connection of its own - the imp model of [ Device<-> Agent <-> internet ] seems to make this impossible. Other than a direct serial connection I can’t see a way around this. Am I missing a trick?

I’ve been caught out by yet another outrageous IoT fail where my home lighting system (Connected by TCP) has switched off their server so I can only control all my light bulbs from the smartphone app on my LAN. So much for that industry player :frowning:

Anyway, I’ve managed to work out how to control the lighting gateway over ethernet with http requests and now I want to restore the lost functionality (IFTTT control, sunrise sunset etc.) using an imp to bridge the gap.

I appreciate that this is working against the grain of the imp system model but you’ve got to admit it really highlights the problems faced by consumers of IoT and their position of being held hostage to the fortunes of the company they invest in. I’ve been sitting on the fence for years over this very issue myself so I would welcome any discussion on this wider topic.

I would say that the imp requires the cloud, no other way around it. So technically, all of us imp users are reliant on the imp servers (the cloud), just like you were with TCP). It’s been very stable and reliable, but who knows about the future?

The internet of things, and clouds, whether for IoT or any other purpose, require hardware that we can’t see or touch. Nobody outside of the cloud knows who can see our data, and what they can do with it. Nobody outside of the cloud knows how secure or reliable the hardware is. Even with the imp, Hugo can tell us how safe, reliable, and free to developers the imp cloud is, but what about 5 years from now, or 10 years from now? It’s a gamble.

And the final topping to all of this IoT is the fact that everybody is jumping on the IoT wagon without regard to WiFi security issues, network issues, and ISP (internet service providers) shutting down someone’s internet connection because of DDOS attacks.

That’s another thing, our ISP’s. They allow us to connect to the internet, but have no say in what the cloud servers do. So we have to worry about the “clouds” AND our ISP … either of them shutting things down, or holding us hostage.

IoT is fun to play with, but seriously scary.

… sorry for the rant, but most people tinkering with WiFi toasters, wash machines, thermostats, etc. don’t have a clue how messed up it really is right now.

I appreciate your comments mlseim. I have to say that of all the ecosystems, the imp is the only one I have any confidence in and I’m not particularly concerned about reliance on the server model. But self-sufficiency is a “thing” and it seems the only way to gain it is by re-inventing as many wheels as possible, stupid as that may be.

Regarding my little problem at home, I’m contemplating connecting a ESP8266 module via serial to an imp to give access to the LAN. Passing http requests back and forth as a serial char stream would seem to retain the security of the imp ecosystem so it makes me wonder why a way of cutting out the middle-man and providing an equivalent os call hasn’t been made available? Just working with a RESTful api for another local network connected device, by passing text objects, what security problems could there be? Or is there another kind of issue?

Well, one of the main reasons electric imp exists at all is to help prevent the nightmare IoT scenario from occurring; we amortize the cost of maintaining a secure OS and service across all customers, which makes it a tractable problem for the long term support required.

One of the reasons that the imp doesn’t do local networking is the potential for abuse. There’s no way for any VM code to talk to the local network, which means you can trust any imp powered device not to misbehave (obviously, that means trusting us, as we are the only ones with the signing keys for the OS running on the imp).

If imps could perform arbitrary local network transactions then they could be used to (for example) hack routers from inside a person’s firewall. This would not be good.

We are working on local networking, but it will be heavily restricted for just these reasons, and the default operation mode will be fully secure. The main use case is not for hitting arbitrary webservers on the local network, it’s for imp to imp comms and talking with other local devices (phones, etc).

Thanks Hugo. Glad to hear that some element of local networking is in development. So you’re saying that the restrictions are there to protect consumers from malicious imp-based products bought into their homes? If so that’s an angle I hadn’t considered at all!

I think homes will end up full of webserving gateways potentially supplying the demands for fully self-sufficient network connected products when the first generation of IoT things crumbles down (unless everyone adopts the electric imp :slight_smile: so hopefully any local networking you implement would be capable of solving my kind of issue - opening up a new market for third-party patches:

[ (defunct cloud) gateway <-> (patch) device <-> agent <-> internet ]

In today’s modular world I see no reason why systems need to scope creep to try and cater for all use cases. This merely introduces new compromises. I vote to keep imp as is.

Assuming you are not trying to have everything operate off a couple of AA batteries, then I agree with you that a cheap and simple solution to cater for this use case would be to add in an esp8266 module (e.g. esp01) and get the IMP to communicate with it via UART.

You can have the esp8266 act as an Access Point to handle local user control in the absence of internet communication. In my opinion this is the safest fall back scenario rather than via LAN - as prevents any chance of an outside hack attack via router.

Yes, the idea is that if the device has an imp in it, it’s trustworthy. This means the user doesn’t have to trust every random vendor who makes every random device. There are a lot of examples where the vendors really can’t be trusted due to the awful vulnerabilities in their product and lack of any software updates to fix them.

I personally think local webservers are an awful way to go. It’s hard to do security in the general case (PKI doesn’t work on local networks) plus the vast majority of local security vulns are related to badly implemented web interfaces… command injection and the rest.

The reason people offer them is that it’s easy. That’s about all it has going for it.

@gerrikoio 8266’s can’t serve many devices as an AP. You’d still use your existing AP for that.

@hugo, my understanding is that this is only an issue if streaming data. Point taken, if it needs to act as a wireless sensor network gateway you will be restricted by how many devices can concurrently connect. For scenarios where devices are in deep sleep and send event data it should be ok. Also, if handling user control at gateway (which is want I was looking at) you would want to restrict how many chiefs can control things.

I agree, local webservers are definitely not the way to go. Not only a huge security risk but adds to the development cost both in terms of hardware and software. Its a legacy issue probably caused by the old dial-up & ftp methodologies, which filtered through to m2m. Will take a while to stamp out.