ppp radius programmer question
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.recvkey, &r->mppe.recvkeylen); log_Printf(LogPHASE, " MS-MPPE-Recv-Key \n"); break; case RAD_MICROSOFT_MS_MPPE_SEND_KEY: <--- isn't here missing: free(r->mppe.sendkey); --> demangle(r, data, len, &r->mppe.sendkey, &r->mppe.sendkeylen); log_Printf(LogPHASE, " MS-MPPE-Send-Key \n"); break; Am I right or is this just a bug in my brain? bye, -- --- -- Michael Bretterklieber- [EMAIL PROTECTED] JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200-- privat A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED] Fax: ++43-(0)316-403274-10 http://www.inode.at/mbretter --- -- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: PPPoEd Bug.
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 understanding that you accidentally had a non-compliant > client, and therefore discoverd that FreeBSD as a server could cope with > that, but that once it did, it couldn't go back? I wasn't at first aware that it was this client at fault (I didn't know it was patched back then). But generally you're right :) > I'll have a look. Thank You Best regards, Pawel 'ofca' Tyll. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
mpd radius - request for review
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 auth-types are supported (pap, chap-md5, mschap v1 and mschap v2),
also mppe works.
Here are the new config-params:
set radius config /etc/radius.conf
or
set radius retries 3
set radius timeout 3
set radius server localhost testing123
=> configures radius (thanks to Brendan Bank).
set bundle enable radius-auth => enables Radius Auth
set bundle enable radius-fallback => enables fallback to mpd.secret if
radius-auth not succeeded
set ipcp enable radius-ip => let the radius-server assign the ip for the
user
with "show radius" all radius-related params are printed out.
After the code has being integrated into mpd I would like continue
implementing more features:
- MPPE Types and Policy
- Let mpd use other radius-params.
- Accounting
If the code is to bad for integration into mpd, no problem, because then
it was only a good exercise for me.
I attached the patches and also 2 new files for mpd 3.10.
bye,
--
--- --
Michael Bretterklieber - [EMAIL PROTECTED]
JAWA Management Software GmbH - http://www.jawa.at
Liebenauer Hauptstr. 200 -- privat
A-8041 GRAZ GSM: ++43-(0)676-93 96 698
Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED]
Fax: ++43-(0)316-403274-10 http://www.inode.at/mbretter
--- --
"...the number of UNIX installations has grown to 10, with more
expected..." - Dennis Ritchie and Ken Thompson, June 1972
Index: Makefile
===
RCS file: /cvsrep/mpd/src/Makefile,v
retrieving revision 1.4
retrieving revision 1.8
diff -r1.4 -r1.8
1c1
< # $Id: Makefile,v 1.4 2002/10/26 12:26:03 mbretter Exp $
---
> # $Id: Makefile,v 1.8 2002/11/03 14:09:20 mbretter Exp $
43a44
>
48a50,52
> RADIUS= yes
> LDADD+= -lradius
>
84c88
< vars.c custom.c
---
> vars.c custom.c radius.c
Index: bund.c
===
RCS file: /cvsrep/mpd/src/bund.c,v
retrieving revision 1.3
diff -r1.3 bund.c
129c129,131
< { 0, 0, NULL},
---
> { 0, BUND_CONF_RADIUSAUTH, "radius-auth" },
> { 0,BUND_CONF_RADIUSFALLBACK, "radius-fallback" },
> { 0,0, NULL},
595,598c597,600
< if ((sb = gBundles[k]) != NULL) {
< printf(BUND_FMT, sb->name);
< BundShowLinks(sb);
< }
---
> if ((sb = gBundles[k]) != NULL) {
> printf(BUND_FMT, sb->name);
> BundShowLinks(sb);
> }
605,610c607,612
< bund = sb;
< if (lnk->bund != bund)
< lnk = bund->links[0];
< } else
< printf("Bundle \"%s\" not defined.\n", av[0]);
< break;
---
> bund = sb;
> if (lnk->bund != bund)
> lnk = bund->links[0];
> } else
> printf("Bundle \"%s\" not defined.\n", av[0]);
> break;
714a717,719
>
> Disable(&bund->conf.options, BUND_CONF_RADIUSAUTH);
> Disable(&bund->conf.options, BUND_CONF_RADIUSFALLBACK);
Index: bund.h
===
RCS file: /cvsrep/mpd/src/bund.h,v
retrieving revision 1.4
diff -r1.4 bund.h
22a23
> #include "radius.h"
40a42,43
> BUND_CONF_RADIUSAUTH, /* enable radius auth */
> BUND_CONF_RADIUSFALLBACK, /* enable fallback to mpd.secret */
134a138,140
>
> /* radius */
> struct radius radius;
Index: ccp_mppc.c
===
RCS file: /cvsrep/mpd/src/ccp_mppc.c,v
retrieving revision 1.2
retrieving revision 1.4
diff -r1.2 -r1.4
595a596,604
> if (bund->radius.valid == 1) {
> if (dir == COMP_DIR_XMIT) {
> memcpy(mppc->xmit_key0, bund->radius.mppe.sendkey,
>MPPE_KEY_LEN);
> } else {
> memcpy(mppc->recv_key0, bund->radius.mppe.recvkey,
>MPPE_KEY_LEN);
> }
> return;
> }
>
Index: chap.c
===
RCS file: /cvsrep/mpd/src/chap.c,v
retrieving revision 1.3
retrieving revision 1.8
diff -r1.3 -r1.8
18a19
> #include "radius.h"
30,42d30
< struct mschapvalue {
< u_charlmHash[24];
< u_charntHash[24];
< u_charuseNT;
< };
<
<
bpf
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 device is not set until the bpf buffer is full. (which might be several seconds away since I´m using fairly large bpf buffers) Looking at the code I get the impression that if there are packets on the bpf buffer when the select timeouts, it should return the fd for the bpf ? Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: bpf
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 wrote: > > 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 > device is not set until the bpf buffer is full. (which might be several seconds > away since I?m using fairly large bpf buffers) > > Looking at the code I get the impression that if there are packets on the bpf > buffer when the select timeouts, it should return the fd for the bpf ? > > Pete > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: mpd radius - request for review
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, > > 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 auth-types are supported (pap, chap-md5, mschap v1 and mschap v2), > also mppe works. > > Here are the new config-params: > > set radius config /etc/radius.conf > or > set radius retries 3 > set radius timeout 3 > set radius server localhost testing123 > => configures radius (thanks to Brendan Bank). > > set bundle enable radius-auth => enables Radius Auth > set bundle enable radius-fallback => enables fallback to mpd.secret if > radius-auth not succeeded > > set ipcp enable radius-ip => let the radius-server assign the ip for the > user > > with "show radius" all radius-related params are printed out. > > After the code has being integrated into mpd I would like continue > implementing more features: > - MPPE Types and Policy > - Let mpd use other radius-params. > - Accounting > > If the code is to bad for integration into mpd, no problem, because then > it was only a good exercise for me. > > I attached the patches and also 2 new files for mpd 3.10. > > > bye, To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
fragmentation issues
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 multicast processing. I guess the correct way to solve the problem is to do some form of fragmentation _before_ adding the new header to the packet. This requires the replication of some code which is in ip_output(). So i was wondering if there objections if in the long term i pull out the fragmentation code from ip_output and put it into a separate procedure that can be used wherever is required without having to replicate the code (and maintain it). comments ? cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: fragmentation issues
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 encapsulations > (gif, maybe faith), with IPSEC, and with some multicast > processing. > yes I have: tcp/udp in ip in ppp in udp in esp in ip in my applications.. I ended up having to set the MTU of the tunnel interfaces down to about 1400 bytes so that the final packet could get into the 1500 byte ethernet frame neeed to get to the router to the Internet. (mtu discovery then reduced the path mtu and everything is cool) > I guess the correct way to solve the problem is to do > some form of fragmentation _before_ adding the new > header to the packet. This requires the replication of > some code which is in ip_output(). > > So i was wondering if there objections if in the long > term i pull out the fragmentation code from ip_output > and put it into a separate procedure that can be used > wherever is required without having to replicate the > code (and maintain it). > > comments ? > seems reasonable. Well see how practical it is when you try do it :-) > cheers > luigi > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
MTU problems ...
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 downloads hanging (ftp/http/scp). The only way to make a download work is to choose an MTU setting on tun0 (this is a pppoe session) of the FreeBSD server (currently 4.6.2-Rel) until I find a value (1452, 1460, most things work at 1492 though) that makes the download complete properly. Sometimes finding an MTU that works is just not possible. The only icmp rule in ipfw is to allow all icmp so I am not unwittingly disallowing anything important. Could this thread be related to my problem? and was there any resolution with this? http://www.freebsd.org/cgi/getmsg.cgi?fetch=61954+0+/usr/local/www/db/text/2002/freebsd-net/20020825.freebsd-net According to my ISP (and a few other ISP's in the area) only FreeBSD systems and certain IOS versions are experiencing this problem. What can I do to start debugging this? Please CC me as I am not subscribed to net@. cheers, -- Derek Marshall Smash and Pow Inc > 'digital plumber' http://www.smashpow.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
