Wifly/Roving Networks/RN-171 socket connections...

Developer's Corner General Dev Discussions
1

Apologies, as this is not connected (yet) to Vera. But I have seen posts in these forums that suggest a few folks have considerable experience with the Roving Networks (now Microchip) Wifi to serial adapters.

I am attemptiong to use one to replace and Aircable BT-serial cable replacement to talk to a WGL Rain8. There was some learning involved, but I have the Wifly configured and socket code written that works perfectly with the device, with one caveat: the code only connects and writes (and reads) to the Wifly and serial device from a Mac.

Compiling the identical code on a Linux box (Ubuntu, Fedora Core, makes no matter) gets me the odd behavior that I get a connect on my socket, but writing to it gives me a SIGPIPE back. Every time. I can and will do more digging and will try to use tcpdump to analyze the traffic to see what is different, but thought I would ask here if any of the gurus have run into and worked around this sort of problem before.

It’s also a little confusing that I can do a telnet to the Wifly IP and port and connect to it 100% of the time from either Linux or MacOS.

A few Wifly config items:
static IP
no password
comm open, close, remote strings set to nil

Any thoughts much appreciated. If not, but anyone here cares, I can follow back up if and when I sort it out.

–Richard

2

I’m assuming you’re running it in server-mode, where it will listen for connections and then proxy them through on the serial side of the module.

First thing to do is check what firmware version you are running. I had a lot of instability with the earlier versions, and had to update. Mostly, it was dropped connections, where they would be dropped over a long course of time.

ie. Initial connections would work, and be sustained for days, but would eventually bail out…

I have successfully sustained connections to a RN-XV from Vera, a Mac, Telnet (Mac, RaspPi) as well as Python on a RaspPi so there’s a bunch they are working to these devices.

If you’re telnet’ing to it, and it’s holding connection, then [unfortunately] there’s likely problem in your C code (whatever you’re porting between platforms that’s having issues).

And as you’ve said, tcpdump will be your friend here, esp looking at the 3-way/startup interaction to see who’s causing it.

BTW: There are a LOT of knobs and dials in the config. Esp buffers and such. Probably best to post all of the ones you’ve tweaked, using their formal command, just in case there’s something significant in there.

3

Indeed, it was my stinky C code. On Linux machines, no packets were being sent at all. Tracked this down to my failure to initialize “sin_family” in the sockaddr_in struct used for the connect. That field has been there forever, but 95% of the code examples don’t set it, since older versions of the IP stack weren’t ipv6-aware/capable. I’m guessing on the Mac, they were kind and used a reasonable default, and on modern Linux, they assume nothing and were using whatever garbage was at that offset in the struct. Once I set this for ipv4, things started working fine.

Now on to the actual Wifly behavior I have to address: the way it pulls RTS/CTS high during boot init, and then drops them once things are up and functional. WGL’s Rain8 takes this as a “enter config mode” signal, and gets hung waiting for configuration info. I couldn’t find a way to disable this in the Wifly ton-o-manual.

WGL’s suggestion: make a cable to connect the Wifly to the Rain8 that is true three-wire: RX, TX and ground. The cable that comes with it is RJ12 to female DB9. Modular RJ12 to DB9 adapters showed up Friday, picked the short RJ12-RJ12 cables at the post office this morning. Will bring the Wifly and Rain8 in from under the front porch and make sure I have the wiring correct, and
can then put this to bed. On autopilot. Whatever.

Thanks for your input and suggestions.

–Richard

[quote=“guessed, post:2, topic:181771”]I’m assuming you’re running it in server-mode, where it will listen for connections and then proxy them through on the serial side of the module.

First thing to do is check what firmware version you are running. I had a lot of instability with the earlier versions, and had to update. Mostly, it was dropped connections, where they would be dropped over a long course of time.

ie. Initial connections would work, and be sustained for days, but would eventually bail out…

I have successfully sustained connections to a RN-XV from Vera, a Mac, Telnet (Mac, RaspPi) as well as Python on a RaspPi so there’s a bunch they are working to these devices.

If you’re telnet’ing to it, and it’s holding connection, then [unfortunately] there’s likely problem in your C code (whatever you’re porting between platforms that’s having issues).

And as you’ve said, tcpdump will be your friend here, esp looking at the 3-way/startup interaction to see who’s causing it.

BTW: There are a LOT of knobs and dials in the config. Esp buffers and such. Probably best to post all of the ones you’ve tweaked, using their formal command, just in case there’s something significant in there.[/quote]

4
Thanks for your input and suggestions.
No worries, and good luck on your adventure!

I find these little devices very handy for adapting stuff, albeit finicky to configure correctly :wink: