The Track network card id (useful for laptops) option is no more in drakconnect.
It was used to set the HWADDR variable in ifcfg files, so that network interfaces names are assigned according to the interface MAC address. But since we do this by default using udev rules anyway, it isn't necessary anymore, and only confuses users with a weird option label.
(and it fixes #23414 as a side effect)
While working on an internal project, I used the occasion to make the network backend easily re-usable, to build configuration tools in a flash.
I tried to build a new simple interface, that allows to connect in a few clicks, whatever the connection type. Some snapshots (WIP) are available, but I should take them again to show the current state:
Additionnal configuration (mainly authentication) could be done in a popup window, with the possibility to save the settings. That may sound very Gnome-ish :-p
I hope this tool will soon end up in cooker.
The new network tool got some GUI updates, mostly about widgets sensitivity. It now allows to set up basic authentication data (login, password) for ppp connections (POTS and xDSL modems).
I'll try to move most of the common stuff about ppp connections in the new network::ppp module, this includes configuration files management, but also listing the required authentication fields. These fields are meant to be used by interfaces, so I've used the same data structure that in the interactive module from DrakX (which doesn't depend on specific interface code).
This way, it could be re-used in our other network interfaces, factorizing again the code. Our current network tools (wizards and some Gtk2 programs) already use the interactive layer. Unfortunately, it's not currently possible with interactive to add Gtk2 widgets in an existing window, so my first draft reimplements (big) bits of this module. But, hopefully, it will get fixed next week!
I've finally handled SIM code entering in the network::mobile_data module, using non-blocking IO and the IO::Select module. It's tricky to parse gcom output since no newline character is written after the "enter SIM code" message... So, the new network tool is now able to fully initialize 3G/Edge/GPRS cards managed by gcom, and to list networks.
Another 3G/Edge/GPRS requirement is to run AT commands to establish the connection, but they're specific to the card. The new network tool should be able to write the right AT commands in a chat script when a card is selected.
This GUI has also a new generic way of displaying networks, that I implemented for 3G first, barely based on drakroam. The nice thing is that once it's done for a connection type, we get it for free (well, 2 lines of Perl actually) for other connection types (for example wireless).
It also handles static lists of providers, they are displayed in a treeview the way the drakconnect does. Same thing, once it's done for xDSL, the POTS providers are supported some minutes later.
Yet, the new interface allows to select devices, initialize them, list networks if possible, select a provider if possible. I just have link that to the actual connection tools, asking authentication parameters first if needed.
A new network configuration interface is being developped (for a client needs). It aims to be a simple tool that allows to connect to Wireless/GPRS/3G/Edge/POTS/xDSL network connections. It basically consists in selecting the connection type, selecting the device, then the network/provider, and here you go. It would eventually ask authentication paramaters (if needed or not already supplied) in a popup, so that the main window remains simple.
Detailled specs have been written, this may help design and tests of network tools, I'll try this work available in the community wiki when possible.
Although this is developped for a specific contract, the code is GPL, and the benefits for the "community distribution" tools are quite nice. It involves rewritting, factorization and abstraction of many of our network modules, and I wanted to do that for a long time.
Additionnally, this interface could be used as a basis for a future network tool, our existing network tools are quite not user friendly :-p
Anyway, since I aim to keep the interface code the lightest I can, it would be damn easy to derive new interfaces from this new one :-)
I've started to build a generic connection type class, to simplify the network interfaces. Currently, a lot of code exists for each connection type, while it can often be done in a similar way. Furthermore, since there is no defined interface, interfaces often tend to duplicate the work. Connection type abstraction would allow to build interfaces faster and probably to simplify them.
This abstract connection_type class would be implemented for ethernet, isdn, mobile_data, pots, wireless, xdsl. The current draft allows to list devices for some basic types (ethernet, wireless, xdsl), and some GUI utilities (get human readable name and icon). It will be extented to list network and providers for a specific device.
When their RF kill switch is on, some wireless devices (ipw2200 for example) don't report their real MAC address, but a zero one instead (00:00:00:00:00:00). These MAC adresses are written in /etc/iftab by drakconnect when a new network interface is configured.
When new network interfaces are created by the kernel, the net agent from hotplug lauchs ifrename to rename the new device according to iftab. However, it has an odd behavior when this file containes a zero MAC address, and the result seems quite random, depending on which network device was created first.
To prevent this situation, drakconnect shouldn't write zero MAC addresses, but ignore them instead.
It may even warn the user that the interface has a zero MAC address, and suggest him to turn the RF kill switch if it is a wireless interface.
The initscripts now allow to have multiple default network routes (since 10.1), but this may lead to problems when the first added route is wrong.
This can happen if both a local router and DHCP DSL server are used. The local router often provides first a wrong default route in its DHCP reply, and then the DSL server provides the real gateway. The route from the local router is preferred because it is the first one, but since the local router doesn't provide a gateway to the Internet, all requests to the outside fail.
I think that this problem comes from the local router, which shouldn't provide a default route if it can't ensure it's available.
Anyway, this kind of scenario happens to exist, and it can be workarounded using some "advanced" features of the initscripts, the metric settings. While the automatic settings works great if the provided routes are correct (e.g. one real gateway on the local net and another wireless one), they miserably screw the connection up if the local gateway is invalid, preferring it over the DSL/wireless one.
A solution is to use an higher metric for the invalid route, so that it isn't used before the real route. For now, this can be set in the ifcfg files, or using the "manage" interface of drakconnect (--skip-wizard option, I'll handle --manage option too), but it isn't available in the main drakconnect wizard.
After 2005 LE is out, I'll add this metric options in the wizard too, so that it can be set up using the text interface of drakconnect (since the "manage" interface only works in graphical mode).
Some wireless cards can't get properly detected unless some action is done on the device. Their wireless drivers don't always support the SIOCGIWNAME ioctl, making tricky to detect if a device supports wireless.
sysfs can help to detect if a card support wireless, because for all XXX interfaces supporting the get_wireless_stats() function, a /sys/class/net/XXX/wireless folder exists.
For example, Ralink (rt2x00) devices need to be up to support this ioctl. This has been workarounded in drakconnect for 2005 LE by bringing up network devices for which this sysfs path exists.
For wlan-ng (prism2_* modules), this is even trickier, since they need some special tweaks issued with the wlanctl-ng command. That's why drakconnect didn't recognize wlan-ng cards if the prism2-utils package wasn't installed.
/proc/net/p80211/*/wlandev could be used to detect wlan-ng cards, but this would add another uneeded detection trick, which can be replaced by the sysfs detection method (works only for 2.6 kernels though).
After 2005 LE, it would be nice to use sysfs as fallback to detect wireless interfaces, so that wlan-ng cards can work out-of-the-box and Ralink specific tricks can be removed.
