PPP Modem Hangup

PPP Modem Hangup

[Devesh Chipade]

Hello,

I am working on establishing a ppp connection over serial (UART)
between two devices (Ubuntu/Linux machine and AOSP Target Device.

From the logs I see that the connection negotiation happens smoothly.
The request/ack is correctly exchanged between the two devices and a
ppp connection is established (ppp0 interface is created.

After about 6secs, there is Modem Hangup on the AOSP target device.
There are exchanges of data where data is sent from the Ubuntu/Linux
device and received on AOSP target device but no data is sent from the
AOSP target device.

I have played around with my options file; adjusting the baud rate,
MTU/MRU, compression is disabled, flow control and behavior settings
etc. But, it did not help with resolving the issue.

The options file for Ubuntu/Linux below:
# UART interface and baud rate
/dev/ttyUSB0 115200

#silent
nolock
kdebug 7

# Do not support ipv6
noipv6

# Flow control and behavior settings
xonxoff                   # Enable software flow control (XON/XOFF)
nodetach                  # Prevents ppd from running in the
backgroud. O/Ps logs to the terminal
debug                     # Enable detailed logging for debugging purposes
nocrtscts                 # Disable hardware flow control (no RTS/CTS
handshaking)
noauth                    # No authentication (open connection)
dump                      # prints out all the option values

# Serial communication settings
local                     # Do not use modem control lines; assume a
direct serial connection

# Compression settings (disable all forms of compression)
noccp                     # Disable CCP (Compression Control Protocol)
nobsdcomp                 # Disable BSD compression
nodeflate                 # Disable Deflate compression
novj                      # Disable Van Jacobson style TCP/IP header compression

# Connection persistence
persist                   # Automatically attempt to keep the
connection alive if it drops

# Transmission Settings
mtu 128                  # Set the Maximum Transmission Unit
mru 128                  # Set the Maximum Receive Unit

# IP addressing and routing settings
nodefaultroute             # Do not add a default route through the
PPP connection
noipdefault              # Do not request a specific IP address from the peer
10.0.0.1:10.0.0.2         # Local IP:Remote IP

# IPCP settings
ipcp-accept-remote        # Accept the IP address provided by the peer
#ipcp-accept-local
maxfail 0

# Link Control Protocol (LCP) settings
lcp-echo-interval 0       # Disable LCP echo requests (used to detect
dead connections)
lcp-echo-failure 0        # Disable LCP echo failure detection

the options file on AOSP Target device
# UART interface and baud rate
/dev/ttyMSM0 115200

kdebug 7

# Do not support ipv6
noipv6

# Flow control and behavior settings
xonxoff                  # Enable software flow control (XON/XOFF)
nodetach          # Prevents ppd from running in the backgroud. O/Ps
logs to the terminal
debug             # Enable detailed logging for debugging purposes
nocrtscts                 # Disable hardware flow control (no RTS/CTS
handshaking)
noauth                    # No authentication (open connection)
dump                      # prints all the option value

# Serial communication settings
local                     # Do not use modem control lines; assume a
direct serial connection
nolock

# Compression settings (disable all forms of compression)
noccp                     # Disable CCP (Compression Control Protocol)
nobsdcomp                 # Disable BSD compression
nodeflate                 # Disable Deflate compression
novj                      # Disable Van Jacobson style TCP/IP header compression

# Connection persistence
persist                   # Automatically attempt to keep the
connection alive if it drops

# Transmission Settings
mtu 128                  # Set the Maximum Transmission Unit
mru 128                  # Set the Maximum Receive Unit

# IP addressing and routing settings
nodefaultroute            # Do not add a default route through the PPP
connection
noipdefault               # Do not request a specific IP address from the peer
10.0.0.2:10.0.0.1   # Local IP : Remote IP

# IPCP settings
ipcp-accept-remote        # Accept the IP address provided by the peer

# Link Control Protocol (LCP) settings
lcp-echo-interval 0       # Disable LCP echo requests (used to detect
dead connections)
lcp-echo-failure 0        # Disable LCP echo failure detectioin

Error Logs on AOSP Target:
using channel 932
Using interface ppp0
Connect: ppp0 <--> /dev/ttyMSM0
sent [LCP ConfReq id=0x3 <mru 128> <asyncmap 0xa0000> <magic
0xc875a15e> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3 <mru 128> <asyncmap 0xa0000> <magic
0x184ddd9> <pcomp> <accomp>]
sent [LCP ConfAck id=0x3 <mru 128> <asyncmap 0xa0000> <magic
0x184ddd9> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x3 <mru 128> <asyncmap 0xa0000> <magic
0xc875a15e> <pcomp> <accomp>]
sent [IPCP ConfReq id=0x3 <addr 10.0.0.2>]
rcvd [IPCP ConfReq id=0x3 <addr 10.0.0.1>]
sent [IPCP ConfAck id=0x3 <addr 10.0.0.1>]
rcvd [IPCP ConfAck id=0x3 <addr 10.0.0.2>]
local  IP address 10.0.0.2
remote IP address 10.0.0.1
Modem hangup
Connect time 0.1 minutes.
Sent 0 bytes, received 1276 bytes.
Connection terminated.

Any inputs to resolve the issue would be helpful.

Thanks,
Devesh

Re: PPP Modem Hangup

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]


Given that you have:

      local                     # Do not use modem control lines; assume a

then pppd ought to tell the TTL to ignore DCD drops.
Is this a real serial connection, or actually serial over USB or PPPoE?
Looks like USB0.  USB/TTL adapter I bet.  Are other pins being used for
(JTAG) programming, reset?

Maybe "stty -F /dev/ttyUSB0 -a" (as root) during your magic 6s.
Is clocal set?



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: PPP Modem Hangup

[Devesh Chipade]

I get the following output:

on AOSP Target Device:
# stty -F /dev/ttyMSM0  -a
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = <undef>; discard = <undef>; min = 1;
time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread clocal -crtscts
ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
-ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase
-tostop -echoprt -echoctl -echoke -flusho -extproc

on Ubuntu/Linux machine:
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread clocal -crtscts
ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
-ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase
-tostop -echoprt -echoctl -echoke -flusho -extproc

On Tue, Sep 10, 2024 at 5:39 AM Michael Richardson <mcr@sandelman.ca> wrote:
>
>
> Given that you have:
>
>       local                     # Do not use modem control lines; assume a
>
> then pppd ought to tell the TTL to ignore DCD drops.
> Is this a real serial connection, or actually serial over USB or PPPoE?
> Looks like USB0.  USB/TTL adapter I bet.  Are other pins being used for
> (JTAG) programming, reset?
>
> Maybe "stty -F /dev/ttyUSB0 -a" (as root) during your magic 6s.
> Is clocal set?
>
>

Re: PPP Modem Hangup

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]


Devesh Chipade <devesh@in-unison.com> wrote:
    > I get the following output:

Looks sane to me.
I had problems with my ISP connection where one of their DSLAMs would not
answer IPCP echo requests if there was already traffic flowing.  I had to
turn off that check at my end, but you already did that.

I think you'll have to enable lots more debuging, and maybe throw in a
printf() here or there.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: PPP Modem Hangup

[Devesh Chipade]

In my options file, I have debug and kdebug 7.
This is all the logs I could get:


logcat:
09-04 14:44:21.829 24869 24869 I pppd    : Using interface ppp0
09-04 14:44:21.829 24869 24869 I pppd    : Connect: ppp0 <--> /dev/ttyMSM0
09-04 14:44:21.831 24869 24869 D pppd    : sent [LCP ConfReq id=0x28
<mru 128> <asyncmap 0xa0000> <magic 0x2fe08c15> <pcomp> <accomp>]
09-04 14:44:21.854 24869 24869 D pppd    : rcvd [LCP ConfReq id=0x28
<mru 128> <asyncmap 0xa0000> <magic 0x3ffaa0d> <pcomp> <accomp>]
09-04 14:44:21.854 24869 24869 D pppd    : sent [LCP ConfAck id=0x28
<mru 128> <asyncmap 0xa0000> <magic 0x3ffaa0d> <pcomp> <accomp>]
09-04 14:44:21.859 24869 24869 D pppd    : rcvd [LCP ConfAck id=0x28
<mru 128> <asyncmap 0xa0000> <magic 0x2fe08c15> <pcomp> <accomp>]
09-04 14:44:21.861 24869 24869 D pppd    : sent [IPCP ConfReq id=0x4f
<addr 0.0.0.0>]
09-04 14:44:21.880 24869 24869 D pppd    : rcvd [IPCP ConfReq id=0x28
<addr 10.0.0.1>]
09-04 14:44:21.880 24869 24869 D pppd    : sent [IPCP ConfAck id=0x28
<addr 10.0.0.1>]
09-04 14:44:21.882 24869 24869 D pppd    : rcvd [IPCP ConfNak id=0x4f
<addr 10.0.0.2>]
09-04 14:44:21.882 24869 24869 D pppd    : sent [IPCP ConfReq id=0x50
<addr 10.0.0.2>]
09-04 14:44:21.897 24869 24869 D pppd    : rcvd [IPCP ConfAck id=0x50
<addr 10.0.0.2>]
09-04 14:44:21.898 24869 24869 I pppd    : local  IP address 10.0.0.2
09-04 14:44:21.898 24869 24869 I pppd    : remote IP address 10.0.0.1
09-04 14:44:26.800 24869 24869 I pppd    : Modem hangup
09-04 14:44:26.800 24869 24869 I pppd    : Connect time 0.1 minutes.
09-04 14:44:26.800 24869 24869 I pppd    : Sent 0 bytes, received 1316 bytes.


dmesg:
3:msm_serial_geni0(53):131203 GICv3:190b6400.qcom,bwmon-llcc(32):86828
GICv3:19091000.qcom,bwmon-ddr(33):58165
[ 4529.150036] (cpu:irq_count)- 0:318453 1:255610 2:1953373 3:2116553
4:1351087 5:1350685
[ 4529.150116] (ipi:irq_count)- 0:3822209 1:149695 2:0 3:0 4:0 5:370658 6:0
[ 4530.754440] init: ... started service 'console' has pid 25224
[ 4530.759148] init: starting service 'audioserver'...
[ 4530.768765] init: ... started service 'audioserver' has pid 25225
[ 4530.769623] init: starting service 'vendor.audio-hal'...
[ 4530.779094] init: ... started service 'vendor.audio-hal' has pid 25226
[ 4530.779157] init: Service 'console' (pid 25224) exited with status 0
[ 4530.779181] init: Sending signal 9 to service 'console' (pid 25224)
process group...
[ 4530.779346] libprocessgroup: Successfully killed process cgroup uid
2000 pid 25224 in 0ms
[ 4530.780358] init: processing action (init.svc.audioserver=running)
from (/system/etc/init/audioserver.rc:35)
[ 4530.780380] init: service 'vendor.audio-hal' requested start, but
it is already running (flags: 4)
[ 4530.911254] healthd: battery l=100 v=4068 t=25.0 h=2 st=2 c=-116091
fc=3588000 cc=0 chg=u
[ 4530.985181] servicemanager: Found
android.hardware.bluetooth.audio.IBluetoothAudioProviderFactory/default
in device VINTF manifest.
[ 4530.986106] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 4531.739378] healthd: battery l=100 v=4425 t=25.0 h=2 st=2 c=109499
fc=3588000 cc=0 chg=u
^[[A^[[A^[[A^[[A^[[A^[[A[ 4532.423386] logd: logdr: UID=1041 GID=1005
PID=25301 n tail=500 logMask=8 pid=25226 start=0ns deadline=0ns

On Tue, Sep 10, 2024 at 11:23 AM Michael Richardson <mcr@sandelman.ca> wrote:
>
>
> Devesh Chipade <devesh@in-unison.com> wrote:
>     > I get the following output:
>
> Looks sane to me.
> I had problems with my ISP connection where one of their DSLAMs would not
> answer IPCP echo requests if there was already traffic flowing.  I had to
> turn off that check at my end, but you already did that.
>
> I think you'll have to enable lots more debuging, and maybe throw in a
> printf() here or there.

Re: PPP Modem Hangup

[Paul Mackerras]

On Tue, Sep 10, 2024 at 11:30:48AM -0700, Devesh Chipade wrote:
> In my options file, I have debug and kdebug 7.
> This is all the logs I could get:

The pppd logs look fine.  There is nothing in the kernel (dmesg) log
that looks relevant (in fact kdebug 7 is mostly useful if you are
actually debugging the kernel driver; it doesn't really help with
problems like this).

Do you have logs from pppd on the ubuntu/linux side?  Is something
causing it to terminate?

Alternatively, do you have another service running on either side
which also thinks it is using the same serial port?  Something like a
getty, or whatever the systemd equivalent is for providing a login
prompt?  You could do "fuser /dev/ttyMSM0" or "fuser /dev/ttyUSB0" as
root during the 6 seconds when the link is up to check if something
other than pppd also has the serial port open.

Paul.

Re: PPP Modem Hangup

[Devesh Chipade]

I have resolved the issue now:

I have commented out the following in my init.rc file
#service console /system/bin/sh
#    class core
#    console
#    disabled
#    user shell
#    group shell log readproc
#    seclabel u:r:shell:s0
#    setenv HOSTNAME console
#    shutdown critical

The console service was configured to use the same UART serial port
that I was using for the PPP connection.
It would interfere with pppd by resetting or controlling the serial
port, causing the "Modem hangup" issue.

I have a stable connection now running for the past 60 minutes. There
is a ppp connection established between Ubuntu Machine and my AOSP
Target Device.
I can ping from AOSP target device into the Ubuntu Machine the
following (it works):
ping -I ppp0 10.0.0.1
(I have to use -I and provide the specific interface to ping even
though the ip route is up to date)
And I cannot ping from Ubuntu to AOSP target.

Strangely, tcpdump shows that packets are received/sent back and forth
 # tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot
length 262144 bytes
14:49:17.949046 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 552, seq
618, length 64
14:49:18.320546 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 15, seq
34, length 64
14:49:18.351262 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 15, seq
34, length 64
14:49:18.972947 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 552, seq
619, length 64
14:49:19.321893 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 15, seq
35, length 64
14:49:19.353363 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 15, seq
35, length 64
14:49:19.997088 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 552, seq
620, length 64
14:49:20.323381 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 15, seq
36, length 64
14:49:20.356685 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 15, seq
36, length 64

I am not blocked any more, but it would be good to know if there is a way for:
1. I would be able to ping from Ubuntu machine as well into the AOSP target
2. Ideally, ping should work without -I and having to explicitly
mention the interface
(something like just ping 10.0.0.1 should work instead of ping -I ppp0 10.0.0.1

Thank you.

On Tue, Sep 10, 2024 at 4:53 PM Paul Mackerras <paulus@ozlabs.org> wrote:
>
> On Tue, Sep 10, 2024 at 11:30:48AM -0700, Devesh Chipade wrote:
> > In my options file, I have debug and kdebug 7.
> > This is all the logs I could get:
>
> The pppd logs look fine.  There is nothing in the kernel (dmesg) log
> that looks relevant (in fact kdebug 7 is mostly useful if you are
> actually debugging the kernel driver; it doesn't really help with
> problems like this).
>
> Do you have logs from pppd on the ubuntu/linux side?  Is something
> causing it to terminate?
>
> Alternatively, do you have another service running on either side
> which also thinks it is using the same serial port?  Something like a
> getty, or whatever the systemd equivalent is for providing a login
> prompt?  You could do "fuser /dev/ttyMSM0" or "fuser /dev/ttyUSB0" as
> root during the 6 seconds when the link is up to check if something
> other than pppd also has the serial port open.
>
> Paul.

Re: PPP Modem Hangup

[Devesh Chipade]

I am still not able to ping into ubuntu/linux or into my aosp target
device without explicitly mentioning -I ppp0 interface.
ping -I ppp0 10.0.0.1 / ping -I ppp0 10.0.0.2 works
but
ping 10.0.0.1 / ping 10.0.0.2 does not work,

I have verified the ip route, ip tables, ip addr show as well as
ifconfig (both on linux and aosp target). Seems to be all good in it.
Any suggestions?

On Tue, Sep 10, 2024 at 5:10 PM Devesh Chipade <devesh@in-unison.com> wrote:
>
> I have resolved the issue now:
>
> I have commented out the following in my init.rc file
> #service console /system/bin/sh
> #    class core
> #    console
> #    disabled
> #    user shell
> #    group shell log readproc
> #    seclabel u:r:shell:s0
> #    setenv HOSTNAME console
> #    shutdown critical
>
> The console service was configured to use the same UART serial port
> that I was using for the PPP connection.
> It would interfere with pppd by resetting or controlling the serial
> port, causing the "Modem hangup" issue.
>
> I have a stable connection now running for the past 60 minutes. There
> is a ppp connection established between Ubuntu Machine and my AOSP
> Target Device.
> I can ping from AOSP target device into the Ubuntu Machine the
> following (it works):
> ping -I ppp0 10.0.0.1
> (I have to use -I and provide the specific interface to ping even
> though the ip route is up to date)
> And I cannot ping from Ubuntu to AOSP target.
>
> Strangely, tcpdump shows that packets are received/sent back and forth
>  # tcpdump -i ppp0
> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
> listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot
> length 262144 bytes
> 14:49:17.949046 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 552, seq
> 618, length 64
> 14:49:18.320546 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 15, seq
> 34, length 64
> 14:49:18.351262 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 15, seq
> 34, length 64
> 14:49:18.972947 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 552, seq
> 619, length 64
> 14:49:19.321893 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 15, seq
> 35, length 64
> 14:49:19.353363 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 15, seq
> 35, length 64
> 14:49:19.997088 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 552, seq
> 620, length 64
> 14:49:20.323381 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 15, seq
> 36, length 64
> 14:49:20.356685 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 15, seq
> 36, length 64
>
> I am not blocked any more, but it would be good to know if there is a way for:
> 1. I would be able to ping from Ubuntu machine as well into the AOSP target
> 2. Ideally, ping should work without -I and having to explicitly
> mention the interface
> (something like just ping 10.0.0.1 should work instead of ping -I ppp0 10.0.0.1
>
> Thank you.
>
> On Tue, Sep 10, 2024 at 4:53 PM Paul Mackerras <paulus@ozlabs.org> wrote:
> >
> > On Tue, Sep 10, 2024 at 11:30:48AM -0700, Devesh Chipade wrote:
> > > In my options file, I have debug and kdebug 7.
> > > This is all the logs I could get:
> >
> > The pppd logs look fine.  There is nothing in the kernel (dmesg) log
> > that looks relevant (in fact kdebug 7 is mostly useful if you are
> > actually debugging the kernel driver; it doesn't really help with
> > problems like this).
> >
> > Do you have logs from pppd on the ubuntu/linux side?  Is something
> > causing it to terminate?
> >
> > Alternatively, do you have another service running on either side
> > which also thinks it is using the same serial port?  Something like a
> > getty, or whatever the systemd equivalent is for providing a login
> > prompt?  You could do "fuser /dev/ttyMSM0" or "fuser /dev/ttyUSB0" as
> > root during the 6 seconds when the link is up to check if something
> > other than pppd also has the serial port open.
> >
> > Paul.

Re: PPP Modem Hangup

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]


Devesh Chipade <devesh@in-unison.com> wrote:
    > I am still not able to ping into ubuntu/linux or into my aosp target
    > device without explicitly mentioning -I ppp0 interface.  ping -I ppp0
    > 10.0.0.1 / ping -I ppp0 10.0.0.2 works but ping 10.0.0.1 / ping
    > 10.0.0.2 does not work,

Android does stuff with the networking stack so that it can live in multiple
provider domains.   So the default route (if it exists) often lives in a
alternate routing table.

    > I have verified the ip route, ip tables, ip addr show as well as
    > ifconfig (both on linux and aosp target). Seems to be all good in it.
    > Any suggestions?

you didn't post details, but..

if you tcpdump on your Ubuntu side, you'll probably see that AOSP side has
picked some other IP address as the source.  If you really want to fix that,
then add a route back to the ppp0 device on the ubuntu side, but probably you
just need to make sure that the Android side always uses the right source IP.




--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: PPP Modem Hangup

[Devesh Chipade]

Posting more details:

On Ubuntu:

$ ip route show
default via 192.168.0.1 dev wlp5s0 proto dhcp src 192.168.0.79 metric 600
10.0.0.0/24 dev ppp0 scope link
10.0.0.2 dev ppp0 proto kernel scope link src 10.0.0.1
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev wlp5s0 proto kernel scope link src 192.168.0.79 metr

$ ip addr show
59: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN group default qlen 3
    link/ppp
    inet 10.0.0.1 peer 10.0.0.2/32 scope global ppp0
       valid_lft forever preferred_lft forever

~$ sudo tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot
length 262144 bytes
11:29:02.068203 IP Devesh > 10.0.0.2: ICMP echo request, id 56351, seq
5744, length 64
11:29:02.394650 IP 10.0.0.2 > Devesh: ICMP echo request, id 32, seq
5882, length 64
11:29:02.394673 IP Devesh > 10.0.0.2: ICMP echo reply, id 32, seq
5882, length 64
11:29:02.490505 IP 10.0.0.2 > Devesh: ICMP echo request, id 28, seq
428, length 64
11:29:02.490533 IP Devesh > 10.0.0.2: ICMP echo reply, id 28, seq 428, length 64
11:29:02.570513 IP 10.0.0.2 > Devesh: ICMP echo request, id 29, seq
239, length 64
11:29:02.570533 IP Devesh > 10.0.0.2: ICMP echo reply, id 29, seq 239, length 64
11:29:03.092195 IP Devesh > 10.0.0.2: ICMP echo request, id 56351, seq
5745, length 64
11:29:03.386211 IP 10.0.0.2 > Devesh: ICMP echo request, id 32, seq
5883, length 64
11:29:03.386238 IP Devesh > 10.0.0.2: ICMP echo reply, id 32, seq
5883, length 64
11:29:03.482223 IP 10.0.0.2 > Devesh: ICMP echo request, id 28, seq
429, length 64
11:29:03.482246 IP Devesh > 10.0.0.2: ICMP echo reply, id 28, seq 429, length 64
11:29:03.578234 IP 10.0.0.2 > Devesh: ICMP echo request, id 29, seq
240, length 64
11:29:03.578258 IP Devesh > 10.0.0.2: ICMP echo reply, id 29, seq 240, length 64
11:29:04.116196 IP Devesh > 10.0.0.2: ICMP echo request, id 56351, seq
5746, length 64
11:29:04.393801 IP 10.0.0.2 > Devesh: ICMP echo request, id 32, seq
5884, length 64
11:29:04.393826 IP Devesh > 10.0.0.2: ICMP echo reply, id 32, seq
5884, length 64


On Android Target Device:

# ip route
default dev ppp0 scope link
10.0.0.0/24 dev ppp0 scope link
10.0.0.1 dev ppp0 proto kernel scope link src 10.0.0.2

# ip addr show
72: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN group default qlen 3
    link/ppp
    inet 10.0.0.2 peer 10.0.0.1/32 scope global ppp0
       valid_lft forever preferred_lft forever

# ifconfig
ppp0      Link encap:Point-to-Point Protocol
          inet addr:10.0.0.2  P-t-P:10.0.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:204583 errors:0 dropped:0 overruns:0 frame:0
          TX packets:137381 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:17453623 TX bytes:11539856

# tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot
length 262144 bytes
11:27:47.371173 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 32, seq
5969, length 64
11:27:47.865949 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 56351,
seq 5830, length 64
11:27:47.979345 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 29, seq
327, length 64
11:27:47.979903 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 32, seq
5970, length 64
11:27:47.980717 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 28, seq
516, length 64
11:27:48.182932 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 29, seq
327, length 64
11:27:48.275624 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 32, seq
5970, length 64
11:27:48.363885 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 28, seq
516, length 64
11:27:48.891693 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 56351,
seq 5831, length 64
11:27:48.979785 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 29, seq
328, length 64
11:27:48.981057 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 32, seq
5971, length 64
11:27:48.981469 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 28, seq
517, length 64
11:27:49.190116 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 29, seq
328, length 64
11:27:49.281473 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 32, seq
5971, length 64
11:27:49.368639 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 28, seq
517, length 64
11:27:49.913433 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 56351,
seq 5832, length 64
11:27:49.980826 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 32, seq
5972, length 64
11:27:49.981377 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 29, seq
329, length 64
11:27:49.982190 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 28, seq
518, length 64
11:27:50.193380 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 32, seq
5972, length 64

On Fri, Sep 13, 2024 at 11:00 AM Michael Richardson <mcr@sandelman.ca> wrote:
>
>
> Devesh Chipade <devesh@in-unison.com> wrote:
>     > I am still not able to ping into ubuntu/linux or into my aosp target
>     > device without explicitly mentioning -I ppp0 interface.  ping -I ppp0
>     > 10.0.0.1 / ping -I ppp0 10.0.0.2 works but ping 10.0.0.1 / ping
>     > 10.0.0.2 does not work,
>
> Android does stuff with the networking stack so that it can live in multiple
> provider domains.   So the default route (if it exists) often lives in a
> alternate routing table.
>
>     > I have verified the ip route, ip tables, ip addr show as well as
>     > ifconfig (both on linux and aosp target). Seems to be all good in it.
>     > Any suggestions?
>
> you didn't post details, but..
>
> if you tcpdump on your Ubuntu side, you'll probably see that AOSP side has
> picked some other IP address as the source.  If you really want to fix that,
> then add a route back to the ppp0 device on the ubuntu side, but probably you
> just need to make sure that the Android side always uses the right source IP.
>
>
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>
>
>

Re: PPP Modem Hangup

[Devesh Chipade]

On analyzing the logs further, I noticed that I can ping only from
AOSP target device to Ubuntu Machine and not the other way around.

On Fri, Sep 13, 2024 at 11:33 AM Devesh Chipade <devesh@in-unison.com> wrote:
>
> Posting more details:
>
> On Ubuntu:
>
> $ ip route show
> default via 192.168.0.1 dev wlp5s0 proto dhcp src 192.168.0.79 metric 600
> 10.0.0.0/24 dev ppp0 scope link
> 10.0.0.2 dev ppp0 proto kernel scope link src 10.0.0.1
> 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
> 192.168.0.0/24 dev wlp5s0 proto kernel scope link src 192.168.0.79 metr
>
> $ ip addr show
> 59: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
> pfifo_fast state UNKNOWN group default qlen 3
>     link/ppp
>     inet 10.0.0.1 peer 10.0.0.2/32 scope global ppp0
>        valid_lft forever preferred_lft forever
>
> ~$ sudo tcpdump -i ppp0
> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
> listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot
> length 262144 bytes
> 11:29:02.068203 IP Devesh > 10.0.0.2: ICMP echo request, id 56351, seq
> 5744, length 64
> 11:29:02.394650 IP 10.0.0.2 > Devesh: ICMP echo request, id 32, seq
> 5882, length 64
> 11:29:02.394673 IP Devesh > 10.0.0.2: ICMP echo reply, id 32, seq
> 5882, length 64
> 11:29:02.490505 IP 10.0.0.2 > Devesh: ICMP echo request, id 28, seq
> 428, length 64
> 11:29:02.490533 IP Devesh > 10.0.0.2: ICMP echo reply, id 28, seq 428, length 64
> 11:29:02.570513 IP 10.0.0.2 > Devesh: ICMP echo request, id 29, seq
> 239, length 64
> 11:29:02.570533 IP Devesh > 10.0.0.2: ICMP echo reply, id 29, seq 239, length 64
> 11:29:03.092195 IP Devesh > 10.0.0.2: ICMP echo request, id 56351, seq
> 5745, length 64
> 11:29:03.386211 IP 10.0.0.2 > Devesh: ICMP echo request, id 32, seq
> 5883, length 64
> 11:29:03.386238 IP Devesh > 10.0.0.2: ICMP echo reply, id 32, seq
> 5883, length 64
> 11:29:03.482223 IP 10.0.0.2 > Devesh: ICMP echo request, id 28, seq
> 429, length 64
> 11:29:03.482246 IP Devesh > 10.0.0.2: ICMP echo reply, id 28, seq 429, length 64
> 11:29:03.578234 IP 10.0.0.2 > Devesh: ICMP echo request, id 29, seq
> 240, length 64
> 11:29:03.578258 IP Devesh > 10.0.0.2: ICMP echo reply, id 29, seq 240, length 64
> 11:29:04.116196 IP Devesh > 10.0.0.2: ICMP echo request, id 56351, seq
> 5746, length 64
> 11:29:04.393801 IP 10.0.0.2 > Devesh: ICMP echo request, id 32, seq
> 5884, length 64
> 11:29:04.393826 IP Devesh > 10.0.0.2: ICMP echo reply, id 32, seq
> 5884, length 64
>
>
> On Android Target Device:
>
> # ip route
> default dev ppp0 scope link
> 10.0.0.0/24 dev ppp0 scope link
> 10.0.0.1 dev ppp0 proto kernel scope link src 10.0.0.2
>
> # ip addr show
> 72: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
> pfifo_fast state UNKNOWN group default qlen 3
>     link/ppp
>     inet 10.0.0.2 peer 10.0.0.1/32 scope global ppp0
>        valid_lft forever preferred_lft forever
>
> # ifconfig
> ppp0      Link encap:Point-to-Point Protocol
>           inet addr:10.0.0.2  P-t-P:10.0.0.1  Mask:255.255.255.255
>           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
>           RX packets:204583 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:137381 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:3
>           RX bytes:17453623 TX bytes:11539856
>
> # tcpdump -i ppp0
> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
> listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot
> length 262144 bytes
> 11:27:47.371173 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 32, seq
> 5969, length 64
> 11:27:47.865949 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 56351,
> seq 5830, length 64
> 11:27:47.979345 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 29, seq
> 327, length 64
> 11:27:47.979903 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 32, seq
> 5970, length 64
> 11:27:47.980717 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 28, seq
> 516, length 64
> 11:27:48.182932 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 29, seq
> 327, length 64
> 11:27:48.275624 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 32, seq
> 5970, length 64
> 11:27:48.363885 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 28, seq
> 516, length 64
> 11:27:48.891693 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 56351,
> seq 5831, length 64
> 11:27:48.979785 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 29, seq
> 328, length 64
> 11:27:48.981057 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 32, seq
> 5971, length 64
> 11:27:48.981469 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 28, seq
> 517, length 64
> 11:27:49.190116 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 29, seq
> 328, length 64
> 11:27:49.281473 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 32, seq
> 5971, length 64
> 11:27:49.368639 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 28, seq
> 517, length 64
> 11:27:49.913433 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 56351,
> seq 5832, length 64
> 11:27:49.980826 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 32, seq
> 5972, length 64
> 11:27:49.981377 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 29, seq
> 329, length 64
> 11:27:49.982190 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 28, seq
> 518, length 64
> 11:27:50.193380 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 32, seq
> 5972, length 64
>
> On Fri, Sep 13, 2024 at 11:00 AM Michael Richardson <mcr@sandelman.ca> wrote:
> >
> >
> > Devesh Chipade <devesh@in-unison.com> wrote:
> >     > I am still not able to ping into ubuntu/linux or into my aosp target
> >     > device without explicitly mentioning -I ppp0 interface.  ping -I ppp0
> >     > 10.0.0.1 / ping -I ppp0 10.0.0.2 works but ping 10.0.0.1 / ping
> >     > 10.0.0.2 does not work,
> >
> > Android does stuff with the networking stack so that it can live in multiple
> > provider domains.   So the default route (if it exists) often lives in a
> > alternate routing table.
> >
> >     > I have verified the ip route, ip tables, ip addr show as well as
> >     > ifconfig (both on linux and aosp target). Seems to be all good in it.
> >     > Any suggestions?
> >
> > you didn't post details, but..
> >
> > if you tcpdump on your Ubuntu side, you'll probably see that AOSP side has
> > picked some other IP address as the source.  If you really want to fix that,
> > then add a route back to the ppp0 device on the ubuntu side, but probably you
> > just need to make sure that the Android side always uses the right source IP.
> >
> >
> >
> >
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> >  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
> >
> >
> >

Re: PPP Modem Hangup

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]


Devesh Chipade <devesh@in-unison.com> wrote:
    > On analyzing the logs further, I noticed that I can ping only from AOSP
    > target device to Ubuntu Machine and not the other way around.

    >> 11:29:02.068203 IP Devesh > 10.0.0.2: ICMP echo request, id 56351, seq
    >> 5744, length 64 11:29:02.394650 IP 10.0.0.2 > Devesh: ICMP echo
        >> request, id 32, seq 5882, length 64 11:29:02.394673 IP Devesh >
    >> 10.0.0.2: ICMP echo reply, id 32, seq 5882, length 64 11:29:02.490505

Looks like it works that way.

    >> cooked v1), snapshot length 262144 bytes 11:27:47.371173 IP 10.0.0.1 >
    >> 10.0.0.2: ICMP echo reply, id 32, seq 5969, length 64 11:27:47.865949
    >> IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 56351, seq 5830, length

And the other way too.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]