BookwormPup64 10.0.5 Connection Manager Problem

[JusGellin]

Since I'm just a beginner I decided to ask help from here. I hope I can explain this well enough.
Is there a utility called "Connection Manager" that sets up the name server For BookwormPup64?

I was trying to make a virtual machine guest for version 10.0.5 but found that it couldn't access the internet because of name resolution problems - it could ping by ip but not by name. For example it could ping 8.8.8.8 but not ping google.com. This didn't work even when the iso started up for the installation. I could just bring up the installation and it would fail the same way. So I tried version 10.0.4 which would work ok. Researching this, I found that at /etc/resolv.conf there wasn't any entry like it should for 10.0.5. But for version 10.0.4 it had

Generated by Connection Manager
nameserver 192.168.122.1

How is this made permanent? If I put this in version 10.0.5, it works but it is gone for the next boot.

The strange thing about this is when I try this on another laptop, it doesn't have this problem. So it probably doesn't fail everywhere.
Thanks

[Marv]

I am also seeing this on 10.0.5 and did not see it on 10.0.4. My hardware is: Fujitsu S761, 2nd gen i5 all intel laptop, circa 2012.

If I then restart connman (/etc/init.d/connman restart), resolve.conf is populated normally. I think that it may be a timing issue and that connmand isn't waiting quite long enough for the system to settle before getting the nameserver info from my router. I just put an executable connman_restart script calling /etc/init.d/connman restart in my /root/Startup directory to patch it for now. Tested the stock kernel, 6.6.17, and 6.7.5 and it is kernel invariant. Relevant dmesg content below :

Connmann connects normally on boot, the relevant dmesg is:

Code: Select all

# dmesg | grep wlan0
[   16.200667] wlan0: 80 MHz not supported, disabling VHT
[   16.217525] wlan0: authenticate with 98:de:d0:21:16:7d (local address=24:ec:99:24:3b:d1)
[   16.217537] wlan0: send auth to 98:de:d0:21:16:7d (try 1/3)
[   16.219798] wlan0: authenticated
[   16.221378] wlan0: associate with 98:de:d0:21:16:7d (try 1/3)
[   16.225669] wlan0: RX AssocResp from 98:de:d0:21:16:7d (capab=0x431 status=0 aid=3)
[   16.225918] wlan0: associated

connman restarted, resolve.conf populated:

271.809298] wlan0: deauthenticating from 98:de:d0:21:16:7d by local choice (Reason: 3=DEAUTH_LEAVING)
[  273.201775] wlan0: 80 MHz not supported, disabling VHT
[  273.218599] wlan0: authenticate with 98:de:d0:21:16:7d (local address=24:ec:99:24:3b:d1)
[  273.218618] wlan0: send auth to 98:de:d0:21:16:7d (try 1/3)
[  273.220814] wlan0: authenticated
[  273.222669] wlan0: associate with 98:de:d0:21:16:7d (try 1/3)
[  273.226917] wlan0: RX AssocResp from 98:de:d0:21:16:7d (capab=0x431 status=0 aid=3)
[  273.227162] wlan0: associated

[JusGellin]

Great, that worked! Thanks.
I had to add a 2 second delay to make it work every time.

I'm really new to this. Could you help me understand some of what you mentioned at the end?

My pups: LxPupSc64 and Voidpup64 with LXDE ydrv & synaptics touchpad drivers, both using savefiles. Ydrv based Jammypup64 (JWM), Bookworm64, Fossapup23 & FossapupFire (LXDE/PCManFM). No savefiles, no fdrvs there

--especially what the ydrv and fdrvs are for? Also, is it good to have no savefiles?

[Marv]

Very briefly, ydrvs are usually used for customizing an installation. If they exist in the boot directory and are appropriately named they are automatically loaded at boot. Once I have a pup set up, I transfer my added applications, custom panel and menu, and symlinks to portable applications from a temporary savefile to that 'permanent' ydrv. It takes a bit more doing -and maintenance takes an additional step- but results in a virtually indestructible install. I call pups set up that way toasters and love them but it takes a bit of learning and doing to get there.

Savefiles or folders -your preference- are much simpler for most users and work very very well. On the pups I set up that way, I always make a subdirectory in the boot directory or in the relevant data directory for that pup and keep a fairly recent copy of the savefile there. I simply call it 'saves'. That has saved my butt more than once.

The fdrv, present in all recent pups, carries the firmware packages for many many network connection cards and modems. On boot, that is where the kernel looks for the package needed for the card in the system. The fdrv that comes with most pups is an attempt to strike a balance between size and completeness but some very large and much more comprehensive ones are available via the forum. The wifi card that I use in all my laptops is directly supported in all recent kernels so I don't need any fdrv in my standard hardware (6 laptops).

The reference to synaptics drivers is again a personal preference. They control how the touchpad on a laptop is set up. They are no longer supported, newer pups use a system called libinput, but I revert to the synaptics package because for all of my touchpads, that has much better acceleration profiles and more pressure and hysteresis settings. Dinosaur here

[radky]

@JusGellin and @Marv

BW64 10.0.5 implements @rerwin's new update of ConnectWizard which adds support for ConnMan and enables on-the-fly switching to/from ConnMan and legacy connection managers such as SNS, Network Wizard, etc.

On initial boot of BW64 10.0.5, ConnMan connects to the internet the same as 10.0.4 by calling connman-ui-gtk. However, in ConnectWizard of BW64 10.0.5, subsequent session calls to network settings are mediated by a new file (/usr/bin/connman-gtk.sh) which executes connman-gtk directly rather than connman-ui-gtk.

Until @rerwin has time to review and address your bug reports, maybe you could try editing /usr/bin/connman-gtk.sh and change exec connman-gtk "$@" to exec connman-ui-gtk "$@" -- just something to test until @rerwin has time to evaluate your reports and provide a proper fix.

[JusGellin]

@Marv
Thanks for the explanation for this. It gives me some things to help me learn more about the workings. I have a long way to go, but it's interesting.

@radky
I tried the change you mentioned after I removed the script that Marv suggested to kick start ConnMan in the Startup folder. It didn't seem to work. I just tried a reboot and saw it didn't resolve names to the internet. Should I have checked it further?

[rerwin]

@JusGellin and @Marv
Until @rerwin has time to review and address your bug reports, maybe you could try editing /usr/bin/connman-gtk.sh and change exec connman-gtk "$@" to exec connman-ui-gtk "$@" -- just something to test until @rerwin has time to evaluate your reports and provide a proper fix.

I am about to start testing 1.0.0.5 but with my updated version of my changes. I will post that soon.

However, note that connman-ui-gtk is the tray icon, not connman. Please don't waste your time trying to debug further the network changes until I provide the update.

I appreciate the report about the timing issue because I have been suspicious of the startup situation. I will look into that.

Richard

[mikeslr]

Just a follow up to Marv's reply to your question about ydrv.sfs. See, https://www.forum.puppylinux.com/viewto ... 983#p12983 for the tool which works with them among other things.The Save2SFS module creates and/or modifies both adrvs, and ydrvs. These are basically identical except that the contents of an adrv will take precedence over that of a ydrv if there are conflicting files.

I usually locate thing which change often --such as web-browsers-- in an adrv; while applications I expect never to have to change I place in a ydrv. Some puppys --such as fossapup64-9.5-- are published with a lot of applications in an adrv. In such case, I Right-Click the adrv and rename it ydrv so that the applications, customizations and settings I later make and include in an adrv will have precedence.