* PPP Modem Hangup @ 2024-09-09 22:55 Devesh Chipade 2024-09-10 12:39 ` Michael Richardson 0 siblings, 1 reply; 12+ messages in thread From: Devesh Chipade @ 2024-09-09 22:55 UTC (permalink / raw) To: linux-ppp 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PPP Modem Hangup 2024-09-09 22:55 PPP Modem Hangup Devesh Chipade @ 2024-09-10 12:39 ` Michael Richardson 2024-09-10 16:42 ` Devesh Chipade 0 siblings, 1 reply; 12+ messages in thread From: Michael Richardson @ 2024-09-10 12:39 UTC (permalink / raw) To: Devesh Chipade; +Cc: linux-ppp [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PPP Modem Hangup 2024-09-10 12:39 ` Michael Richardson @ 2024-09-10 16:42 ` Devesh Chipade 2024-09-10 18:23 ` Michael Richardson 0 siblings, 1 reply; 12+ messages in thread From: Devesh Chipade @ 2024-09-10 16:42 UTC (permalink / raw) To: Michael Richardson; +Cc: linux-ppp 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? > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PPP Modem Hangup 2024-09-10 16:42 ` Devesh Chipade @ 2024-09-10 18:23 ` Michael Richardson 2024-09-10 18:30 ` Devesh Chipade 0 siblings, 1 reply; 12+ messages in thread From: Michael Richardson @ 2024-09-10 18:23 UTC (permalink / raw) To: Devesh Chipade; +Cc: linux-ppp [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PPP Modem Hangup 2024-09-10 18:23 ` Michael Richardson @ 2024-09-10 18:30 ` Devesh Chipade 2024-09-10 23:53 ` Paul Mackerras 0 siblings, 1 reply; 12+ messages in thread From: Devesh Chipade @ 2024-09-10 18:30 UTC (permalink / raw) To: Michael Richardson; +Cc: linux-ppp 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PPP Modem Hangup 2024-09-10 18:30 ` Devesh Chipade @ 2024-09-10 23:53 ` Paul Mackerras 2024-09-11 0:10 ` Devesh Chipade 0 siblings, 1 reply; 12+ messages in thread From: Paul Mackerras @ 2024-09-10 23:53 UTC (permalink / raw) To: Devesh Chipade; +Cc: linux-ppp 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PPP Modem Hangup 2024-09-10 23:53 ` Paul Mackerras @ 2024-09-11 0:10 ` Devesh Chipade 2024-09-13 1:43 ` Devesh Chipade 0 siblings, 1 reply; 12+ messages in thread From: Devesh Chipade @ 2024-09-11 0:10 UTC (permalink / raw) To: Paul Mackerras; +Cc: linux-ppp 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PPP Modem Hangup 2024-09-11 0:10 ` Devesh Chipade @ 2024-09-13 1:43 ` Devesh Chipade 2024-09-13 18:00 ` Michael Richardson 0 siblings, 1 reply; 12+ messages in thread From: Devesh Chipade @ 2024-09-13 1:43 UTC (permalink / raw) To: Paul Mackerras; +Cc: linux-ppp 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PPP Modem Hangup 2024-09-13 1:43 ` Devesh Chipade @ 2024-09-13 18:00 ` Michael Richardson 2024-09-13 18:33 ` Devesh Chipade 0 siblings, 1 reply; 12+ messages in thread From: Michael Richardson @ 2024-09-13 18:00 UTC (permalink / raw) To: Devesh Chipade; +Cc: Paul Mackerras, linux-ppp [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PPP Modem Hangup 2024-09-13 18:00 ` Michael Richardson @ 2024-09-13 18:33 ` Devesh Chipade 2024-09-13 20:33 ` Devesh Chipade 0 siblings, 1 reply; 12+ messages in thread From: Devesh Chipade @ 2024-09-13 18:33 UTC (permalink / raw) To: Michael Richardson; +Cc: Paul Mackerras, linux-ppp 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* > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PPP Modem Hangup 2024-09-13 18:33 ` Devesh Chipade @ 2024-09-13 20:33 ` Devesh Chipade 2024-09-13 23:03 ` Michael Richardson 0 siblings, 1 reply; 12+ messages in thread From: Devesh Chipade @ 2024-09-13 20:33 UTC (permalink / raw) To: Michael Richardson; +Cc: Paul Mackerras, linux-ppp 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* > > > > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PPP Modem Hangup 2024-09-13 20:33 ` Devesh Chipade @ 2024-09-13 23:03 ` Michael Richardson 0 siblings, 0 replies; 12+ messages in thread From: Michael Richardson @ 2024-09-13 23:03 UTC (permalink / raw) To: Devesh Chipade; +Cc: Paul Mackerras, linux-ppp [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2024-09-13 23:03 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-09-09 22:55 PPP Modem Hangup Devesh Chipade 2024-09-10 12:39 ` Michael Richardson 2024-09-10 16:42 ` Devesh Chipade 2024-09-10 18:23 ` Michael Richardson 2024-09-10 18:30 ` Devesh Chipade 2024-09-10 23:53 ` Paul Mackerras 2024-09-11 0:10 ` Devesh Chipade 2024-09-13 1:43 ` Devesh Chipade 2024-09-13 18:00 ` Michael Richardson 2024-09-13 18:33 ` Devesh Chipade 2024-09-13 20:33 ` Devesh Chipade 2024-09-13 23:03 ` Michael Richardson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).