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.
Despite of warnings from comcontrol, /etc/rc.d/serial works nevertheless. Now re-post stty output while mpd5 runs LCP.
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.
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.
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
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.
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.
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.
You could find useful ktrace(1) kernel facility to record system calls and sent/received data of mpd5 process: ktrace -i mpd5 ... kdump
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 ...:.......
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?
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"
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...
Anyway, please post latest mpd log.
The only notable difference left is accmap option, try to add this: set link accmap 0
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.
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?
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.
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).
util.c: avoid usage of unneeded struct sockaddr_inarp
changes.sgml: elaborate latest change and move to Changes section
radius.c: cut all null bytes at start of RAD_MICROSOFT_MS_CHAP_ERROR msg
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
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.
http_server.c: remove commented debugging code
changes.sgml: document system call decrease
changes.sgml: document the change for default version string
gencmd.sgml: add label for the Changes secion.
changes.sgml: mention new command "set global version"
doc/gencmd.sgml: document new command: set global version [ string ]
Include the version level of the operating system as per "uname -v"
interface.sgml: grammar fix "we are not clear" -> "we do not clear"
auth.sgml: note that OPIE support is not compiled in by default since 5.6.
Improve description of "acct-decimal" option.
mpd.conf.sample: add some more commentaries
tcp.c: fix spelling, thie -> this
changes.sgml: document memory and file descriptor leak plugged in r2559.
command.c: properly close FILE* rf got from libfetch
Document possibility of building Mpd without libpcap
Document total amount of traffic filters supported without rebuild.
Introduce new build mode USE_PCAP=no to disable usage of libpcap.
It works again, thank you. The ticket may be closed.
svn+ssh:// public key authorisation broken
iface.c: correction after r2544
I believe the problem should be discussed in the FreeBSD Bugzilla then. Please file a Problem Report there: https://bugs.freebsd.org/ for its base system (kernel part) and post PR number here. The Problem Report should include exact versions of FreeBSD and mpd5.
I believe the problem should be discussed in the FreeBSD Bugzilla then. Please file a Problem Report there: https://bugs.freebsd.org/ for its kernel and post PR number here.
Please specify exact mpd5 version you use, as per: pkg info -x mpd5
Avoid repeating gethostname() system call caching hostname
Makefile: correction after r2545
Fix build with OpenSSL 3.0 that removed ERR_GET_FUNC() macro
iface.c: libpcap 1.8.1 deprecated pcap_compile_nopcap()
If compression and/or encryption is enabled and negotiated for a connection,
ipv6cp.sgml: improve description
iface.c: spelling fix timespamp -> timestamp
Fix implementation of administrative link state
Introduce new interface description conversion specification %s
changes.sgml: move description of PPPoE link auto-reconnection to Bugfixes
changes.sgml: remove clause about socket opening from Changes section
iface.c: remove #include's for some headers already included in ppp.h
New function GetLocalSocket() caches obtained
Unbreak PPPoE connection if peer does not advertize its MRU.
"Cannot allocate memory" is very unusual error while constructing new PPPoE connection. Indeed, mpd5 port code after 5.9_2 did not receive any memory-related updates and it still runs just fine to busy installations but it may require some NETGRAPH tuning in /boot/loader.conf: net.graph.maxdata=65536 net.graph.maxalloc=65536 If you have not done it, I suggest to apply these settings (requires reboot). Otherwise, it could be some leak inside kernel. Unfortunately, FreeBSD 12.2 is EOL. I'd suggest...
main.c: use _assert(0) in main() too
pppoe.c: use _assert(0) for fatal error
link.c: check for regcomp() failure
util.c: replace strcpy() with memmove() in ParseLine()
util.c: unbreak Escape() function
util.c: no need to overwrite double quote with itself in Escape()
log.c: add /* FALLTHROUGH */ to LogCommand()
eap.c: add sanity checks for incoming EAP packets
eap.c: revert r2517 as pkg may be NULL for EAP Success or Failure packets.
auth.c: revert previous commit r2519
auth.c: avoid dereferencing pkt for short EAP packet
auth.c: rearrange sanity check in AuthInput()
eap.c: place asserts where pkt cannot be NULL.
Add asserts for Mbuf where is cannot be NULL.
Compile out asserts in HTTP server code, too,
Introduce new macro _assert() not depending on NDEBUG.