Is qinternet or smpppd broken in openSUSE 11.3 final version?

I wished to use qinternet under openSUSE 11.3 to control multiple interfaces (a mixture of internet/intranet, DHCP/static IP), so I applied the same settings/tests which were successful for kinternet under open/SUSE 11.2:

Selected options within Yast2/Network Settings:

[INDENT][INDENT]Traditional Method with ifup[/INDENT][/INDENT][INDENT][INDENT]Enable Device Control for Non-root User Via Qinternet[/INDENT][/INDENT]

Yast2/System/System Services(RunLevel)/smpppd = “yes”

From command line terminal:

command issued  = usr/sbin/rcsmpppd status
returned result = "Checking for SMPPPD:      running"

When qinternet was run it appeared as an icon towards the right of the bottom panel (also true for kinternet under openSUSE 11.2). However qinternet under openSUSE 11.3 was non-functional. Apart from that core issue, the other observed differences between qinternet/openSUSE 11.3 and kinternet/openSUSE 11.2 are summarized by the table below (the code box format allowed me to simulate a table):

                                + --------------- + ----------------- +
                                |  Default state  | Interface option  |
   +  -----------------------   + --------------- +------------------ +
   |  qinternet/openSUSE 11.3   |  Disconnected   | Greyed out        |  
   +  -----------------------   + --------------- + ----------------- +
   |  kinternet/openSUSE 11.2   |  Connected      | Selectable        |
   +  ------------------------  + --------------- + ----------------- +

Default state indicated by different icons.

Interface option brought up by right-mouse-clicking on the qinternet/kinternet panel icon and choosing Settings/Various Settings/Startup tab.

Note: Regardless of whether qinternet was running or not, internet communications via the relevant network interface still worked.

In case the failure of qinternet/smpppd was simply a PolicyKit issue, I edited /etc/PolicyKit/PolicyKit.conf to ensure that the relevant user had the necessary privilege to run smpppd (I assume that qinternet can be ignored since it is just the front end for smpppd) e.g.

<?xml version="1.0" encoding="UTF-8"?> <!-- -*- XML -*- -->

<!DOCTYPE pkconfig PUBLIC "-//freedesktop//DTD PolicyKit Configuration 1.0//EN"

<!-- See the manual page PolicyKit.conf(5) for file format -->

<config version="0.1">
  <match action="org.opensuse.smpppd.connect">
      <return result="yes"/>

This made no difference, SO FOR DIAGNOSTIC PURPOSES ONLY, I logged in as root after first removing the power from the network switches externally connected to each network interface (isolating the local host). I then ran qinternet but once again, the Interface option was greyed out. This confirmed fairly conclusively that lack of privilege was not responsible for the qinternet/smpppd problem.

Have I missed something or do you think I should submit this as a bug report?

(yes Bloggs_J is just a pseudonym)

Sorry. In case it matters to anyone, allow me to correct a small typographical error. The first code box should in fact have read:

command issued  = /usr/sbin/rcsmpppd status
returned result = "Checking for SMPPPD:      running"


I have the same issue with opensuse 11.3 (final version) here.

Controlling my 2 interfaces “eth0” and “eth1” (both wired; traditional method; non-root-user enabled) with “ifup” and “ifdown” is working fine. Both interfaces are working.

In opensuse 10.3 (my current setup) I used kinternet to enable/disable the internet connection on eth1 and see, if there is any traffic. The connection to the internal network on eth0 is always enabled.

I tried to do the same thing in my new opensuse 11.3-setup … but all Qinternet-Buttons except “Settings” and “Quit” are greyed out. Using “cinternet -v -I” only results in the one line “trying to connect local smpppd”. So obviously smpppd (which is up and running) does not report “eth0” and “eth1” as existing interfaces to the frontends.

It does not matter if I start the commands as root or as a normal user. The result is always the same.

I also would like to know if I missed something or if smpppd is broken.


By coincidence, somebody submitted a bug report on the same day that I submitted my first post on this topic.
Apparently non-dialup device support was deliberately dropped from smpppd.
If you find this as remarkable and incongruous as I did, I suggest you read the bug report.
If you wish to get this situation changed, you will have to vote. In order to do so, you need to be registered with Bugzilla to add to the thread.



… thank you for the link to the bug report. I will try to recompile and enable the support for non-dialup-devices. This hopefully will last for the time until Networkmanager is a working alternative for my needs.


OK this is my last post on this topic.

Here is summary of the main points to date:

Current Status

[INDENT]qinternet/smpppd does not support non-dialup devices such as eth0.[/INDENT]

Future plans for openSUSE 11.3

[INDENT]An update is promised (see to restore support for wired non-dialup devices. Wireless support will remain broken but to quote Ludwig Nussel from the bug report hyperlinked above, “You can still ifup/ifdown them just like wired devices. Only the part that allowed scanning and setting WEP(!) keys is disabled”.[/INDENT]

Future plans for openSUSE 11.4 and beyond

[INDENT]The following comments by Ludwig Nussel in the bug report:
[INDENT][INDENT]“I’ve disabled wireless support in smpppd as it was broken anyways. Removing wireless support however also removed support for any non-dialup devices. Since supporting non-dialup devices was a hack anyways I’m not sure I want to have it back”.

“noone cares about smpppd these days you know, everyone wants NetworkManager.
Removing support for all non-dialup interfaces was an unintentional side effect
of removing he wireless support. Noone complalined about that during beta phase”.[/INDENT]

suggest that non-dialup device support is likely to be discontinued (read the full bug report and visit [Portal:Factory - openSUSE](http://en.opensuse.or /Portal:Factory)).