AsyncLabs Forums

[GregEigsti]

There is a void zg_reset(); function declared but not defined. Should not be too difficult to define but would have to study the stack state machine to make sure to get everything right. Almost seems like calling zg_init() would be easier because it should do everything that zg_reset() might do.

BTW - I did completely trash your sample pde; one of the changes was to do the init found in setup() every time we cycle into the beginning of the cycle - search for APs.

Greg

[spidermonkey04]

I was wondering what kind of shenanigans you were up to with sending packets...but I get it now. It looks like some of that google book is a bit dated, but I can't find anything better. A few bits say reserved when they now mean something (bit9-Auth 802.1x, bit10-Auth PSK, others). So we definitely should be able to tell which APs support WEP/WPA/WPA2. BTW, WPA is indicated by Auth802.1x AND AuthTKIP bits being set. I guess the only other thing to watch out for is supported data rates (make sure AP does 1or2Mbps). Not sure why I was thinking it is b/g either. I'll look around for some more of that info. Too bad I can't veg in front of the computer today...
---Jared

[GregEigsti]

Its cranking away, connecting to a neighbor's open AP, and sending a packet home. No DHCP yet and it is still only able to send every other time (some state variable in the stack not being set/reset on stack_init?). But I did play with changing my ip/gateway/host addrs and found doing so after the connect won't work. So as a workaround the code now WiFi.int()/connects once with bogus ip - this will allow dhcp to be called here - then it calls WiFi.int()/connect again using the data from dhcp. I am mocking the dhcp data but the whole two WiFi.int()/connects thing feels wrong. Can probly get dhcp pre connect like you are doing with the scan function... Right now a successful cycle is taking ~20 seconds and an unsuccessful cycle is taking ~1 minute (worst). Getting the packets displayed on the home server!

Currently I believe the only working WiShield DHCP code requires a connection before querying for DHCP data (based on uIP author's sample). A better way would be to talk directly to the ZG and have the "dhcp conversation" before initial WiFi.int()/connect call. But I wrote the code hoping to get that working DHCP code.

Was thinking of adding DNS as well. Got APP_SOCKAPP / APP_UDPAPP working together (udp needed for dhcp/dns); updated uip-conf.h to define the correct UDP stuff if APP_UDPAPP is set. Adding WiServer is slightly more complicated. Trying to get all sample sketches working with TCP/UDP is more difficult (I've been close but gave up due to apathy).

Greg

[GregEigsti]

Got DHCP (with the help of a friend) and DNS running on the widget tonight! It still does the double connect (once to get DHCP data and once with DHCP data) and is only getting a packet through every other cycle but DHCP/DNS are solid and working every time. Code looks like crap and needs some serious refactoring - but its working! Also noticed that I cannot get DHCP back from the neighbor's AP that I was sending TCP packets through; its RSSI is 112-118 and I had been needing 118 to get a packet through. Tonight can connect but not get DHCP back at 118. Working great on my open AP.

Hmmm, DHCP/DNS working every time and they are UDP - might have helped narrow the problem to TCP (and what happens before a timeout).

Greg

[GregEigsti]

I did a bunch of work on the WiShield libs today and pushed them to the user contrib branch on GiHub. Its all there: AP scanning, DNS, DHCP and a few new examples (WiServer + DNS, TCP/SocketApp + DNS, and the sketch that I posted about on this thread which uses scanning/DHCP/DNS/TCP to sniff out and send a TCP packet through open APs). Also, most users won't need to mess with app-config.h and uip-config.h any longer - most of the uip-config settings can be set in app-config (one stop shopping just makes it easier).

So the samples work but the stack seems awful wobbly. I tried many different samples and versions of the libs; the latest master 1.3.0 seems just as wobbly so I don't think I have negatively affected things. DNS and DHCP definitely work on their own and together (I saw it I swear) and the new samples should get you started.

Oh yeah, also got spidermonkey04's "too large of an incoming packet" fix in there. Did not apply any of the latest tweaks to WiServer other than to get it compatible with the other changes (I'll let shard7 decide what fix goes in). The SimpleClientDNS example clearly shows that DNS and WiServer work together!

I am unhappy with DHCP. I have not figured out how to connect, get DHCP, apply DHCP return and merrily go on my way. I am having to re-init the WiShield after getting the DHCP return and before going on my merry way. Would love another set of eyes to look this one over - I have a feeling I am missing something simple...

Would also appreciate anyone who could look into the overall stack wobbliness. I have noticed that things seem to work just about every other time (in all versions of the stack). I am thinking stack or ZeroG not getting init'ed/re-init'ed properly? Also seems to be related to stack timeouts; almost seems like we get into a state that will end up being a timeout and we need to wait for the actual timeout to occur for things to be ok; if we reset before achieving timeout things get funky??? Dunno just wondering how hitting a timeout seems to make things ok for the next iteration??? Good reset-um code in the timeout handler?

Bleah bleah bleah. Check it out and let me know. Link to GitHub AsyncLabs user contrib branch
Greg

[MTT727]

Greg -

I'm having trouble compiling WiFiScan. I get the following error message(s):

/Documents/Arduino/libraries/asynclabs_WiShield_beta/socketapp.h:52: error: previous declaration of 'uip_tcp_appstate_t' was here from /Documents/Arduino/libraries/asynclabs_WiShield_beta/uipopt.h:104,

from /Users/Mac/Documents/Arduino/libraries/asynclabs_WiShield_beta/uip.h:89,

from /Users/Mac/Documents/Arduino/libraries/asynclabs_WiShield_beta/global-conf.h:43,

from /Users/Mac/Documents/Arduino/libraries/asynclabs_WiShield_beta/clock-arch.c:35:

/Documents/Arduino/libraries/asynclabs_WiShield_beta/server.h:65: error: conflicting types for 'uip_tcp_appstate_t'

/Documents/Arduino/libraries/asynclabs_WiShield_beta/socketapp.h:52: error: previous declaration of 'uip_tcp_appstate_t' was here

(I called your WiShield_user_contrib files from Github WiShield_beta). I've enabled APP_SOCKAPP, APP_UDPAPP, APP_WISERVER, UIP_DNS, UIP_DHCP, and UIP_SCAN in
apps-conf.h.

I appreciate all the work you've done on this.

Mac

[GregEigsti]

I'll bet if you comment out APP_WISERVER it will work for you
BTW - WiServer is mostly broken in the user contrib branch.

Greg

[MTT727]

Voila! I thought I had tried that, but I guess not. Working like a champ. Thanks.

I'm very much a newbie, so here's a newbie question: There are some variable declarations/assignments that I don't follow, like
U8 security_type = 0;

Is UB a user defined variable type that's defined elsewhere?

Thanks.
Mac

[GregEigsti]

Is UB a user defined variable type that's defined elsewhere?

Probably, no most certainly If you are familiar with grep/findstr you can find it in source files pretty quickly. It stands for Unsigned 8 bit value - otherwise known as an unsigned char.

Greg

[GregEigsti]

And you will find that things in the user contrib stack are slightly different that what is in the normal distribution. For instance some of the WiFi params have been moved out of PROGMEM to normal memory so they can be changed on the fly (for scanning, DHCP, etc.). Apps-conf.h also contains much more of the configuration stuff that you used to have go to different files for...

Greg