If sleeping or hibernating, hardware can be detached and reattached as long as it's the same port and interface without causing problems.

To be honest with you, all operating systems kinda behave this way. Windows, for example, will reattach a disconnected network1 device as network2 when reattached even if it's the same hardware as long as the system in in the active/running state.

I tested hotplugging a wireless usb device, same one, on slackware 14.1, and slackware current (as of today, dec 3rd, latest update) multiple times. So despite ReaperX7 speaking on how OS handle hotplugging, and despite what USUARIONUEVO shows in his 70-persistent-net.rules, I cannot reproduce the behavior. My device net dev name is persistent with udev and eudev. I did try different ports, but in my case, they appear to be all on the same bus. However, I think that usuario found this still even plugging into the same port multiple times. If that is the case, then I cannot reproduce his problem at all. I'm glad since I was a little worried that eudev was different for some reason.

Couldn't replicate this either, it's just a single line per interface here.
I may have an idea where it's coming from, you should be able to break it in (/lib/udev) 75-persistent-net-generator.rules
.. by dropping everything that isn't eth0 or wlan0 :
.. and commenting out the renaming part :
It's a theory anyway, not sure how this would work if copied from /lib/udev into /etc/udev

As others can't reproduce your issue, we should first make sure that it is not the consequence of a mistake done when upgrading.

In that aim I suggest that you do a fresh installation of Slackwate-current (32-bit or 64-bit) using one of the ISOs provided by Eric Hameleers here and see if the problem persists.

I test this in to a alienbob livecd iso beta 2 (liveslack) fresh boot (no persistency)

If reboot , then the device goes to permanent name. (slackware installed on hard disk or fresh install to original iso)

Then i think its because are added into hardware.db but no work if no reboot.

When start with device plugeed, is added to db and then the rule works when arrives to desktops.
When start with unpluged , then device is added but (i think) not in db , then the rule goes to dinamically

need static, without reboot.


no need plug/unplug ... rmmod/modprobe do the same.

I test with two different usb cards ,different chips , do the same actions.

We can't draw a conclusion from that. Please use one of the ISO I suggested.

OK , i download and install a new iso from 3 december and test , i thinking around record with recordmydesktop. :=)

You might want to consider talking to eudev or the kernel driver team. Also, I'm not sure what other network device you tried, but make sure you tried a device that has a completely different driver stack. There is such a thing called a "usb device #" that always increments on plugging a device--meaning every time you plug something in, it ensures that the device has a unique, fresh instance. ReaperX7 is right in his perspective of the usb subsystem, and that could be an influence eudev to not be persistent, if the information given eudev on the hotplug event is always different. There is something else going on. Personally I think that eudev isn't necessarily the culprit, but could be the driver stack your device uses. Or a failed upgrade. It definitely should not behave this way from the user perspective, so make sure that your eudev configuration is the same as stock and then pursue the driver/eudev interaction.

I tested things out on my end and I did find that if I'm running the Huge kernel, eudev doesn't need to trigger an event to reload the driver module, but when I use the Generic kernel, each time, eudev triggers a reload event my device changes nodes.

Are you running huge kernel or generic kernel?

For specific devices such as a USB to RS422 cable I add a symlink to the udev rule. That way I can unplug/plug it and the symlink will always be pointing to the right port.