Wifi-Connect 2017B beta (Deprecated)

[stemsee]

wifi-connect-27.sfs

[stemsee]

Scanner is now handling spaced names as well.

[gcmartin]

@StemSee, I have 5 64bit PUP distros I run regularly. They are Just-Lighthouse, Emsee, Slacko64, DLNAPUP and TahrPUP64 on my laptops/desktops. On one of my desktops, it has 2 LAN adapters on its motherboard and I use this on a regular basis. As such, it would be an advantage if when it boots, it gains its LAN personality over the LAN adapter which has the wire plugged in (this use to be a feature of FD5 series but was removed for no apparent reason). It does remain a automatic service in both Lighthouse and Just-Lighthouse which I use.

I am interested in some guidance:

• Does any of the existing LAN subsystems need removal in preparation for Wifi-Connect so that it can fully accomplish what it is designed to do?
  
  In other words, if Wifi-connect installs will it replace the current LAN adapter that exist?
  
  Or should it just be installed without concern of conflicts?

Thanks in advance for your insight(s).

[stemsee]

Install without concerns!
a LAN adapter is necessarily hardware, this is only software.
I will consider adding a function to save eth0/1 status, so that it can auto-connect to either or both ethernets as part of the defaultwifi that gets created in ~/Startup .... might be a good addition.

is your second ethernet adapter eth1? Or some other name?

[stemsee]

Ethernet auto connect function added. I removed password confirm from gui, or rather reconfigured it to enter parameters fro ethernet/s auto start: it works like this: for no ethernet autostart enter '0', for card 1 (eth0) enter '1', for card 2 enter '2' for cards 1 and 2 enter '3'. These will be be saved with the default wifiprofile and will connect before wifi. I can see that a ethernet only auto-connect service might be desirable from time to time; this could be implemented by entering 4 in the ethernet auto start field.

[gcmartin]

Sorry for the delay

Code: Select all

bash-4.1$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:1f:c6:28:c7:55 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:1f:c6:29:e2:bb brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.201/26 brd 192.168.1.255 scope global eth1

Thanks. Will test tomorrow and report.

[stemsee]

Do you have access to my machine? Then how can you test it? I haven't posted it yet!!

[stemsee]

With default ethernet start function.

[gcmartin]

Hello @StemSee

Do you have access to my machine? Then how can you test it? I haven't posted it yet!

I had assume (apparently wrongly) that you had already posted in your opening post.

My OSes that I run are 64bit OSes. I see a post, today, for "i386".

So, I'll have to wait for your other versions. Other members, though, could/should/would test the 32bit implementation presented in the preceding post.

[stemsee]

Hi Gcmartin

the only binary included is dhcpcd, i386, you can just swap that out with your x64 dhcpcd, the rest is all srcipt! Having said that it works fine on fatdog64 702

But anyway I may have uploaded the wrong file yesterday.
This one is the correct one for sure.

[gcmartin]

In exposing the PET for testing, I am unsure of a method of replacing the bin file that wont lead to problems. Can you post a PET without the bin file. I will assume that without that included in the PET, the PET/subsystem will use the internal system's DHCPD. And, as such, the replacement would work in any system, 32/64.

Correct?

[stemsee]

That seems correct to me.

Just download the pet posted and use uextract (or what have you) to extract the pet then remove /usr/sbin/dhcpcd binary file from the extracted pet, then rebuild the pet or make an sfs. Maybe run in term 'which dhcpcd' first to see where your existing dhcpcd is.

[gcmartin]

@Stemsee, I am sure you are aware, but might be important.

Some of my distros, i.e. Slacko 32/64 use /usr/sbin/udhcpd. Thus, these do not have a "DHCPD" as is currently in the Wifi-Connect PET for 32bit systems.

What is a proper way to use or test your PET in those systems? Or is there a PET available for those systems?

I ask, because if I remove the /usr/bin/dhcpd from the existing PET, will the Wifi-Connect 2016 functionality work as you expect it in those PUP distros using udhcpd? Thus a PET without the "dhcpd" component will work on all modern PUP distros no matter if they have either dhcpd or udhcpd. Is that correct?

Is a new PET in order?

Thanks in advance.

[stemsee]

If your distro uses udhpcd then you can safely install the pet without overwriting udhpcd. My scripts do not use udhpcd if present although I looked at adding the possibilty just needs two variables, one for acquiring ip and one for releasing lease on interface. The switches/options are different for udhcpd and dhcpcd.

Install dhcpcd(5) using ppm or gslapt, or directly download package and install. I do not maintain dhcpcd, I maintain only wifi-connect scripts (wifiprofi, scanner, eduwifi, hotspot, wifi-connect and wifi-connect-2, and oui.txt for random mac address). All scripts have a routine for informing if any dependency is missing, independent of the installer.

[stemsee]

Here is a pet with no dhcpcd and renamed, in case the name trips the install.

udhcpd/c is the busybox dhcp server which hasn't had work since 2002. Dhcpcd is an external server which had work up to about 4 years ago, on raspberrypi there is ongoing work here https://github.com/raspberrypi/dhcpcd-6 ... /changelog . Work by RedHat is current.

[stemsee]

I see a let-down if the machine doesn't have a wifi-card there is zero functionality for ethernet. So now I will be adding more access for ethernet and usb.

[slavvo67]

Stemsee:

Does this search for wifi drivers on the hard drive and wrap them? It would be nice to have that kind of functionality for people that can't find Linux drivers for their particular systems.

Kind regards,

Slavvo67

[stemsee]

Slavvo

I had a look at how to use ndiswrapper. It seems there are two stages 1) associate the windows wifi driver *.inf with ndiswrapper 2) then use the -D switch to uspecify ndiswrapper as the driver when using wpasupplicant.

To build the module for each system seems to require installing the headers, and compiling ndiswrapper from source. Also requires downloading the windows driver for your wifi card/s and locating it.

I have no way to develope and test such routines as all my wifi cards work on linux.

Actually none of these scripts have the option to test or load other drivers.

If anyone wants to volunteer some tested code, great!

stemsee

[gcmartin]

I can see where system's available drivers would be outside of the scope of this utility. Still the utility has its solid offering for what it does in its mission. Ease!

The driver issue in Puppyland has been a "target" for years with no clear-cut direction. Some developers include all in base ... Some include drivers in zdrv/ydrv/adrv ... Some only include a subset ... Each distro has a reflection of what its developer feel best fro his offering.

This driver problem is consistent across operating systems.

Ease of use, though, and clear guidance in ease of use it what appears, here, leaving driver discovery to the base running system.

[stemsee]

In the meantime here is wifi-connect-30

Solves wlan1/2 start/stop bug in wifi-connect-2 menu.

Introduces code that should allow the gui to start when no wifi-card found (not tested by me as machine has two unremoveable cards)

Solves issue when only one AP is found; loop generated 30 entries the same for when only one AP found.

Scanner early menu wouldn't close