Author Topic: 16 GPIO Output control over TCP connection using MCP23S17  (Read 6841 times)

0 Members and 1 Guest are viewing this topic.

Offline metalphreakTopic starter

  • Frequent Contributor
  • **
  • Posts: 815
  • Country: au
  • http://d.av.id.au
    • D.av.id.AU
16 GPIO Output control over TCP connection using MCP23S17
« on: April 29, 2015, 01:11:59 pm »
https://github.com/MetalPhreak/ESP8266_GPIO16_TCP_Example

Microchip MCP23S17 SPI GPIO expander connected over the hardware HSPI module.

TCP Listener configured on port 33333. Send it a 2 byte command to turn the outputs on or off.

Code: [Select]
echo -ne '\xFF\xFF' | nc 192.168.5.1 33333
Could easily be expanded to a project controlling relays, triacs, etc.


Offline PeterFW

  • Frequent Contributor
  • **
  • Posts: 577
  • Country: de
    • Stuff that goes boom
Re: 16 GPIO Output control over TCP connection using MCP23S17
« Reply #1 on: April 29, 2015, 01:18:42 pm »
Microchip MCP23S17 SPI GPIO expander connected over the hardware HSPI module.

Nice, thanks for posting! :)
 

Offline metalphreakTopic starter

  • Frequent Contributor
  • **
  • Posts: 815
  • Country: au
  • http://d.av.id.au
    • D.av.id.AU
Re: 16 GPIO Output control over TCP connection using MCP23S17
« Reply #2 on: May 06, 2015, 12:48:37 pm »
Now with more Android control :)

Will post updates to ESP code and android source once I complete it a bit more...


Online linux-works

  • Super Contributor
  • ***
  • Posts: 1993
  • Country: us
    • netstuff
Re: 16 GPIO Output control over TCP connection using MCP23S17
« Reply #3 on: May 06, 2015, 01:37:28 pm »
how is the security on this?  can you do permit/deny on things (mac, ip, other stuff)?

any authentication at all?

I always ask the security questions when an IoT project is mentioned.  few seem to think about it or care, but it IS important.  if you can twiddle real world bits, you need to have a security story or its just going to go wrong, eventually.

Offline metalphreakTopic starter

  • Frequent Contributor
  • **
  • Posts: 815
  • Country: au
  • http://d.av.id.au
    • D.av.id.AU
Re: 16 GPIO Output control over TCP connection using MCP23S17
« Reply #4 on: May 07, 2015, 07:53:32 am »
No security on it yet. I want to get it all working before I add any layers of security.

Plan is to use an ssl tcp connection and a device password that's sent with every request.

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: 16 GPIO Output control over TCP connection using MCP23S17
« Reply #5 on: May 07, 2015, 10:16:46 am »
No security on it yet. I want to get it all working before I add any layers of security.

Plan is to use an ssl tcp connection and a device password that's sent with every request.

That is still problematic. Consider SSH protocol with certificate-only authentication which is a lot safer.
 

Online linux-works

  • Super Contributor
  • ***
  • Posts: 1993
  • Country: us
    • netstuff
Re: 16 GPIO Output control over TCP connection using MCP23S17
« Reply #6 on: May 07, 2015, 12:59:48 pm »
as long as there is a plan, that's good.  small steps to the big plan are also fine.

its when people say 'hey, this is a controlled lan, we don't need no stinkin' passwords, etc etc'.

when the ethernet 'shield' first came out for the arduino and I saw the ultra shitty driver for it (still shitty, but that's beside the point), I asked 'what's the point of this, as it will be a node on the ip network and yet have ZERO security to it.  why even bother?'.  the question was not really answered, just lots of noise about security not being needed (damn).  they didn't 'get it' or just refused to see how bad it is to have IoT stuff without a good security story to go along with it.

then, the rasp pi style cheap boards became very popular and suddenly, we had a PROPER ip stack and all that went with it, for about the same price as an arduino and official ethernet shield.  why mess around with hardware ip stacks that are non upgradable, non patchable and don't even come close to the features and security of a software ip stack, such as the raspi.

I like the idea of a small 'ip stack on a chip' or small board, but if its going to touch real world things, I do insist that there at least be a story for how to secure it down.

oh, and this story was just on slashdot recently, about the 'least secure IP device they ever saw':

http://it.slashdot.org/story/15/05/06/2215205/researcher-drug-infusion-pump-is-the-least-secure-ip-device-hes-ever-seen

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: 16 GPIO Output control over TCP connection using MCP23S17
« Reply #7 on: May 07, 2015, 01:49:58 pm »
as long as there is a plan, that's good.  small steps to the big plan are also fine.

its when people say 'hey, this is a controlled lan, we don't need no stinkin' passwords, etc etc'.

when the ethernet 'shield' first came out for the arduino and I saw the ultra shitty driver for it (still shitty, but that's beside the point), I asked 'what's the point of this, as it will be a node on the ip network and yet have ZERO security to it.  why even bother?'.  the question was not really answered, just lots of noise about security not being needed (damn).  they didn't 'get it' or just refused to see how bad it is to have IoT stuff without a good security story to go along with it.

then, the rasp pi style cheap boards became very popular and suddenly, we had a PROPER ip stack and all that went with it, for about the same price as an arduino and official ethernet shield.  why mess around with hardware ip stacks that are non upgradable, non patchable and don't even come close to the features and security of a software ip stack, such as the raspi.

I like the idea of a small 'ip stack on a chip' or small board, but if its going to touch real world things, I do insist that there at least be a story for how to secure it down.

oh, and this story was just on slashdot recently, about the 'least secure IP device they ever saw':

http://it.slashdot.org/story/15/05/06/2215205/researcher-drug-infusion-pump-is-the-least-secure-ip-device-hes-ever-seen

I would say the same. Any IoT device that is IP attached must be fortified or your life can be screwed by a stranger.

I have Cat5e running in my apartment wirings leading from the exchange point to every electric switch box in my home, with intention to implement IoT home automation in some future time. The reason I chose Cat5e as the medium instead of wireless (Wi-Fi or Zigbee) is security - I don't want my devices that cannot run a proper SSL stack exposed in an IP-enabled network or a wireless network, and most microcontrollers can't. Also a lot of people suggest me to connect the microcontrollers using wired Ethernet over the same cables - same rules apply, not going to do it. This is why I am researching running some kind of non-IP protocol over the Cat5e cabling.
 

Online linux-works

  • Super Contributor
  • ***
  • Posts: 1993
  • Country: us
    • netstuff
Re: 16 GPIO Output control over TCP connection using MCP23S17
« Reply #8 on: May 07, 2015, 02:56:42 pm »
I currently rent and so I can't easily modify my place ;(  for some stuff, I do run wifi but I hate it and cabling is SO much better, its not even funny.  not even close.  some things are really latency sensitive - if I start playback of an HD file over my htpc, on wireless it can take a minute before the mkv starts.  on wired, even 10/100 wired, it starts immediately.

wifi is not secure, generally (some commercial ones are a bit better but home versions are all a joke).  and wifi will always be a target for hackers.

I love zigbees but don't believe for a second they are secure.  if you layer stuff on top of it, you can make them more secure, though.

but given a choice, wired is my choice, too.  if I could, I would do the same - have gig-e wired (2 pairs at least) be in every room of the house and have them tie to a common wiring closet of some kind.  (my current cheap/good managed switch is this one: http://www.amazon.com/gp/product/B006B7R3YC/ and you can bury that in an attic or some remote place and fully remotely manage it via web, cli, snmp.  its a nice little cisco-like cheap l2 switch.  and if you do install that remotely, you DO want to run a 2nd management-network wire to it; I prefer serial which is also a cisco standard.  if you are pulling wire, pull lots of ethernet drops but also some serial drops as well).
« Last Edit: May 07, 2015, 03:00:05 pm by linux-works »
 

Online linux-works

  • Super Contributor
  • ***
  • Posts: 1993
  • Country: us
    • netstuff
Re: 16 GPIO Output control over TCP connection using MCP23S17
« Reply #9 on: May 07, 2015, 03:02:07 pm »
I have to look at the code - but - is there a planned or desired REST interface?

web is good.  automated web (REST) is even better ;)

and REST can be secure.  not sure about low-end controller things, though.

Offline metalphreakTopic starter

  • Frequent Contributor
  • **
  • Posts: 815
  • Country: au
  • http://d.av.id.au
    • D.av.id.AU
Re: 16 GPIO Output control over TCP connection using MCP23S17
« Reply #10 on: June 14, 2015, 11:36:22 am »


My relay controller pcbs arrived :D

Now I have something proper to start writing code for :)

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: 16 GPIO Output control over TCP connection using MCP23S17
« Reply #11 on: June 15, 2015, 10:52:06 pm »
I have to look at the code - but - is there a planned or desired REST interface?

web is good.  automated web (REST) is even better ;)

and REST can be secure.  not sure about low-end controller things, though.

You will have difficulties running any proper (as in not brute-force crackable with a top-of-the-line gaming rig within a week) security stack on your low end microcontroller.

The better solution will be using a Raspberry Pi, it can run a proper TLS 1.3 stack with latest crypto suites that provides perfect forward secrecy, and will take a few years even by NSA (according to public knowledge) to crack.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf