| onefang | What's the generally accepted replacement for wicd in Daedalus? My use case - I'm setting up my spare test computer to be portable, it's a tiny desktop that's made from laptop parts. So I'll need to connect to random free WiFi hotspots (mostly the city councils) as I wander around with this. Wicd was great for that sort of thing. | 03:39 |
|---|---|---|
| debdog | onefang: connman would be one option | 03:41 |
| * onefang installs it and tries it. | 03:42 | |
| fsmithred | I was using connman with two wireless networks in the house and it gave me a hard time about using the one I wanted to use. So I switched to network-manager. It's also possible to use wpa-gui. See https://www.devuan.org/os/documentation/install-guides/daedalus/network-configuration | 03:47 |
| * debdog puts wpa-gui on his list | 03:49 | |
| rwp | I have been using wpa-gui after the recommendations. It seems it works well, for other people. For me it's been somewhat problematic. | 05:14 |
| rwp | wpa-cli which is part of wpa-gui will start a second dhclient before killing the first dhclient resulting in two dhclients fighting over the interface. Each will start by bringing the interface down and resetting it and then DHCP'ing an address. At which point the other will do the same. Flip. Flop. Endlessly. | 05:14 |
| rwp | I moved dhclient to dhclient.real and put a wrapper in place of dhclient so I could debug what's starting the 2nd one and it is always wpa-cli starting the second one. And always when wpa-gui is actively running. If I kill those two off then wpa_supplicant handles everything okay. However... | 05:15 |
| rwp | For some reason wpa_supplicant in this configuration will not associate with a different access point. I think wpa-gui has used wpa-cli to instruct wpa_supplicant to use a particular access point only. And therefore when I suspend here and resume there it doesn't follow. | 05:16 |
| rwp | If I use wpa_supplicant just myself configuring and running it then wpa_supplicant automatically connects to new access points and reconnects as I relocate to a different one. | 05:17 |
| rwp | Which means that instead of "Just Working" it means I have to manually get in there and either fire up wpa-gui to tell it to connect, again, to the AP or I have to ifdown and then ifup wlan0 interface. Either of which is something it should have been able to do automatically and that which wpa_supplicant normally does automatically. | 05:18 |
| rwp | So I am thinking of returning to connman again and refreshing my memory of why I don't like it either. | 05:18 |
| rwp | In the meantime I now have my dhclient wrapper kill the previous running dhclient before starting a fresh one. I tried not doing it and that works too but takes dhclient to try to time to renew the lease first. So starting a new one causes the dhcp to happen now. | 05:20 |
| rwp | And I have resigned myself to the fast that when using wpa-gui it is a manual connect to the access point. It won't do it automatically for it. I have to tell it. Each and every time. | 05:21 |
| rrq | rwp: I thought 2 dhcp clients come up (only?) if there's a misconfiguration in /etc/network/interfaces | 05:33 |
| auto | rtk | 05:34 |
| rwp | rrq, What type of misconfiguration? Here is mine: https://paste.debian.net/plain/1331822 | 05:36 |
| rrq | hmm looks same as mine except that I also have a "down" action for "default", to kill the dhcp client (I'm using udhcpc) | 05:38 |
| rwp | And looking at /etc/wpa_supplicant/wpa_supplicant.conf it appears that wpa-gui is explicitly disabling them all preventing wpa_supplicant from roaming among them. disabled=1 is set with each of them. | 05:38 |
| rrq | I might have added that down" action to handle that dhcp client "replication"... (don't remember) | 05:39 |
| rwp | Hmm... That's an interesting thing. You needed to put in a down action to kill the running dhclient. And I am complaining that it starts a new one without stopping the previous one. | 05:39 |
| rrq | yes.. addressing same issue :) | 05:40 |
| rwp | Here is the first couple of entries in my wpa_supplicant.conf file. Note that this file is managed by wpa-gui and I don't touch it so all of that config is output from wpa-gui. Avoiding manual editing of that file is the entire purpose of wpa-gui. | 05:41 |
| rwp | https://paste.debian.net/plain/1331823 | 05:41 |
| rwp | I have a dozen other network sections and all are pretty much identical to the tranquilizeddreams one using WPA and each of them has disabled=1 in it! I included one coffee shop entry which is open without encryption and it is the only one that does not say disabled=1 | 05:42 |
| rrq | yes; though I think it's actually rewritten by wpa_supplicant | 05:43 |
| rrq | the other wpa_* tools talks to it via that ctrl_interface | 05:45 |
| rwp | I have also run a different laptop for a year totally manually. I edited the wpa_supplicant.conf file and just hacked things in as I needed it. Except for the tedious need to scan for new APs and then to create and add in a new network section doing everything manually worked extremely well. Once a new network was present then wpa_supplicant the running daemon would roam among any of them. | 05:45 |
| rrq | works well as long as there isn't 2 or more (enabled) AP nearby | 05:46 |
| rwp | I would still be doing that except for the recommendations for wpa_gui and so I have been using it instead. But it has also been freaking out starting and restarting dhclients. And that's how I have arrived at this point. | 05:46 |
| rwp | I normally have two APs in the house. I didn't have any particular problem with it running that way in the manual mode. | 05:47 |
| rrq | my sown action line is: down pkill -f "udhcpc.*wlan0.pid" || true | 05:47 |
| rrq | s/s/d | 05:47 |
| rwp | So it seems you are also needing to kill the previous dhcp client, I'll say manually since this is not part of the standard process, too. | 05:49 |
| rrq | yes; it might be a newish handling of the "dhcp" method | 05:51 |
| rrq | that each "ifup default" starts a new dhcp | 05:51 |
| rrq | I suppose one might get the same effect for a cable setupu using the dhcp method | 05:52 |
| rwp | Now that I realize that disabled=1 is set for every network I think I should hack that out and then run wpa_supplicant and I bet I would not need to touch it again, until I needed to use wpa_gui to add a new AP. I am thinking that it will then add a new one and also disable all of the others as it has already done. | 05:54 |
| rwp | Too bad the man page for wpa_gui is so terse on documentation. So terse that is is basically worthless documentation. Sigh. | 05:55 |
| rrq | I thought all operationa logic is done by wpa_supplicant, using wpa_action, while wpa_guui and wpa_cli only mediates user interactions | 05:57 |
| rwp | It would make sense if that were the case. But my wrapper at /sbin/dhclient is indicating that as an extra it is being started by /sbin/wpa_cli -B -P /run/wpa_action.wlan0.pid -i wlan0 -p /var/run/wpa_supplicant -a /sbin/wpa_action | 06:00 |
| rwp | Here is the call tree looking upward from the newly called /sbin/dhclient up through the process tree: https://paste.debian.net/plain/1331825 | 06:01 |
| onefang | In my case connman didn't help, but wpa-gui worked once, then I rebooted to see if it persisted, and it can't talk to wpa_supplicant now. Then I went shopping. | 06:03 |
| rwp | D'Oh! Looking at it now I am going through the options and I see dhclient -r there. I didn't notice that before! | 06:03 |
| rwp | -r Release the current lease and stop the running DHCP client as previously recorded in the PID file. | 06:04 |
| rwp | So... It's actually attempting to kill the previous dhclient. Which means I need to go back to the debugging again. Let it kill the client, or attempt to, and see what happens then. | 06:04 |
| rrq | right.. it's the "ifdown wlan0" which comes before the "ifup wlan0=default" .. handling a disconnect/connect spike | 06:06 |
| * onefang gives up on WiFi networking for that computer for now. Ethernet strung across three rooms is working at home, WiFi when out and about was just a "nice to have". Time to get back to getting ALSA and JACK sorted on it. Those are the actual important thing. | 06:08 | |
| rrq | mmmm maybe it was that inability to kill dhclient lead me to go to udhcpc ... (too foggy memory:) | 06:08 |
| onefang | Coz it's job as a portable computer is mostly to be a synth for my MIDI keyboard. | 06:09 |
| rrq | lead = that led | 06:09 |
| rwp | Wired is best. But out and about needs WiFi. This was good because I moved forward one step now understanding that the -r is sometimes there. I need to account for that in the debbuging. | 06:09 |
| debdog | oy vey, feels like living in 2005 | 06:09 |
| debdog | my connman experience ain't better than onefang's | 06:10 |
| rwp | connman worked for me. I expect I will return to it if I don't figure out wpa_gui. But connman worked. It just had an unusual UI. | 06:12 |
| rwp | It's the highly odd user interface of connman I didn't like. But I didn't have any actual bugs like extra dhclients using it. | 06:12 |
| debdog | yah, the UI is bad. but in my case it unloaded the kernel module and wifi stopped working entirely | 06:13 |
| onefang | Mostly I couldn't find a way to "show me the APs, lemme choose one" in connman. | 06:13 |
| rwp | It's there. It's just so bizarre that one can't believe that's the UI for it. | 06:15 |
| onefang | So best avoided, and no point hunting for it then I guess. | 06:15 |
| rwp | It's been long enough now I don't remember exactly how it is driven. I guess I will have to activate it again and use it again for a while to remember. | 06:15 |
| rrq | you can use linssid to see which AP there are | 06:16 |
| rrq | though not selecting/connecting | 06:16 |
| Xenguy | I absolutely hated connman when I tried it; it won't get another chance on my laptops... | 10:10 |
| Xenguy | wpa-gui works fine for my simple use case: connect to public wifi when I'm out and about. I always ifdown eth0 before I suspend my laptop and leave home, then connect to public wifi with wpa-gui. When I'm done a session (e.g. maybe I'm heading home now), I right-click the wpa-gui icon in the tray, disconnection, and then quit. So I always tear-down any given public wifi session. It works fine for me, with no issues, so much so that if wicd ever mananged | 10:14 |
| Xenguy | to make a return, I probably wouldn't bother going back to it, though it worked quite nicely for me. | 10:14 |
| Xenguy | s/disconnection/disconnect | 10:15 |
| buZz | i miss wicd :( | 13:51 |
| djph | buZz: same. | 13:58 |
| cousin_luigi | buZz: Does debian have wicked? | 14:52 |
| buZz | cousin_luigi: no, its python2 | 14:52 |
| cousin_luigi | buZz: Hmm, looks like C to me (https://github.com/openSUSE/wicked) | 14:54 |
| buZz | wicd | 14:54 |
| buZz | not wicked | 14:54 |
| cousin_luigi | I wrote wicked | 14:54 |
| buZz | welp, debian has no wicked either, whatever that may be :D | 14:54 |
| cousin_luigi | To make this absolutely plain, wicked is in no way related to WICD, for good | 14:55 |
| cousin_luigi | or bad. It's just coincidence. | 14:55 |
| buZz | 'a library' , ok | 14:55 |
| cousin_luigi | Interesting. | 14:55 |
| cousin_luigi | It's an alternative to networkmanager or ifupdown, I believe. Not that I've used it much. | 14:55 |
| cousin_luigi | By the way, does anyone here use iwd? | 14:56 |
| drizzt | not me | 15:20 |
| drizzt | did not even know about it :( | 15:21 |
| avir327 | cousin_luigi: I have been fiddling with it, but the 'wired' module (for 802.1x auth) seems to be not yet fully implemented. That had been the only reason so far to check it out. | 16:02 |
| avir327 | Just read, that Debian is planning to deprecate ifupdown... (which is probably already mentioned in the backlog?) | 16:03 |
| yeti | *ribbit!* | 16:04 |
| drizzt | avir327: do you have a date on the post mentionning this ? | 16:04 |
| yeti | debian plays boiling the frog with us | 16:05 |
| drizzt | because the first mentions about changes on all of the network tools is more than a decade old | 16:05 |
| drizzt | 2011 from what I can remember | 16:05 |
| drizzt | ifconfig was due to be replaced by ip at that time | 16:06 |
| drizzt | yep : a blog post from december 2011 : https://dougvitale.wordpress.com/2011/12/21/deprecated-linux-networking-commands-and-their-replacements/ | 16:07 |
| drizzt | almost 13 years old | 16:07 |
| avir327 | drizzt: It was just a few days ago, definitely this week. | 16:08 |
| drizzt | and dit some stupid move from iptables to nftables even before nftables was functionnal (it's still not fully functionnal) | 16:10 |
| drizzt | but maybe this time there's something serious behind, aside from doing something stupid | 16:10 |
| drizzt | https://debian-facile.org/viewtopic.php?id=20161 | 16:11 |
| drizzt | 2017 | 16:11 |
| drizzt | erf, this is ubuntu related rather than debian | 16:12 |
| avir327 | drizzt: Can't find it right now, might have been some warmed up news on yc/hn. | 16:12 |
| avir327 | drizzt: https://lwn.net/Articles/989055/ | 16:23 |
| avir327 | I /read/ it this week, lacking an lwn account. | 16:24 |
| drizzt | Used to have one but it's way too time consuming | 16:25 |
| drizzt | avir327: The plan right now seems to be to change the default network manager, not to abandon ifupdown | 16:27 |
| drizzt | and lol : "he argued that systemd‑networkd would be a better choice for server and embedded installations" | 16:27 |
| drizzt | systemd is a really stupid choice for an embedded system ... so is any systemd related stuff | 16:28 |
| drizzt | (well I could have stoped the sentence after the 6th word anyway) | 16:29 |
| avir327 | drizzt: Yeah, perhaps I am still shocked by the mention... just recently got that thing running with ifupdown, only with ifupdown. Had tried a lot to get nm working with machine certificates. | 16:34 |
| avir327 | ("for usability") | 16:35 |
| Xenguy | Deprecating ifupdown in favour of systemd or network manager based networking?! Gawd forbid, do I have to switch distros to avoid this Debian contamination?? | 16:40 |
| cousin_luigi | avir327: Wireless with 802.11r seems to work better. | 17:29 |
| drizzt | Xenguy: alternative is to package for devuan :) | 19:06 |
| drizzt | we already have an alternative distribution, why not use it to go on maintaining usefull stuff which newbies to not find fancy just because it's working fine and as such did not receive 1500 pull requests on github over the last few days ? | 19:08 |
| drizzt | (what most people call "an inactive projetc" | 19:08 |
| drizzt | or even "unmaintained" | 19:09 |
| drizzt | but a programm as simpel as "/bin/true" or "/bin/false" does not need "active maintainance" | 19:09 |
| fsmithred | drizzt, as this list grows, we will need more package maintainers: https://salsa.debian.org/matthew/orphan-sysvinit-scripts/-/tree/master/scripts?ref_type=heads | 19:22 |
| drizzt | fsmithred: yep, gonna learn the basics using debian maintainers time by handling the packaging of my orphaned package lpctools | 19:28 |
| drizzt | I paid a debian maintainer to take care of the packaging some (long) time ago, as a support to debian | 19:29 |
| drizzt | he turned out to be a systemd fanboy :( | 19:29 |
| drizzt | first packaging occured before the systemd mess | 19:29 |
| drizzt | when he asked me to pay again so he can go on maintaining the package I gave him the whole length of my point of view on the subject | 19:30 |
| drizzt | so my tool is now orphaned, which a goos starting point :) | 19:31 |
| drizzt | (well, I already built packages to deploy some stuff like qtembedded on specific embedded platforms, but this will be a step further | 19:32 |
| fsmithred | cool. I see it's in excalibur/ceres | 19:33 |
| fsmithred | Him?? | 19:33 |
| fsmithred | someone else is maintaining it now? | 19:34 |
| fsmithred | Sophie | 19:34 |
| drizzt | sophie is working for the company created by the guy I paid back in ... 2012 ? | 19:36 |
| drizzt | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037150 | 19:36 |
| fsmithred | I dream that one day a bunch of debian developers will come over to devuan, and debian will have to get packages from us. | 19:45 |
| fsmithred | (pretty sure they already do get some) | 19:46 |
| * golinux nods and wonders when Debian devs will have had enough of the abuse over there | 19:46 | |
| Xenguy | drizzt, fsmithred , golinux I suppose learning how to package would be a useful skill anyone might be able to investigate (surely it has to be easier than building ISO's but maybe I'm wrong about that) | 19:54 |
| fsmithred | building isos is actually pretty easy | 19:55 |
| Xenguy | Well unless I'm entirely uninformed, it sure looks like a black arte to me = ) | 19:55 |
| fsmithred | squash a filesystem, put it in a live-iso framework using xorriso (or genisoimage if you prefer) | 19:56 |
| drizzt | Xenguy: building a package is very straightforward and easy | 20:12 |
| drizzt | getting it in a distrib may be harder (need signing, having your signing key in the signing pool, and related stuff) and also submitting to the server correctly, etc ... | 20:13 |
| drizzt | as for the iso, it's seldom usefull to build an iso (unless you still use CD/DVDs) | 20:14 |
| drizzt | but there's no need for an ISO on an USB key | 20:15 |
| Xenguy | fsmithred, Oh, maybe we are think of different kinds of ISO's (e.g. Excalibur ISO's might take more knowledge to build correctly?) ? | 20:16 |
| fsmithred | Xenguy, yes. | 20:16 |
| Xenguy | drizzt, re: package building, I expect Devuan is less bureacratic than Debian at least | 20:17 |
| fsmithred | ^^^understatement of the day | 20:17 |
| Xenguy | I recall someone else wondering why the ISO format is still used, but I have no knowledge of why it still seems to be the predominant format installation media | 20:18 |
| fsmithred | I'll answer in OT | 20:30 |
| drizzt | OT ? | 22:52 |
| drizzt | off-topic ? | 22:52 |
| debdog | right: #devuan-offtopic | 22:54 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!