- Thu Aug 20, 2015 5:56 am
#26550
Well, HTTPS support is just not there, and it would be very hairy to implement it - the end user would basically always run into a certificate error because we basically need to impersonate the website they go to in order to redirect it to the local IP. I don't like to basically teach people to ignore certificate errors.
Moderator: Sprite_tm
- Thu Nov 12, 2015 10:36 am
#33786
I'm having the same issue but with an android device (HTC one M8 android 5.0.1 on verizon). Whenever I try to connect it will state successfully connected, but then immediately pulls up the landing page (the page I am redirecting everything to) but with bars on the top and bottom, top asks me to login and bottom is just a cancel button. If I hit cancel or try to navigate away from the "login" screen then it automatically disconnects from the AP. Would this be the same issue? Does anyone know what reply google phones would be looking for, would it be the same Success statement as the apple phones?
- Fri Dec 25, 2015 10:13 pm
#37139
I'm trying to get get the captive portal to work on both Android and Windows without success so far. Some debugging with Wireshark shows that the DNS response packets are always marked as invalid because the Ethernet FCS (Frame Check Sequence) is incorrect.
Not sure if this is part of the reason why the captive portal doesn't fire. I don't think I can change the FCS to fix this (maybe if I start using open lwip?). Is this behavior expected?
Not sure if this is part of the reason why the captive portal doesn't fire. I don't think I can change the FCS to fix this (maybe if I start using open lwip?). Is this behavior expected?
- Wed Dec 30, 2015 10:09 am
#37473
Which SDK do you use? It seems to only work as expected with 1.3.0 for me...
ToSa wrote:I'm trying to get get the captive portal to work on both Android and Windows without success so far. Some debugging with Wireshark shows that the DNS response packets are always marked as invalid because the Ethernet FCS (Frame Check Sequence) is incorrect.
Not sure if this is part of the reason why the captive portal doesn't fire. I don't think I can change the FCS to fix this (maybe if I start using open lwip?). Is this behavior expected?
Which SDK do you use? It seems to only work as expected with 1.3.0 for me...
