Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sat 14 Dec 2019, 15:57
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
Fatdog64-802/801/800 Final [21 May 2019]
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 26 of 30 [448 Posts]   Goto page: Previous 1, 2, 3, ..., 24, 25, 26, 27, 28, 29, 30 Next
Author Message
jake29

Joined: 24 Jul 2015
Posts: 243

PostPosted: Sat 02 Nov 2019, 10:45    Post subject:  

Hi folks. I have an app that requires a login/password when launched. Login is being saved, however pass is not. The app now uses 'Gnome Keyring' - previous versions did not and I had no issue.

Is there a solution?
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3680

PostPosted: Wed 06 Nov 2019, 08:42    Post subject:  

rufwoof wrote:
Good spot SFR. I did compile a standard kernel/default config ... which also has those "not set". I built the same version of standard kernel as Fatdog, with localyesconfig so all modules are built into the kernel. Also drop initrd (initramfs.cpio) into the kernel, so just the one file to boot (vmlinuz), but with a cut down Bulldog (fatdog initrd) as the initramfs.cpio. My laptop works with the default kernel included firmware, so no external modules/firmware whatsoever. Hence the 11MB vmlinuz size (enough for cli/wifi net connected/ssh).

My intent was to have that as a means to quickly boot (1 second, 6 seconds with net connected), and pull in a main system from wherever (mounted filesystem, via the internet ...etc.) and then (re)boot using that. kexec came to mind, but its equally just as easy to (temporarily) modify menu.lst to boot the new main system and reboot into that.

EDIT: having rebuilt the kernel with KEXEC enabled that is working OK i.e. can from within Bulldog kexec -l vmlinuz --initrd=initrd;kexec -e ... and it boots to full graphical Fatdog desktop mode using that alternative kernel.

upx'd the kexec and with initrd built into the kernel along with all modules (just boots with vmlinuz alone), that's a 9.9MB vmlinuz filesize (I dropped btrfs support and some other stuff out of the kernel build). That boots to cli, wifi net connect and has ssh (so I can ssh into hashbang and access tmux for email/irc ...etc.), is set to support overlayfs and now has functional kexec - so it can directly boot another system/puppy without having to reboot via BIOS.

ssh (scp) is a little slow compared to a fully booted systems scp speed. Pulling down a fatdog iso for instance and then extracting the initrd out of that and booting it isn't a quick task/action - more like a coffee break task.

I've removed Dropbear and replaced that with the Openssh, so has sftp, scp, sshfs alongside ssh now. Along with, screen (terminal multiplexing), mc (file manager and text editor), and ccrypt (tar up the .ssh folder keys/files and ccrypt them - so if the usb is lost the ssh keys are obscure), and kexec ... and that's 'bloated' the vmlinuz to 11.87MB. As my ssh keys are in the initramfs having that incorporated into the kernel (vmlinuz) further hides them.

I'm now using that as my default boot. Boot, check out irc/email ...etc (Bulldog cold boots to wifi net connected from usb in just a few seconds), then use that and/or kexec a main full system (fatdog desktop) or any other Puppy as desired.

Generally operational wise to pull down and boot a main system using wget to download Fatdog is quicker than using ssh
Code:
wget --no-check-certificate https://distro.ibiblio.org/fatdog/iso/Fatdog64-802.iso

Mount that, copy out the vmlinuz and initrd, and then run kexec .. is around a 2 minute action, compared to more like 5 minutes if using ssh/scp. Having the main Fatdog boot files locally however avoids that download 'lag' i.e. I keep copies on the usb and just boot those directly, also keeping the saves (I use multi-session save) on usb.

For the marginal increase in vmlinuz file size to have openSSH available instead of Dropbear ssh ... well worth it IMO (even for the added benefit of having sshfs alone i.e. sshfs mount a remote folder and have all of those files visible/available within mc (ncurses based file manager).

Another benefit is that when using usb3, copying the main Fatdog into ram after having booted to Bulldog is much quicker, around 4 times quicker by my (casual) estimate.

EDIT: As the 4.14.152 kernel was out today (I've opted to track the 4.14 for its 2024 EOL date), I'm currently compiling that with simple-mtp also thrown in. ... Done. 13.2MB vmlinuz with all modules/firmware and initramfs contained within that, along with wifi net connect, screen, mc, ccrypt, openssh (so scp/sftp/sshfs also included), kexec and simple-mtp (to mount my android phone). Quite a nice Bulldog IMO.

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
don570


Joined: 10 Mar 2010
Posts: 5397
Location: Ontario

PostPosted: Wed 06 Nov 2019, 20:04    Post subject: GIMP - external paint program  

I am using fatdog64 802...

To get mypaint to recognize an external paint program --->
I added gimp to this line of
/root/.local/share/applications/mimeinfo.cache
Result....

Code:
image/png=gimp.desktop;wine-extension-png.desktop;



mypaint appimage download...
https://github.com/mypaint/mypaint/releases
_______________________________________________________
Code:
[MIME Cache]
application/pdf=wine-extension-pdf.desktop;
application/rtf=wine-extension-rtf.desktop;
application/vnd.ms-htmlhelp=wine-extension-chm.desktop;
application/winhlp=wine-extension-hlp.desktop;
application/x-mswinurl=wine-extension-url.desktop;
application/x-mswrite=wine-extension-wri.desktop;
application/x-wine-extension-ini=wine-extension-ini.desktop;
application/x-wine-extension-msp=wine-extension-msp.desktop;
application/x-wine-extension-vbs=wine-extension-vbs.desktop;
application/xml=wine-extension-xml.desktop;
image/gif=wine-extension-gif.desktop;
image/jpeg=wine-extension-jpe.desktop;wine-extension-jfif.desktop;
image/png=gimp.desktop;wine-extension-png.desktop;
text/html=wine-extension-htm.desktop;
text/plain=wine-extension-txt.desktop;
Back to top
View user's profile Send private message 
don570


Joined: 10 Mar 2010
Posts: 5397
Location: Ontario

PostPosted: Wed 06 Nov 2019, 20:10    Post subject: menu.lst produced by grub4dosconfig-v1.7  

Code:
# menu.lst produced by grub4dosconfig-v1.7
color white/blue black/cyan white/black cyan/black
timeout 10
default 0

# Boot from Partition Boot Sector

title Windows Vista/2008/7 (sda1:PBS)
  uuid 767274B3727479A7
  chainloader +1

title Fatdog64 (sda3/fatdog802)
  find --set-root uuid () 1fc15612-18ea-4972-a15b-035326f12a12
  kernel /fatdog802/vmlinuz  pdrv=1fc15612-18ea-4972-a15b-035326f12a12 pmedia=atahd psubdir=/fatdog802 pfix=fsck savefile=direct:device:sda3:/fd64save-802
  initrd /fatdog802/initrd
 



Note that I added to kernel line....
savefile=direct:device:sda3:/fd64save-802

_____________________________
Back to top
View user's profile Send private message 
don570


Joined: 10 Mar 2010
Posts: 5397
Location: Ontario

PostPosted: Wed 06 Nov 2019, 20:18    Post subject: SFS Loader  

I think I have tracked down why I was having problems with the SFS loader when I first booted with
no savefile.

I clicked on 'APPLY' button to change the folder but then didn't realize that I had to click a second time on 'APPLY' button before exiting
to store the settings.

This could be made clearer if there was a third button a bottom of window
'Apply and Exit'
(see image)
screenshot-sfsloader.png
 Description   
 Filesize   15.55 KB
 Viewed   451 Time(s)

screenshot-sfsloader.png

Back to top
View user's profile Send private message 
don570


Joined: 10 Mar 2010
Posts: 5397
Location: Ontario

PostPosted: Wed 06 Nov 2019, 20:22    Post subject: right click menu for mount point  

Tip: to place a pFind menu item in right click menu of a partition icon in Rox filer,
just type this in terminal...
Code:
ln -s /usr/local/apps/pFind   /root/.config/rox.sourceforge.net/SendTo/.inode_mount-point/pFind

___________________________________________________________
screenshot-pfind.png
 Description   
 Filesize   19.13 KB
 Viewed   447 Time(s)

screenshot-pfind.png

Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3388
Location: The Blue Marble

PostPosted: Thu 07 Nov 2019, 11:35    Post subject:  

@jake29: I will try to build gnome-keyring for you. It may or may not help. I'll let you know when ready. Hopefully it doesn't pull too many dependencies (if it does, I'd probably give up).

@rufwoof: Nice setup you have there Smile

@don570: regarding the mimeinfo.cache stuff: Thanks for that info. Eventually Fatdog needs to catch up that. When we started all these fancy schmancy stuff didn't exist. We only had /etc/mime.types, /etc/mailcap, and /usr/share/applications/defaults.list. But those freedesktop guys got infected by NIH virus and indecision virus - they keep inventing new locations every few years or so, for where to keep these file-association information. I personally think the way rox handles file association is the best; but of course opinions differ. I personally think that putting all your eggs in one basket like mimeinfo.cache smells much too rotten like the windows registry. But that's just me, and since eevryone has moved into that direction, sooner or later we'll all have to wear the mask too ...

@don570: grub4dosconfig was designed for puppy, not for Fatdog. We include it in Fatdog because people find it useful. I'm not sure if shinobar still maintains it (or if he's still even here in the forum). We include it in Fatdog also because there is no better tool. But as you can see, it's not perfect. That's perhaps another item we need to add to the FAQ ...

@don570: Re: adding the button to SFS loader: I wish I could do that, but since SFS loader is written using the extremely primitive Xdialog, two buttons is the maximum we can get. That's why i have to go with the kludge of "tick here to change directory" stuff. Otherwise I would have added a button to change directory.

@rufwoof: re: the cryptsetup unmount: the "unmount" should only unmount. If we want to totally close the the luks container, then another action should added. The equivalent analogy is a flash drive. When you click the "x" rox icon, the drive is unmounted, but the drive icon remains. To remove it, we have to right-click on the drive and choose "safely remove". That's where "close luks partition" functions should go; instead of combining it together with the unmount function.

But before we go that way, we need to modify "filemnt" to be able to open the luks container in the first place ...

_________________
Fatdog64 forum links: Latest version | Contributed packages | ISO builder
Back to top
View user's profile Send private message 
don570


Joined: 10 Mar 2010
Posts: 5397
Location: Ontario

PostPosted: Thu 07 Nov 2019, 20:11    Post subject:  

James wrote:
@don570: grub4dosconfig was designed for puppy, not for Fatdog.


I forgot to mention that I had set up the bootloader for my windows10 computer by booting with an old CD of Lucid puppy and running grub4dos from it , not fatdog64.
_______________________________________________
Back to top
View user's profile Send private message 
don570


Joined: 10 Mar 2010
Posts: 5397
Location: Ontario

PostPosted: Thu 07 Nov 2019, 20:20    Post subject: latest mtpaint 3.49.19  

I was able to compile latest mtpaint 3.49.19
with ./configure
I had upgraded my install with png12 because of gmic plugins
which have dependencies
http://murga-linux.com/puppy/viewtopic.php?p=1041255#1041255
___________________________________________
Back to top
View user's profile Send private message 
don570


Joined: 10 Mar 2010
Posts: 5397
Location: Ontario

PostPosted: Thu 07 Nov 2019, 20:42    Post subject: SFS loader  

Quote:
SFS loader is written using the extremely primitive Xdialog, two buttons is the maximum we can get


I didn't realized that SFS loader was written with Xdialog!!!

Perhaps the button could be re-labelled...

or just have one button i.e. to quit program you have to use upper right close box.
screenshot-sfsloader.png
 Description   
 Filesize   6.49 KB
 Viewed   362 Time(s)

screenshot-sfsloader.png

Back to top
View user's profile Send private message 
jake29

Joined: 24 Jul 2015
Posts: 243

PostPosted: Fri 08 Nov 2019, 09:19    Post subject: h  

@jamesbond - Please don't make too much effort if it's going to mean major bloat for Fatdog64.

I now have a more pressing issue. I bought a Bluetooth mouse (Microsoft mobile mouse 3600) and I can pair, trust and connect - but mouse refuses to work.

I tried in Ubuntu 19.04 for comparison, and the exact same steps result in a working mouse. Perhaps due to this mouse being a BT Low Energy (LE) device is a factor. I am unable to pkgbuild the latest version of Bluez due to changes in source.

FD64-802:
Code:
[bluetooth]# scan on
Discovery started
[CHG] Controller 60:57:18:E0:05:69 Discovering: yes
[NEW] Device C8:1B:F6:35:48:07 BluetoothMouse3600
[CHG] Device C8:1B:F6:35:48:07 RSSI: -47
[bluetooth]# pair C8:1B:F6:35:48:07
Attempting to pair with C8:1B:F6:35:48:07
[CHG] Device C8:1B:F6:35:48:07 Connected: yes
[CHG] Device C8:1B:F6:35:48:07 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1B:F6:35:48:07 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1B:F6:35:48:07 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1B:F6:35:48:07 UUIDs: 0000180f-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1B:F6:35:48:07 UUIDs: 00001812-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1B:F6:35:48:07 ServicesResolved: yes
[CHG] Device C8:1B:F6:35:48:07 Paired: yes
[NEW] Primary Service
   /org/bluez/hci0/dev_C8_1B_F6_35_48_07/service0008
   00001801-0000-1000-8000-00805f9b34fb
   Generic Attribute Profile
[NEW] Primary Service
   /org/bluez/hci0/dev_C8_1B_F6_35_48_07/service0009
   0000180a-0000-1000-8000-00805f9b34fb
   Device Information
[NEW] Characteristic
   /org/bluez/hci0/dev_C8_1B_F6_35_48_07/service0009/char000a
   00002a29-0000-1000-8000-00805f9b34fb
   Manufacturer Name String
[NEW] Characteristic
   /org/bluez/hci0/dev_C8_1B_F6_35_48_07/service0009/char000c
   00002a50-0000-1000-8000-00805f9b34fb
   PnP ID
Pairing successful
[CHG] Device C8:1B:F6:35:48:07 Modalias: usb:v045Ep0916d0110
[BluetoothMouse3600]# trust C8:1B:F6:35:48:07
[CHG] Device C8:1B:F6:35:48:07 Trusted: yes
Changing C8:1B:F6:35:48:07 trust succeeded
[BluetoothMouse3600]# connect C8:1B:F6:35:48:07
Attempting to connect to C8:1B:F6:35:48:07
Connection successful


Ubuntu 19.04 (w/ bluez v5.50):
Code:
user@Venue-11-Pro-7140:~$ bluetoothctl
Agent registered
[NEW] Device C8:1C:F5:36:48:07 BluetoothMouse3600
[bluetooth]# scan on
Discovery started
[CHG] Device C8:1C:F5:36:48:07 RSSI: -49
[bluetooth]# pair C8:1C:F5:36:48:07
Attempting to pair with C8:1C:F5:36:48:07
[CHG] Device C8:1C:F5:36:48:07 Connected: yes
[CHG] Device C8:1C:F5:36:48:07 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1C:F5:36:48:07 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1C:F5:36:48:07 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1C:F5:36:48:07 UUIDs: 0000180f-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1C:F5:36:48:07 UUIDs: 00001812-0000-1000-8000-00805f9b34fb
[CHG] Device C8:1C:F5:36:48:07 ServicesResolved: yes
[CHG] Device C8:1C:F5:36:48:07 Paired: yes
[NEW] Primary Service
   /org/bluez/hci0/dev_C8_1C_F5_36_48_07/service0008
   00001801-0000-1000-8000-00805f9b34fb
   Generic Attribute Profile
[NEW] Primary Service
   /org/bluez/hci0/dev_C8_1C_F5_36_48_07/service0009
   0000180a-0000-1000-8000-00805f9b34fb
   Device Information
[NEW] Characteristic
   /org/bluez/hci0/dev_C8_1C_F5_36_48_07/service0009/char000a
   00002a29-0000-1000-8000-00805f9b34fb
   Manufacturer Name String
[NEW] Characteristic
   /org/bluez/hci0/dev_C8_1C_F5_36_48_07/service0009/char000c
   00002a50-0000-1000-8000-00805f9b34fb
   PnP ID
Pairing successful
[CHG] Device C8:1C:F5:36:48:07 Modalias: usb:v045Ep0916d0110
[BluetoothMouse3600]# trust C8:1C:F5:36:48:07
[CHG] Device C8:1C:F5:36:48:07 Trusted: yes
Changing C8:1C:F5:36:48:07 trust succeeded
[BluetoothMouse3600]# connect C8:1C:F5:36:48:07
Attempting to connect to C8:1C:F5:36:48:07
Connection successful


EDIT: Kernel modules comparison.

FD64-802:
Code:
# lsmod | grep '^blue' | column -t
bluetooth  307200  31  btrtl,btintel,btbcm,bnep,btusb,rfcomm
# lsmod | grep '^bt' | column -t
btusb    40960  0 
btrtl    16384  1  btusb
btbcm    16384  1  btusb
btintel  16384  1  btusb


Ubuntu 19.04:
Code:
user@Venue-11-Pro-7140:~$ lsmod | grep '^blue' | column -t
bluetooth  557056  31  btrtl,btintel,btbcm,bnep,btusb,rfcomm
user@Venue-11-Pro-7140:~$ lsmod | grep '^bt' | column -t
btusb    49152  0
btrtl    20480  1  btusb
btbcm    16384  1  btusb
btintel  24576  1  btusb


Below image is from Windows 8 (where mouse also functions correctly):
btmouse3600.PNG
 Description   
 Filesize   19.23 KB
 Viewed   322 Time(s)

btmouse3600.PNG

Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3680

PostPosted: Fri 08 Nov 2019, 12:22    Post subject:  

Tried upx'ing libs in my cut down Bulldog, and with the initramfs built into the kernel and with the kernel .config set to use xz compression that actually expanded the vmlinuz size. So I opted to un upx everything inside the initramfs (including what the standard Bulldog upx's by default) ... went around the various folders running upx -d * and after recompiling the kernel that reduced the vmlinuz down to 12.4MB. With some further kernel config refinement, 11.6MB. The notes I recorded in the /README within Bulldog ...
Quote:
This is Bulldog initrd, as of Mar 2019.

Contains:
- busybox 1.27.0.git.2017.03 with guess-fstype patch (aboriginal 1.2.4)
- busybox init 1.27.0.git.2017.03 (musl 1.1.21), compiled separately for memory reasons
- dropbear 2018.76 (musl 1.1.21) # up to date as of Mar 2019
- losetup-klibc (losetup from klibc 2.0.6) # up to date as of Mar 2019
- ntfs-3g/ntfsfix 2017.3.23 (aboriginal 1.2.4 --disable-mtab) # up to date as of Mar 2019
*- wpa_supplicant (uclibc, br 2012.02) # needs update
*- iwconfig (uclibc, br 2012.02) # needs update
- sdparm 1.07 (can't remember I used musl or uclibc or klibc)
- LVM 2.2.02.177 (dmsetup/lvm) without udev - (musl 1.1.21 + util-linux 2.31.1) # 2018 version
- cryptsetup 2.1.0 (musl 1.1.21 + LVM 2.2.0.177 + util-linux 2.31.1) # jake's build # up to date as of Mar 2019
- e2fsck 1.43.9 (musl-libc) # 2018 version
- dosfsck 4.1 (musl 1.1.21) # up to date as of Mar 2019
- mount.cifs - from cifs-utils 16.8 (musl 1.121) # up to date as of Mar 2019
- mdadm 4.1 (musl 1.1.21) # up to date as of Mar 2019
- katz-git abb56e4c07 (musl, musl-gcc) # up to date as of Mar 2019
- evtest 91f924bc9a (musl 1.1.21) - 2019 # up to date as of Mar 2019
- strace 4.26 (musl 1.1.21) # up to date as of Mar 2019
- posixovl-deztructor-2015 (musl 1.1.15 with fuse 2.9.4) # up to date as of Mar 2019

- full fledged init, supports coldplug and hotplug
- barebones rc.sysinit & rc.cleanup

these binaries are upx-ed (3.0.8 ):
- ntfs-3g, ntfsfix, wpa_supplicant and friends, iw_config, dmsetup, lvm, strace,
sdparm, dropbear, cryptsetup, e2fsck, dosfsck, mount.cifs, mdadm, katz, evtest
posixovl
==> binaries that are only rarely used or only executed once.

Will require:
- squashfs.ko in /lib/modules/$KVER (none if it's already built-in)
- kernel_modules.sfs (optional)

Compiled standard 4.14 kernel with localyesconfig i.e. machine specific modules.
Kernel's standard firmware support seems adequate enough for text cli and wifi
net connect on this laptop.

Added KEXEC kernel (.config) elements
Added kexec binary (and man etc.) musl build with upx'd kexec bin
Added (upx --ultra-brute) screen - that requires pseudo terminal
Added simple-mtpfs with ultra-brute upx'd /usr/bin/simple-mtpfs
Added ccrypt (musl and upx'd) for ssh key protection purposes.
Added openssh
Added mc

Removed strace, lvm, ntfs-3g ntsfix, microcode for genuine intel
(as my laptop is radeon).
Removed mdadm (raid - which I dont use).
Removed /sbin/e2fsck and dosfsck
Removed vmcore-dmesg and kdump from the kexec build
Removed /usr/lib/kexec-tools folder and kexec_test file within that
Removed some things from kernel .config i.e. btrfs
Removed /usr/share/mc ...hints, skins, help files for non UK
Removed /usr/share/terminfo files for xterm and rxvt
Removed dropbear

After upx'ing all libs, found that the vmlinuz was LARGER
(with initrd within that) despite upx ultra-brute seemingly
compressing files quite tightly. Opted to remove all upx'ing
across all files, so went around all folders running upx -d *
Larger initramfs_data.cpio, but when built into the kernel which
is then xz compressed that compresses more tightly.

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
jake29

Joined: 24 Jul 2015
Posts: 243

PostPosted: Sun 10 Nov 2019, 00:58    Post subject:  

To follow-up from my previous post regarding Bluetooth mouse issue. The following may be a potential cause. The 'hid' and 'hid-generic' Kernel modules are missing in the current kernel. I've also read that kernel option UHID (Device Drivers -> HID Support -> User-space I/O driver support for HID subsystem) needs to be enabled.

FD64-802:
Code:
# HID support
#
CONFIG_HID=y
CONFIG_HID_BATTERY_STRENGTH=y
CONFIG_HIDRAW=y
CONFIG_UHID=m
CONFIG_HID_GENERIC=y

Ubuntu 19.04:
Code:
# HID support
#
CONFIG_HID=m
CONFIG_HID_BATTERY_STRENGTH=y
CONFIG_HIDRAW=y
CONFIG_UHID=m
CONFIG_HID_GENERIC=m

EDIT: I got the mouse working by loading the uhid module (modprobe uhid) and then doing pair/trust/connect. I also had to set 'UserspaceHID=true' in /etc/bluetooth/input.conf and restart the bluetooth service to stop an endless cycle of disconnecting/reconnecting.
Back to top
View user's profile Send private message 
belham2

Joined: 15 Aug 2016
Posts: 1707

PostPosted: Sun 10 Nov 2019, 04:22    Post subject:  

Hi Fatdog gang,

Just wondering if anyone has ever come across this issue before.

I can't figure out if it as a hardware issue on my end (seems unlikely since Fatdog has done this (described below) on 4 different machines, AMD & Intel), but the issue involves wireless and a router's Hidden SSID.

Here's what happened: I decided to use a Hidden SSID on my router for our wifi network in our home.

All my other pups and DDogs and larger Linux OSes I run have no problem seeing this "Hidden SSID" as long as I enter the correct SSID in their profile setups.

But in Fatdog, after I go in and remove all old wifi & lan profiles from previous setups, then reboot to bring everything up fresh, Fatdog immediately sees my wifi network, showing (when using Scan in the network-control applet) the XOXOXOXOXOXOOXO for a Hidden SSID network, I then click on it, and Fatdog brings up the popup where I build a profile of this. I think great, no problem here.

I then, for the profile, enter the correct SSID, the WPA2-PSK, CCMP, password, etc---all the stuff I have normally been doing for years now with Fatdog and non-Hidden SSID networks. I hit save, go to "Activate" the network, and---HERE IT IS----Fatdog refuses to connect.

I scratch my head.

I then use another machine in the house, go back into the DD-WRT router, uncheck the "Hidden" feature of the SSID, go back to Fatdog, delete all profiles again. I do the same procedures as above, and sure enough, Fatdog 802 sees the exact same 'unhidden ssid' network and, suddenly, with no problems, connects super-fast.

I scratch my head even more.

So then I try this on other computers and one other laptop with Fatdog USB sticks I have, and Fatdog proceeds to do the same thing on all of them with a 'Hidden SSID' wifi network and refusing to connect to it despite easily seeing the 'hidden ssid' wifi network.

I now realize it is probably not a hardware problem on my end. Un-hide the SSID, and Fatdog connects. Hide the exact same SSID, make the necessary modifications in the wifi profile, and Fatdog refuses to connect. On all the computers/laptops Fatdog did this.

Thinking that maybe there's a problem in Fatdog 802 itself, I go back and test 801, 800 and even the 700s.

Same issue, Fatdog, despite connecting to the exact wifi network if the SSID is NOT hidden, will not---at least for me---connect to any wifi network if the SSID is "Hidden". This was true for any wifi router. I say any because of this reason: it seems to have nothing to do with the DD-WRT router I run otherwise all machines in the house would exhibit the same behavior, and to be sure, I even plugged my ISP's provided wifi/router combo back in, Fatdog connects easily with it provided the SSID is NOT hidden. But the moment I choose to enable the "Hidden SSID" in the router, again, Fatdog (none of them from 700s up to 802) will connect via wifi even ot this router. Yet all my other computer systems and laptops do.


Has anyone else experienced this? Or do I just have a special Gremlin/Demon running around my house and screwing with me when I use Fatdog?
Back to top
View user's profile Send private message 
step

Joined: 04 May 2012
Posts: 1225

PostPosted: Sun 10 Nov 2019, 19:45    Post subject:  

I suspect wpa-supplicant's default configuration is causing your issue.
Try editing /etc/wpa_supplicant.conf and adding this line

scan_ssid=1

after line

ssid="the-hidden-ssid" (replace the-hidden-ssid with yours)

and restart the connection (right click the newtork tool tray icon).

Can it connect to the-hidden-ssid now?

_________________
Fatdog64-810|+Packages|Kodi|gtkmenuplus
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 26 of 30 [448 Posts]   Goto page: Previous 1, 2, 3, ..., 24, 25, 26, 27, 28, 29, 30 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1040s ][ Queries: 12 (0.0120s) ][ GZIP on ]