I am trying to run internet via HUAWEI E3372 on Debian. It worked on Windows but did not work on Debian.The error is this: ATDT*99# ERROR --> Invalid dial command. wvdial: utils/wvtask.cc:303: static int WvTaskMan::yield(int): Assertion *current_task->stack_magic == WVTASK_MAGIC' failed. Aborted Here you are the issue info: *wvdial.conf* root@debian:/home/b# cat /etc/wvdial.conf [Dialer orange] Modem = /dev/ttyUSB1 Phone = *99# Username =; Password =; Init1 = ATZ Init2 = AT+CGDCONT=1,"IP","internet","",0,0 Auto DNS = on root@debian:/home/b# *dmesg | grep tty* root@debian:/home/b# dmesg | grep tty [ 0.000000] console [tty0] enabled [ 4.288912] usb 2-8: GSM modem (1-port) converter now attached to ttyUSB0 [ 4.288990] usb 2-8: GSM modem (1-port) converter now attached to ttyUSB1 root@debian:/home/b# *wvdial orange* root@debian:/home/b# wvdial orange --> WvDial: Internet dialer version 1.61 --> Initializing modem. --> Sending: ATZ ATZ OK --> Sending: AT+CGDCONT=1,"IP","internet","",0,0 AT+CGDCONT=1,"IP","internet","",0,0 OK --> Modem initialized. --> Sending: ATDT*99# --> Waiting for carrier. ATDT*99# ERROR --> Invalid dial command. wvdial: utils/wvtask.cc:303: static int WvTaskMan::yield(int): Assertion `*current_task->stack_magic == WVTASK_MAGIC' failed. Aborted root@debian:/home/b# *lsusb* root@debian:/home/b# lsusb Bus 002 Device 002: ID 12d1:1506 Huawei Technologies Co., Ltd. Modem/Networkcard Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 003: ID 1a40:0101 Terminus Technology Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 002: ID 0bf8:1004 Fujitsu Siemens Computers Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub root@debian:/home/b# ## UPDATE ## The configuration worked and internet got present actually. It was empty resolve.conf simlink so I copied /etc/ppp/resolve.conf one and it worked. Anyway **the error still remains** and I would like to get rid of it. Also note that I am doing all with Network Manager service disabled.

I have a SIM LTE modem that use "pon" to connect. This pon use a chat script that send the AT commands needed to connect. when I try to start the ppp service, the AT commands all fail by timeout:

pi@raspberrypi:~ $ sudo pon
pppd options in effect:
debug           # (from /etc/ppp/peers/provider)
updetach                # (from /etc/ppp/peers/provider)
persist         # (from /etc/ppp/peers/provider)
dump            # (from /etc/ppp/peers/provider)
noauth          # (from /etc/ppp/peers/provider)
remotename 3gppp                # (from /etc/ppp/peers/provider)
/dev/ttyUSB3            # (from /etc/ppp/peers/provider)
115200          # (from /etc/ppp/peers/provider)
lock            # (from /etc/ppp/peers/provider)
connect chat -s -v -f /etc/chatscripts/chat-connect -T internet.x              # (from /etc/ppp/peers/provider)
disconnect chat -s -v -f /etc/chatscripts/chat-disconnect               # (from /etc/ppp/peers/provider)
nocrtscts               # (from /etc/ppp/peers/provider)
modem           # (from /etc/ppp/peers/provider)
asyncmap 0              # (from /etc/ppp/options)
lcp-echo-failure 4              # (from /etc/ppp/options)
lcp-echo-interval 30            # (from /etc/ppp/options)
hide-password           # (from /etc/ppp/peers/provider)
novj            # (from /etc/ppp/peers/provider)
novjccomp               # (from /etc/ppp/peers/provider)
ipcp-accept-local               # (from /etc/ppp/peers/provider)
ipcp-accept-remote              # (from /etc/ppp/peers/provider)
ipparam 3gppp           # (from /etc/ppp/peers/provider)
noipdefault             # (from /etc/ppp/peers/provider)
ipcp-max-failure 30             # (from /etc/ppp/peers/provider)
defaultroute            # (from /etc/ppp/peers/provider)
usepeerdns              # (from /etc/ppp/peers/provider)
noccp           # (from /etc/ppp/peers/provider)
noipx           # (from /etc/ppp/options)
abort on (BUSY)
abort on (NO CARRIER)
abort on (NO DIALTONE)
abort on (ERROR)
abort on (NO ANSWER)
timeout set to 30 seconds
send (AT^M)
expect (OK)
^M
alarm
Failed
Script chat -s -v -f /etc/chatscripts/chat-connect -T internet.x finished (pid 2017), status = 0x3

Now, If I run all the commands that are preset in the **/etc/chatscripts/chat-connect** script using minicom, the answer for those commands are instant:

pi@raspberrypi:~ $ sudo minicom -D /dev/ttyUSB3 -b 115200

Welcome to minicom 2.8

OPTIONS: I18n
Port /dev/ttyUSB3, 16:08:09

Press CTRL-A Z for help on special keys

AT

OK
ATE0

OK
AT+CPIN?

+CPIN: READY

OK
AT+CSQ

+CSQ: 16,99

OK
AT+CREG?

+CREG: 0,5

OK
AT+CGREG?

+CGREG: 0,5

OK
AT+COPS?

+COPS: 0,0,"XXX",0

OK
AT+CGDCONT=1,"IP","internet.x",,0,0

OK
ATD*99#

CONNECT 150000000

There are no delays, no waits. The OK are received instantly. Not sure what is happening. I still don't see the ppp0 connection with ifconfig tho.

I recently moved to another company. I had to format my computer, so I decided to test Debian 11. But now I'm facing some issues with VPN. I can't connect to any site that's only is available under VPN. They use SonicWall NetExtender. I've got some logs but it doesn't provides any clues about what is happening...

04/20/2022 20:25:55.411 [connect info    14505] User:   
04/20/2022 20:25:55.411 [connect info    14505] Domain: 
04/20/2022 20:25:55.411 [connect info    14505] Server: 
04/20/2022 20:25:55.457 [general notice  14505] Connecting to ...
04/20/2022 20:25:55.554 [general notice  14505] Connected.
04/20/2022 20:25:55.554 [general notice  14505] Logging in...
04/20/2022 20:25:55.645 [general notice  14505] Login successful.
04/20/2022 20:25:55.806 [general error   14505] Version header not found
04/20/2022 20:25:55.806 [epc     info    14505] Server don't support EPC check. Just pass EPC check
04/20/2022 20:25:55.806 [general warn    14505] WireGuard is not capable, root permission is required.
04/20/2022 20:25:55.907 [connect notice  14505] Try to connect with SSLVPN...
04/20/2022 20:25:56.160 [general notice  14505] SSL Connection is ready
04/20/2022 20:25:57.166 [general info    14505] Using new PPP frame encoding mechanism
04/20/2022 20:25:57.167 [general info    14505] Using PPP async mode (chosen by server) 
04/20/2022 20:25:57.167 [general info    14505] Connecting tunnel...
04/20/2022 20:26:00.282 [connect info    16154] PPP interface up
04/20/2022 20:26:01.282 [dns     notice  16154] Setting up DNS
04/20/2022 20:26:01.296 [general info    16154] Setting up DNS suffixes
04/20/2022 20:26:01.301 [general info    16172] Monitoring processes:  nx=14505, pppd=16132
04/20/2022 20:26:01.301 [dns     info    16172] Monitoring nameserver: 
04/20/2022 20:26:01.301 [dns     info    16172] Monitoring nameserver: 
04/20/2022 20:26:01.301 [dns     info    16172] Monitoring DNS suffix: 
04/20/2022 20:26:01.301 [dns     info    16172] Monitoring DNS suffix: 
04/20/2022 20:26:02.262 [general info    14505] Client IP Address: 
04/20/2022 20:26:02.262 [general info    14505] You now have access to the following 25 remote networks:
04/20/2022 20:26:02.262 [general info    14505] [redacted information]
04/20/2022 20:26:02.264 [general notice  14505] NetExtender connected successfully.
04/20/2022 20:26:02.412 [general info    14505] Saving profiles/preferences...
04/20/2022 20:26:02.412 [general info    14505] Done saving profiles/preferences

Apparently I'm connected but I can't reach any site that's depends on VPN. EDIT: As suggested in comment

# ip route
default via  dev wlp4s0 proto dhcp metric 600 
/16 via  dev ppp0 
 via  dev ppp0 
 via  dev ppp0 
 via  dev ppp0 
 via  dev ppp0 
 via  dev ppp0 
 via  dev ppp0 
 via  dev ppp0 
 via  dev ppp0 
/16 via  dev ppp0 
/16 via  dev ppp0 
/16 dev wlp4s0 scope link metric 1000 
/12 via  dev ppp0 
/16 dev docker0 proto kernel scope link src  linkdown 
 via  dev wlp4s0 
 via  dev ppp0 
 dev ppp0 proto kernel scope link src  
/24 dev wlp4s0 proto kernel scope link src  metric 600 
 dev wlp4s0 scope link 
/24 via  dev ppp0 
/22 via  dev ppp0 
/23 via  dev ppp0 
/23 via  dev ppp0 
/22 via  dev ppp0 
/24 via  dev ppp0 
/23 via  dev ppp0 
/23 via  dev ppp0 
/24 via  dev ppp0 
 via  dev ppp0 
 via  dev ppp0

# ip link
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp3s0:  mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 7c:8a:e1:d8:d2:89 brd ff:ff:ff:ff:ff:ff
3: wlp4s0:  mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 5c:cd:5b:52:8e:ec brd ff:ff:ff:ff:ff:ff
5: docker0:  mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:16:bf:bb:e8 brd ff:ff:ff:ff:ff:ff
8: ppp0:  mtu 1280 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 3
    link/ppp 

# ip address
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0:  mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 7c:8a:e1:d8:d2:89 brd ff:ff:ff:ff:ff:ff
3: wlp4s0:  mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 5c:cd:5b:52:8e:ec brd ff:ff:ff:ff:ff:ff
    inet /24 brd 192.168.15.255 scope global dynamic noprefixroute wlp4s0
       valid_lft 11638sec preferred_lft 11638sec
    inet6 2804:7f0:b980:7174:f5b5:34f3:be57:c90e/64 scope global dynamic noprefixroute 
       valid_lft 43170sec preferred_lft 43170sec
    inet6 fe80::f9c3:d2a:431f:b878/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
5: docker0:  mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:16:bf:bb:e8 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
8: ppp0:  mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 3
    link/ppp 
    inet  peer /32 scope global ppp0
       valid_lft forever preferred_lft forever

**Background Information** * I'm using a Linux system to route traffic for a small block of public IPv4 addresses (by enabling IP forwarding in sysctrl.conf). * The router is connecting to the ISP over eth1 using PPPoE. * The local peer address used for ppp is a manually-configured IP address that was specified by the ISP. The local peer address is 10.0.0.10. * The remote peer address used for ppp is also a manually-configured IP address that was specified by the ISP. The remote peer address is 10.0.0.9. * The router's default route is 10.0.0.9 via 10.0.0.10. * The router is connected to an Ethernet switch via eth0. eth0 is configured to use one of the public addresses. * The switch connects all other public hosts. Each connected host uses a public IP address.

10.0.0.9
ISP ----------+
              |   10.0.0.10                       X.X.X.X
              +------------- (eth1) ROUTER (eth0) --------------- SWTICH 
                                                                     |     
                                                                     +-- X.X.X.Y
                                                                     +-- X.X.X.Z
                                                                     ...

**My Problem** Everything works as expected except for programs running on the router. Any application that I run on the router uses 10.0.0.10 as the source IP address when initiating connections to the internet. This is understandable since eth1 is where the internet is available. However, because the address is not publicly routable, apt, ping, and other programs don't work. If I explicitly set the source address on applications that support it (i.e. ping), applications do work. **My Question** How can I configure the router to route unknown packets via eth1/10.0.0.9 while also using the public IP address on eth0 as the default source when initiating new connections?

I am trying to set up SIM7000E via ppp. SIM7000E is connected to a beaglebone black via micro USB cable. Beaglebone uses 5.10.168-ti-r71 kernel (Debian). SIM7000E drivers have been installed successfully and also ppp is installed too. I entered the directory /etc/ppp/peers, copied the file provider and named it gprs. Gprs file looks like this: # example configuration for a dialup connection authenticated with PAP or CHAP # # This is the default configuration used by pon(1) and poff(1). # See the manual page pppd(8) for information on all the options. # MUST CHANGE: replace myusername@realm with the PPP login name given to # your by your provider. # There should be a matching entry with the password in /etc/ppp/pap-secrets # and/or /etc/ppp/chap-secrets. user "myusername@realm" # MUST CHANGE: replace ******** with the phone number of your provider. # The /etc/chatscripts/pap chat script may be modified to change the # modem initialization string. connect "/usr/sbin/chat -v -f /etc/chatscripts/gprs" # Serial device to which the modem is connected. /dev/ttyUSB2 # Speed of the serial line. 115200 nocrtscts debug nodetach ipcp-accept-local ipcp-accept-remote # Assumes that your IP address is allocated dynamically by the ISP. noipdefault # Try to get the name server addresses from the ISP. usepeerdns # Use this connection as the default route. defaultroute # Makes pppd "dial again" when the connection is lost. persist # Do not ask the remote to authenticate. noauth Then when I try to call gprs by typing: pppd call gprs The result is this: Script /usr/sbin/chat -v -f /etc/chatscripts/gprs finished (pid 1186), status = 0x0 Serial connection established. using channel 2 Using interface ppp0 Connect: ppp0 /dev/ttyUSB2 sent [LCP ConfReq id=0x1 ] rcvd [LCP ConfReq id=0x4 ] sent [LCP ConfNak id=0x4 ] rcvd [LCP ConfAck id=0x1 ] rcvd [LCP ConfReq id=0x5 ] sent [LCP ConfAck id=0x5 ] sent [LCP EchoReq id=0x0 magic=0xf0cd2f0e] sent [PAP AuthReq id=0x1 user="myusername@realm" password=] rcvd [LCP DiscReq id=0x6 magic=0xd0a7832b] rcvd [LCP EchoRep id=0x0 magic=0xd0a7832b f0 cd 2f 0e] rcvd [PAP AuthAck id=0x1 ""] PAP authentication succeeded sent [CCP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] rcvd [LCP ProtRej id=0x7 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f] Protocol-Reject for 'Compression Control Protocol' (0x80fd) received sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [LCP EchoReq id=0x1 magic=0xf0cd2f0e] IPCP: timeout sending Config-Requests IPV6CP: timeout sending Config-Requests sent [LCP TermReq id=0x2 "No network protocols running"] sent [LCP TermReq id=0x3 "No network protocols running"] Connection terminated. Modem hangup I do not understand where is the problem. Can anyone help with this? The /etc/chatscripts/gprs contains: # You can use this script unmodified to connect to cellular networks. # The APN is specified in the peers file as the argument of the -T command # line option of chat(8). # For details about the AT commands involved please consult the relevant # standard: 3GPP TS 27.007 - AT command set for User Equipment (UE). # (http://www.3gpp.org/ftp/Specs/html-info/27007.htm) ABORT BUSY ABORT VOICE ABORT "NO CARRIER" ABORT "NO DIALTONE" ABORT "NO DIAL TONE" ABORT "NO ANSWER" ABORT "DELAYED" ABORT "ERROR" # cease if the modem is not attached to the network yet ABORT "+CGATT: 0" "" AT TIMEOUT 12 OK ATH OK ATE1 # +CPIN provides the SIM card PIN #OK "AT+CPIN=1234" # +CFUN may allow to configure the handset to limit operations to # GPRS/EDGE/UMTS/etc to save power, but the arguments are not standard # except for 1 which means "full functionality". #OK AT+CFUN=1 OK AT+CGDCONT=1,"IP","\T","",0,0 OK ATD*99# TIMEOUT 22 CONNECT "" I changed the gprs file in /etc/ppp/peers and put this: connect "/usr/sbin/chat -v -f /etc/chatscripts/gprs" -T internet.vodafone.gr I tried to call gprs again and the result was this Script /usr/sbin/chat -v -f /etc/chatscripts/gprs -T internet.vodafone.gr finished (pid 3457), status = 0x0 Serial connection established. using channel 27 Using interface ppp0 Connect: ppp0 /dev/ttyUSB2 sent [LCP ConfReq id=0x1 ] rcvd [LCP ConfReq id=0x0 ] sent [LCP ConfNak id=0x0 ] rcvd [LCP ConfAck id=0x1 ] rcvd [LCP ConfReq id=0x1 ] sent [LCP ConfAck id=0x1 ] sent [LCP EchoReq id=0x0 magic=0x7969ae32] sent [PAP AuthReq id=0x1 user="myusername@realm" password=] rcvd [LCP DiscReq id=0x2 magic=0xd16a9755] rcvd [LCP EchoRep id=0x0 magic=0xd16a9755 79 69 ae 32] rcvd [PAP AuthAck id=0x1 ""] PAP authentication succeeded sent [CCP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] rcvd [LCP ProtRej id=0x3 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f] Protocol-Reject for 'Compression Control Protocol' (0x80fd) received sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] sent [LCP EchoReq id=0x1 magic=0x7969ae32] IPCP: timeout sending Config-Requests IPV6CP: timeout sending Config-Requests sent [LCP TermReq id=0x2 "No network protocols running"] sent [LCP TermReq id=0x3 "No network protocols running"] Connection terminated. Modem hangup Then i changed the /etc/chatscripts/gprs file and put the pin number of my sim card, removing the # sign. Called again gprs and the result now was this: Script /usr/sbin/chat -v -f /etc/chatscripts/gprs -T internet.vodafone.gr finished (pid 3473), status = 0x0 Serial connection established. using channel 28 Using interface ppp0 Connect: ppp0 /dev/ttyUSB2 sent [LCP ConfReq id=0x1 ] rcvd [LCP ConfReq id=0x4 ] sent [LCP ConfNak id=0x4 ] rcvd [LCP ConfAck id=0x1 ] rcvd [LCP ConfReq id=0x5 ] sent [LCP ConfAck id=0x5 ] sent [LCP EchoReq id=0x0 magic=0xc95e726d] sent [PAP AuthReq id=0x1 user="myusername@realm" password=] rcvd [LCP DiscReq id=0x6 magic=0xd172abe9] rcvd [LCP EchoRep id=0x0 magic=0xd172abe9 c9 5e 72 6d] rcvd [PAP AuthAck id=0x1 ""] PAP authentication succeeded sent [CCP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] sent [IPV6CP ConfReq id=0x1 ] rcvd [LCP ProtRej id=0x7 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f] Protocol-Reject for 'Compression Control Protocol' (0x80fd) received rcvd [IPCP ConfNak id=0x1 ] sent [IPCP ConfReq id=0x2 ] Modem hangup Connection terminated. In other words I did not receive a "No network protocols running" message.

My ISP asked me to use custom nameserver settings. I have placed these in /etc/resolv.conf. Unfortunately, every time I reboot the computer, the contents of this file is changed. To connect to the Internet, I must first edit that file. How can I ensure that this file does not change?

I have two PPP peers, dsl-line1 and dsl-line2 which are configured with pppd on Ubuntu (Server) Linux. They are brought up by the /etc/network/interfaces file with the auto thingy however each PPP connection chooses the name pppX where X varies depending on which comes up first. I would like to make it such that dsl-line1 comes up with a name such as "dsl0" and dsl-line2 with a name like "dsl1" so that I can create firewall rules more easily for each and set up routing (as well as having it easier to configure). My question is how can I get the pppd's interfaces to name themselves? /etc/ppp/peers/dsl-line1 (dsl-line2 is basically the same apart from the default route being removed and the ethernet interface being different) noipdefault defaultroute replacedefaultroute hide-password #lcp-echo-interval 30 #lcp-echo-failure 4 lcp-echo-interval 10 lcp-echo-failure 3 noauth persist #mtu 1492 #persist #maxfail 0 #holdoff 20 plugin rp-pppoe.so eth1 user "xxxx@xxxx.xxx" /etc/network/interfaces (the line1 part, again, 2 is very similar) auto dsl0 iface dsl0 inet ppp pre-up /sbin/ifconfig eth1 up # line maintained by pppoeconf post-up /bin/sh /home/callum/ppp0_up.sh # Route everything post-up /bin/sh /etc/miniupnpd/ppp0_up.sh # Start miniupnpd (if not alr$ provider dsl-line1 Thanks in advance.

Sorry if this is a repeat. I searched, but with no luck. I'm using SNMPd on an openwrt/wr host with some ppp and tun connections. These connections get IDs in the if table, and will actually get a new ID whenever the tunnels reconnect. Nagios (check_mk), when that happens, complains that an interface went down; oh, and a different one with the same name came up right afterward. In the meantime, it's iterating over so many interfaces that the reports are of 'interface 4933 down'; and an snmpwalk shows close to 4932 datapoints before it. How are the helpful folks here handling a monitoring situation like that?

For a POINTOPOINT [PPPoE](https://en.m.wikipedia.org/wiki/Point-to-Point_Protocol_over_Ethernet) ppp0 device in Linux, how to get the underlying ethernet device in a reliable way? I've looked in the output of ip -d link and in the /sys/class/net/ppp0 directory, but neither mention the parent device, nor the PID of the pppd process. If only one pppd runs on the system, then there is a "workaround":

`
$ cat /proc/net/pppoe
Id       Address           Device
0000516D dc:99:16:c4:58:35 wan.25

` In this case, wan.25 is the wanted info. But that "Id" 0000516D I have not seen other places linking it to the PPP device. So how would I differentiate between several PPPoE interfaces?

On Ubuntu 16.04LTS I'm having trouble getting my service to wait for my PPPoe internet connection before starting. My unit file: [Unit] Description=Home Assistant Wants=network-online.target After=network-online.target [Service] Type=simple User=%i ExecStart=/srv/homeassistant/bin/hass -c "/home/homeassistant/.homeassistant" [Install] WantedBy=multi-user.target My /etc/network/interfaces: auto lo iface lo inet loopback auto enp4s0 iface enp4s0 inet manual mtu 1508 auto enp4s0.35 iface enp4s0.35 inet manual vlan-raw-device enp4s0 mtu 1508 auto wan iface wan inet ppp provider bell auto enp3s0 iface enp3s0 inet static address 192.168.80.1 network 192.168.80.0 broadcast 192.168.80.255 If I run pon bell there is a considerable delay (10-20s) between the command finishing execution and when the interface appears in ifconfig. I believe homeassistant is starting early because its logs contain errors about failing to reach public endpoints, which doesn't occur if I restart the service manually after boot. How can I get the service to wait properly?

I am working on setting up an embedded linux device so that it can connect to a backend server via cellular connection. I am using PPP version 2.4.2 and a Sequans cell chip. I have the device working and talking to the backend. To test its performance, the backend will send a message every 5 minutes, and the device should respond. At random intervals for random amounts of time, my device seems to lose connection and will randomly come back. The cell chip does not lose connection, and ppp does not go down. Everything seems fine within my application logs. To debug this issue, I have been using ppp's **record** ***filename*** option and tcpdump on my ppp interface. What I have found is the during this loss of communication, tcpdump shows that nothing is coming in or out of the ppp interface. The ppp record file shows that *something* is happening within ppp. Does anyone know what is going on within ppp during this time? The snippet below is from the file (which I opened using pppdump -h *filename*). It seems like what is being sent out is prepending a c0 at the beginning when it gets in this weird sent/rcvd loop. In some cases, communication continues on its own. In other cases, the device will send a modem ping to the backend which will then cause the device to receive all the messages that it missed from the backend and responds to all of them. The snippet shows normal communication, followed by the sent/rcvd loop, followed by the message finally being sent. I have put XX over the part that would have been the IP address.

rcvd   7e 21 45 00 00 23 72 91 00 00 7c 11 36 d5 XX XX  ~!E..#r...|.6..(
       XX XX XX XX XX XX 04 64 c7 7a 00 0f 5a d2 7d 5d   _.,`..d.z..Z.}]
rcvd   04 00 50 06 66 c0 15 c2 7e                       ..P.f...~
time  8.0s
sent   7e 21 45 00 00 30 b1 0a 40 00 40 11 f4 4e XX XX  ~!E..0..@.@..N.,
       XX XX XX XX XX XX c7 7a 04 64 00 1c d1 3c 7d 5d  `..( _.z.d...<}]
       11 a0 67 2c 11 f5 38 dd 45 34 bb 21 b8 88 bc 9e  ..g,..8.E4.!....
       f5 33 08 b0 a3 7e                                .3...~
time  4.5s
rcvd   7e 21 45 00 00 23 72 92 00 00 7c 11 36 d4 XX XX  ~!E..#r...|.6..(
       XX XX XX XX XX XX 04 64 c7 7a 00 0f 59 d1 7d 5d   _.,`..d.z..Y.}]
rcvd   04 00 50 06 67 c1 c2 ac 7e                       ..P.g...~
time  0.1s
sent   7e 21 45 00 00 30 b2 aa 40 00 40 11 f2 ae XX XX ~!E..0..@.@....,
       XX XX XX XX XX XX c7 7a 04 64 00 1c 8f 99 7d 5d  `..( _.z.d....}]
       11 a0 68 c5 60 17 31 07 2d 07 56 ff 14 63 3c bf  ..h.`.1.-.V..c<.
       6b e4 8d cc 58 7e                                k...X~
time  0.2s
rcvd   7e 21 45 00 00 23 72 93 00 00 7c 11 36 d3 XX XX ~!E..#r...|.6..(
       XX XX XX XX XX XX 04 64 c7 7a 00 0f 58 d0 7d 5d   _.,`..d.z..X.}]
rcvd   04 00 50 06 68 c2 ed 79 7e                       ..P.h..y~
time  4.3s
sent   7e c0 21 09 59 00 08 83 0d 23 8a 31 3a 7e        ~.!.Y....#.1:~
rcvd   7e ff 03 c0 21 0a 59 00 08 2b b6 cb 61 cd 98 7e  ~...!.Y..+..a..~
time  30.1s
sent   7e c0 21 09 5a 00 08 83 0d 23 8a 5f 92 7e        ~.!.Z....#._.~
rcvd   7e ff 03 c0 21 0a 5a 00 08 2b b6 cb 61 a3 30 7e  ~...!.Z..+..a.0~
time  30.0s
sent   7e c0 21 09 5b 00 08 83 0d 23 8a 8a 0d 7e        ~.!.[....#...~
rcvd   7e ff 03 c0 21 0a 5b 00 08 2b b6 cb 61 76 af 7e  ~...!.[..+..av.~
time  30.0s
sent   7e c0 21 09 5c 00 08 83 0d 23 8a 92 ca 7e        ~.!.\....#...~
rcvd   7e ff 03 c0 21 0a 5c 00 08 2b b6 cb 61 6e 68 7e  ~...!.\..+..anh~
time  30.0s
sent   7e c0 21 09 5d 00 08 83 0d 23 8a 47 55 7e        ~.!.]....#.GU~
rcvd   7e ff 03 c0 21 0a 5d 00 08 2b b6 cb 61 bb f7 7e  ~...!.]..+..a..~
time  30.1s
sent   7e c0 21 09 5e 00 08 83 0d 23 8a 29 fd 7e        ~.!.^....#.).~
rcvd   7e ff 03 c0 21 0a 5e 00 08 2b b6 cb 61 d5 5f 7e  ~...!.^..+..a._~
time  30.0s
sent   7e c0 21 09 5f 00 08 83 0d 23 8a fc 62 7e        ~.!._....#..b~
rcvd   7e ff 03 c0 21 0a 5f 00 08 2b b6 cb 61 00 c0 7e  ~...!._..+..a..~
time  30.0s
sent   7e c0 21 09 60 00 08 83 0d 23 8a 42 ad 7e        ~.!.`....#.B.~
rcvd   7e ff 03 c0 21 0a 60 00 08 2b b6 cb 61 be 0f 7e  ~...!.`..+..a..~
time  30.0s
sent   7e c0 21 09 61 00 08 83 0d 23 8a 97 32 7e        ~.!.a....#..2~
rcvd   7e ff 03 c0 21 0a 61 00 08 2b b6 cb 61 6b 90 7e  ~...!.a..+..ak.~
time  30.1s
sent   7e c0 21 09 62 00 08 83 0d 23 8a f9 9a 7e        ~.!.b....#...~
rcvd   7e ff 03 c0 21 0a 62 00 08 2b b6 cb 61 05 38 7e  ~...!.b..+..a.8~
time  30.0s
sent   7e c0 21 09 63 00 08 83 0d 23 8a 2c 05 7e        ~.!.c....#.,.~
rcvd   7e ff 03 c0 21 0a 63 00 08 2b b6 cb 61 d0 a7 7e  ~...!.c..+..a..~
time  30.0s
sent   7e c0 21 09 64 00 08 83 0d 23 8a 34 c2 7e        ~.!.d....#.4.~
rcvd   7e ff 03 c0 21 0a 64 00 08 2b b6 cb 61 c8 60 7e  ~...!.d..+..a.`~
time  30.1s
sent   7e c0 21 09 65 00 08 83 0d 23 8a e1 5d 7e        ~.!.e....#..]~
rcvd   7e ff 03 c0 21 0a 65 00 08 2b b6 cb 61 1d ff 7e  ~...!.e..+..a..~
time  30.0s
sent   7e c0 21 09 66 00 08 83 0d 23 8a 8f f5 7e        ~.!.f....#...~
rcvd   7e ff 03 c0 21 0a 66 00 08 2b b6 cb 61 73 57 7e  ~...!.f..+..asW~
time  30.0s
sent   7e c0 21 09 67 00 08 83 0d 23 8a 5a 6a 7e        ~.!.g....#.Zj~
rcvd   7e ff 03 c0 21 0a 67 00 08 2b b6 cb 61 a6 c8 7e  ~...!.g..+..a..~
time  30.0s
sent   7e c0 21 09 68 00 08 83 0d 23 8a ae 73 7e        ~.!.h....#..s~
rcvd   7e ff 03 c0 21 0a 68 00 08 2b b6 cb 61 52 d1 7e  ~...!.h..+..aR.~
time  30.1s
sent   7e c0 21 09 69 00 08 83 0d 23 8a 7b ec 7e        ~.!.i....#.{.~
rcvd   7e ff 03 c0 21 0a 69 00 08 2b b6 cb 61 87 4e 7e  ~...!.i..+..a.N~
time  28.8s
sent   7e 21 45 00 00 3b 10 38 40 00 40 11 95 16 XX XX ~!E..;.8@.@....,
       XX XX XX XX XX XX c7 7a 04 64 00 27 ed 37 7d 5d  `..( _.z.d.'.7}]
       1c 00 55 03 fe 01 30 31 35 37 37 30 30 30 31 38  ..U...0157700018
       32 32 33 38 37 f7 8e 68 c0 df 78 5b 53 28 5c 74  22387..h..x[S(\t
       7e                                               ~
sent   21 45 00 00 30 10 39 40 00 40 11 95 20 XX XX XX !E..0.9@.@.. .,`
       XX XX XX XX XX c7 7a 04 64 00 1c b0 64 7d 5d 11  ..( _.z.d...d}].
       a0 69 04 ee 90 77 36 49 41 d0 ce 5f 9b 2f 88 4f  .i...w6IA.._./.O
       d1 35 c1 11 7e                                   .5..~
time  1.2s
sent   7e c0 21 09 6a 00 08 83 0d 23 8a 15 44 7e        ~.!.j....#..D~
rcvd   7e ff 03 c0 21 0a 6a 00 08 2b b6 cb 61 e9 e6 7e  ~...!.j..+..a..~
time  3.8s
sent   7e 21 45 00 00 30 11 f7 40 00 40 11 93 62 XX XX ~!E..0..@.@..b.,
       XX XX XX XX XX XX c7 7a 04 64 00 1c b5 e8 7d 5d  `..( _.z.d....}]
       11 a0 69 f1 79 85 ad e8 d8 66 04 71 7d 5e 29 6d  ..i.y....f.q}^)m
       94 4e d5 d0 05 ef 7e                             .N....~
time  2.9s

I am currently able to connect a handheld to the PC running Linux with a very old Ubuntu 14.04, adding repository PPA for SynCE to source list. Now, the goal is to update the operating system, I chose Debian Buster where I have successfully installed the DEB packages from the same repository in its version for Ubuntu Xenial. In Debian, USB serial device is recognized and connects with ttyUSB bus, obtains an IP address and disconnects after a few seconds (two, max three). I have done a PPP debug (options debug dump & kdebug), everything seems normal: pppd options in effect: debug # (from /etc/ppp/options) kdebug 7 # (from /etc/ppp/options) logfile /tmp/pppd.log # (from /etc/ppp/options) linkname synce-device0 # (from command line) dump # (from /etc/ppp/options) noauth # (from command line) /dev/ttyUSB0 # (from command line) 115200 # (from command line) lock # (from /etc/ppp/options) connect /usr/lib/synce-core/synce-serial-chat # (from command line) record /tmp/pppd.pcap # (from /etc/ppp/options) crtscts # (from command line) local # (from command line) asyncmap 0 # (from /etc/ppp/options) lcp-echo-failure 4 # (from /etc/ppp/options) lcp-echo-interval 30 # (from /etc/ppp/options) hide-password # (from /etc/ppp/options) ms-dns xxx # [don't know how to print value] # (from command line) nodefaultroute # (from command line) 192.168.131.1:192.168.131.129 # (from command line) noipx # (from /etc/ppp/options) Removed stale lock on ttyUSB0 (pid 4366) Script /usr/lib/synce-core/synce-serial-chat finished (pid 4435), status = 0x0 Serial connection established. using channel 14 Using interface ppp0 Connect: ppp0 /dev/pts/3 rcvd [LCP ConfReq id=0x0 ] sent [LCP ConfReq id=0x1 ] sent [LCP ConfAck id=0x0 ] rcvd [LCP ConfAck id=0x1 ] sent [LCP EchoReq id=0x0 magic=0xf230f2eb] sent [CCP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] rcvd [CCP ConfReq id=0x0 ] sent [CCP ConfRej id=0x0 ] rcvd [IPCP ConfReq id=0x2 ] sent [IPCP ConfRej id=0x2 ] rcvd [IPV6CP ConfReq id=0x0 ] Unsupported protocol 'IPv6 Control Protocol' (0x8057) received sent [LCP ProtRej id=0x2 80 57 01 00 00 0e 01 0a 42 83 de ff fe ae de c9] rcvd [LCP EchoRep id=0x0 magic=0x0] rcvd [CCP ConfRej id=0x1 ] sent [CCP ConfReq id=0x2] rcvd [IPCP ConfAck id=0x1 ] rcvd [CCP ConfReq id=0x1] sent [CCP ConfAck id=0x1] rcvd [IPCP ConfReq id=0x3 ] sent [IPCP ConfNak id=0x3 ] rcvd [CCP ConfNak id=0x2 ] sent [CCP ConfReq id=0x3] rcvd [IPCP ConfReq id=0x4 ] sent [IPCP ConfAck id=0x4 ] local IP address 192.168.131.1 remote IP address 192.168.131.129 Script /etc/ppp/ip-up started (pid 4444) rcvd [CCP ConfAck id=0x3] Script /etc/ppp/ip-up finished (pid 4444), status = 0x0 In UDEV, I see that after the "add" event, from the kernel, it fires a "remove", without having disconnected the device. It is striking that the event is associated only with the ppp0 network device.

KERNEL[13133.932298] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2 (usb)
KERNEL[13133.941859] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0 (usb)
KERNEL[13133.946512] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0 (usb-serial)
KERNEL[13133.946847] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0/tty/ttyUSB0 (tty)
KERNEL[13133.946887] bind     /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0 (usb-serial)
KERNEL[13133.946930] bind     /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0 (usb)
KERNEL[13133.947016] bind     /devices/pci0000:00/0000:00:06.0/usb2/2-2 (usb)
UDEV  [13133.951550] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2 (usb)
UDEV  [13133.967665] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0 (usb)
UDEV  [13133.969926] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0 (usb-serial)
UDEV  [13133.993251] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0/tty/ttyUSB0 (tty)
UDEV  [13134.002291] bind     /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0 (usb-serial)
UDEV  [13134.003803] bind     /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0 (usb)
UDEV  [13134.004620] bind     /devices/pci0000:00/0000:00:06.0/usb2/2-2 (usb)
KERNEL[13134.445488] add      /devices/virtual/net/ppp0 (net)
KERNEL[13134.445509] add      /devices/virtual/net/ppp0/queues/rx-0 (queues)
KERNEL[13134.445519] add      /devices/virtual/net/ppp0/queues/tx-0 (queues)
UDEV  [13134.498959] add      /devices/virtual/net/ppp0 (net)
UDEV  [13134.510588] add      /devices/virtual/net/ppp0/queues/rx-0 (queues)
UDEV  [13134.514145] add      /devices/virtual/net/ppp0/queues/tx-0 (queues)
>
KERNEL[13137.624110] remove   /devices/virtual/net/ppp0/queues/rx-0 (queues)
KERNEL[13137.624144] remove   /devices/virtual/net/ppp0/queues/tx-0 (queues)
KERNEL[13137.624169] remove   /devices/virtual/net/ppp0 (net)
UDEV  [13137.644633] remove   /devices/virtual/net/ppp0/queues/tx-0 (queues)
UDEV  [13137.644791] remove   /devices/virtual/net/ppp0/queues/rx-0 (queues)
UDEV  [13137.659488] remove   /devices/virtual/net/ppp0 (net)

The event is related to the network interface or the network protocol, but I have not seen anything that causes it. Looked at the network traffic with Whireshark (record to pcap file), I have not found any clue. I have compared with the connection in Ubuntu and I do not see anything. In Ubuntu, despite the RSTs, the connection is never lost (see below image) On Debian, it is lost abruptly. The objective is to have a TCP/IP stable connection between the USB serial device and Linux PC: ppp0 /dev/ttyUSB0 Currently, with Debian, the connection is lost in a few seconds (two or three)... Jan 18 20:26:56 debian10 pppd: local IP address 192.168.131.1 Jan 18 20:26:56 debian10 pppd: remote IP address 192.168.131.129 Jan 18 20:26:56 debian10 dccm: DEBUG: synce_device_manager_check_interface_cb: address ready Jan 18 20:26:56 debian10 dccm: DEBUG: synce_device_manager_create_device: found device interface for /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0/tty/ttyUSB0 Jan 18 20:26:56 debian10 dccm: DEBUG: synce_device_manager_create_device: listening for device /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0/tty/ttyUSB0 Jan 18 20:26:56 debian10 dccm: DEBUG: synce_device_manager_create_device: NOT triggering connection Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_manager_client_connected_cb: have a connection to port 5679 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_manager_client_connected_cb: creating device object for /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0/tty/ttyUSB0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_set_property: running for device /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0/tty/ttyUSB0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_initable_init: connecting to udev Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: info buffer length = 138 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 0: unknown: guint32 ?: 40 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 4: os_major: guint8: 6 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 5: os_minor: guint8: 0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 6: unknown, build number ?: guint16 ?: 0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 8: cpu_type: guint16: 2577 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 10: unknown: guint16 ?: 0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 12: unknown: guint32 ?: 0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 16: cur_partner_id: guint32: 0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 20: second partner id ?: guint32 ?: 0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 24: offset to device name: guint32: 40 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 28: offset to platform name: guint32: 74 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 32: offset to model name: guint32: 104 Jan 18 20:26:57 debian10 dccm: Message: synce_device_dbus_init: registering object path '/org/synce/dccm/Device/_devices_pci0000_00_0000_00_06_0_usb2_2_2_2_2_1_0_ttyUSB0_tty_ttyUSB0' Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_manager_device_obj_path_changed_cb: sending connected signal for /org/synce/dccm/Device/_devices_pci0000_00_0000_00_06_0_usb2_2_2_2_2_1_0_ttyUSB0_tty_ttyUSB0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_dbus_init: obj_path set to /org/synce/dccm/Device/_devices_pci0000_00_0000_00_06_0_usb2_2_2_2_2_1_0_ttyUSB0_tty_ttyUSB0 Jan 18 20:26:57 debian10 dccm: DEBUG: get_password_flag_text: setting password flags unset Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: setting CTRL_STATE_CONNECTED Jan 18 20:26:58 debian10 dccm: DEBUG: gudev_uevent_callback: received uevent **remove** for device /sys/devices/virtual/net/ppp0/queues/tx-0 Jan 18 20:26:58 debian10 dccm: DEBUG: gudev_uevent_callback: received uevent **remove** for device /sys/devices/virtual/net/ppp0/queues/rx-0 Jan 18 20:26:58 debian10 dccm: DEBUG: gudev_uevent_callback: received uevent **remove** for device /sys/devices/virtual/net/ppp0 How can I detect what is happening?, What can be the cause for the kernel to remove the ppp0 device? Any answer that helps to solve this problem will be highly appreciated, even if there is another way to connect a USB serial device, I don't know if there is.

Connecting a PDA device with Debian Buster using SynCE, USB serial device is recognized and connects with ttyUSB bus, obtains an IP address and disconnects after a few seconds (two, max three). This is how it looks in syslog: Jan 18 20:26:57 debian10 dccm: Message: synce_device_dbus_init: registering object path '/org/synce/dccm/Device/_devices_pci0000_00_0000_00_06_0_usb2_2_2_2_2_1_0_ttyUSB0_tty_ttyUSB0' Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_manager_device_obj_path_changed_cb: sending connected signal for /org/synce/dccm/Device/_devices_pci0000_00_0000_00_06_0_usb2_2_2_2_2_1_0_ttyUSB0_tty_ttyUSB0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_dbus_init: obj_path set to /org/synce/dccm/Device/_devices_pci0000_00_0000_00_06_0_usb2_2_2_2_2_1_0_ttyUSB0_tty_ttyUSB0 Jan 18 20:26:57 debian10 dccm: DEBUG: get_password_flag_text: setting password flags unset Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: setting CTRL_STATE_CONNECTED Jan 18 20:26:58 debian10 dccm: DEBUG: gudev_uevent_callback: received uevent **remove** for device /sys/devices/virtual/net/ppp0/queues/tx-0 Jan 18 20:26:58 debian10 dccm: DEBUG: gudev_uevent_callback: received uevent **remove** for device /sys/devices/virtual/net/ppp0/queues/rx-0 Jan 18 20:26:58 debian10 dccm: DEBUG: gudev_uevent_callback: received uevent **remove** for device /sys/devices/virtual/net/ppp0 Seeing the output, I decided to delve deeper into monitoring UDEV events with "udevadm control -l debug"... and this was the result: Jan 23 15:01:28 debian10 dccm: DEBUG: get_password_flag_text: setting password flags unset Jan 23 15:01:30 debian10 systemd-udevd: Cleanup idle workers Jan 23 15:01:30 debian10 systemd-udevd: Unload module index Jan 23 15:01:30 debian10 systemd-udevd: Unloaded link configuration context. Jan 23 15:01:30 debian10 systemd-udevd: Unload module index Jan 23 15:01:30 debian10 systemd-udevd: Unloaded link configuration context. Jan 23 15:01:30 debian10 systemd-udevd: Worker exited Jan 23 15:01:30 debian10 systemd-udevd: Worker exited Jan 23 15:01:30 debian10 systemd-udevd: rx-0: Device (SEQNUM=1738, ACTION=remove) is queued Jan 23 15:01:30 debian10 systemd-udevd: Validate module index Jan 23 15:01:30 debian10 systemd-udevd: Check if link configuration needs reloading. Jan 23 15:01:30 debian10 systemd-udevd: Successfully forked off 'n/a' as PID 1327. Jan 23 15:01:30 debian10 systemd-udevd: rx-0: Worker is forked for processing SEQNUM=1738. Jan 23 15:01:30 debian10 systemd-udevd: tx-0: Device (SEQNUM=1739, ACTION=remove) is queued Jan 23 15:01:30 debian10 systemd-udevd: Successfully forked off 'n/a' as PID 1328. Jan 23 15:01:30 debian10 systemd-udevd: tx-0: Worker is forked for processing SEQNUM=1739. Jan 23 15:01:30 debian10 systemd-udevd: ppp0: Device (SEQNUM=1740, ACTION=remove) is queued Jan 23 15:01:30 debian10 systemd-udevd: rx-0: Processing device (SEQNUM=1738, ACTION=remove) Jan 23 15:01:30 debian10 systemd-udevd: tx-0: Processing device (SEQNUM=1739, ACTION=remove) Jan 23 15:01:30 debian10 dccm: DEBUG: gudev_uevent_callback: received uevent remove for device /sys/devices/virtual/net/ppp0/queues/tx-0 Jan 23 15:01:30 debian10 systemd-udevd: tx-0: Device (SEQNUM=1739, ACTION=remove) processed Jan 23 15:01:30 debian10 dccm: DEBUG: gudev_uevent_callback: received uevent remove for device /sys/devices/virtual/net/ppp0/queues/rx-0 Jan 23 15:01:30 debian10 systemd-udevd: rx-0: Device (SEQNUM=1738, ACTION=remove) processed Jan 23 15:01:30 debian10 systemd-udevd: rx-0: sd-device-monitor: Passed 157 byte to netlink monitor Jan 23 15:01:30 debian10 systemd-udevd: tx-0: sd-device-monitor: Passed 157 byte to netlink monitor Jan 23 15:01:30 debian10 systemd-udevd: ppp0: sd-device-monitor: Passed 179 byte to netlink monitor Jan 23 15:01:30 debian10 systemd-udevd: ppp0: Processing device (SEQNUM=1740, ACTION=remove) Jan 23 15:01:30 debian10 systemd-udevd: ppp0: RUN 'ifupdown-hotplug' /usr/lib/udev/rules.d/80-ifupdown.rules:5 Jan 23 15:01:30 debian10 systemd-udevd: ppp0: IMPORT builtin 'path_id' /usr/lib/udev/rules.d/80-net-setup-link.rules:5 Jan 23 15:01:30 debian10 systemd-udevd: ppp0: IMPORT builtin 'path_id' fails: No such file or directory Jan 23 15:01:30 debian10 systemd-udevd: Starting 'ifupdown-hotplug' Jan 23 15:01:30 debian10 systemd-udevd: Successfully forked off '(spawn)' as PID 1329. Jan 23 15:01:30 debian10 systemd-udevd: Process 'ifupdown-hotplug' succeeded. Jan 23 15:01:30 debian10 systemd-udevd: ppp0: Device (SEQNUM=1740, ACTION=remove) processed Jan 23 15:01:30 debian10 dccm: DEBUG: gudev_uevent_callback: received uevent remove for device /sys/devices/virtual/net/ppp0 Jan 23 15:01:30 debian10 systemd-udevd: ppp0: sd-device-monitor: Passed 298 byte to netlink monitor Jan 23 15:01:34 debian10 systemd-udevd: Cleanup idle workers Jan 23 15:01:34 debian10 systemd-udevd: Unload module index Jan 23 15:01:34 debian10 systemd-udevd: Unloaded link configuration context. Jan 23 15:01:34 debian10 systemd-udevd: Unload module index Jan 23 15:01:34 debian10 systemd-udevd: Unloaded link configuration context. Jan 23 15:01:34 debian10 systemd-udevd: Worker exited Jan 23 15:01:34 debian10 systemd-udevd: Worker exited Evident, SynCE use glib based gudev to monitor the udev events. Listen to the events "uevent" signal, to do that, attach a callback to this signal and wait for the notification. The USB device is not unplugged, no reason for signal "action remove". With Ubuntu 14.04 it works out of the box very well. Here comes my knowledge. I don't know how to get closer to the origin of the problem. I need to make the connection ppp0 /dev/ttyUSB0 stable. Any help or suggestion will be well received and greatly appreciated.

I'm connecting a linux machine using a nowadays popular Huawei Brovi E3372-325 LTE USB Stick to the internet. The special requirement is that incoming ssh/ping/NTP/... connections must reach my linux OS. The state is, that using usb_modeswitch -X and the option driver I can bring up the 3 ttyUSB interfaces, and connect successfully using wvdial. But for some reason, ifconfig does not list a HW/MAC address for ppp0 interface, and devices on the same APN network can't ping the my IP address. I don't think the reason is blockage by the ISP, because my other devices are ping-able on the network. Output of ip addr

19: ppp0:  mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet 10.250.0.112 peer 10.64.64.64/24 scope global ppp0
       valid_lft forever preferred_lft forever

1. If I'm not mistake, I don't use RNDIS right now. Am I right, that in general the popular RNDIS protocol does not suit my use case, because that creates an additional local network, making it trickier to forward incoming connections to the OS? Pinging might work from outside because that's answered by the USB modem itself, but incoming ssh would fail. 2. What might be the reason, that ppp0 does not have a MAC address? How it's even possible? Should I assign one? Is it probably the reason that other devices can't ping it's IP? How to solve this situation?

On Ubuntu 21.10, I have a cellular modem connected via USB that I need to be the primary interface on which all network traffic utilizes. However, I also need the wifi interface (in my case, wlo1) to also continue to work, and be the backup in case the ppp0 interface goes down. ping google.com -I ppp0 -> works through ppp ping google.com -I wlo1 -> works though wifi ping google.com -> works through ppp (this is the difficult part) I can get the cellular modem online just fine using pppd and corresponding scripts, and get a valid IP address. It's the routing I seem to be struggling with. What I've tried =============== pppd ---- I first tried utilizing options in the PPP script, options like defaultroute and replacedefaultroute. defaultroute does not alter the routing table and add a default route at all. Perhaps this is because, as I've come to learn, a routing table can only have one default route. Not sure. When trying to use the replacedefaultroute option, pppd does add a default entry into the main routing table, however, this winds up breaking both interfaces and I have no internet connection whatsoever. It does not remove the existing default route for wifi, thus there exist two default routes in the main routing table. Manually adding routes ---------------------- I then played around with adding routes to the main routing table manually. Whan I run sudo ip route add {ipAddress} dev ppp0 src {ipAddress}, then both interfaces work, but wifi is still the primary interface. Attempting to add that route with a metric lower than the wifi's metric also does not make it so that the ppp interface is primary (i.e. ping google.com still goes out via wifi). I can add a second default, but it must have a metric *higher* than wifi, else it causes both connections to stop working. A second routing table ---------------------- Following other stack exchange posts and articles like this one , I explored the option of having two routing tables and adding a route and a default route the second routing table. While this doesn't break either connection, even using a metric lower than the wifi's metric, the ppp interface still is not the primary interface. Also, if I disconnect from wifi, then the ppp interface stops working as well, and the 2nd routing table is cleared (is this NetworkManager doing this?) Questions ========= Is what I am trying to accomplish even possible? If so, what am I doing wrong? Am I fighting with NetworkManager? Any help is *greatly* appreciated!

I want to run a _ppp_ connection when my USB modem is connected, so I use this udev rule:

ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="16d8",\
    RUN+="/usr/local/bin/newPPP.sh $env{DEVNAME}"

(My modem appears in /dev as ttyACM0) **newPPP.sh:** #!/bin/bash /usr/bin/pon prov $1 >/dev/null 2>&1 & ###Problem:### The udev event fires, and newPPP.sh is running, but newPPP.sh process is killed after ~4-5s. ppp does not have time to connect (its timeout is 10s for dial up). How can I run a long time process, that will not be killed? I tried using nohup, but it didn't work either. System: Arch Linux **Update** I found a solution here , thanks to maxschlepzig . I use at now to run my job detached from udev process. But the one question remains unanswered: Why do nohup and & not work?

**Problem:** I have two Linux machines connected with a serial interface. I use ppp to communicate between them (I have to since it is a project requirement). Communication speed is at 9600 bits/s. I need to measure bandwidth used, bits/s, live, i.e. while the system is running. Initially I thought I would use ifstat -btwTWS -i ppp0, since this is what the tools was designed for. However the value that was displayed was way more than 9600 bits/s. It hovered around 12.09 Kbits/s. I did ask why this happening , and the response was that it could be because of a compression. This does make sense. What I need, however, is actual bits/s after compression and before decompression happens. **My initial approach to solve this problem:** Initially I thought to use some sort of a serial traffic sniffer with a capability to display a data rate. I've tried several, but whenever I try to connect to /dev/ttyUSB0 I'm getting a resource busy error. This is happening because PPP is taking over the device. **My second approach to solve this problem:** I want to create a pseudo serial port, connect it to a real serial port. Then PPP will take over pseudo serial port and I will sniff the traffic on a real serial port. Here is the diagram:

--------------------         -------------------------  
|                  |         |                       |
|      PPP         |         |        sniffer        |
|  -------------   |         |   ------------------  |              
|  | /dev/pty0 |---|---------|---|  /dev/ttyUSB0  |  |
|  -------------   |         |   ------------------  |
|                  |         |                       |
--------------------         -------------------------

My understanding is that socat can do that. I've been reading up on this, but I coulnd't find any options that allow me to do that. **So here is my question:** How do I create a pseudoterminal with socat and connect to a real serial port? Is that even possible?

I have a PC on a test bench with 2 interfaces, enp2s0 and enp3s0. The IPs are public and obtained with DHCP, based on the interfaces MACs. There is a second computer on my bench, a Raspberry Pi Compute Module 3, which I want to expose on the internet. The RPi and bench sever are connect together through PPP, over a serial connection. On both side the ppp interface is called ppp0. How can I bridge ppp0 and enp3s0, so that the RPi CM3+ accessible from the public IP? I'm lost among linux's many bridge and tunnel options... My organization doesn't allow me to do routing or use switches. Any solution that minimize the chance of me wrecking the rest of the network would be awesome.

My pppoe client automatically adds an iptables rule iptables -t mangle -o "$PPP_IFACE" --insert FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu from /etc/ppp/ip-up.d. However, this rule in nftables looks like

table ip mangle {
	chain FORWARD {
		type filter hook forward priority mangle; policy accept;
		oifname "ppp0" meta l4proto tcp tcp flags & (syn|rst) == syn # tcpmss match 1400:65495 counter packets 714 bytes 42388 tcp option maxseg size set rt mtu
	}
}

Why contents after tcpmss is commented and this rule seems to do nothing?

I have a Debian 8.7 IoT Version on a Beaglebone Black device which is connected to the Internet using a GSM Modem. I installed a VPN client (zerotier ) which joins a virtual network. Something changes the default route and my Internet is no longer working. netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 zt0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0 10.64.64.64 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 10.241.0.0 0.0.0.0 255.255.0.0 U 0 0 0 zt0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 zt0 192.168.6.0 0.0.0.0 255.255.255.252 U 0 0 0 usb1 192.168.7.0 0.0.0.0 255.255.255.252 U 0 0 0 usb0 How can I ensure the default communication is routed over ppp0 and only 10.241.0.0/16 over zt0. After adding the default GW, I get the following Table: Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 zt0 0.0.0.0 100.97.168.1 0.0.0.0 UG 0 0 0 ppp0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0 I found out what adds the entry: Oct 02 12:55:48 PTMH7 connmand: zt0 {add} route 0.0.0.0 gw 0.0.0.0 scope 253 How can I prevent ConnMan from doing so?