Puppy Network Managers - SNS, Frisbee, NetWiz, Pgprs, Pupdial

[taersh]

Hmm, SNS 3.0 <---> SNS 4.x ???

[rerwin]

Oops. Thanks for catching that. I meant 2.4.x. Corrected.

[rerwin]

Uploaded final versions of the 2.x series and SNS 3.0, available at viewtopic.php?p=2241#p2241.

SNS 2.4.2 adds the "Rescan" button to the wireless setup window, similar to the woofCE version. It is appropriate for Puppys older than TahrPups, which may be unable to use the new 3.0 version.

The final 3.0 package contains some improvements over the beta package. They include:

• the "Rescan" button

• display of the full 32-character network names (SSIDs)

• prevention of configuration file corruption due to a failed new-connection attempt

• correction to the display of splash messages

• many bug fixes and some code cleanup

SNS 3.0 seems to work on Puppys as old as TahrPup64, but not TahrPup32. The determiner is the availability of the "iw" command, which does not appear to be available to TahrPup32. This upgrade version requires at least the busybox version of the 'ip' command and the full version of the 'iw' command. [EasyOS condition removed.]

Again, if you encounter anything "not right" with 3.0, please report that here, so that I might fix it.

Richard

[BarryK]

It can work in EasyOS if the 'iw' command in installed to replace the busybox version of "iw".

I don't recall how long ago it was done, but EasyOS now has the full iw.

[rerwin]

BarryK,

Thank you for your correction. Statement removed.

However, in working with EasyOS 2.8.4 I notice that the connection is not started at boot time as I intend.

The udev rule that supports re-connection fails because the MODALIAS environment variable is absent. The parameter ATTRS{modalias}== (or ATTRS{MODALIAS}==) does trigger the rule and the assignment variable %s{modalias} works. So, I am re-thinking how to detect which drivers should be loaded.

The command, "udevadm info -a -p /sys/class/net/wlan0" command (but for each interface) looks promising, using the first non-null DRIVERS= value, in rc.network. The rule that uses MODALIAS could then be used only for resolving "preferences" (PREFLIST=) in regular Puppys.

Richard

[rerwin]

Uploaded Simple Network Setup 3.1, available at: viewtopic.php?p=2241#p2241

This version reworks the reconnect function to be compatible with EasyOS and any future Puppys that might similarly change the way kernel module loading is accomplished (although I am unaware of any such intent). The issue is that module preferences are not supported in EasyOS.

In addition, the splash messages now use gtkdialog-splash instead of yaf-splash because they are identical in Puppys but are different in EasyOS, where yaf-splash does not support all of the gtkdialog-splash options.

This version also has a few bug and internationalization fixes. See the change descriptions at: viewtopic.php?p=2249#p2249

A note about the wifi re-connection process:
Instead of connecting to the first interface and network that becomes ready at boot-up, the priorities in cases of multiple interfaces or networks are:

• The first wireless interface in the connections list is used as soon as its driver is loaded.

• If the first interface is not installed (USB dongle removed), other interfaces will wait for drivers until timed out after 8 seconds.

• The networks will be checked in the order they appear in the Connections list, on the first listed interface that is active.

• If no wireless interfaces or networks are available, an available wired ethernet interface will be used.

As usual, please report anything that does not seem right about this release.

I would like to submit this to woofCE, if there is no objection. Should I wait until translators have had a chance to provide some translations for the new text domain, "simple_network_setup"?

Richard

[rerwin]

puppytrue,

Thanks for your inquiry.

AFAIK, the "3G" tools should work for 4G. I have not seen any postings indicating that they don't.

Either pupdial (Dialup...) or pgprs (Wireless GPRS...) should work. Let me know if they don't.

Richard

[rerwin]

puppytrue,

From your links I conclude that you have been unsuccessful with any other linux distro. Right?

It may be a driver issue. Please tell me what you know about your 4G modem. Also:
- If it is a PCI modem, what does 'lspci -nn' show?
- If it is a USB modem, what does 'lsusb' show?
- To check for a firmware issue, what is the output of:
dmesg | grep 'irmware'

I need that information so I can check if linux supports it and what its driver is.

And also please test with fossapup64 (or fossa pup 32 if necessary).

Richard

[rerwin]

Uploaded Simple Network Setup 3.2, available at: viewtopic.php?p=2241#p2241

This version improves the support for wired ethernet to give the user better control over its automatic bootup/restart prioritization relative to wireless interfaces. In addition, wired interfaces are retried for recovery from slow hardware.

Now, like for wireless connections, new wired connection profiles are added to the top of the connection list, so that they can become the "default" interface. Previously, wired interfaces were checked only if no wireless connections were available. Thanks to @vin for alerting me to the need for this capability, at https://forum.puppylinux.com/viewtopic.php?p=37765#p37765.

To reduce the likelihood that a wired connection fails at bootup, particularly if it receives an invalid IP address (169...), the connection will be retried after 5 seconds, twice. As always, if the first-listed interface exists but does not respond, there will be a delay before other interfaces are tried, to allow for slow hardware.

To be consistent with the rc_network log of wireless connections, the similar log for wired connections is now /tmp/simple_network_setup/rc_network_wireless_connection_log (instead of sharing /tmp/sns_wired_log).

Note that the package was reloaded late on 10/7/21, so the first 2 downloads should be replaced. I assume they were automatic downloads for archives. The reload fixed a few minor bugs.

I plan to submit this version to woofCE but am concerned that I have not seen any indication that translations have been made or planned for it. The new domain for SNS is "simple_network_setup" instead of sns___sns, etc.

As usual, please report anything that does not seem right about this release.

Richard

[Clarity]

HI Richard, I am a constant user of this in PUPs.

Curious: Is there any reason why the logs are kept there versus maintaining them in /var/log along-side other important system logs?

Merely curious: I am sure if it make sense, it will move in the future.

[rerwin]

Clarity,

Keep in mind that SNS was originally written more than 15 years ago. I suspect the logs were mainly for debugging. I doubt users are concerned about them. Just an opinion.

[redquine]

As mentioned in response to viewtopic.php?p=40773 :

I started using SNS to set up a tethered connection. It reported a successful connection to usb0 and there was a flashing icon in the system tray. I was initially able to use it without issue. The next time I connected my phone, I again had a success report and flashing icon but was unable to connect to anything in my browser.

On investigation, I found that the MAC address originally used was no longer valid. My phone appears to issue a new address each time I switch on USB tethering; I don't know if this is common behaviour or specific to my phone & Android version, but I could not find any way of controlling it.

My workaround was to:
1. Find the current address at /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-5/2-5:1.0/net/usb0/address - this pathway varies between installs but should be something similar on yours.
2. Manually replace the address at /etc/simple_network_setup/connections and save it. (Before updating SNS, I had to change the address to upper case before saving it.)
3. If already "connected", I needed to "disconnect" and reconnect at this point.

I appreciate this would be practically impossible to test with every combo of system and hardware but in case these details are useful, I'm using:

Fossapup64 9.5 on Toshiba Satellite P200-17C
Android 8.1.0 on Moto G5
SNS 3.2

[rerwin]

@redquine,
Thank you for working this with me.

On investigation, I found that the MAC address originally used was no longer valid. My phone appears to issue a new address each time I switch on USB tethering; I don't know if this is common behaviour or specific to my phone & Android version, but I could not find any way of controlling it.
. . .
but in case these details are useful, I'm using:
. . .
Android 8.1.0 on Moto G5
SNS 3.2

With that information I found this:
https://www.techrepublic.com/article/ho ... ndroid-10/
which explains the random MAC addresses for privacy reasons. Although the article is about wifi privacy, the randomization apparently applies to the wired/tether connection, as well. (Or is there a similar option for a wired/tether connection?)

The seemingly obvious way to prevent the randomization is to temporarily change the setting to "Use device MAC" before attaching the tether, and restore "Use randomized MAC" after disconnecting the USB tether.

Settings > Network & Internet > Wi-Fi > gear icon associated with the wireless connection to be configured > Advanced > Privacy > Use device MAC|Use Randomized MAC.

If that workaround is unacceptable, I will need to code a way to tolerate the randomized MAC addresses, which seem like the "wave of the future".

BTW, for your workaround, you should not need to capitalize the substitute MAC address because SNS 3.x uses lower case for profile MAC addresses.

Richard

[rerwin]

@redquine ,
To fix the code to handle randomized MAC addresses, I am considering using the interface name as an indication of that possibility, usbx. I need to know what the other form of the name is, too. Peebee's bionicpup32 (upupbb) and later upups use the "predictable" form of the names.

Could you run with one of the upups to see what interface name it uses instead of usb0?

I assume that all Android phones use the same interface name for tethering (e.g., usb0). If anyone reading this post knows of another interface name associated with tethering to phones, such as possibly for iPhones, please tell me here or by PM.

TIA
Richard

EDIT: I am finding that using the interface name to identify possible tethered phones may be too simplistic. I may need to use a udev rule to set a specific name for such cases. That will take more research. I welcome anyone's thoughts about identifying a tethered phone through /sys/class/net or any other way.

[rerwin]

@redquine,

I am hoping to use info from the lsusb command to identify phones. Could you run "lsusb -v" for me and send me the output by PM, as a file if you can, or in the message. It produces too much output to include here (although a zipped file would be OK). But the output of:
lsusb -v | grep 'Product'
would be OK to post here, too.

Thanks.

[redquine]

Output as requested:

Code: Select all

root# lsusb -v | grep 'Product'
  idProduct          0x2e25 
  iProduct                2 Moto G (5)
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable

I haven't had a chance to boot with a upup yet but I'll get back to you tomorrow about that.

[redquine]

@redquine ,
To fix the code to handle randomized MAC addresses, I am considering using the interface name as an indication of that possibility, usbx. I need to know what the other form of the name is, too. Peebee's bionicpup32 (upupbb) and later upups use the "predictable" form of the names.

Could you run with one of the upups to see what interface name it uses instead of usb0?

When I tested it with upupFF+D, it came up as usb0 as well.

EDIT: I am finding that using the interface name to identify possible tethered phones may be too simplistic. I may need to use a udev rule to set a specific name for such cases. That will take more research. I welcome anyone's thoughts about identifying a tethered phone through /sys/class/net or any other way.

In case it helps: the only files in /sys/devices/ with the exact name 'address' are under their device names. For example, my full list is:

Code: Select all

/sys/devices/pci0000:00/0000:00:1c.1/0000:04:00.0/net/eth0/address
/sys/devices/pci0000:00/0000:00:1c.2/0000:05:00.0/net/wlan0/address
/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-5/2-5:1.0/net/usb0/address
/sys/devices/virtual/net/lo/address

Each of those subdirectories has a heap of other files in it. Do any of them help to identify the device type?

[rerwin]

@redquine,
We are thinking along the same lines. But I am curious about the driver used for the tether.

SNS finds the driver by a command related to:
udevadm info -a -p /sys/class/net/usb0 | grep 'DRIVERS=='

Please try that command when tethered. Maybe the driver is key to detecting such tethers.

Another possibility to try is:
ls -1 /sys/class/net/usb0/*/device/driver/module/drivers/

I hope to see "phy-cpcap-usb" but maybe whatever driver you find will work, too.

You might also try:
lsmod | grep '^phy-'

TIA

[redquine]

Code: Select all

root#  udevadm info -a -p /sys/class/net/usb0 | grep 'DRIVERS=='
    DRIVERS=="rndis_host"
    DRIVERS=="usb"
    DRIVERS=="usb"
    DRIVERS=="ehci-pci"
    DRIVERS==""

Code: Select all

root#  ls -1 /sys/class/net/usb0/*/device/driver/module/drivers/
ls: cannot access '/sys/class/net/usb0/*/device/driver/module/drivers/': No such file or directory

On investigation, /sys/class/net only contains symlinks to the directories I mentioned earlier.
The command lsmod | grep '^phy-' didn't seem to do anything.

[rerwin]

@redquine,

Code: Select all

root#  udevadm info -a -p /sys/class/net/usb0 | grep 'DRIVERS=='
    DRIVERS=="rndis_host"
    DRIVERS=="usb"
    DRIVERS=="usb"
    DRIVERS=="ehci-pci"
    DRIVERS==""

OK!
rndis_host seems to be the driver I am looking for! I suspect it should work for all phones.

Thank you. Now I can proceed with modifying the SNS code.

[rerwin]

Uploaded Simple Network Setup 3.3-beta, available at: viewtopic.php?p=2241#p2241

I call it a "beta" because command tracing is turned on so I can diagnose any problem that may arise, and because it needs some verification by testers. The traces will be logged in /tmp/bootsysinit.log and /tmp/xerrs.log.

This version adds support of dynamic MAC address "spoofing", in two ways:

• For a wireless connection, the interface's MAC address is changed to a random value appropriate for the vendor of the interface hardware when the "macchanger" package is installed.

• For tethered smart phones (and other "gadgets") that "spoof" their MAC addresses (e.g., Android phones) and change them from time to time, they are accommodated. (Thanks to redquine for reporting the need for it.)

Macchanger is available in a package repository, accessible by the Puppy Package Manager and other tools. Note, however, that the TahrPup version of macchanger does not change the MAC; after installation, replace /usr/bin/macchanger with the XenialPup (or later) version of it, to make it work as intended.

@redquine Note that the tethered gadget capability needs to be verified because I could only simulate the condition based on my assumptions about how it works.

Implementing the spoofing capability uncovered the need to correct the module-loading detection and fix some other functions, which are included.

Testing with VoidPup32 necessitated reworking the udev rule that detects the initiation of module loading. It seems that in recent Puppys the old method of loading by the pupevent_backend_modprobe script is no longer used. It provided the possibility of substituting preferred driver modules, which appears to still be offered as a possibility. If that function is provided another way, I am unaware of it; otherwise, that capability may no longer work. Anyone who needs this, please test SNS for it in a recent Puppy.

As usual, please report anything that does not seem right about this release.

Richard

[redquine]

Many thanks, Richard!

I've tested it three times on FossaPup 64, switching both laptop and phone off between tests (so the MAC address definitely changed each time). The third time, I waited until the desktop came up before switching on USB tethering; I could simply click the network icon and 'Connect Now'.

It seems to connect faster than Frisbee as well, so I'm now using it as my default. I'll let you know if I run into any problems but all's well so far.

[rerwin]

redquine,

Thank you very much for testing this version (and your "thank") and for reporting your success.

The tether-spoofing issue got me to look into spoofing. I was unaware of the "tracking" issue resulting in the cell phone MAC address spoofing.

I imagined some people would want to avoid tracking of their laptops, too, so implemented spoofing support in SNS. I am interested to see comments about that.

Richard

[Neo_78]

Do you plan to implement MAC address spoofing for ethernet connections?

[rerwin]

@Neo_78,

Thank you for asking about ethernet and spoofing.

The decision was arbitrary. Since cell phones are wireless and can use wifi, I figured that SNS wireless spoofing is consistent with that. Wired ethernet spoofing seemed less necessary. The implementation has spoofing on for all internet connections, but not for local static IP addresses.

I infer that you would like to add spoofing of wired connections, too. I can add that easily for beta2.

What is not so easy is implementing control of the usage of spoofing other than by installing macchanger or not. Are you OK with that situation? Or anyone else, too?

Just be aware that the spoofed MAC address will change at each boot-up. A router's list of active IP addresses will increase with repeated rebooting within 24 hours, which might slow it down when returning new IP addresses. I think I saw that with my test setup, where my ethernet connection had to be retried (a ~20-second delay) and sometimes failed during boot-up. But manual reconnecting succeeded. The slow-down went away a day after I stopped using spoofing, I assume because connection authorization expires after 24 hours.

Richard

[rerwin]

Uploaded Simple Network Setup 3.3-rc, available at: viewtopic.php?p=2241#p2241

The noticeable changes from the beta are:

• Spoofing of MAC addresses is extended to wired ethernet interfaces as well as for wifi, except for tethered gadgets/smartphones, which provide their own spoofing.

• Reconnecting when a wired ethernet interface is unplugged is much faster due to the elimination of waiting for all interfaces to be ready. However, a 23-second delay may occur during boot-up. This is due to waiting for possibly slow interfaces (previously reported to be necessary).

Further bug fixes and code refinements were implemented.

As usual, please report anything that does not seem right about this release candidate.

Richard

[rerwin]

Uploaded Simple Network Setup 3.3, available at: https://archive.org/download/Puppy_Linu ... -3.3.1.pet

The noteworthy changes from the release candidate are:

• The maximum wait time for dhcpcd requests for IP addresses is increased from the default 30 seconds by 10 seconds, to accommodate possible delays resulting from the changing of spoofed network-interface MAC addresses. This should reduce the random connection failures due to not receiving a valid IP address but getting "169.254..." instead. If anyone continues to randomly see "169.254..." addresses or very long (20 seconds or more) delays in reconnecting, please report that in this thread (or by PM to me).

• Although it may be moot, when the 'iw' command is not installed, instead of refusing to start SNS, wired networks are supported but attempts to connect to a wireless network result in the wireless setup window stating that the 'iw' command is missing.

• When installing the SNS .pet package, any old-format (SNS 2.4...) connection file will be removed, instead of being saved for restoration if the package is uninstalled. SNS 3.x connections are retained.

Further code refinements were implemented.

Note that when spoofing is active, due to the installation of the macchanger package, SNS shows a message that the "active" interface's hardware/MAC address is spoofed. However, because the spoofing occurs only when a connection is made, the MAC may not be spoofed after the installation of macchanger but before reconnection. Also, if the active interface is changed, the previous interface's MAC will remain spoofed until the next reboot.

As usual, please report anything that does not seem right about this release.

Richard

[rerwin]

This package, network_connect_update-20220122, corrects a recent change made to connectwizard and makes some minor changes for probably-rare cases. It is available here: viewtopic.php?p=2241#p2241

It removes a dependency on 'ethtool', allows control of ethernet connections when no network managers have been used, and may reduce the incidence of invalid IP addresses if MAC spoofing is in effect. Details:

• Connectwizard windows are centered on screen (as in FossaPup), instead of cascaded from upper left.

• Connectwizard no longer sets current manager name for pgprs because pgprs now changes it only when connecting, allowing viewing of its setup without making it "current".

• Connectwizard and network_default_connect accommodate connman alternate network manager.

• The default ethernet interface (used when no network manager has been set up) can now be disconnected and reconnected with the network tray icon.

• The default ethernet setup no longer uses ethtool to check for "plugged in", replaced by ip-show and a test for LOWER_UP.

• The default ethernet setup waits 10 seconds longer for an IP address, which may reduce the incidence of failure (indicated by an address of 169.254...), possibly more likely if MAC address spoofing is used on a LAN.

All components have been checked with 'shellcheck' and have had its warnings resolved, making some of the code more efficient, simpler and less vulnerable to coding mistakes.

As usual...

Richard

[rerwin]

New Puppy distros built from woofCE since January may contain a version of the Connect Wizard script that impacts the use of a default network manager.

If one merely displays the Connect Wizard and clicks "Ok", the default is changed to PupDial, the first in the list of "radio buttons". Thus, any further attempt to use "Setup networking" from the "Network" tray icon starts PupDial!

The workaround is to avoid clicking "Ok" on the main "Connection" tab. Clicking on the X button to abort or selecting an option does not change the default. And changing the default (under the "Desktop / Tray" tab) and clicking "Ok" succeeds.

This has been fixed in the network_connect_update package announced just above, which contains connectwizard and related updated scripts.

For anyone not ready to install that entire package, I attach only its connectwizard as a gzipped file that should be placed in /usr/sbin and be clicked on to unzip it in place. Or unzip it elsewhere an move it to /usr/sbin.

Richard

[rerwin]

The package, network_connect_update-20220407, contains minor updates, including 2 synchronized with woofCE. The only operational change is that the default wired ethernet starter (rc.network_eth) will retry (once) obtaining an IP address if the initial attempt fails, usually indicated by appearing to obtain a 169.254... address.

It is available here: viewtopic.php?p=2241#p2241