| Wizzup | freemangordon: the only thing I can do is enable them, start the scan, and disable them immediately | 00:02 |
|---|---|---|
| Wizzup | freemangordon: https://w1.fi/cgit/hostap/tree/wpa_supplicant/scan.c#n1519 | 00:05 |
| inky | uvos: i think it is enough to follow the keyboard. if the keyboard changed to english, then setxkbmap "us", if the keyboard changed to armenian, then setxkbmap "us, am". | 00:13 |
| inky | let me explain why. if the vkbd is russian, you need to do setxkbmap "ru, us" because ru also contains dot, comma, etc from the ascii segment. | 00:13 |
| inky | by the way, armenian layout has own dot symbol, but shares the comma. (: so still, as the general rule | 00:14 |
| inky | it is better to activate two layouts - us and something. | 00:14 |
| joerg | weird, buzz spamming #libera with a surefire-kline ascii art :-o | 00:17 |
| Wizzup | freemangordon: ok, I think I have a hack | 00:25 |
| Wizzup | freemangordon: so if we 'disconnect' the interface (we don't need to do it if we are already connected), then wpa_supplicant will not auto connect | 00:26 |
| Wizzup | because the reassociate key is set to 0 | 00:26 |
| Wizzup | so then we can scan properly for hidden ssids | 00:26 |
| Wizzup | but then select_network will set reassociate back to 1, so if we get dropped from the AP, we need to set disconnect before scanning | 00:27 |
| lel | informer2016 opened an issue: https://github.com/maemo-leste/eg25-manager/issues/1 (EG25-G GB - official SDK and many helpful files) | 00:28 |
| Wizzup | uvos: if you have time this weekend, I can try to make clownboot work | 00:30 |
| inky | uvos: ah know this is a problem, setxkbmap cannot, i guess, accept both us and am simultaneously. | 00:47 |
| inky | it has switch to accept one or the other. | 00:47 |
| inky | so then depending on the utf-8 keycode it has to choose hardcoded range. | 00:48 |
| inky | hm. | 00:48 |
| inky | not keycode, utf-8 code. | 00:48 |
| inky | but that's possible, because we know all the utf-8 symbols that are used in the vkbs. | 00:49 |
| Wizzup | freemangordon: ok, this works | 00:50 |
| Wizzup | I'll clean it up tomorrow | 00:50 |
| inky | uvos i found it https://github.com/maemo-leste/hildon-input-method-plugins/blob/master/hildon-im-virtual-keyboard-layouts/hy_AM.xml but it does not help us. | 00:55 |
| Wizzup | ok, except that the dbus interface for wpa supplicant doesn't do the same on fi.w1.wpa_supplicant1.Interface.Disconnect compared to 'disconnect' on the ctrl interface | 00:57 |
| Wizzup | ...... | 00:57 |
| Wizzup | so then I would have to *also* connect to the wpa_supplicant control interface | 00:59 |
| Wizzup | freemangordon: https://github.com/maemo-leste/bugtracker/issues/489#issuecomment-850713508 | 01:05 |
| * Wizzup wondering if we can make ofono and asterisk play nice somehow | 01:39 | |
| Wizzup | or maybe they just complement each other | 01:39 |
| Wizzup | gn | 01:39 |
| tmlind | mighty: i'd use the known working android mux setting, not sure what the difference. see also the gpio-hog for msecure-hog in arch/arm/boot/dts/omap5-board-common.dtsi, maybe something similar works for you too | 06:48 |
| tmlind | mighty: i think you just want to keep msecure high for twl access, so muxing it into gpio mode and using a gpio hog should do it | 06:53 |
| freemangordon | Wizzup: nice, just LMK why it doesn't work through the wizard when it comes to it | 06:58 |
| freemangordon | ah, wlancond interface I guess | 07:28 |
| freemangordon | Wizzup: do you remember/have any clue why we decided to drop osso-wlan (wlancond)? https://github.com/community-ssu/osso-wlan | 07:51 |
| freemangordon | It is weird we did it like that, given that wpa_supplicant replaces eapd | 07:56 |
| freemangordon | maybe we shall reconsider | 07:56 |
| freemangordon | keep in mind we lack support for WPS too ATM | 07:56 |
| parazyd | freemangordon: WPS is fundamentally broken and unsafe btw. | 08:47 |
| parazyd | Haven't seen it deployed in a long time. | 08:48 |
| freemangordon | so, we shall not support that? | 08:49 |
| Danct12 | for some reason the technician guys from the isp still uses wps | 08:50 |
| parazyd | I wouldn't really. | 08:50 |
| Danct12 | so usually when they're done replacing my router i just turn it off | 08:50 |
| freemangordon | afk, ttyl | 08:50 |
| parazyd | Nowadays script kiddies use reaver and pixiewps to screw up routers that have it enabled | 08:51 |
| parazyd | ttyl | 08:51 |
| Danct12 | right, ttyl 2 | 08:52 |
| parazyd | freemangordon: (for later), Did osso-wlan also do hostap? | 08:52 |
| Danct12 | one last thing, is there a list of things that needs to be TODO? | 08:52 |
| Danct12 | i'd like to have screenshooting as a feature | 08:53 |
| parazyd | In case no, it might also be interesting to look forward, rather than backwards: https://wiki.archlinux.org/title/Iwd | 08:53 |
| parazyd | Danct12: https://github.com/maemo-leste/bugtracker/issues/ | 08:54 |
| parazyd | This really | 08:54 |
| tvall | wps was wonderful the last time i lived in an apartment. reaver is so much quicker than brute forcing handshakes | 08:57 |
| tvall | would never let it anywhere near a network i run | 08:58 |
| parazyd | Yeah I also used it in a clutch when I needed Internet access but no open networks :D | 09:01 |
| Danct12 | what did you need for internet access at that moment? | 09:04 |
| Danct12 | updating the system? :P | 09:04 |
| parazyd | Well, I wanted to use it, but didn't have a connection at home at that time | 09:05 |
| parazyd | I had this 1W device and a yagi https://www.alfa.com.tw/products/awus036h | 09:06 |
| Danct12 | i heard alfa made really high quality stuffs, i had a few friends who had one | 09:10 |
| parazyd | Yeah | 09:10 |
| sicelo | parazyd: no, wlancond didn't do hostapd | 10:01 |
| sicelo | Anyway, n900 wifi card/driver doesn't do ap mode at all. Any hotspot applications that existed were doing adhoc network | 10:02 |
| parazyd | freemangordon: I have a WIP patch for hildon-input-method-framework gtk3: http://sprunge.us/KRcRJ3 | 10:05 |
| parazyd | freemangordon: Could you try having a look at the remaining compiler errors? | 10:05 |
| parazyd | freemangordon: There is also a dependency on https://maemo.org/api_refs/5.0/5.0-final/gtk/GtkIMContext.html#hildon-gtk-im-context-show | 10:05 |
| sicelo | screen shooting means screen recording? Or screenshot? | 10:29 |
| freemangordon | parazyd: can't open the link | 11:14 |
| parazyd | freemangordon: Which? | 12:18 |
| parazyd | You can curl/wget http://sprunge.us/KRcRJ3 | 12:19 |
| mighty | `<6>[ 0.269683] twl6030: PIH (irq 39) chaining IRQs 368..387` downstream and `twl 0-0048: PIH (irq 146) nested IRQs` mainline | 12:19 |
| mighty | this is sus right? | 12:19 |
| mighty | tmlind yeah something like the gpio hog should work lets try | 12:26 |
| Wizzup | freemangordon: I think wpa_supplicant implements both wlancond and eapd | 12:28 |
| Wizzup | parazyd: wlancond does not do hostapd, we don't need it | 12:29 |
| parazyd | (y) | 12:31 |
| freemangordon | parazyd: I get 404 | 12:31 |
| freemangordon | in the browser that is | 12:31 |
| parazyd | freemangordon: I pushed here: https://github.com/maemo-leste/hildon-input-method-framework/tree/gtk3 | 12:31 |
| parazyd | Unsure, it loads fine here | 12:31 |
| parazyd | Anyway, it's in this gtk3 branch now | 12:31 |
| freemangordon | ok | 12:31 |
| mighty | but i cant understand how omap5 has done it ie what is p234 | 12:33 |
| mighty | also only this is needed right https://github.com/torvalds/linux/commit/af756bbccff85504ce05c63a50f80b9d7823c500#diff-49bb9f3d1c5e2d002c2e7cfc17c39443c007e2dbd32a0d5282934f24f9b02c68R133-R142 | 12:33 |
| freemangordon | Wizzup: not sure, I think it is only eapd that's implemented, but won't argue much | 12:33 |
| Wizzup | freemangordon: wpa supplicant does everything on the wireless side, I can't imagine what wlancond did | 12:34 |
| Wizzup | (not arguing btw :p) | 12:34 |
| freemangordon | because, from what I understand, wlancond implements what icd2 plugin requires in terms of caching and stuff like hidden wlan and wps and adhoc | 12:35 |
| freemangordon | IIUC it is a kind of a proxy | 12:35 |
| Wizzup | wpa_supplicant caches Bss info | 12:35 |
| Wizzup | I don't know much about icd2 caching though | 12:36 |
| Wizzup | but wpa_supplicant is also a 'proxy' in many ways, you can do some of the same things with a lower level interface, but then you rely on (sometimes) buggy kernel drivers, etc | 12:36 |
| freemangordon | what about hidden wlan support? how we're going to implement this https://github.com/maemo-leste/connui-internet/blob/master/src/settings/easy-wlan.c#L936? | 12:36 |
| Wizzup | by implementing another dbus interface | 12:36 |
| Wizzup | s/implementing/reading/ | 12:36 |
| freemangordon | any hint which one? | 12:37 |
| freemangordon | as I am going to implement it as soon as I know how :) | 12:37 |
| Wizzup | See fi.w1.wpa_supplicant1.Interface.Scan | 12:37 |
| Wizzup | SSIDsaayArray of SSIDs to scan for (applies only if scan type is active)No | 12:37 |
| freemangordon | but, you said this shall be called after 'disconnect', no? | 12:37 |
| Wizzup | It might interact with our icd2 module, but I can maybe work around that | 12:37 |
| freemangordon | exactly | 12:38 |
| Wizzup | not in that way | 12:38 |
| freemangordon | this is my point about wlancond acting as a proxy | 12:38 |
| Wizzup | the disconnect is not relevant, the icd2 module can handle that | 12:38 |
| Wizzup | I am providing you the replacement dbus code, I would write the easy wlan stuff differently I think | 12:38 |
| Wizzup | I think all you need it already in the IAP data that gets created from icd2 | 12:38 |
| freemangordon | ok, lets not discuss that now as I have to go. Will think about it a bit more, please, you do too. | 12:38 |
| Wizzup | ok | 12:39 |
| freemangordon | bbl | 12:39 |
| Wizzup | hi | 12:42 |
| * ^-^hi | 12:43 | |
| ^-^hi | Wizzup: if you have implemented and tested the battery use improvements on n900, why don't you incorporate them? | 12:44 |
| Wizzup | ^-^hi: sorry, what exactly are you talking about? Got a link/reference? | 12:45 |
| sicelo | I suppose he means the tweet about N900 doing off mode | 12:46 |
| Wizzup | sicelo: I realised, but I'd like context :) | 12:46 |
| ^-^hi | you sent a tweet somewhere saying that n900 battery now lasts much longer. i come every few months and ask if the battery use improvements are already included and hear no. | 12:47 |
| Wizzup | ^-^hi: I see, ok | 12:51 |
| ^-^hi | is it included already? | 12:51 |
| Wizzup | ^-^hi: so the answer is that it's not just a question of 'merging in some code', it's a decent amount of research work, let me explain | 12:51 |
| Wizzup | Our current Linux on the N900 is 5.1 with some patches, some of our own, some powervr patches, for omapfb and powervr. The tweet was plain mainline (5.8 or so?) with no maemo leste loaded - minimal userspace, showing that it is possible to enter those idle/off modes | 12:52 |
| Wizzup | What needs to be done to get it all in place and merged is: (1) move from kernel 5.1 to a newer/latest kernel - this is being blocked by some of us not knowing how to port to 5.2 and forward due to some kernel change | 12:52 |
| Wizzup | (2) is then loading up minimal userspace, hitting off mode with the powervr driver loaded but not used, and then booting maemo bits one at a time, and see what can prevent OFF mode from being hit | 12:53 |
| Wizzup | (3) making n900 on maemo play nice with off mode once (1) and (2) are done | 12:53 |
| Wizzup | We're not doing (1) at the moment because we want to switch to another, newer, powervr userspace + kernel driver so that we're using the same one on all devices, but that driver needs some more work to get X11 going with hildon-desktop | 12:54 |
| Wizzup | If we can get the new driver working, we can skip (1) outright, and since we want to do that anyway, it's better to aim for the newer driver rather than having to redo the work we just did to begin with | 12:54 |
| Wizzup | A shortcut to start on (2) and (3) is to load the latest kernel without powervr on the n900 and start working on OFF mode, without 3d acceleration, this can be useful, but it won't result in a useful phone until it's once again equipped with the 3d driver | 12:55 |
| Wizzup | One other shortcut is that maybe it is possible to try to hit off mode on kernel 5.1, but if we can't, we cannot report bugs since everyone (rightfully so) will tell us: does it work with latest kernel? as first question | 12:56 |
| Wizzup | Hope this clarifies it a bit, please let me know if you have more questions | 12:57 |
| ^-^hi | any way to run new software on fremantle without compiling everything and its dependencies? | 12:58 |
| * ^-^hi 's English is degrading | 13:00 | |
| Wizzup | If you fremantle you mean the ancient kernel and ancient userspace, then likely only chroot will be easy, but even that will likely have trouble with really old kernel | 13:01 |
| sicelo | Not really enough useful ways for that. | 13:01 |
| ^-^hi | didn't linux have a policy of "don't break userspace"? | 13:02 |
| Wizzup | Maybe if you also go for arm eabi, and use the space x11 driver ported to latest xorg server and using eabi in the chroot, you could get something going, but that by itself is probably more effort than the work required to get decent PM on leste | 13:02 |
| sicelo | ^-^hi: if you want to help with the off mode issue (and get some use out of the device in the meantime), maybe look at running plain devuan with i3 or similar light UI (no 3d required). Should make it easier to play with kernel, and still use device to some extent | 13:04 |
| ^-^hi | i know C but don't know anything about kernel and such stuff | 13:05 |
| sicelo | If you know C, you're already halfway :-) | 13:05 |
| sicelo | I don't know C, but already 'fixed' something for the LED driver ... so you should do even better. Also, the PM stuff doesn't necessarily need you to do actual dev. Testing, reporting, testing some more, etc. is still a good start | 13:07 |
| Wizzup | sicelo: I'm not sure if that helps that much (with i3), it's mostly kernel stuff really | 13:07 |
| Wizzup | Don't mean to discourage, but I think if folks want to contribute without the powervr stuff, then picking the last path I outlined is helpful: latest mainline linux without powervr, and making things play nice then | 13:08 |
| Wizzup | you could do that with i3, but might as well do it with maemo tbh | 13:08 |
| Wizzup | freemangordon: these bits should allow just reading the iap network attrs without extra dbus calls already iiuc: https://github.com/maemo-leste/libicd-network-wpasupplicant/blob/master/src/wpaicd.c#L611 | 13:11 |
| Wizzup | freemangordon: seems like I already implemented the wlancond caps in icd2 since it's part of the api :) | 13:12 |
| Wizzup | freemangordon: and src/wlan.c's wlan_search_network_added_cb uses network_attrs = wpaicd_bssinfo_to_network_attrs(info); | 13:13 |
| Wizzup | so at least icd2 is already perfectly aware of this | 13:13 |
| Wizzup | so if you can get access to the IAP you need to connect to for the hidden wlan, you can already know the capabilities and the entire scan is redundant | 13:14 |
| Wizzup | freemangordon: so this can just go away and be replaced with reading icd2 network attrs https://github.com/maemo-leste/connui-internet/blob/master/src/settings/easy-wlan.c#L429 | 13:14 |
| Wizzup | also it looks like there is cap2nwattr | 13:15 |
| Wizzup | no clue where it comes from, though | 13:16 |
| freemangordon | Wizzup: but how do we match a hidden wlan to the SSID just entered? | 14:27 |
| freemangordon | but yeah, might be possible, will check leater on | 14:28 |
| Wizzup | freemangordon: with the ssid that someone fills in | 14:54 |
| Wizzup | freemangordon: oh, I see, how do we known which of the hidden ssids it might be | 14:54 |
| Wizzup | freemangordon: in that case we can just have it trigger a scan via icd2, and get the info that way? | 14:56 |
| Wizzup | it does sometimes take one or two scans to fully pick the ap up though | 14:56 |
| Wizzup | honestly if it was me I'd make people do it through the settings ;-) | 14:56 |
| Wizzup | freemangordon: hm, I think we would know what hidden ssid it is, since someone would pick it from the UI | 16:23 |
| Wizzup | freemangordon: but all of the would just say 'Hidden WiFi' | 16:23 |
| Wizzup | the whole idea behind hidden APs is so broken | 16:23 |
| Wizzup | parazyd: re: him gtk3 | 16:27 |
| Wizzup | gtk HildonGtkInputMode could perhaps be replaced with https://developer.gnome.org/gtk3/stable/GtkEntry.html GtkInputPurpose | 16:27 |
| Wizzup | parazyd: various things there do depend on gtk2 patches like the filter_event | 16:38 |
| Wizzup | in GtkIMContextClass | 16:38 |
| Wizzup | debian/patches/hildonize-gtk-imcontext.diff is particularly relevant | 16:39 |
| Wizzup | parazyd: so this would go into our gtk3 patch set I think | 16:43 |
| Wizzup | The hildongtkinputmodes we can maybe base on the GtkInputPurpose enums as listed above | 16:44 |
| Wizzup | but the other stuff requires more significant changes | 16:44 |
| Wizzup | We can look at dropping it maybe, but it seems quite relevant | 16:45 |
| parazyd | ftr | 17:10 |
| parazyd | 15:43 <parazyd> I'm not sure what exactly hildonize-im-context.patch really does, but if the idea was: "hide the input method on focus change or on windowing system state change", then it should not be necessary | 17:10 |
| parazyd | 15:43 <parazyd> Widgets should do that | 17:11 |
| freemangordon | Wizzup: I'll debug to see what exactly data we have in connui dialogs | 17:56 |
| Wizzup | freemangordon: ok | 17:59 |
| Wizzup | parazyd: I don't think it was about focus tracking | 17:59 |
| Wizzup | parazyd: it is a way to force-raise the IM it looks like | 17:59 |
| freemangordon | Wizzup: it seems we have some caps, whether they are correct is another story | 18:04 |
| Wizzup | freemangordon: they should be I think | 18:04 |
| Wizzup | freemangordon: if they are not please let me know | 18:04 |
| Wizzup | freemangordon: we render them in the UI based on those caps (the lock, etc) | 18:04 |
| freemangordon | ok, will just comment trhe code that scans and will se how it will pan out | 18:04 |
| freemangordon | *the | 18:04 |
| Wizzup | ok, I need to push some code from my side as well but I don't have the control interface part yet | 18:06 |
| freemangordon | Wizzup: hmm, won;t work, because you may have more than one hidden wifi around, and in the menu only one entry seems to be shown | 18:13 |
| freemangordon | which is the case here | 18:13 |
| Wizzup | freemangordon: I don't know how that can ever be made sensible UX tbh | 18:14 |
| freemangordon | I guess that's why Nokia did it like that - no matter how many hidden nets you have around, only one entry is shown. Once you click it, you enter ssid and caps for that ssid are retreived | 18:15 |
| freemangordon | or, we can group in the UI by caps | 18:16 |
| freemangordon | hmm, no, not a good idea | 18:17 |
| Wizzup | can't people use the cpa? | 18:17 |
| Wizzup | (serious question) | 18:17 |
| freemangordon | Wizzup: the more I think, the more I agree with how nokia did implement it | 18:17 |
| Wizzup | it seems to be a better way to implement it | 18:17 |
| freemangordon | status menu is way more intuitive | 18:18 |
| freemangordon | also, we know how to do it, well, lets do it then | 18:18 |
| freemangordon | Wizzup: you may expose dbus interface from wpa plugin to be called by the dialog to get the caps | 18:19 |
| Wizzup | freemangordon: I need to check if wpa_supplicant can scan for ssid without proving key_mgmt | 18:19 |
| freemangordon | not sure what you mean, but ok | 18:20 |
| Wizzup | but if it does, I suggest that you use icd2 dbus api to just issue another scan and then wait | 18:20 |
| Wizzup | you can add a 'temporary' IAP and scan | 18:20 |
| Wizzup | no need for more dbus apis iiuc | 18:20 |
| freemangordon | I think at that point we already have temporary iap | 18:20 |
| freemangordon | we just need its caps so UI to know which dialogs to show | 18:21 |
| Wizzup | then just issue another icd2 scan, as when I push my code the thing should show up upon rescan if it's present as temporary | 18:21 |
| freemangordon | hidden wlans are not shown unless you add them | 18:22 |
| freemangordon | you == wpa plugin | 18:23 |
| Wizzup | freemangordon: yes, the new code does that (local) | 18:23 |
| Wizzup | I already connected to hidden wlan at home | 18:23 |
| Wizzup | and it shows up in the scan dialog | 18:23 |
| Wizzup | I just need to add the control interface and send "DISCONNECT" at the right time | 18:23 |
| freemangordon | but how to issue another scan from the UI? | 18:23 |
| freemangordon | I don't think that is going to work, not reliably | 18:24 |
| Wizzup | How does it do the first one? ;) | 18:24 |
| freemangordon | doesn;t matter, we are already in a different state | 18:24 |
| freemangordon | also, I am not sure icd2 will reissue a scan before the cache is expired | 18:25 |
| freemangordon | so that would mean that we will have cache expiry timeout+scan time for the new entry to appear | 18:25 |
| freemangordon | more that 30 seconds, which is very bad UX imo | 18:26 |
| freemangordon | not to say that you have to now that you have to search for the SSID you have just entered in the list and click it | 18:27 |
| freemangordon | *know | 18:27 |
| Wizzup | a new ssid showing up doesn't matter to the cache | 18:27 |
| Wizzup | afaik | 18:27 |
| freemangordon | afaik, no new scan to the plugin is issued while the cache is still valid | 18:28 |
| freemangordon | so plugin won;t have the chance to update the list with that temporary iap, if we assume it is created | 18:29 |
| Wizzup | freemangordon: maybe allow cache to be invalidated rather than new api? | 18:34 |
| freemangordon | Wizzup: why you don't like the idea? | 18:34 |
| freemangordon | also, how exactly is UI supposed to invalidate icd2 cache? | 18:35 |
| Wizzup | freemangordon: I am not sure if I don't like it, but adding more interfaces when we already have interfaces to (1) add a network to that is is scanned (2) issue another scan seems unnecessary | 18:35 |
| Wizzup | s/to that is/so that it/ | 18:35 |
| freemangordon | but, we don;t really want another full scan, no? | 18:36 |
| freemangordon | we just want details for a single SSID | 18:36 |
| Wizzup | that's still a scan | 18:36 |
| freemangordon | yes, but not full | 18:36 |
| freemangordon | btw, what is the problem to call wpa_supplicant? | 18:36 |
| freemangordon | do you think it will connect? | 18:37 |
| freemangordon | also, how it is going to connect without a key? | 18:37 |
| Wizzup | I don't think there is one, as long as the libicd-network-wpasupplicant's callbacks for scan results do not confuse icd2 | 18:37 |
| Wizzup | freemangordon: wait, why are we talking about connect? | 18:37 |
| Wizzup | freemangordon: oh, sorry | 18:37 |
| freemangordon | because you said (at least that's what I understood) is that issuing scan for ssid will also connect it | 18:38 |
| Wizzup | freemangordon: no, it should be fine to call wpa_supplicant | 18:38 |
| Wizzup | freemangordon: yes, but I found a workaround for that (with meridions help) | 18:38 |
| freemangordon | unless you call 'disconnect' | 18:38 |
| freemangordon | hmm? | 18:38 |
| Wizzup | I can try to describe it here, but if you didn't, can you read my post on the gh issue first? | 18:38 |
| freemangordon | what is the workaround | 18:38 |
| Wizzup | I tried to describe it well there | 18:38 |
| Wizzup | https://github.com/maemo-leste/bugtracker/issues/489#issuecomment-850713508 | 18:39 |
| Wizzup | so the tl;dr is we can prevent wpa_supplicant for from acting on it's own by: | 18:39 |
| Wizzup | (1) if we are not connected to any APs, call 'DISCONNECT' on the ctrl interface | 18:39 |
| Wizzup | (2) if we are connected to something else, we don't need to do anything | 18:39 |
| Wizzup | If we are not connected, calling 'DISCONNECT' just has the effect of setting the 'reassociate' variable in wpa_supplicant to 0 which means it will *not* try to connect on its own | 18:40 |
| Wizzup | so I think it's fine if the easy-wlan calls out to wpa_supplicant over dbus to do a scan of a single ssid, I will just need to teach the libicd-network-wpasupplicant code to deal properly with scans it did not initiate | 18:41 |
| freemangordon | and that's why we need a separate daemon to control that, because UI has no clue (or at least should not care) whether we are connected or not | 18:41 |
| Wizzup | freemangordon: easy-wlan will not need to issue 'DISCONNECT' | 18:41 |
| Wizzup | libicd-network-wpasupplicant will take care of all of that | 18:41 |
| freemangordon | sure? ok, then it is fine | 18:41 |
| Wizzup | yes | 18:41 |
| freemangordon | I have no issue to call wpa_supplicant from the UI | 18:41 |
| Wizzup | ok, then maybe that's the best solution | 18:41 |
| Wizzup | Should we split out wpaicd to some shared lib? | 18:42 |
| freemangordon | yes, this is what code currently does, albeit it calls wlancond and not wpa_supplicant :) | 18:42 |
| Wizzup | I have some more local code, but I'm currently at my parents place and already started on the wine, so I'm worried that if work too much on it now I'll create more work for myself tomorrow :p | 18:42 |
| freemangordon | no, connui has pretty much very good dbus support already | 18:42 |
| Wizzup | ok | 18:42 |
| freemangordon | Wizzup: take your time, I'll try to replace wlancond with wpa_supplicant calls | 18:43 |
| freemangordon | BTE, UI runs as user, is that a problem in regards to dbus security? | 18:43 |
| freemangordon | *BTW | 18:43 |
| Wizzup | I would have to check, good question | 18:44 |
| Wizzup | wpa_supplicant runs on system I think | 18:44 |
| freemangordon | also, tomorrow I'll be MIA the whole day, so you'll have plenty of time to implement whatever changes are needed in the plugin :p | 18:44 |
| freemangordon | maybe we shall check the dbus service | 18:44 |
| Wizzup | ok | 18:45 |
| Wizzup | I know what I need to implement from my side, and tomorrow morning I'll be home with the hidden ap again | 18:45 |
| freemangordon | great | 18:45 |
| Wizzup | I'll push all the code to make auto connect and configured-via-cpa to work | 18:45 |
| freemangordon | I'll try to finish UI part today | 18:45 |
| Wizzup | and then we can test the other code when you get back | 18:45 |
| freemangordon | mhm | 18:45 |
| freemangordon | deal | 18:45 |
| freemangordon | Wizzup: one more thing - which interface I shall use to issue the scan? | 18:48 |
| Wizzup | freemangordon: wlan0 currently, that's also the assumption in libicd-network-wpasupplicant | 18:48 |
| Wizzup | I imagine that eventually we want to get rid of that, but for now ... eh | 18:48 |
| freemangordon | I meant dbus, I guess it is fi.w1.wpa_supplicant1.Interface | 18:48 |
| Wizzup | https://w1.fi/wpa_supplicant/devel/dbus.html | 18:48 |
| Wizzup | https://w1.fi/wpa_supplicant/devel/dbus.html#dbus_interface | 18:49 |
| Wizzup | https://github.com/maemo-leste/libicd-network-wpasupplicant/blob/master/src/wpasupplicant-defs.h | 18:49 |
| freemangordon | thanks | 18:49 |
| freemangordon | Wizzup: hmm, it seems I shall issue more than one dbus call, right? "Scan" first then GetAll on BSS id, right? | 18:59 |
| Wizzup | freemangordon: yeah, you need to wait for it to complete | 19:02 |
| freemangordon | ok | 19:02 |
| Wizzup | but it;s async | 19:02 |
| Wizzup | https://github.com/maemo-leste/libicd-network-wpasupplicant/blob/master/src/wpaicd.c#L487 | 19:02 |
| freemangordon | I can issue sync dbus acll | 19:02 |
| freemangordon | *call | 19:02 |
| Wizzup | + https://github.com/maemo-leste/libicd-network-wpasupplicant/blob/master/src/wpaicd.c#L574 | 19:03 |
| Wizzup | well the signal is 'ScanDone | 19:03 |
| Wizzup | ' | 19:03 |
| freemangordon | current code does https://github.com/maemo-leste/connui-internet/blob/master/src/settings/easy-wlan.c#L986 | 19:05 |
| freemangordon | so this is already handled | 19:05 |
| freemangordon | anyways, dinner | 19:05 |
| freemangordon | ttyl | 19:05 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!