Stratux doesn't allow iFly to share flight plans via wifi any more

[Nokomis449]

1. Stratux version: v0.7b3 (17ab2e5c41)

2. Stratux config: bone stock image with network channel changed to 8

   SDR [ ] single [ X ] dual

   GPS [X ] yes [ ] no type: VK-172

   AHRS [ ] yes [ X ] no

   power source: Jackery 12000mAh/44.4Wh

   usb cable: short/thick

3. EFB app and version: (e.g., WingX Pro7 8.6.2) iFly GPS latest beta

   EFB platform: (e.g., iOS 9.2) Android phone, Android tablet, iFly 740 EFB hardware: (e.g., iPad Mini 2) Samsung S4, LG 8.3 LTE, iFly 740

4. Description of your issue: v0.7b3 is rock solid and I'll be sticking with it while v8 matures. iFly has a feature that allows you to create a flight plan on one device and then share that plan, and optionally plan updates, with all devices that have iFly up and running on the same network. On a previous version of Stratux, probably v4.4 or maybe a 5, I tested this feature and it worked. This weekend I tested it with v0.7b3, and it did not work. I switched all 3 devices to the SkyRadar DX wifi, and it worked. I also tested it on my home WiFi network and my phone's hotspot, and it worked. So I suspect AP Isolation or similar has been activated on the Stratux access point, preventing the devices from "seeing" each other and communicating on the network. If this is the case 1) can it be switched back, and 2) if not how can I reconfigure it to work on my personal Stratux?

Thanks!

If possible, enable "Replay Logs", reproduce the problem, and provide a copy of the logs in http://192.168.10.1/logs/stratux/ and http://192.168.10.1/logs/stratux.log.

[cyoung]

Just a housekeeping item - v0.8r1 is just a few commits (nothing significant) from the version of v0.7b3 that you're using. The end of the line on the betas will always be release versions. When/if you update to v0.8r1, you'll only be getting a nicer logs page.

What is the name of the iFly feature? Are you able to do any network captures? tcpdump -n -i wlan0 and paste the logs as you try to share flight plans when the devices are connected. No changes to networking relevant to this have been made in a while. It might have been the gateway change.

If you'd like to experiment, replace /etc/dhcp/dhcpd.conf with https://raw.githubusercontent.com/cyoung/stratux/929e1e1fef2d6929ffb20f04f00701d4af00fcf0/image/dhcpd.conf, reboot, and test out the iFly feature.

[Ergonomicmike]

I made a video for Brian (at iFly) a few days ago about Flight Plan transfer. (I had found a small bug.) It's working in v0.8r1. (At least, it is on mine. (I have a custom hostapd. But I don't think it's different.)) Update: iFly app on tablets.

[Ergonomicmike]

@Nokomis449 Another thing I found in my testing for Brian - one of my tablets won't accept incoming flight plans. That is, I can send a flight plan from it. But it won't receive any.

[cyoung]

And this only happens on the stratux network?

[Ergonomicmike]

Are you asking me or Jeff? My unidirectional xfer problem happens over my home network too. I think it's due to a custom ROM in my Nook HD+ tablet. The developer did some whacky stuff with the Wi-Fi in the ROM.

[cyoung]

@Ergonomicmike - that answers it.

[Ergonomicmike]

It's the same tablet that causes a disconnect if I have BT enabled on it with Wi-Fi and two clients on Stratux.

[Nokomis449]

You asked What is the name of the iFly feature?

Tap the Flight Plan button, tap More Options, and the last selection is Share with Local Devices. When you tap it, the other instances of iFly (regardless of hardware platform) that are on the same network will pop up a dialog box where you can accept the incoming flight plan, and optionally continue to accept changes to the plan. The only time I've seen it not work is when I'm on a network that does not allow clients to see each other (most hotels and public hotspots), and when the network is my own personal hotspot. The latter is a known case where the hotspot device can accept plans from hotspot clients, but the hotspot itself cannot share it's plan because when working as a hotspot, all of its traffic goes to the outside network. So to clarify, my current issue only occurs when on the Stratux network. I just now tried again, and no joy via the Stratux network, but worked as designed via personal hotspot. If I get the chance tonight, I'll try v8 on a fresh card. If it still doesn't work, I'll try to get you the results of the tcpdump and try your config file above. Thanks for the help and info.

[Ergonomicmike]

This is an excerpt from Brian when he sent an email to me about my issue: "Flight Plan sharing is done via broadcast [mulit-cast].. the sending device blasts out the Flight Plan onto the local network in a manner which says “everyone listen!”… and on the receiving end, your device must be configured to “trust local network” such that it receives this broadcast."

[Nokomis449]

So since it works on other networks, that rules out tablet/phone/740 setup, because I haven't configured them any differently to "not trust" Stratux vs SkyRadar or home network or personal hotspot. Hopefully version 8 will solve it and it will be chalked up to Operator Error. I'll post results tonight.

[Ergonomicmike]

@Nokomis449 And the answer is?

[Nokomis449]

It's a riddle inside a mystery wrapped in a taco... I tried the .conf file above with 7.3, but Stratux would only allow my tablet to log on and not my phone, so I was unable to test it. Last night I made an 8.1 image and it ran fine all night with a client constantly connected, but I didn't get to test flight plan sharing until today. So while ago I finally got to test it, and it still doesn't work with Stratux WiFi but I can boot up my portable router and flight plan sharing works. But you say it works for you with 8.1, albeit with a tweaked driver. So i don't know if it's an iFly issue, a Stratux issue, or Operator Headgap issue. I have not had time to run the commands Chris mentioned and I may not have a chance for a while. :(

[Ergonomicmike]

And you're not running any firewalls on your various devices? (I am, and I have to enable iFly to have access to the Wi-Fi (in addition to the LAN) on my Firewall for Flight Plan transfer.)

The only other thing that I can think of that's different between your set up and mine is that I'm running all Android tablets. You have an iFly box. And an iOS device, correct? Perhaps you could try just a pair at a time so see if one of them is causing a problem? Or, try sending from every box you have. (As I said earlier, my Nook HD+ will send invitations to share a FP, but it will not accept invitations. So when I try sending a Flight Plan from my ZenPad, it has the appearance of not working, since nothing happens on my Nook.)

Of course, Chris is right - AFAIK, there weren't any overt changes in the WiFi from v0.7b3 to v.8r1. IIRC, Brian told me that nothing changed in iFLY either - although I found a small bug with Flight Plan transfer that he's fixed for v9.5. I could see that bug causing a collision inside iFly. (Although I would think that you would get the collision on your public hotspot too.)

So unless iFly v9.5 fixes the problem, it looks like this might be a subtle issue with the latest version of Stratux.

[Nokomis449]

Today and yesterday's testing was done with just two Androids - a stock Galaxy S4 and stock LG VK810. My wife has repossessed her iPad, and the iFly 740 was not used in these tests. No additional firewalls or such added by me. I tried sending one direction with no success, rebooted the Androids and Stratux, and tried sending the other direction with no success. Immediately tried with my handy travel router, a TP-LINK TL-MR3040 with success. Plus, the Androids share plans between each other as expected on multiple other WiFi networks. And to be clear, I haven't used a "public" hotspot, just my private, WPA2-secured hotspots available on each device. Stratux acts as if it has "AP Isolation" ON, but I don't know yet how to verify that until I can ask The Google.

[Ergonomicmike]

I suppose that I should make a new image of v0.7b1 and bring it up to v0.8r1 without my trick stuff to see if I can xfer FP's w/ that. Then you and I should be apples to apples.

[Nokomis449]

No, I kept my 7.3 image and flashed a brand new 8.1 image to a new 8Gb card as downloaded (no further updates via .sh). That should be all you need to do. You can also back up your trick image so you can restore it after testing.

[Ergonomicmike]

@Nokomis449 I didn't see your latest comment til just now.

I imaged back to v0.7b1 and then .sh'd to v0.8r1. iFly Flight Plan transfer works.

So maybe it's something about the v0.8r1 image? (I thought I recalled someone else noticing a distinction between doing the .sh to v0.8r1 and doing the image. (Although there shouldn't be any difference.))

Guess I'll do that next. Give me twenty minutes. (It's a Class 4 card. Takes a while to write to.)

[Nokomis449]

Thanks for birddogging this. "The Google" isn't being helpful today; maybe your tests will give me a direction to go.

[Ergonomicmike]

@cyoung @Nokomis449 Okay, Jeff, you're not crazy. (Well, you might be crazy. But not about this.)

Confirmed that when you use the v0.8r1 image, iFly will not transfer Flight Plan. Whereas updating from v0.7b1 and .sh'ing to v8r1 works fine. Points to something wrong with the spindle thingie that makes the images?

Also @ScraboTower had a similar problem with WingX. https://github.com/cyoung/stratux/issues/316

[Ergonomicmike]

Perhaps this issue should be renamed to something like "WiFi issue with v0.8r1 image"?

[Ergonomicmike]

This change was made a day before the image.

Wi-Fi Watcher Script. Don't know why it would change things. (Update: Multicast is mentioned.)

https://github.com/cyoung/stratux/commit/857b71b71686d254718bf4893b098931b3b7437d

[Nokomis449]

"I'm not crazy; my mother had me tested!".

[quickly glues hair back on]

If I have time tonight I'll reimage and .sh like you did and see if it works. Thanks for the sanity check.

[cyoung]

Looks like it could have been an issue with spindle, will investigate what is different (minus gen_gdl90 and the usual changes) between v0.7b1 image and v0.8r1 image.

Spindle is going away soon, anyways - but will use this as an opportunity to double check my work in the transition.

[Ergonomicmike]

FWIW, I looked at the raw code for the image and the .sh. They look the same to me. I'm going to guess that the the image is working as written (albeit wrongly), and that something is persisting in a working Stratux despite the .sh update.

[Nokomis449]

I flashed a card with 7.1 and updated via .sh to 8.1. Flight plans still will not share between Androids. Switching both androids to the home network, they share without fail. :(

[ghost]

SWAG -- default route was removed from the dhcpd.conf at v0.5b1.

Just for testing, what would happen if you added option routers 192.168.10.1;?

[Nokomis449]

I had to look up SWAG -

https://en.m.wikipedia.org/wiki/Scientific_wild-ass_guess

I'll have to try that tomorrow as the warden has just turned out the lights.

[Ergonomicmike]

I just updated the v0.8r1 image (the one that did not transfer flight plans earlier today) with the cd97.sh update (dated March 16). iFly transfer works now on that. (Update: No trick kernel or hostapd on the imaged one.)

Jeff, by any chance, did you put that off brand Wi-Fi dongle back in your Stratux? (The one with the Green Light?)

[Ergonomicmike]

@Nokomis449 I just .sh'd to the 2nd March 16 beta update. (In this last one, Chris took out some stuff about Multicast.) Both updates allow me to transfer flight plans. (Although on the second one this morning, there was about a 15 second delay on the first invitation. Don't know if that was iFly thinking about something or the latest changes in Stratux.)

[Nokomis449]

What's the link to these beta .sh's? I can't seem to find them. I've tried the "option routers" line as AvSquirrel suggested with no luck. Even changed the option routers address to 0.0.0.0 because that's what was in the early builds, but no joy. Tried copying all the lines From the old dhcp.conf, but nothing would allow flight plan sharing. Flying tomorrow, so tonight is my last chance to test/fix it. Not that it's a BIG deal, I can always switch the 3 devices to the SkyRadar network and share the plan, but I'm trying to ween myself from the SkyRadar. Oh, and I'm still using the blue EdiMAX WiFi dongle. The green one is a TP-Link; perhaps I should try it again...

[Ergonomicmike]

@Nokomis449 The latest betas (I've been calling them alphas, but now I see what Chris is doing (there will no longer be numbered beta releases like we've gotten used to seeing)) are at http://updates.stratux.me/builds/

[skypuppy]

Could someone explain the release policies of the moment, please? I assume the "production release" is the full image downloadable from "stratux.me, download."

Previously, we've had:

0. full image download from reddit,
1. get development (alpha/beta) download from github,
2. updates.stratux.me/builds,
3. various pulls from github,
4. I'm sure I've missed/forgotten others.

I'm getting lost in the forest. Please tell me what the current procedures are.

Thanks, Skypuppy (I don't understand all of git yet, either.)

On 03/16/2016 04:16 PM, Ergonomicmike wrote:

@Nokomis449 https://github.com/Nokomis449 The latest betas (I've been calling them alphas, but now I see what Chris is doing (there will no longer be numbered beta releases like we've gotten used to seeing)) are at http://updates.stratux.me/builds/

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/331#issuecomment-197552420

[cyoung]

Ok, did you reboot stratux after each one of these changes?

On Wednesday, March 16, 2016, Nokomis449 notifications@github.com wrote:

What's the link to these beta .sh's? I can't seem to find them. I've tried the "option routers" line as AvSquirrel suggested with no luck. Even changed the option routers address to 0.0.0.0 because that's what was in the early builds, but no joy. Tried copying all the lines From the old dhcp.conf, but nothing would allow flight plan sharing. Flying tomorrow, so tonight is my last chance to test/fix it. Not that it's a BIG deal, I can always switch the 3 devices to the SkyRadar network and share the plan, but I'm trying to ween myself from the SkyRadar. Oh, and I'm still using the blue EdiMAX WiFi dongle. The green one is a TP-Link; perhaps I should try it again...

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/331#issuecomment-197524337

[Ergonomicmike]

@Nokomis449 Since this is a potential bug issue, please stay w/ the Edimax for now. (Since it's the recommended hardware.)

To review, I was able to reproduce your issue when I imaged v0.8r1 directly. But after .sh'ing the image to either one of the March 16 update betas, the problem went away. Since you've been trying different fixes on your version, I suggest re-imaging to v0.8r1 and then updating to the latest .sh after that.

[Nokomis449]

Yes, Stratux was rebooted after every change and the Androids were rebooted after most changes.

Wanna hear the wierd part? I get home and swap the Wifi's, putting the TP-Link dongle in the Stratux, and guess what... FLIGHT PLAN SHARING.

So just to make sure it wasn't a fluke, I swapped 'em back and NO FLIGHT PLAN SHARING.

Here's the tail of the dhcp.conf:

subnet 192.168.10.0 netmask 255.255.255.0 { range 192.168.10.10 192.168.10.50; option broadcast-address 192.168.10.255; option routers 0.0.0.0; default-lease-time 12000; max-lease-time 12000;

option domain-name "stratux.local";

option domain-name-servers 4.2.2.2;

}

I'm about to reimage to 8.1 and .sh to the latest and I'll report back.

[Nokomis449]

Whoa, don't know what happened there - those last two lines are supposed to be normal text, but commented out with a pound sign.

[Ergonomicmike]

I wonder if some of us have buggy Edimax's and/or if old RPi2 users who have any problems should switch to the TP-Link? Supposed to be the same as the Edimax? Is this the part you have? http://www.amazon.com/TP-LINK-TL-WN725N-Wireless-Adapter-150Mbps/dp/B008IFXQFU/ref=sr_1_1?ie=UTF8&qid=1458183502&sr=8-1&keywords=tplink+usb

[Nokomis449]

I wouldn't do anything drastic just yet. Yep, that's the same model number as my TP-Link; but mines a few years old.

So I've re-imaged and .sh'd to the latest - ...66288. Sharing did NOT work with EdiMAX, but DID work with TP-Link. So maybe my EdiMAX has been bumped one too many times... so I opened up a brand new, never-used EdiMAX from its package and ... and... and... NO flightplan sharing.

But Ergo, you say yours is working? I'm befuddled. And we're flying to Dallas tomorrow, so I need to have a fairly stable system for the trip. I guess I'll keep the TP-Link in the Stratux for the time being.

[Ergonomicmike]

Yep, FP sharing is working for me now over the Stratux network. Dallas is just a bit too far for me, else I would be tempted to fly out to experiment. (I'm running a BU-353. IIRC, you're running a RY?)

BTW, a reviewer on Amazon says that there was a chipset change in the TP and it's no longer compatible out of the box with Linux.

Anyway the fact that the TP works for you is a clue - although no idea what it's telling us.

[Nokomis449]

I shelved the RY until AHRS is working. I'm currently using a VK-172.

[Ergonomicmike]

Our GPS's seem to be the only differences then. I'm finding on Chris's jessietest, that my BU-353 is affecting Wi-Fi. So after your trip, you could put the Edimax back in, disconnect the VK and see if you can share Flight Plans.

[Nokomis449]

I'll try that, but my VK as well as the 2 SDR's are outside the box on USB extensions; the Wifi is the only dongle plugged directly into the Pi. It's a new thing I'm trying where I can velcro the box under the panel and have the SDR's in cooler air and also put the antennas & VK in the window. I'm taking a 2nd setup with me that'll have every dongle plugged into the Pi, with an EdiMAX. You know, in case I get bored and want to run 2 Stratux's and a SkyRadar.

[Ergonomicmike]

It's not always cooler under the panel - not when we're running cabin heat that keeps our toes warm.

[skypuppy]

Ah, maybe you gave a clue there, Nokomis449. Back when I first started playing with stratux I had to radios (still the same two today, so far) that worked fine via a powered hub. I wanted to arrange things differently so I put both of them on a USB cable extender. Guess what?
Neither one of them worked. Took them off, plugged them directly into the Pi, and both worked just fine. Maybe some (all?) of the USB extender cables give us trouble with the radios? I never gave them another thought after that until I read your post. Mine are simply too big to have them both and the wifi dongle plugged directly into the back of the Pi. Maybe the new ones won't have that problem, and neither should the -3 since it has built-in wifi.

Skypuppy

On 03/17/2016 12:12 AM, Nokomis449 wrote:

I'll try that, but my VK as well as the 2 SDR's are outside the box on USB extensions; the Wifi is the only dongle plugged directly into the Pi. It's a new thing I'm trying where I can velcro the box under the panel and have the SDR's in cooler air and also put the antennas & VK in the window. I'm taking a 2nd setup with me that'll have every dongle plugged into the Pi, with an EdiMAX. You know, in case I get bored and want to run 2 Stratux's and a SkyRadar.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/331#issuecomment-197705573

[ghost]

Crossposting from reddit...

I ran into stability problems with the Jessie test build on my Pi 2 model B when I plugged in a second SDR. One of the SDR LEDs blinked out momentarily, the blue light briefly died on the Edimax, and my VK-172 went AWOL.

Way back when @cyoung first added dual SDR support, we had a similar problem. The hub on the Pi is limited to 600 mA output, unless max_usb_current=1 added to /boot/config.txt. That doubles the total current limit to 1.2 A, shared between all four ports.

The Jessie test didn't have that line. I added it, rebooted, and am up and running #340 with dual SDRs and the VK-172.

[Ergonomicmike]

@AvSquirrel @cyoung Also cross posting from reddit.

The max_usb_current fixed the non-working SDR's on the jessietest. I also added the lines to enable i2c and now AHRS works. (Question: enable i2c or i2c1? And still 40000 baud?)

[skypuppy]

on the Pi, it's i2c1. One can see that by "i2cdetect -y 1" and if you try -y 0 or -y 2, it will complain. I think i2c1 is the only one we can get to, by design.

Standard i2c speed is 100,000 bits per second. High speed is 400,000 bps. I think the default for the Pi is 100k and with only one or 2 devices that is plenty for your needs.

On 03/17/2016 02:00 AM, Ergonomicmike wrote:

@AvSquirrel https://github.com/AvSquirrel @cyoung https://github.com/cyoung Also cross posting from reddit.

The max_usb_current fixed the non-working SDR's on the jessietest. I also added the lines to enable i2c and now AHRS works. (Question: enable i2c or i2c1? And still 40000 baud?)

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/331#issuecomment-197733328

[dbhorvath]

@skypuppy I'm reading up on I2C and SPI. Apparently the -y is for RPi versions (since the ports switched up over time).

[cyoung]

The "-y" option is to specify the I2C bus that you want to use. On RPi2/RPi3, it's always "1".

@Ergonomicmike - here are the lines that should be at the end of /boot/config.txt.

max_usb_current=1
dtparam=i2c1=on
dtparam=i2c1_baudrate=400000
dtparam=i2c_arm_baudrate=400000

That the first two i2c lines are "i2c1" settings and the last an "i2c" setting is correct.

[cyoung]

@Nokomis449 - did sharing work alright on your trip? What's your latest testing config? Still unclear on if this is a confirmed/reproducible bug or not.