Hi,
I'm implementing radius for mpd and I found maybe a leak in radius.c of
the userland-ppp.
in the function radius_Process, I think there is a missing free function
call:
snip
case RAD_MICROSOFT_MS_MPPE_RECV_KEY:
free(r->mppe.recvkey);
demangle(r, data, len, &r->mppe.re
On Sat, 2 Nov 2002, Julian Elischer wrote:
> The code for doing non complient pppoe was written to be used as a
> client. I'm amazed it works as a server too.. (and I wrote it).
Well, it worked allright for me (and it would be a nice feature too, short
of this bug ;) )
> Am I right in understandi
Hi,
now I finished the work for radius-mpd-integration.
It would be great if my code will be reviewed and integrated into
"official" mpd.
If there are any bugs or dirty hacks in my code, then let me know.
I tested the code successfuly against freeradius and Microsoft Radius
(Windows 2000).
All
I believe the select operation on bpf is not functioning as supposed to.
I´m calling select with 100ms timeout. The bpf interface is listening to
an interface with constant packet rate, so it´s certain that multiple packets
have been received during the select call. However the fd for the bpf
devi
I believe you're misunderstanding the meaning of the timeout in select(2).
Timeout applies only when no FDs are ready.
Also, you might be better off setting immediate mode on your bpf fd,
if you want a return before the buffer is full.
On Mon, Nov 04, 2002 at 12:12:26AM +0200, Petri Helenius wrot
Hi,
I have not tested your code yet.
However, according to me the radius code should be into link.c and not bund.c
For example, it is important in order to support the accounting of the
multilink ppp sessions, isn'it ?
Vincent
Le Dimanche 3 Novembre 2002 15:34, Michael Bretterklieber a écrit :
Hi,
a colleague pointed out the following problem: the various
forms of encapsulation of IP traffic might result in IP
datagrams which are larger than the IP maximum datagram
length (64k).
The problem arises with the various IP-in-IP encapsulations
(gif, maybe faith), with IPSEC, and with some mul
On Sun, 3 Nov 2002, Luigi Rizzo wrote:
> Hi,
> a colleague pointed out the following problem: the various
> forms of encapsulation of IP traffic might result in IP
> datagrams which are larger than the IP maximum datagram
> length (64k).
>
> The problem arises with the various IP-in-IP encapsul
hi,
I'll start this off by claiming ignorance about the deep inner workings of
tcp/ip. As such, this is not going to be a really technically detailed
report. I will be more than happy to provide any info that might help in
tracking this problem down though!
The problem manifests as large download
