Activity for MPD: FreeBSD PPP daemon
-
Grzesiek G modified a comment on discussion Help
Solved. radsrv open must be at the end of the mpd.conf file
-
Solved
-
Unable to connect to the radsrv server. I want to disconnect the session from the freeradius server. I'm testing with the radiusclient client. Error Nov 27 09:13:58 busko2 mpd[42573]: radsrv: request receive error: -2 Nov 27 09:14:58 busko2 mpd[42573]: radsrv: request receive error: -2 My config: radius: set radius server 127.0.0.1 secret 1812 1813 set radius server 10.90.91.2 secret 1812 1813 set radius retries 2 set radius timeout 10 set radius me 10.90.91.13 set auth acct-update 300 set auth enable...
-
Yannick C posted a comment on discussion Help
Hi @Eugene, could you kindly check this ? Regards.
-
Hello Eugene, it happened again : route_monitor.log 03:01:03.057 PID 0 add/repl iface iface#225 ng192 admin DOWN oper DOWN mtu 1500 03:01:03.058 PID 0 add/repl iface iface#225 ng192 admin DOWN oper DOWN mtu 1492 03:01:03.078 PID 0 add/repl iface iface#225 ng192 admin UP oper UP mtu 1492 03:01:03.078 PID 0 add/repl addr 10.129.39.254/32 -> 10.129.36.24 iface ng192 03:01:03.078 PID 0 add/repl addr 10.129.39.254/32 -> 10.129.36.24 iface ng192 03:01:03.078 PID 0 add/repl iface iface#225 ng192 admin UP...
-
Hi Eugene, the issue just happened, here are the grabbed log files. Please let us know your thoughts. Regards.
-
Eugene Grosbein posted a comment on discussion Help
For a test, you can change default initial flags and "lock" them: stty -f /dev/cuau4.init -icanon -isig -iexten -echo -echoe -icrnl ... stty -f /dev/cuau4.lock icanon isig iexten echo echoe icrnl ... And so on, to make set of flags identical to working set used by ppp. Then restart mpd5.
-
kuba tyszko posted a comment on discussion Help
Ok, I did all the steps and here's the stty output diff now: bsm% diff --side-by-side stty1pre stty1lcp bsm# stty -a -f /dev/cuau4 bsm# stty -a -f /dev/cuau4 speed 115200 baud; 0 rows; 0 columns; speed 115200 baud; 0 rows; 0 columns; lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -ec | lflags: icanon isig iexten echo echoe -echok echoke -echonl e -echoctl -echoprt -altwerase -noflsh -tostop -flusho | -echoprt -altwerase -noflsh -tostop -flusho -pendin - -nokerninfo -extproc | -extproc...
-
Despite of warnings from comcontrol, /etc/rc.d/serial works nevertheless. Now re-post stty output while mpd5 runs LCP.
-
Nothing changed, mpd takes the new setting just fine but there's no difference in LCP. adding the 'modem u 4' to /etc/rc.d/serial doesn't work either, it won't work with or without mpd5 running, I tried both: bsm# echo 'modem u 4' >> /etc/rc.d/serial bsm# service serial restart comcontrol: couldn't open file /dev/ttyu4: Device busy bsm# service mpd5 stop Stopping mpd5. Waiting for PIDS: 40154. bsm# bsm# service serial restart comcontrol: TIOCMSDTRWAIT: Inappropriate ioctl for device
-
https://mpd.sourceforge.net/doc5/mpd43.html#43 Try to add to mpd.conf: set modem speed 115200 Try to add a line to the end of /etc/rc.d/serial: modem u 4 Then do "service serial start". Then restart mpd5 with above command added.
-
bsm% diff --side-by-side sttympdidle sttympdlcp speed 115200 baud; 0 rows; 0 columns; | speed 9600 baud; 0 rows; 0 columns; lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -ec | lflags: icanon isig iexten echo echoe -echok echoke -echonl e -echoctl -echoprt -altwerase -noflsh -tostop -flusho | -echoprt -altwerase -noflsh -tostop -flusho -pendin - -nokerninfo -extproc | -extproc iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -ima | iflags: -istrip icrnl -inlcr -igncr ixon -ixoff...
-
Please share output of "stty -a -f /dev/cuau4" at server side while running mgetty and ppp first, and then output of same command while running mpd5.
-
Hi there, I know this may be a bit unusual these days, but I'm trying to create a dial-in server on my FreeBSD box with 14.2 and MPD5 (version 5.9). It's working just fine when I use mgetty and ppp - including NAT etc. My next goal is to play with multilink-PPP (something I never had a chance to do during modem era), and for that I need MPD5. Now, I tried dialing into BSD from Windows XP, from Linux and from another FreeBSD (with MPD) to get additional debugging info, but it fails during LCP without...
-
Hi there, I know this may be a bit unusual these days, but I'm trying to create a dial-in server on my FreeBSD box with 14.2 and MPD5 (version 5.9). It's working just fine when I use mgetty and ppp - including NAT etc. My next goal is to play with multilink-PPP (something I never had a chance to do during modem era), and for that I need MPD5. Now, I tried dialing into BSD from Windows XP, from Linux and from another FreeBSD (with MPD) to get additional debugging info, but it fails during LCP without...
-
Hi there, I know this may be a bit unusual these days, but I'm trying to create a dial-in server on my FreeBSD box with 14.2 and MPD5 (version 5.9). It's working just fine when I use mgetty and ppp - including NAT etc. My next goal is to play with multilink-PPP (something I never had a chance to do during modem era), and for that I need MPD5. Now, I tried dialing into BSD from Windows XP, from Linux and from another FreeBSD (with MPD) to get additional debugging info, but it fails during LCP without...
-
Hi Eugene, thank you for replying and your support. The script is running, we are waitinf for the next route event. Regards.
-
Are you able to reproduce this using "clean" environment? That is: take a system having no such bad route yet, run "script route.log route -n monitor", reproduce the problem, post route.log
-
Are you able to reproduce this using "clean" environment? That is: take a system having no such bad route yet, run "scrupt route.log route -n monitor", reproduce the problem, post route.log
-
Hi Grzesiek, It looks we have the same bug, I've updated to FreeBSD 14.3-RELEASE and the bug is still present for me. please check my post : https://sourceforge.net/p/mpd/discussion/44693/thread/2b3e5ea536/?limit=100
-
Hi Eugene, We are on FreeBSD 14.3-RELEASE and the bug is still present. Which options do we have without moving to STABLE versions ? Thanks in advance for your advice.
-
I updated to version 14.3. I tested it and it works as expected. Thank you for your help.
-
Danster posted a comment on discussion Open Discussion
Hi Eugene, Thanks for the response. But, I am not following you 100%. The below is dummy config just to create some context: default: load complete_lac #========================================================================== #VLAN2485 #========================================================================== create link template L2485 pppoe set pppoe iface vtnet1 set link no eap set link enable pap chap chap-msv1 chap-msv2 chap-md5 set link enable multilink set link action forward L30 "@test$"...
-
Such implementation is not planned at the moment. However, you can get it with some scripting and mpd5's telnet console: use "set iface down-script" for primary peer to issue "open" command for secondary peer over telnet.
-
Such implementation is not planned at the moment. However, you can get it with some scripting and mpd5's telnet console: use "set iface down-script" for primary peer to issue "open" command fir secondary peer over telnet.
-
Hi there, Unless I’ve overlooked an existing feature, I wanted to ask whether there are any plans to implement L2TP peer redundancy or failover support in MPD5? For example, my use case involves configuring multiple L2TP peers (e.g., a primary and secondary) within a single L2TP template. The idea would be that, should the primary peer become unreachable (detected via lack of hello packets or similar mechanism), the system automatically attempts to establish a connection with the backup peer. This...
-
Also, 13.5-RELEASE contains the fix, too. So you may find that version useful.
-
This is kernel bug (not mpd bug) already fixed in stable/14 branch: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279988 Either switch to 14.2-STABLE or apply the fix manually to the 14.2-RELEASE kernel or wait for 14.3-RELEASE.
-
Hi @dadv, any update for us please ? Cheers?
-
This bug looks similar to the previous thread "IFACE: Adding IPv4 address to ng0 failed: File exists + iBGP or OSPF" but I am on freeBSD 14.2, it should be fixed.... I also posted in FreeBSF Forum : https://forums.freebsd.org/threads/cannot-delete-ip-route.97263/#post-694914
-
This bug looks similar to the previous thread "IFACE: Adding IPv4 address to ng0 failed: File exists + iBGP or OSPF" but I am on freeBSD 14.2, it should be fixed....
-
Hello, normally mpd should delete the connected route when the pppoe session is terminated, but in my case we have a "ghost" route still present and when a new pppoe connection is requesting 10.128.32.4 which is supposed to be available, we have an error from mpd : Mar 20 09:00:02 bng1 mpd[77832]: [BT1517-167] IPCP: state change Ack-Rcvd --> Opened Mar 20 09:00:02 bng1 mpd[77832]: [BT1517-167] IPCP: LayerUp Mar 20 09:00:02 bng1 mpd[77832]: [BT1517-167] 10.128.35.254 -> 10.128.32.4 Mar 20 09:00:02...
-
Add missing article.
-
Nevermind. I've managed to test the fix myself, it works. I've merged the fix to stable branches. So, you can either update to 14.2-STABLE or wait for 14.3-RELEASE.
-
Sorry, I referred to different problem. The one I meant is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277125 The fix has been committed to CURRENT but not in STABLE branches yet. Are you in position to test the fix with your system? You'll need to install sources, apply attached patch, rebuild kernel only, install the kernel and reboot.
-
Refer to https://reviews.freebsd.org/D46301 for defails.
-
This is known and yet unfixed problem in FreeBSD 14.0+ kernel. You may find 13.4-RELEASE more usable until that's fixed.
-
The configuration is FreeBSD 14.1-RELEASE-p5 mpd5-5.9_18 Bird2 Two PPPoE routers running the mpd daemon. Broadcasting combined PPPoE routes between PPPoE and BGP routers (bird2). Pppoe login associated with a static IP/32 address. MPD does not establish a tunnel if there is an entry from the bird daemon in the Routing table. net.route.multipath: 1 error [B-1] IFACE: Adding IPv4 address to ng0 failed: File exists netstat -rn 10.20.20.2 10.10.10.1 UGH em1 mpd.conf pppoe_server: create bundle template...
-
Dmitry S. Lukhtionov committed [r2596] on Code
Add endpoint-independent mapping (EIM) support for NAT
-
Ruben Vos posted a comment on discussion Help
@Eugene Grosbein: The sample config files were instrumental to setting up the mpd5 config I have been running with for the past few months. TnX for your suggestion!
-
Ari Suutari posted a comment on discussion Help
Upgraded to FreeBSD 14.1 and now it works.
-
I'm starting to suspect that problem is not in mpd5, but in ng_ kernel modules that are being used here. If I disable ipcp the link stays up. And ipcp happens in ng_ module (as far as I understand).
-
You could find useful ktrace(1) kernel facility to record system calls and sent/received data of mpd5 process: ktrace -i mpd5 ... kdump
-
There is only one relevant initialization setting in mpd.script (AT+CGDCONT), which is same for both.
-
Make sure that your AT-commands script for the modem initializes it exactly same way as one for user-ppp.
-
Your logs already have it, for example: Sep 16 12:08:38 box-174 mpd[6329]: [B-Link] rec'd 27 bytes frame from link proto=0xc021 Sep 16 12:08:38 box-174 mpd[6329]: c0 21 01 06 00 19 02 06 00 00 00 00 03 05 c2 23 .!.............# Sep 16 12:08:38 box-174 mpd[6329]: 05 05 06 3a 14 eb db 07 02 08 02 ...:.......
-
Is it possible to have mpd5 log serial line data ? Something like this in user-mode ppp: Sep 17 10:00:59 synciot-174 ppp[28658]: tun1: Debug: proto_LayerPush: Using 0xc021 Sep 17 10:00:59 synciot-174 ppp[28658]: tun1: HDLC: hdlc_Output Sep 17 10:00:59 synciot-174 ppp[28658]: tun1: HDLC: ff 03 c0 21 01 01 00 18 08 02 07 02 02 06 00 00 ...!............ Sep 17 10:00:59 synciot-174 ppp[28658]: tun1: HDLC: 00 00 01 04 05 dc 05 06 8f d7 8c 75 33 58 ...........u3X
-
It's not ISP I'm talking to. It's LTE/4G modem, which uses PPP between it and host system. This is very common with such devices, but there is now PPP going out from modem's radio! https://source.sierrawireless.com/resources/airprime/minicard/75xx/41111748-airprime-em75xx-at-command-reference/ Section 13 in manual "GSM/WCDMA AT COMMANDS", page 131. As these modems can achive quite high network speeds, we have been preferring mpd5 instead FreeBSD's user mode ppp (which pushes all the traffic thru...
-
Perhaps, your ISP somehow detects you are "sharing" the connection among multiple devices while it does not permit that? Try filtering all IP traffic running over ng0 interface for some time to see if termination delays, too?
-
Tried that. Unfortunately no luck.
-
OTOH, maybe other side wants to serve only "known" PPP clients. Try to pretend this is user-ppp: set link ident "user-ppp 3.4.2"
-
OTOH, maybe other side wants to serve only "known" PPP clients. Try to pretend ths is user-ppp: set link ident "user-ppp 3.4.2"
-
Oh yes, I tried to add it because there was something similar in ppp.log. Removed now, fresh log and config attached.
-
The log shows the following: Sep 16 12:08:38 box-174 mpd[6329]: [B-Link] LCP: SendIdent #1 Sep 16 12:08:38 box-174 mpd[6329]: [B-Link] MESG: synciot Sep 16 12:08:38 box-174 mpd[6329]: [B-Link] xmit frame to link proto=0xc021 Sep 16 12:08:38 box-174 mpd[6329]: ff 03 c0 21 0c 01 00 10 21 10 f1 31 73 79 6e 63 ...!....!..1sync Sep 16 12:08:38 box-174 mpd[6329]: 69 6f 74 00 The documentation https://mpd.sourceforge.net/doc5/mpd20.html#20 tells: set link ident string This enables the sending of an identification...
-
The log shows the following: Sep 16 12:08:38 box-174 mpd[6329]: [B-Link] LCP: SendIdent #1 Sep 16 12:08:38 box-174 mpd[6329]: [B-Link] MESG: synciot Sep 16 12:08:38 box-174 mpd[6329]: [B-Link] xmit frame to link proto=0xc021 Sep 16 12:08:38 box-174 mpd[6329]: ff 03 c0 21 0c 01 00 10 21 10 f1 31 73 79 6e 63 ...!....!..1sync Sep 16 12:08:38 box-174 mpd[6329]: 69 6f 74 00 The documentation https://mpd.sourceforge.net/doc5/mpd20.html#20 tells: set link ident string This enables the sending of an identification...
-
The log shows the following: Sep 16 12:08:38 box-174 mpd[6329]: [B-Link] LCP: SendIdent #1 Sep 16 12:08:38 box-174 mpd[6329]: [B-Link] MESG: synciot Sep 16 12:08:38 box-174 mpd[6329]: [B-Link] xmit frame to link proto=0xc021 Sep 16 12:08:38 box-174 mpd[6329]: ff 03 c0 21 0c 01 00 10 21 10 f1 31 73 79 6e 63 ...!....!..1sync Sep 16 12:08:38 box-174 mpd[6329]: 69 6f 74 00 The documentation https://mpd.sourceforge.net/doc5/mpd20.html#20 tells: set link ident string This enables the sending of an identification...
-
The log shows the following: Sep 16 12:08:38 box-174 mpd[6329]: [B-Link] LCP: SendIdent #1 Sep 16 12:08:38 box-174 mpd[6329]: [B-Link] MESG: synciot Sep 16 12:08:38 box-174 mpd[6329]: [B-Link] xmit frame to link proto=0xc021 Sep 16 12:08:38 box-174 mpd[6329]: ff 03 c0 21 0c 01 00 10 21 10 f1 31 73 79 6e 63 ...!....!..1sync Sep 16 12:08:38 box-174 mpd[6329]: 69 6f 74 00 The documentation https://mpd.sourceforge.net/doc5/mpd20.html#20 tells: set link ident string This enables the sending of an identification...
-
Here is the latest log.
-
Anyway, please post latest mpd log.
-
Unfortunately, with this change, it still behaves same as before.
-
The only notable difference left is accmap option, try to add this: set link accmap 0
-
Disabling vjcomp and CCP didn't help. Here is mpd2.log from connection attempt with those disabled. I'll attach also ppp.log from user-level ppp which contains successful negotiation.
-
Also, remote side rejects CCP protocol, so change "set bundle enable compression" to "set bundle disable compression"
-
First, disable IPCP vjcomp option as remote side rejects it anyway: set ipcp disable vjcomp And retry. If it does not help, please collect similar log of user-level ppp that includes IPCP negotiation to compare, and post it.
-
Hi, I have a FreeBSD 13.3 machine with Sierra Wireless EM7421 LTE/4G modem. I have been trying to get mpd5 (mpd5-5.9_18) working with without much success. The configuration I'm using is the same which works with older devices having SimTech modems. My configuration looks like this: mobile: create bundle static mobile set bundle links B-Link set bundle enable ipcp set bundle enable compression set iface route default set ipcp ranges 0.0.0.0/0 10.0.0.1/0 set ipcp enable req-pri-dns set ipcp enable...
-
Ben Evans posted a comment on discussion Help
Hi, after some tweaking was able to setup mpd5 and much happier with cpu usage compared to pppd but have a minor issue. When the pppoe interface is created with the ipv6cp option it assigns the ipv6 link-local address as fe80::1 instead of a eui-64 based on the physical interface's mac which I'd prefer as it's used by dhcpcd to negotiate a global address. I'm aware you can run a script to change the address after the interface is up but feels more fragile and it appears to be possible to use an eui-64...
-
So unless the client accepts our use of pap/chap at the lcp layer, then it wont make it to generating a radius request? It depends. Do you try to make split LAC/LNS configuration or mpd5 needs to serve users all by itself?
-
Mr Steven Crangle posted a comment on discussion Help
Thanks. So unless the client accepts our use of pap/chap at the lcp layer, then it wont make it to generating a radius request? Or am I misunderstanding? I think our previous patched version of 5.8 did a sort of proxy auth instead of dealing with it in the lcp error, but it was never merged in to mpd, and is likely uncompatible with the current code base.
-
This log indicates exactly same problem: a client rejects to authorize itself with MS-CHAPv2. The client must be reconfigured to use MS-CHAPv2.
-
This log indicates extactly same problem: a client reject to authorize itself with MS-CHAPv2. The client must be reconfigured to use MS-CHAPv2.
-
Our solution talks to FreeRADIUS also on FreeBSD, so I'd assume it needs CHAP-MD5. I've tried enabling that too, but no chap setting seems to result in a radius request being generated by MPD, it's like it's just trying to auth locally even though internal auth is disabled. Thanks Steven
-
Apologies, here are the logs with the recommended log settings: Jun 21 08:52:54 manlns1 mpd[97891]: Incoming L2TP packet from 185.153.238.191 1701 to 185.100.175.193 1701 Jun 21 08:52:54 manlns1 mpd[97891]: L2TP: ppp_l2tp_ctrl_create invoked Jun 21 08:52:54 manlns1 mpd[97891]: L2TP: Control connection 0x5242e765e310 185.100.175.193 1701 <-> 185.153.238.191 1701 accepted Jun 21 08:52:54 manlns1 mpd[97891]: L2TP: RECV [MESSAGE_TYPE SCCRQ] [PROTOCOL_VERSION 1.0] [HOST_NAME "3UK-SL01RPG01-LAC"] [RECEIVE_WINDOW_SIZE...
-
Please do not cut the logs. We need full session log. Also, replace your "log +ALL -EVENTS -FRAME -ECHO +RADIUS +RADIUS2" with something like the following: log +auth +bund +iface +iface2 +ipcp +ipcp2 +link +lcp +lcp2 +rep
-
The log shows that client was not configured to use MS-CHAPv2 and rejected to used it while mpd5 server was configured to require MS-CHAPv2 (not PAP).
-
Another thing we see in the RADIUS layer too, is this: Jun 20 10:04:36 manlns1 mpd[95157]: [TUK175193-2] RADIUS: Put RAD_ACCT_MULTI_SESSION_ID: 8877876-LTE-2 Jun 20 10:04:36 manlns1 mpd[95157]: [TUK175193-2] RADIUS: Put RAD_MPD_BUNDLE: LTE-2 Jun 20 10:04:36 manlns1 mpd[95157]: [TUK175193-2] RADIUS: Put RAD_MPD_IFACE: ng0 Jun 20 10:04:36 manlns1 mpd[95157]: [TUK175193-2] RADIUS: Put RAD_MPD_IFACE_INDEX: 8 Jun 20 10:04:36 manlns1 mpd[95157]: [TUK175193-2] RADIUS: Put RAD_MPD_PEER_IDENT: Jun 20 10:04:36...
-
Hi, I'm currently running FreeBSD 14.0 Release with MPD 5.9_18. I'm attempting to use a radius server to auth PAP/CHAP requests. Here are what I think are the relevant parts of the config: set link action bundle LTE set link enable incoming set link disable peer-as-calling set link enable pap chap # settings on the link set link disable acfcomp set link disable protocomp set link disable check-magic set link deny acfcomp set link deny protocomp radiussettings: set radius server 172.31.4.193 BIYAQsK5BtnM5dUMYt4NYXS53MIlICNA...
-
Format JSON output
-
`show customer` admit only in `bundle` layer
-
Temporary disable usage of clock_gettime()
-
Fix
-
Fix previous commit
-
First step to remove gettimeofday()
-
util.c: avoid usage of unneeded struct sockaddr_inarp
-
changes.sgml: elaborate latest change and move to Changes section
-
Fix previouse commit
-
Update `changes`
-
radius.c: cut all null bytes at start of RAD_MICROSOFT_MS_CHAP_ERROR msg
-
Fix
-
Fix display MS-CHAPv2 message
-
Malloc() zeroes area that is excessive if we overwrite it immediately.
-
iface.c: simplify code as Malloc() never returns NULL
-
pppoe.c: expand commentary about magic number
-
iface.c: avoid extra zeroing
-
EAP transcript
-
Add dictionary directory
-
Makefile: use optional REVISION as suffix for VERSION
-
l2tp_ctrl.c: correction after r2398: change log level to LOG_WARNING
-
Makefile: prepare for 5.10 release.
-
Remove commented debugging code.
1 >
