ppp receiving wrong device number (cuaa10 instead of cuaaa, cuaa15
instead of cuaaf)
Alexander Lunyov
lan at startatom.ru
Mon May 17 04:21:02 PDT 2004
Hello.
We have a gateway for our inner clients, it is FreeBSD-4.8R-p14,
three Cronyx Omega PCI multiport cards (24 ports in sum), mgetty
listening on all those ports, and when user connects, mgetty run
exppp (enchanced ppp incarnation, http://shs.sumy.ua).
Freeradius handles authentication and accounting. When i've enable
freeradius module rlm_ippool (ip addresses pooling module), dialup
users start receiving error "server have not assign ip address"
after connecting on some telephone numbers (not all, just some
numbers), and when i dig some further, i found, that freeradius in
such cases did not receive NAS-Port-Id attribute from exppp.
Freeradius receive standard request, but without one attribute, in
example:
Service-Type = Framed-User
User-Name = "bpv89"
Framed-Protocol = PPP
CHAP-Password = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
CHAP-Challenge = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
NAS-Identifier = "zeus.domain.ru"
NAS-Port-Type = Async
Then i started to watch for ppp connections. And i found strange thing. Look
at this (ppp log):
Phase: Using interface: tun9
Phase: deflink: Created in closed state
Command: default: set radius /etc/radius.conf
Command: default: set dns 192.168.33.127
Command: default: set local_ip 62.33.65.0/24
Warning: Add local net: 62.33.65.0/24
Command: default: accept dns
Command: default: enable lqr
Command: default: enable pap
Command: default: enable chap
Command: default: enable mschap
Command: default: enable mschapv2
Command: default: set rad_alive 20
Command: default: disable acfcomp protocomp
Command: default: deny acfcomp
Command: dialup: set timeout 900
Command: dialup: set mru 576
Command: dialup: set mtu 576
Phase: PPP Started (direct mode).
Phase: bundle: Establish
Phase: deflink: closed -> opening
Phase: deflink: Connected!
Phase: deflink: opening -> carrier
> Phase: deflink: /dev/cuaa15: CD detected *** (1)
Phase: deflink: carrier -> lcp
Phase: bundle: Authenticate
Phase: deflink: his = none, mine = CHAP 0x05
Phase: Chap Output: CHALLENGE
Phase: Chap Input: RESPONSE (16 bytes from rim74)
> Error: NAS-Port-Id borken: -1 *** (2)
Phase: Radius: Request sent
Phase: Radius(auth): ACCEPT received
Phase: Octets limit 292770808
Phase: Chap Output: SUCCESS
Phase: deflink: lcp -> open
Phase: bundle: Network
Then disconnection occures - freeradius didn't deliver ip address for
this connection.
(1) - But mgetty said that modem connects to /dev/cuaaf port! Where
did come digit 15 from? This situation (decimal port number instead
of hex) can also be seen on ports cuaa10 (cuaaa), cuaa11 (cuaab),
cuaa12 (cuaac) etc till cuaa15 - port cuaag always comes in hex.
(2) - This is my debug entry, that i insert in radius.c. Original
code:
if ((slot = physical_Slot(p)) >= 0)
if (rad_put_int(rad, RAD_NAS_PORT, slot) != 0) {
log_Printf(LogERROR, "rad_put: rad_put_int: %s\n", rad_strerror(rad));
rad_close(rad);
return 0;
}
I've added debug 'else' for first 'if' (2). Thus physical_Slot() from
physical.c returning '-1'. In physical.c:
int
physical_Slot(struct physical *p)
{
if (p->handler && p->handler->slot)
return (*p->handler->slot)(p);
return -1;
}
And p->handler is coming from tty.c (if i'm not missed the trail)
in tty_iov2device():
memcpy(&dev->dev, &basettydevice, sizeof dev->dev);
physical_SetupStack(p, dev->dev.name, PHYSICAL_NOFORCE);
if (dev->Timer.state != TIMER_STOPPED) {
dev->Timer.state = TIMER_STOPPED;
p->handler = &dev->dev; /* For the benefit of StartTimer */
tty_StartTimer(p);
}
return &dev->dev;
And i don't know where should i dig further. Must be some place,
where hex numbers returns as decimal, but i don't know, where is it.
Ports on multiport cards are:
cuaa[1-8] - first card
cuaa[9-g] - second card
cuaa[h-o] - third card
And next strange thing is that this problem rising only on ports
cuaa[10-15] (!), in hex is cuaa[a-f] - and i'm surprised that
cuaag is working fine! The most surprising thing is that all ports
on third card (cuaa[h-o]) is working as they should!
But still, 6 of 24 modems are out of order :(
Where those decimal port numbers come from?
I found only one similar problem, but there is no answer to it:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=313299+0+archive/2000/freebsd-bugs/20000702.freebsd-bugs
I've contacted Cronyx company (they produce those multiport cards),
and their specialist said that this is not their driver issue and
he can prove it. And i believe him :)
# uname -a
FreeBSD zeus.domain.ru 4.8-RELEASE-p14 FreeBSD 4.8-RELEASE-p14 #4: Tue Mar 30 10:17:02 MSD 2004
root at zeus.domain.ru:/usr/src/sys/compile/zeus i386
# pkg_info -I freeradius\* mgetty\*
freeradius-0.9.3 A free RADIUS server implementation
mgetty-1.1.28.01.10 Handle external logins, send and receive faxes
p.s.: fragments of code in this message have not changed in exppp,
they are same as in original ppp
p.p.s.: dmesg and all config files are in attachement, if more debug
will be needed - i'll give it.
--
Alexander Lunyov, lan_mailing at startatom.ru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg.boot
Type: application/octet-stream
Size: 4863 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20040517/277fd2b8/dmesg.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mgetty_login.config
Type: application/octet-stream
Size: 103 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20040517/277fd2b8/mgetty_login.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mgetty_mgetty.config
Type: application/octet-stream
Size: 929 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20040517/277fd2b8/mgetty_mgetty.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ppp.conf
Type: application/octet-stream
Size: 741 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20040517/277fd2b8/ppp.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: radiusd.conf
Type: application/octet-stream
Size: 4711 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20040517/277fd2b8/radiusd.obj
More information about the freebsd-net
mailing list