linecontrol-development — LineControl development

[LineControl-development] Help with configuration on lineserv on CentOS (SME)

[<bro...@ne...>]

I recently downloaded and compiled linesrv (linesrv-2.1.21.src.tar.bz2 
<http://downloads.sourceforge.net/linecontrol/linesrv-2.1.21.src.tar.bz2?modtime=1111340335&big_mirror=0>) 
from sourceforge. No problems there. Then I  edited the config file to 
fit my setup, and when the linesrv program is executed it starts up OK 
and  displays its config. I then downloaded  WLC (wlc-2.0.6-static.zip 
<http://linecontrol.srf.ch/down/wlc-2.0.6-static.zip>) from the  
linecontrol.srf.ch website and installed that on a WinXP laptop. Once I 
configured that,  I was able to connect to the linesrv daemon on the SME 
box, but it won't display connection status for ppp0 (my dialup 
connection) and won't allow me to bring the connection up/down from WLC.
My first thought was that the "service wan up" and "service wan down" 
commands I would normally use to connect/disconnect were the problem. I 
thought maybe the config file didn't like the fact that those contain 
spaces, so I created two basic scripts:

wanup:
#!/bin/sh
service wan start

wandown:
#!/bin/sh
service wan stop

which I added to my /etc/ppp directory. Then I changed the two lines in 
my config file to point to those instead, but it didn't help... Please 
let me know if you need more info to troubleshoot this. I wasn't sure 
what the policy was on this mailing list for attached files, so I have 
not included my linesrv.conf file. Here is the section I think may be 
relevant though:

line CWNet
script_up /etc/ppp/wanup
script_dn /etc/ppp/wandown
interface ppp0
con_type netdev
#mklog yes
line_baud_up 53000
line_baud_down 53000
allow_manually no
#script_esc /etc/ippp/isdn.hangup
#con_status_file /var/lib/linesrv/con-is-up
con_timeout 20
#con_down_timeout 60
send_throughput yes
line_locking no

TIA! Any assistance would be appreciated.

-- 
--==From the mailbox of B. Wheeler==--

Gossip is when you hear something you like about someone you don't.

Re: [LineControl-development] LineControl -- cvs / svn

[Stefan G. <sg...@gm...>]

Am Samstag, 11. M=E4rz 2006 09:44 schrieb S. Fuchs:
> > To be honest, I have never even looked at the monitorapplet and
> > just discovered some months ago, that it's part of klcc. I don't
> > know what it actually does or if it works at all, probably have to
> > check that ;)
>
> ok, no problem, don't hurry ;).
> what about moving to svn?

Only if the sf servers are faster than the cvs ones. As svn is atomic you=20
usually cannot CTRL-C it when things take too long, very annoying if the=20
server is stalling all the time.
I use svn myself for qlinecontrol sources, if the servers prove to be faste=
r I=20
could move sources over there.

> Hey... cool, nice to know.
> In case I write a gentoo ebuild, shall I provide the package on my
> own server or will you keep the release files at the same location
> over a long period of time?

I plan to keep the release tarballs for quite some time, the only thing I=20
usually do is purging older releases, i.e. you will only be able to downloa=
d=20
the last two releases. Otherwise we could as well try to upload files on sf=
=20
for 0.2.

> Hmm... seems I have to rewrite the linecontrol homepage. ;)

And add the "new" klcc screenies? ;)

> Btw, if you want some user feedback, then just announce your client
> on freshmeat. The feedback for the server and my clients was usually
> more or less coincident with the announcements.

I'll probably do for 0.2 then. The current release is probably a bit buggy=
=20
(read: untested) when used with more than one line, I have to configure my=
=20
server and add two emulated lines :)

> > I use linesrv2 for my 2MBit line and I'm quite happy with it. There
> > are a few things that need fixing but it works quite well most of
> > the time :)
>
> I'm running linesrv2 myself to monitor the throughput of my cable modem.
> What needs fixing in linesrv2 at your opinion? Might be good to know...

=2D close unneeded FDs when starting linesrv and when forking other process=
es

=2D safe way to monitor download/upload bytecount, simply using a long long=
=20
won't cut it (maybe a long plus another long that counts the time the real=
=20
counter would have wrapped already)

=2D sometimes my cable-modem resets, afterwards eth1 is active, from then o=
n=20
linesrv thinks the line was brought up by something else and refuses to=20
control it, that's annoying because I have to fix it with a manual "ifdown=
=20
eth1" every time

=2D web-frontend so one could even work without a client installed locally =
(does=20
linesrv have a pipe to control it?)

=2D big whish: protocol based on cleartext instead of structs, maybe use ve=
ry=20
simple xml, that would be more future-proof as clients can check if they=20
support this packet-version and don't need to know how long a certain struc=
t=20
is


Bye, Stefan aka mETz

Re: [LineControl-development] LineControl -- cvs / svn

[S. F. <lin...@sr...>]

Hallo,

> > Is it maybe more logic to put klcc and klcmonitorapplet
> > into klcc/client and klcc/monitorapplet ? I don't
> > know how much they're related to each other.
> 
> To be honest, I have never even looked at the monitorapplet and
> just discovered some months ago, that it's part of klcc. I don't
> know what it actually does or if it works at all, probably have to
> check that ;)

ok, no problem, don't hurry ;).
what about moving to svn?

> > What about the Qt linux/win client project?
> > Is it dropped or still in progress / planned?
> 
> There's even something called a "release" out already:
> http://metz.gehn.net/projects/qlinecontrol/
> 
> So far I have it installed on 2 linux machines and about 5 win32
> systems, didn't receive any feedback from externals users yet (not
> that I really want any right now, I know tons of stuff is missing).

Hey... cool, nice to know.
In case I write a gentoo ebuild, shall I provide the package on my
own server or will you keep the release files at the same location
over a long period of time?

Hmm... seems I have to rewrite the linecontrol homepage. ;)

Btw, if you want some user feedback, then just announce your client
on freshmeat. The feedback for the server and my clients was usually
more or less coincident with the announcements.

> Sorry for not having posted this in here earlier but I'm busy with
> other stuff right now, qlinecontrol-0.1 is just there because I

You don't have to be sorry about that. That's just the way I'm
writing software.

> needed a win32-client that is less weird than wlc2 (this is
> probably all Borlands fault, I know parts of it from Delphi and
> have learned to hate it with a passion *g*) ;)

Hey, that was at the beginning of my coding engagement. The start
to teach myself C++ (not to say object orientation... ;).
I like the GUI, but the code is horrible and I not going to look
at it again. It's always shocking to look at old code after one
learned quite a few things more.

> > Regarding linesrv-3: I have to sort out a problem
> > during line shutdown (uncought signal initiates
> > shutdown of the server...;). Due to several other
> > projects (mainly hw) and my diploma thesis this has
> > quite low priority. Growing 24/7 broadband access
> > makes the project needless anyway... but I planned
> > to bring linesrv 3 at least to a halfway usable
> > alpha state.
> 
> I use linesrv2 for my 2MBit line and I'm quite happy with it. There
> are a few things that need fixing but it works quite well most of
> the time :)

I'm running linesrv2 myself to monitor the throughput of my cable modem.
What needs fixing in linesrv2 at your opinion? Might be good to know...

Greetings

Stefan Fuchs

Re: [LineControl-development] LineControl -- cvs / svn

[Stefan G. <mE...@we...>]

Am Samstag, 25. Februar 2006 11:43 schrieb S. Fuchs:
>
> Is it maybe more logic to put klcc and klcmonitorapplet
> into klcc/client and klcc/monitorapplet ? I don't
> know how much they're related to each other.

To be honest, I have never even looked at the monitorapplet and just 
discovered some months ago, that it's part of klcc. I don't know what it 
actually does or if it works at all, probably have to check that ;)


> What about the Qt linux/win client project?
> Is it dropped or still in progress / planned?

There's even something called a "release" out already:
http://metz.gehn.net/projects/qlinecontrol/

So far I have it installed on 2 linux machines and about 5 win32 systems, 
didn't receive any feedback from externals users yet (not that I really want 
any right now, I know tons of stuff is missing).

Sorry for not having posted this in here earlier but I'm busy with other stuff 
right now, qlinecontrol-0.1 is just there because I needed a win32-client 
that is less weird than wlc2 (this is probably all Borlands fault, I know 
parts of it from Delphi and have learned to hate it with a passion *g*) ;)


> Regarding linesrv-3: I have to sort out a problem
> during line shutdown (uncought signal initiates
> shutdown of the server...;). Due to several other
> projects (mainly hw) and my diploma thesis this has
> quite low priority. Growing 24/7 broadband access
> makes the project needless anyway... but I planned
> to bring linesrv 3 at least to a halfway usable
> alpha state.

I use linesrv2 for my 2MBit line and I'm quite happy with it. There are a few 
things that need fixing but it works quite well most of the time :)

Bye, Stefan aka mETz

[LineControl-development] LineControl -- cvs / svn

[S. F. <lin...@sr...>]

Hello out there,

As sourceforge.net added SVN to their services I decided
to enable this feature for the linecontrol project. I leave
the decision on whether to use it or not up to the maintainers
of each package. Personally I would like to see everything
converted to SVN whithin the next... (baah... don't hurry ;).

I thought to have the svn repository structure as follows:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
https://svn.sourceforge.net/svnroot/linecontrol
  |
  |-- trunk
  |     |-- servers
  |     |     |-- 2
  |     |     |-- 3
  |     |
  |     \-- clients
  |           |-- jlc
  |           |-- klcc
  |           |-- klcmonitorapplet
  |           |-- lcc
  |           |-- xlc
  |           \-- wlc
  |
  |-- releases
  |     |-- <package-name>
  |     |-- linesrv-2.1.20
  |     \-- linesrv-2.1.21
  |
  \-- branches
        |-- <developer-name>
        |     \-- whatever-descriptive-name
        |
        \-- sfuchs
              \-- jlc-swt-gentoo-fix

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The directories
  trunk/servers/3
  trunk/clients
  releases
  branches
exist already. The rest serves for illustration.
Is it maybe more logic to put klcc and klcmonitorapplet
into klcc/client and klcc/monitorapplet ? I don't
know how much they're related to each other.

Creating entries in the 'releases' directory
falls under the charge of the according package
owners. Development in the 'clients/<package>'
and 'servers/<major>' shall be coordinated by
the according package owners too.

Before importing server2/lcc/xlc I'll wait for
your feedback.

What about the Qt linux/win client project?
Is it dropped or still in progress / planned?
Regarding linesrv-3: I have to sort out a problem
during line shutdown (uncought signal initiates
shutdown of the server...;). Due to several other
projects (mainly hw) and my diploma thesis this has
quite low priority. Growing 24/7 broadband access
makes the project needless anyway... but I planned
to bring linesrv 3 at least to a halfway usable
alpha state.

Greetings

Stefan Fuchs
--
http://srf.ch/

Re: [LineControl-development] Re: Future of KLCC / current state of linesrv3

[S. F. <lin...@sr...>]

> > linesrv3 needs some polishing and a lot of bugfixes before
> > we can release a testing version. Registering/unregistering
> > a client works (LCP3, as linesrv2 is using), dialing works
> > too (at least for certain line types), but apparently I don't
> > catch SIGCHLD properly. The server terminates during hangup.
>=20
> Well, maybe using some sort of toolkit might help you too :)
>=20
> It would be cool if distros started shipping Qt4 libs in parts too
> as you could use QtCore then (only contains the non-gui parts).

Maybe... I didn't look at Qt until now. But usually I don't
like those toolkits. Besides of that, the toolkit don't solve
the problem of bad software design... probably the biggest
problem is that I didn't have any clue about software design
when I started to write linesrv3.

> > If anyone has the neccessary time and interest to help on
> > linesrv3, feel free. I suggest to use KDevelop or some other
>=20
> Right now I don't think I have enough time but I'll check the
> sourcecode nevertheless.

You better stick to klcc, except you really want to go for
linesrv ;)

> Btw, I just made new screenshots for the website, you can grab them
> from http://metz.gehn.net/klcc-screenshots.tar.bz2

Got it (I just don't know why wget was so fast and reported
something about "1.06M/s" on that 1.2 mbit/s cable modem link).
Kick me (sr...@sw...), if I forget to put it online tomorrow.

Greetings

Stefan

Re: [LineControl-development] Re: Future of KLCC / current state of linesrv3

[Stefan G. <sg...@gm...>]

On Monday October 10 2005 19:30, S. Fuchs wrote:
> Hello,
>
> > as WLC is kind of dead
>
> It is dead... at least from my side, and nobody seems to be willing
> to take it over. The source is GPL since 2004-05-16.
> I just don't have any interest in coding Windows applications and
> learning all the neccessary things for it I currently don't know.

Well, I'm not much into hardcore windows-coding either, fortunately Qt4 
abstracts all this away, except for some small things like systray.
I'm still using windows for uni work and for playing games so I can test the 
client on both OSes.

> linesrv3 needs some polishing and a lot of bugfixes before
> we can release a testing version. Registering/unregistering
> a client works (LCP3, as linesrv2 is using), dialing works
> too (at least for certain line types), but apparently I don't
> catch SIGCHLD properly. The server terminates during hangup.

Well, maybe using some sort of toolkit might help you too :)

It would be cool if distros started shipping Qt4 libs in parts too as you 
could use QtCore then (only contains the non-gui parts).

> If anyone has the neccessary time and interest to help on
> linesrv3, feel free. I suggest to use KDevelop or some other

Right now I don't think I have enough time but I'll check the sourcecode 
nevertheless.

Btw, I just made new screenshots for the website, you can grab them from 
http://metz.gehn.net/klcc-screenshots.tar.bz2

Bye, Stefan aka mETz
-- 
ICQ#51123152 | Moege der Pinguin mit euch sein

[LineControl-development] Re: Future of KLCC / current state of linesrv3

[S. F. <lin...@sr...>]

Hello,

> as WLC is kind of dead

It is dead... at least from my side, and nobody seems to be willing
to take it over. The source is GPL since 2004-05-16.
I just don't have any interest in coding Windows applications and
learning all the neccessary things for it I currently don't know.


I'm glad to hear that something's still going on. Reminds me
somehow of finishing linesrv3. Motivation is not that big as
I learned a few things about softare design patterns after I
designed linesrv3 ;) (I think I started linesrv3 before I began
my electrotechnical engineering studies... which will be over
in about 27 weeks). Starting a large, sorry... long, project
and learning a few things afterwards though you should have
known them before can be quite tediously...

linesrv3 needs some polishing and a lot of bugfixes before
we can release a testing version. Registering/unregistering
a client works (LCP3, as linesrv2 is using), dialing works
too (at least for certain line types), but apparently I don't
catch SIGCHLD properly. The server terminates during hangup.

If anyone has the neccessary time and interest to help on
linesrv3, feel free. I suggest to use KDevelop or some other
IDE that helps navigating C++ classes. Before you start reading
the Line- / Client State Machines I suggest taking a look
at the following two documents:
ftp://fuchs.dnsalias.net/linecontrol/client-state-machine.pdf
ftp://fuchs.dnsalias.net/linecontrol/line-state-machine.pdf
They can be found in the source under linesrv-3/doc/code/*.pdf too.
.o0( hope I committed them ;)
And... yes, I know, the protocol stack is a horrible "design".
Logging doesn't seem work be implemented / work yet.

Greetings

Stefan Fuchs
---
http://srf.ch/

[LineControl-development] Future of KLCC

[Stefan G. <sg...@gm...>]

Moin,

as WLC is kind of dead and KLCC hasn't seen a release for quite some time=20
either I decided to finish kwallet support in cvs now and get KLCC 2.2.0 ou=
t=20
of the door. I dropped saving passwords in the config, only kwallet will be=
=20
supported now.

=46rom then on I will probably not do another release (compiling fixes and=
=20
compatiblity with newer KDE3/Qt3 versions is a reason to do another one of=
=20
course) and instead use the lcpio backend to create a Qt4-based=20
LineControl-Client. This step will have a few pros and cons:


+ only one application for both Unix and Windows (and Mac if I find a fello=
w=20
Mac-Developer who helps me with the few system-dependent things)

+ will have no external dependency except for Qt, no need for KDE anymore=20
(yes, not everybody wants to install kdelibs just for a small app)

=2D less framework help as if using KDE, stuff like systemtray, standard di=
alog=20
layouting (ok, abort buttons, tabbed dialogs) etc. are not provided by Qt,=
=20
fortunately I already have some helper classes and a systray source that is=
=20
said to work on both Windows and Unix (didn't try it yet)


I'll announce in here when KLCC 2.2.0 is finally done and probably some tim=
e=20
after that come back with the Qt4 rewrite (it's not going to be a port=20
because I want to change some things drastically, the mainwindow contents f=
or=20
instance).

Btw, if any of the KLCC translators is reading this, you can have a new=20
tarball with a few new/changed strings to translate ;)

Bye, Stefan aka mETz
=2D-=20
ICQ#51123152 | Moege der Pinguin mit euch sein

Re: [LineControl-development] Number of dial attempts

[S. F. <li...@sr...>]

Hi,

> My question is how can i influence the number of retries ? I mean i
> want to stop dialing after 3 unsuccesful trial.
> (I have a script which dials into a customer every night and it made
> me a 100 EUR phone bill because it dials every 3 minutes for two
> days :(.   ) In another hand i also like to set if a connection has
> timed out then it should not be reconnected again automatically.

Well... it's a long time I looked into the details of linesrv 2.1 the
last time. But as far as I remember I din't implement any redialing
features in linesrv (has anyone an other opinion?).
In other words, that what you desire is the normal behaviour of
linesrv. Maybe you're using isdn and didn't turn off some automatic
dialing feature...

I'm sorry about your 100 EUR, but in my point of view it's not
directly related to linesrv.
- have a look at the sourcecode of linesrv to convince me about
  its redailing features
- dig into your up/down scripts and perhaps deeper to find the
  redailing troll.

Furthermore: please don't ask any questions here without providing
full information about your setup:
http://people.ee.ethz.ch/~sfuchs/LineControl/contact.php
(it's the same as http://linecontrol.srf.ch/ --> "Contact")

Greetings

Stefan Fuchs

Re: [LineControl-development] LineSrv pppd Error handling

[S. F. <lin...@sr...>]

Hi Timothy,

sorry, your mail nearly drowned...

> I'm posting this here because there are few subscribers to the users
> lists. Sometimes when I connect with linesrv the ppp connection
> fails to initiate properly. Unfortunately linesrv isn't detecting
> the error. I am using pon and poff for the scripts so I'm wondering
> how it actually detects a failed dial attempt.

Whatever your pon/poff scripts are... linesrv uses only a timeout
to conclude that the dial attempt failed.

> As far as I can see /var/run/ppp-Provider.pid remains although the
> pppd process has finished. Both pppd and chat have exited.
> Looking through the src I can see that for a ppp connection it
> checks to see when ppp0 is up. Wouldn't it make more sense to also
> check to see if pppd is running?
> i.e. if (line_status(line) = CST_DIALING) {
>               /* Check if line is up yet */
>               /* Check if pppd is still active, if pppd has died
>               then
> return \
>                    status to CST_DOWN and send client an error */
>         }
> 
> Any other suggestions on how this can be achieved? I can change the
> con_type to file and have a ip-up.d/connected script that creates a
> file but I'm not 100% sure of con_type file
> I'm going to try con_timeout with 120 seconds to see how that goes,
> otherwise I'll try con_type file.

- create your own solution with con_type file
- implement a new mechanism which uses the
  proposed 'pppd running detection'
- configure redial attempts and chat/pppd timeouts
  in a manner to work correctly with the linesrv
  timeouts you configured.

Greetings

Stefan Fuchs
--
http://srf.ch/

[LineControl-development] Number of dial attempts

[<sf...@bl...>]

Hi,

My question is how can i influence the number of retries ? I mean i want to
stop dialing after 3 unsuccesful trial.
(I have a script which dials into a customer every night and it made me a
100 EUR phone bill because it dials every 3 minutes for two days :(.   )
In another hand i also like to set if a connection has timed out then it
should not be reconnected again automatically.

thanks a lot., Sandor

[LineControl-development] LineSrv pppd Error handling

[Timothy W. <we...@ti...>]

I'm posting this here because there are few subscribers to the users lists.
Sometimes when I connect with linesrv the ppp connection fails to
initiate properly. Unfortunately linesrv isn't detecting the error.
I am using pon and poff for the scripts so I'm wondering how it actually
detects a failed dial attempt.
As far as I can see /var/run/ppp-Provider.pid remains although the pppd
process has finished. Both pppd and chat have exited.
Looking through the src I can see that for a ppp connection it checks to
see when ppp0 is up. Wouldn't it make more sense to also check to see if
pppd is running?
i.e. if (line_status(line) = CST_DIALING) {
              /* Check if line is up yet */
              /* Check if pppd is still active, if pppd has died then
return \
                   status to CST_DOWN and send client an error */
        }

Any other suggestions on how this can be achieved? I can change the
con_type to file and have a ip-up.d/connected script that creates a file
but I'm not 100% sure of con_type file
I'm going to try con_timeout with 120 seconds to see how that goes,
otherwise I'll try con_type file.

Thanks

Tim

--
Tim White - Use the Fox, Luke!
PGP/GPG id: 602E944D, Pub Key Serv: subkeys.pgp.net
Fingerprint: 04C2 9682 B7B2 3006 009D  A9F3 067E EDCD 602E 944D
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me 
spread!
--
Linux linmedia 2.6.10linmedia #4 Mon Feb 21 21:19:38 WST 2005 i686 GNU/Linux

Re: [LineControl-development] linesrv 2.1.15 leaks filedescriptors

[S. F. <lin...@sr...>]

Hi,

> just today I discovered why I cannot restart linesrv while my
> connection is  up:
> # lsof -i -P -n | grep 16007
> linesrv  18856  0  3u  IPv4 46809507  TCP 192.168.0.30:16007
> (LISTEN) linesrv  18856  0  4u  IPv4 46809508  UDP
> 192.168.0.30:16007 linesrv  18856  0  7u  IPv4 46809598  TCP
> SRV:16007->ME:36731 (ESTABLISHED) dhclient 18956  0  3u  IPv4
> 46809507  TCP 192.168.0.30:16007 (LISTEN) dhclient 18956  0  4u 
> IPv4 46809508  UDP 192.168.0.30:16007 dhclient 18956  0  7u  IPv4
> 46809598  TCP SRV:16007->ME:36731 (ESTABLISHED)
> 
> SRV == My server's ip
> ME  == my workstation ip
> 
> This looks a lot like linesrv is fork()ing for running up/down
> scripts without  closing unneeded filedescriptors after the fork
> (the child should do so  though).

As far as I remember... you're right. I assumed that the forked
processes get terminated before the parent process gets terminated. In
your case this doesn't apply.

> the config for the device is:
> line           myline1
> interface      eth1
> con_type       netdev
> script_up      /sbin/ifup eth1
> script_dn      /sbin/ifdown eth1
> line_baud_up   2000000
> line_baud_down 2000000
> allow_manually yes
> script_esc     /sbin/ifdown eth0
> 
> 
> Would be nice if this could be fixed in case it's not fixed already.
> 
> linesrv-2.1/server/NEWS doesn't mention such a change between 2.1.15
> and  2.1.20 so I guess it's still there.

Hmm... I just wrote a rather long paragraph about why there's a
time to wait before a tcp socket can be bound to a previously used
tcp port. Then I probably got the problem:

You run linesrv, start the connection and the script_up doesn't
terminate? Your linesrv dies (why??? shouldn't!)/gets killed and the
script_up keeps running whith the tcp-16007 socket still open, right?
Then you can't restart linesrv... ok, that's no surprise anymore ;).

The neccessary filedescriptors can be accessed via the global
variables "server" and "cltlist" (see global_vars.h). Do we need
to close all (what happens with the connections to the clients
if we issue a close() on their file descriptors?) or just the
server socket?

Closing needs to be done between fork() and exec*(). So this is
probably in execute.c.
I'll be glad if someone could do this for me as I've quite a
few examinations in the next weeks and I regard this as a low
priority bug.

Due to bad design (design??) of linesrv one has to make sure
not to call close() for a file descriptor which is not open yet,
e.g. when exec_dont_care*() gets called before the socket
is opened. Maybe we're lucky and exec_dont_care*() gets only
called with an open socket... has to be checked.

Greetings & thanks for the report

Stefan Fuchs
--
http://srf.ch/

[LineControl-development] linesrv 2.1.15 leaks filedescriptors

[Stefan G. <sg...@gm...>]

Moin,

just today I discovered why I cannot restart linesrv while my connection is 
up:
# lsof -i -P -n | grep 16007
linesrv  18856  0  3u  IPv4 46809507  TCP 192.168.0.30:16007 (LISTEN)
linesrv  18856  0  4u  IPv4 46809508  UDP 192.168.0.30:16007
linesrv  18856  0  7u  IPv4 46809598  TCP SRV:16007->ME:36731 (ESTABLISHED)
dhclient 18956  0  3u  IPv4 46809507  TCP 192.168.0.30:16007 (LISTEN)
dhclient 18956  0  4u  IPv4 46809508  UDP 192.168.0.30:16007
dhclient 18956  0  7u  IPv4 46809598  TCP SRV:16007->ME:36731 (ESTABLISHED)

SRV == My server's ip
ME  == my workstation ip

This looks a lot like linesrv is fork()ing for running up/down scripts without 
closing unneeded filedescriptors after the fork (the child should do so 
though).

the config for the device is:
line           myline1
interface      eth1
con_type       netdev
script_up      /sbin/ifup eth1
script_dn      /sbin/ifdown eth1
line_baud_up   2000000
line_baud_down 2000000
allow_manually yes
script_esc     /sbin/ifdown eth0


Would be nice if this could be fixed in case it's not fixed already. 
linesrv-2.1/server/NEWS doesn't mention such a change between 2.1.15 and 
2.1.20 so I guess it's still there.

Bye, Stefan aka mETz
-- 
ICQ#51123152 | Moege der Pinguin mit euch sein

[LineControl-development] KLCC 2.2.0 in CVS

[Stefan G. <sg...@gm...>]

Moin,

I finally decided to commit my (not entirely finished) code to CVS so people 
can at least test it :)
The KWallet handling still is a bit buggy, partly also caused by KWallet 
itself being buggy (I once managed to hang KWallet, it stopped providing 
passwords to _any_ application).

So far two ways of authentication exist:
- save password in kwallet
- don't save at all, i.e. ask for password on connect

I will probably change this to either save both username+pw in kwallet or save 
nothing at all and ask for both on connect, saving only the username in 
kconfig looks weird to me.

Btw, KDE 3.4 will have passwordless wallets, i.e. klcc will have access to its 
data without being forced to enter a password to open the wallet.
That change will essentially make kwallet equal to the old config-saved data 
and make lazy people happy ;)

Bye, Stefan aka mETz
-- 
ICQ#51123152 | Moege der Pinguin mit euch sein

Re: [LineControl-development] what's going on...

[Stefan G. <sg...@gm...>]

On Mittwoch Oktober 6 2004 13:55, S. Fuchs wrote:
> Hello,
>
> > >    I've lost interest to continue on WLC2 because I'm not running
> > >    windows anymore. Well... sometimes... every other month or so I
> > >    boot it because I can't avoid it.
> >
> > Hmm, what a pity. Personally I'm still using WLC1 here because WLC2
> > never got stable enough and has problems with starting minimized. It
> > would be really cool if somebody with windows-coding knowledge could
> > take over WLC, all I know about is Delphi (and that's ugly).
>
> There was once a DC or LC client written in Delphi ;)
> Well, I've given up...
>
> The problem with the existing WLC2 bugs is, that my Win coding
> knowledge is too small / non-existent to fix them.

hmm, and I know nobody using WLC and coding on windows :(

> Sounds great. I just checked out the latest CVS version and tried to
> compile it. There was no 'configure.in' but instead I found a
> 'configure.in.in'. It didn't seem to contain stuff needing
> preprocessing so I just moved it to configure.in and tried the usual
> 'aclocal ; autoheader ; automake --foreign --add-missing ; autoconf'.
> It seems configure.in.in is a bit too minimal... ;). I didn't
> investigate it further, probably no output directives for the
> Makefiles in configure.in or something like that I guess.
>
> Did I do something wrong or is it at the moment effectively in a
> non-working state? No problem for me... just wondering...

did you try make -f Makefile.dist (sometimes also known as Makefile.cvs)? :)
That one is meant to create configure.in and configure from that 
configure.in.in file. Don't ask me how all this actually works, I'm not 
automake/autoconf-guru either.

Bye, Stefan aka mETz
-- 
ICQ#51123152 | Moege der Pinguin mit euch sein

Re: [LineControl-development] what's going on...

[S. F. <lin...@sr...>]

Hello,

> >    I've lost interest to continue on WLC2 because I'm not running
> >    windows anymore. Well... sometimes... every other month or so I
> >    boot it because I can't avoid it.
> 
> Hmm, what a pity. Personally I'm still using WLC1 here because WLC2
> never got stable enough and has problems with starting minimized. It
> would be really cool if somebody with windows-coding knowledge could
> take over WLC, all I know about is Delphi (and that's ugly).

There was once a DC or LC client written in Delphi ;)
Well, I've given up...

The problem with the existing WLC2 bugs is, that my Win coding
knowledge is too small / non-existent to fix them.

> 6. The last thing I have to add to klcc before a new release is
> kwallet support (it's in my code already but not properly done yet).
> I plan on ditching the "save in config" option and allow either
> fetching it off kwallet or typing it in on connect. As kwallet is
> part of KDE since 3.2 I think people AND applications should finally
> start using it. Apart from that I fixed a few things and added
> support for some KDE 3.2 specific items. The next release will most
> probably only work with KDE 3.2, I hope this is ok for most users.

Sounds great. I just checked out the latest CVS version and tried to
compile it. There was no 'configure.in' but instead I found a
'configure.in.in'. It didn't seem to contain stuff needing
preprocessing so I just moved it to configure.in and tried the usual
'aclocal ; autoheader ; automake --foreign --add-missing ; autoconf'.
It seems configure.in.in is a bit too minimal... ;). I didn't
investigate it further, probably no output directives for the
Makefiles in configure.in or something like that I guess.

Did I do something wrong or is it at the moment effectively in a
non-working state? No problem for me... just wondering...

Greetings

Stefan Fuchs

Re: [LineControl-development] what's going on...

[Stefan G. <sg...@gm...>]

On Mittwoch Oktober 6 2004 10:37, S. Fuchs wrote:
>    I've lost interest to continue on WLC2 because I'm not running windows
>    anymore. Well... sometimes... every other month or so I boot it
>    because I can't avoid it.

Hmm, what a pity. Personally I'm still using WLC1 here because WLC2 never g=
ot=20
stable enough and has problems with starting minimized. It would be really=
=20
cool if somebody with windows-coding knowledge could take over WLC, all I=20
know about is Delphi (and that's ugly).

> 5. I kicked off some project members during summer (see my previous mail
>    to the list). Remaing members are:
>     - Martin Berentsen
>     - Stefan Gehn
>     - Daniel R=F6thlisberger
>     - Stefan Fuchs
>    .o0( hmm... nice alignment... )
>    Please keep me informed about your interest in LineControl to keep
>    the list more or less up to date.
>

to continue this list:

6. The last thing I have to add to klcc before a new release is kwallet=20
support (it's in my code already but not properly done yet). I plan on=20
ditching the "save in config" option and allow either fetching it off kwall=
et=20
or typing it in on connect. As kwallet is part of KDE since 3.2 I think=20
people AND applications should finally start using it.
Apart from that I fixed a few things and added support for some KDE 3.2=20
specific items. The next release will most probably only work with KDE 3.2,=
 I=20
hope this is ok for most users.

Bye, Stefan aka mETz
=2D-=20
ICQ#51123152 | Moege der Pinguin mit euch sein

[LineControl-development] what's going on...

[S. F. <lin...@sr...>]

Hi there,

1. Due to users requesting something like a forum (whaaa... I hate html for=
ums)
   I created the lin...@li... mailing list.

2. Hmm... linesrv 3... I continued a little bit in the summer. Basic stuff =
is
   now implemented (naa... not really working yet, too many bugs). Looks pr=
omising
   to me. If anyone thinks about studying the code (mix of ugly and good co=
de
   I think ;) then it's probably the right time now.
   Please don't think that I'll finish it within the next half year... I've
   got some other things to do too. Before you investigate the line state,
   dialing and hangup or client state mechanisms you probably want to take
   a look at linesrv-3/doc/code/client-state-machine.(fig|pdf) and
   linesrv-3/doc/code/line-state-machine.(fig|pdf).
   For the next few months:
   ftp://fuchs.dnsalias.net/linecontrol/client-state-machine.pdf
   ftp://fuchs.dnsalias.net/linecontrol/line-state-machine.pdf
   Feel free to send me patches against cvs head.

3. If you want to make changes on linesrv 2, feel free to send patches
   against the newest version / cvs head. I'll create new releases as
   apropriate. I'm not going to do further work on linesrv 2 myself. I'll
   concentrate the time I'm still working for LineControl on the new server.

4. I gave away several copies of the WLC2 source code to interested people.
   Some of them told me they're going to work on it. But I didn't hear
   anything... So if you find someone who would like to _really_ take over
   development of the WLC2 client (incl. releases, ...; GPL2), then tell
   him to contact me.
   I've lost interest to continue on WLC2 because I'm not running windows
   anymore. Well... sometimes... every other month or so I boot it
   because I can't avoid it.

5. I kicked off some project members during summer (see my previous mail
   to the list). Remaing members are:
    - Martin Berentsen
    - Stefan Gehn
    - Daniel R=F6thlisberger
    - Stefan Fuchs
   .o0( hmm... nice alignment... )
   Please keep me informed about your interest in LineControl to keep
   the list more or less up to date.

Greetings

Stefan Fuchs
--
http://srf.ch/

Re: [LineControl-development] KLCC maintainer

[S. F. <lin...@sr...>]

Hi there,

> > am I right with the assumption that klcc does not have a
> > maintainer anymore? If yes then I hereby volunteer to take over
> > development and maintainance. I just recently wrote a mail to its
> > former maintainer as I didn't knew he quit work on klcc. Because
> > I'm lazy I'll just go and append the text here :)
> >
> > -----------------
> > Moin,
> >
> > I've done a few things to my local checkout of klcc as it does not
> > seem to be developed anymore (and since KDE 3.2 some things
> > started annoying me).
> >
> > The story so far:
> > - Make use of new KDE 3.2 API
> > - use KWallet for password handling instead of storing it in
> > KConfig- fix quit in menubar, it only hided the mainwindow but did
> > not exit klcc(slightly changed logic inside kdelibs)
> > - include moc files, compiling them can cause strange compiler
> > errors and takes way longer
> >
> > In case somebody is interested in getting this into CVS I'll
> > provide a patch. -----------------
> >
> > If everbody is fine with me taking care of klcc from now on I'll
> > go and commit this stuff to cvs (well, need rights for that but I
> > guess "the other" Stefan has the power to do that :) ).
> >
>
> Ok with me at least :)

Thanks. I just added Stefan Gehn as a project developer for LineControl.
I'll update the web-pages in a few minutes.

The already registered proj. dev. got a mail because I would like to
clean up that list a bit. The mail has been sent to their sourceforge address.

Greetings

Stefan Fuchs

Re: [LineControl-development] KLCC maintainer

[Peter S. <ps...@li...>]

On Friday 02 July 2004 19:01, Stefan Gehn wrote:
> Moin,
>
> am I right with the assumption that klcc does not have a maintainer
> anymore? If yes then I hereby volunteer to take over development and
> maintainance. I just recently wrote a mail to its former maintainer as I
> didn't knew he quit work on klcc. Because I'm lazy I'll just go and append
> the text here :)
>
> -----------------
> Moin,
>
> I've done a few things to my local checkout of klcc as it does not seem to
> be developed anymore (and since KDE 3.2 some things started annoying me).
>
> The story so far:
> - Make use of new KDE 3.2 API
> - use KWallet for password handling instead of storing it in KConfig
> - fix quit in menubar, it only hided the mainwindow but did not exit klcc
> (slightly changed logic inside kdelibs)
> - include moc files, compiling them can cause strange compiler errors and
> takes way longer
>
> In case somebody is interested in getting this into CVS I'll provide a
> patch. -----------------
>
> If everbody is fine with me taking care of klcc from now on I'll go and
> commit this stuff to cvs (well, need rights for that but I guess "the
> other" Stefan has the power to do that :) ).
>
Ok with me at least :)

-- 
LLaP
Peter Simonsson

Kivio - http://www.koffice.org/kivio/

[LineControl-development] KLCC maintainer

[Stefan G. <sg...@gm...>]

Moin,

am I right with the assumption that klcc does not have a maintainer anymore? 
If yes then I hereby volunteer to take over development and maintainance. I 
just recently wrote a mail to its former maintainer as I didn't knew he quit 
work on klcc. Because I'm lazy I'll just go and append the text here :)

-----------------
Moin,

I've done a few things to my local checkout of klcc as it does not seem to be 
developed anymore (and since KDE 3.2 some things started annoying me).

The story so far:
- Make use of new KDE 3.2 API
- use KWallet for password handling instead of storing it in KConfig
- fix quit in menubar, it only hided the mainwindow but did not exit klcc 
(slightly changed logic inside kdelibs)
- include moc files, compiling them can cause strange compiler errors and 
takes way longer

In case somebody is interested in getting this into CVS I'll provide a patch.
-----------------

If everbody is fine with me taking care of klcc from now on I'll go and commit 
this stuff to cvs (well, need rights for that but I guess "the other" Stefan 
has the power to do that :) ).

Bye, Stefan aka mETz
-- 
ICQ#51123152 | Moege der Pinguin mit euch sein

Re: [LineControl-development] feature request

[S. F. <lin...@sr...>]

Hi,

please subscribe to the list before posting again something.

Usually postings from non-memebers are discarded to block
spam. Unfortunately this requires me to login on sf.net and
do it manually...

> I have noticed two features that are missing from current
> LineControl server and client software.
> 
> The current software does not terminate the dialup process when I
> terminate the client and I am the only user. That is, sometimes I
> start the client and I am the only user authenticated, so the server
> starts PPPD or any other dialup tool; during the connection process,
> I decide to terminate it, and I think that the server has terminated
> the running dialup program. But that's false. I have noticed it
> using lcc, because with xlc when the server is connecting, the
> disconnect option is not available. Looking at the sources,
> specifically in server/proc_lcp3.c and debugging, I saw that the
> client sends a offline command only when a connection has been
> instanciated. If I terminate the client during a connection, the
> client only gets a 'kick'.

That's correct. Linesrv shouldn't interrupt ongoing dial attempts
until the timeout (script_esc) occured or the line is established.
Dialing and then terminating the client doesn't make much sense anyway.

Taking a connection down which is currently dialing is a non-standard
behaviour which needs special treatment. One could either try it with
the script_esc or then introduce another script for that purpose.

I decided to disallow the abortion of dialing because I didn't want to
mess around with modems or other media which might not respond during
the dialing process even though pppd and similar programs should
handle this case. There wouldn't be any feedback that the line is down
and ready to get dialed again but linesrv would need that information.
Solve that problem... then come back with the solution ;).

> There is another feature that is missing, IMHO. I cannot specify in
> the configuration file whether or not retry the connection if it
> fails.

I think there are clients which are able to do that though I never
tested that feature. Indeed, one could do it on the server side also.
Is it worth the extra effort? If a dialup fails then usually the
provider has a problem or the peer configuration changed, no need
to silly dial again.
Do you really often need to dial twice? Why?

Greetings

S. Fuchs

[LineControl-development] feature request

[The N. <neu...@pa...>]

I have noticed two features that are missing from current LineControl server and client software.

The current software does not terminate the dialup process when I terminate the client and I am the only user. That is, sometimes I start the client and I am the only user authenticated, so the server starts PPPD or any other dialup tool; during the connection process, I decide to terminate it, and I think that the server has terminated the running dialup program. But that's false.
I have noticed it using lcc, because with xlc when the server is connecting, the disconnect option is not available.
Looking at the sources, specifically in server/proc_lcp3.c and debugging, I saw that the client sends a offline command only when a
connection has been instanciated. If I terminate the client during a connection, the client only gets a 'kick'.

There is another feature that is missing, IMHO. I cannot specify in the configuration file whether or not retry the connection if it fails.


-- 
Knowledge is power