I have removed the bridge service in cooker, since it can be better replaced with the standard network configuration scheme. Bridge interfaces can be configured using /etc/sysconfig/network-scripts/ files.
While at it, I have also documented bridge interface configuration on the wiki.
The s2u bus is already used to notify hostname modifications, with /etc/sysconfig/network-scripts/hostname.d/s2u.
It could be extended to handle more network events:
This could be done by adding a minimal number of hooks in the /etc/ifplugd/ifplugd.action and /etc/sysconfig/network-scripts/ifup-eth, by calling a s2u-notify wrapper around dbus-send:
#!/bin/sh # usage "s2u-notify <com.mandriva.user member> <string argument> if [ -z "$1" ] || [ -z "$2" ]; then exit fi dbus-send --system --type=signal /com/mandriva/user com.mandriva.user.$1 string:$2
Events would then ben sent using such a sequence:
[ -x /usr/sbin/s2u-notify] && s2u-notify hostname foo [ -x /usr/sbin/s2u-notify] && s2u-notify link_up eth0 [ -x /usr/sbin/s2u-notify] && s2u-notify dhcp_start eth0 [ -x /usr/sbin/s2u-notify] && s2u-notify dhcp_failure eth0 [ -x /usr/sbin/s2u-notify] && s2u-notify zcip_start eth0 [ -x /usr/sbin/s2u-notify] && s2u-notify zcip_success eth0
This can be monitored using:
dbus-monitor --system interface=com.mandriva.user
This solution is really easy to implement in system scripts, and it doesn't require much in user applications such as net_applet and drakroam, they just have to listen for events on the com.mandriva.user interface.
The "message" member of "com.mandriva.user" is only used for hostname, it could be renamed as "hostname" (and have the new hostname as arg), or maybe use a different object path.
To change the bridge interface in VMware, the vmware-config.pl script can be used, or eth0 can be manually replaced with eth1 in the /etc/vmware/location file.
Our udev scripts were quite buggy in Mandriva 2006 regarding vmnet interfaces, they were automatically set up to use DHCP, which is wrong. An updated package in Mandriva 2006.0 community fixes this issue, but the /etc/sysconfig/network-scripts/ifcfg-vmnet* files have to be manually removed.
Vanilla vmnet module from VMware workstation oops when using bridge over wireless. It seems to be fixed in VMware-any-to-any-update patches.
It seems to be working on Suse 10.1 with VMware server, according to a Wireless and bridging topic on VMware forums.
Though, I was only able to connect with the host system, and not to other hosts on the local network. I've tried various ipw2200 and kernel releases, so the problem would be more likely to be on VMware's side.
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)
wpa_supplicant looks broken with ipw in Mandriva 2006.0 (see #18195). We can't backport wpa_supplicant directly, we need to select the right patches.
I've started a network::cellular_providers module that aims to include information about mobile internet providers. The most important one is the APN (Access Point Name).
Currently, it only includes some french providers.
I should probably use some scripts to import the data from these lists:
For consistency, the old network::adsl_consts module as been renamed as network::xdsl_consts.
The configuration tools can now ask for settings that are required to "boot" the hardware, if the connection type requires it. This is useful for 3G PCMCIA cards, that require a PIN code.
This hardware step asks for the settings, and allows to go on only if the device initialization is successful.
The common ppp layer in network tools is now enhanced to support chat scripts as well. This allows to re-use a lot of common code in 3G and Bluetooth modules.
When a dial number is specified, a set of generic AT commands is written to the chat script, and can be extended by a connection type-specific array of AT commands.
Mandriva network tools now have a basic mobile internet support, using either PCMCIA cards, or mobile phones over bluetooth. Though, it can still be improved.
These tools only support GSM (GPRS/EDGE/3G) for now. It would be nice to have CDMA (1xRTT/1xEV-DO) support as well :
More AT commands could be supported, such as AT_OPSYS (to select the preferred network type):
The "replacedefaultroute" patch could be applied to pppd, so that it can add a default route even if another already exists. A better solution would be not to check default route on other interfaces.
Gentoo's wiki page about bluetooth might be of some help to debug connections over bluetooth.
drakconnect can now configure Internet connections using mobile phones over Bluetooth.
It basically uses sdptool search DUN to list phones providing a network service, and configures rfcomm devices in /etc/bluetooth/rfcomm.conf.
The rfcomm.conf configuration is quite brutal for now, I'd rather use something like libconf to do that. But well, writing an high-level Glueconf module looks quite weird to me, judging by the Samba example.
Some D620 laptops come with a Connexant HDA D110 MDC V.92 winmodem, plugged on the High Definition Audio (HDA) bus.
snd-hda-intel : Intel Corporation|I/O Controller Hub High Definition Audio (vendor:8086 device:27d8 subv:1028 subd:01c2)
It seems Linuxant has released hsfmodem drivers with HDA bus support, but I didn't get a chance to try it. Anyway, it requires a recent alsa release, that wasn't available in Mandriva 2006.0.
/proc/asound/card0/codec#1 and /proc/asound/pcm (grep for m/modem/i ) could be used by drakconnect to detect such cards.
References:
Several bugs prevented the domain name guess to be correct in drakconnect (#22480). It now makes sure guessed domain names really contain a name, and not just a TLD. It also doesn't overwrite user-provided domainname by the one it guesses.
Since we now have the latest ipw2200 module in cooker, I've made the wireless thirdparty structure require new the firmware files (ipw-2.4-*.fw).
The generic connection layer now supports selection of the protocol (auto/DHCP/static), so it will allow to merge some more steps in the drakconnect wizard (the same will be used for xDSL/POTS/Ethernet/wireless).
drakroam has been adapted to the new keyring image location in usermode (#22495), but I should really request new encryption icons to our graphical team.
It would be nice to have one icon for weak encryption (WEP) and one for strong encryption (WPA), much like it is on my Nokia 770.
drakproxy didn't use to export the https_proxy environment variable in the 2006.0 release, it generates a lot of problems for Kiosk users that need to pass through such a proxy.
A good fix was already available in cooker, but couldn't be backported because of translation issues.
I've patched drakproxy to export https_proxy with the content of http_proxy. It's quite a minimal fix, but should be enough for Kiosk. See bug #19666 and the related Club threads for more info.
xDSL settings can be set-up using the network::thirdparty structure, that is to say using the generic infrastructure that allows to match network devices and their firmware/packages/modules settings. It now also includes ppp settings, and makes all the remaining bits of the old DSL module unnecessary.
The network::xdsl module also contains generic protocol-related settings, because latest xDSL drivers seldomly require specific configuration.
cable and dvb have a quite empty implementation for now, but it will be completed soon.
So, now that we got a nice generic layer, and an implementation for both xDSL and mobile data devices, it's time to rebuild interfaces using it.
I started to add hooks for these generic steps in the drakconnect wizard. Compatibility structures allow to keep the old steps for wirelessethernet configuration, but there days are now counted.
The abstraction is going on, POTS/xDSL and mobile data configuration modules now have a common network::ppp base class, as well as a common network::connection base class. Ggrmpf, I now have to handle multiple inheritance!
This new network::ppp class aims to factorize all of the /etc/ppp/peers/ files handling, and also the secret files (passwords).
Most of the xDSL options are now build using this module, using a temporary compatibility layer in old modules I plan to drop.
The xDSL layer also includes generic connection/disconnection methods.
Thanks to the introduction of ueagle-atm and the use of firmware hotplugging for the speedtch module, I decided to clean our DSL configuration code.
We used to have a lot of tricks for a lot of modems in a lot of different places, but this is now quite dead. I've already moved most of the dectection code to the network::xdsl module, using the generic network::connection class.
It already shares some code that is used in the network::mobile_data and network::posts classes.
This abastraction will make interfaces really simple and not (much) dependant on the connection type.
Since ueagle-atm is now included in the cooker kernel, and even in upstream kernels, it was high time to drop the old eagle-usb module and its eponym package.
I've dropped this package, We now use the ueagle-atm module and its new firmware hotplugging feature. drakconnect is able to handle the new ueagle-data firmware files, located in /lib/firmware/ueagle-atm.
I happily removed a lot of eagle-usb-specific code, and moved on more generic code.
As of kernel 2.6.10, the speedtch module doesn't need modem_run anymore to load the firmware, it uses the generic firmware hotplugging infrastructure. It allows to reuse most of the configuration code for USB modems (orevious speedtouch and eagle-usb packages), and to remove the crappy hacks I added in udev rules to wait for /usr to be mounted (firmwares are in /lib).
But it's not as easy as it was previously, where we simply had to copy the mgmt.o firmware files from Windows drivers. Now, this firmware has to be splitted in two stage files (speedtch-1.bin and speedtch-2.bin). This is done by the firmware-extractor tool, that I package in the speedtouch-firmware-extractor package.
I added support for this new tool and firmware files in drakconnect, so that I can build the new firmware files easily (it can find the original firmware on a Windows partition, and it also allows to manually choose a firmware path now).
This required some new features in our DrakX modules:
To make it even easier, I've renamed our previous speedoutch_mgmt commercial package as speedtouch-firmware, and build the two firmware stage files for each modem revision (0, 2 or 4), naming them as speedtch-$stage.bin.$revision (which works fine with the speedtch module).
When a hotspot doesn't broadcast an ESSID, some drivers (such as ipw) report it with the <hidden> ESSID. drakroam correctly handles this case: it shows the access point MAC address when it doesn't know the hidden ESSID, and it shows the ESSID if the hidden hotspot has already been configured.
Well, at least it did handle that when wpa_supplicant was used, but it was broken for the "standard" way (using iwlist). I must have been on drugs when I wrote this piece of code, but it is now fixed in SVN, cooker and 2006.0 update packages should follow soon.
Thanks to Scara for spotting this!
The DrakX network backend now supports GPRS/Edge/3G/UMTS cards managed by the option (using usbserial) and serial_cs drivers.
It's only a matter of detecting the cards that use this driver, which is automatic for PCMCIA cards appearing on the USB bus and claim they use the option module.
It's a bit more tricky for cards using serial_cs, since this module is rather generic, and manage a lot more than 3G cards. So, I improved our PCMCIA devices detection to use sysfs to read descriptions, and consider the card is 3G powered only if the description matches /GPRS|Edge|3G|UMTS|H.DPA/i.
3G now works (great) in the 2006.0-mobile branch of the drakxtools. Only the backend stuff can be found there, since the fronted is developed for specific needs.
Basically, this 3G/Edge/GPRS backend can:
It integrates nicely in the new generic connection framework. It shares most of the interface stuff with the wireless module, since both 3G and wireless are about listing networks and connecting to them.
I've also splitted configuration stuff out of drakroam, and moved most of the stuff to interface-agnostic modules. This makes possible to write a very generic interface in a couple hundreds of code lines, managing all supported connection types.
To test all this stuff, we got a 3G subscription, that was sold with a Nokia 6680 phone. It means I know have the required stuff to make connection over Bluetooth just work.
So, stay tuned :-)
As many laptops nowadays, the Dell's D820 we are currently certifying at Mandriva includes an HSDPA card. French models use a Novatel Merlin EU740 PCI Express card.
See a nice review of HSDPA on D820.
gcom allows to enter the PIN code for this card, but then it fails to detect the current network, while it works fine using AT+COPS? in minicom. Maybe I can use gcom with custom scripts and adequate delays. gsmctl (from gsmlib) fails to manage this card.
Once the device is reachable through serial port devices, the only important configuration is the APN (Access Point Name), see a list of known APNs. Then, it will integrate nicely with the new network configuration tool we have in project.
Some articles about 3G/GPRS cards:
Some interesting articles about EVDO (Evolution-Data Optimized) cards:
Though, I haven't found in these articles how to easily enter the PIN code for the SIM card. These cards are probably unlocked by default, since they're meant to reside in the laptop. Anyway, it should be available through standard AT commands,
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.
We should really detect more networks attacks in Mandriva's Interactive Firewall project, and SSH brute force attacks are today's plague.
Some solutions use the ipt_recent module from iptables to blacklist users if they try too often to connect:
Some programs parse logs to detect attacks (/var/log/auth.log):
But I'd rather use more integrated solutions, instead of connection count heuristics or logs parsing. pam looks like the exact component where this detection should take place, we already mentionned it when IFW was designed, with Fred Lepied.
It seems the pam_abl already does that (see pam_abl's doc). A further effort could be to blacklist the attackers not only in pam, but also in iptables, using some Interactive Firewall notifications.
I've fixed some issues in the network::thirdparty module that takes care of installing the required packages for a device. It includes the firmware and a daemon for ipw3945.
I had to a fix a bug about firmwares in network::thirdparty, it checks that the firmware files are installed by testing if a filename or file pattern matches. It used the glob_() function, from MDK::Common, but this won't work when a raw filename is passed (i.e. no wildcard). The standard glob() function (from Perl) won't work either, since it returns the expression even if the file doesn't exist. I had to bsd_glob() from File::Glob, forcing it to use no flags.
Another issue was some timing problem with the ipw3945 daemon, the network interface isn't immediately created once the daemon is started. So, a wonderful sleep 2 after daemon start copes with that...
I've fixed a lame bug that prevented the wireless link quality to be detected properly in net_applet and drakroam. It occured only when iwlist was used, it should be ok when wpa_supplicant and network roaming are enabled.
I guess it's bug #19379. Yes, I sux.
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.
I've started to develop support for 3G/Edge cards in network tools, especially on the /Option GlobeTrotter 3G/Edge/ card.
This involves building the nozomi kernel driver (see drivers on PHARscape forum).
The card also requires the GCOM utility, that basically allows initializing the device (here /dev/noz0), checking SIM, entering the PIN code, registering on the network, getting signal and various info.
More info about that is available at Linux and 3G on PHARscape
I've also created a new network::mobile_data module, it will be used in network tools to detect, prepare (ask SIM code), list networks, and connect to them. For now, it barely runs gcom on the selected device. Sending the SIM code from the Perl module isn't really easy, I'll use IPC::Open2 to be able to feed in the SIM code.
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 a page about DrakX Network tools on Mandriva's wiki. It's about listing our tools, hardrware support, features, interfaces.
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.
add function in network::tools to get interface description
write shorewall rules in rules.drakx and allow user modifications to be kept in /etc/shorewall/rules (ask for confirmation if needed)
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).
