Page 1 of 1

PPP not routing to network

Posted: Tue Sep 24, 2024 11:02 am
by chrisy

Hi

I was using UART mode PPP from the MiniMig and ao486 cores and it was working fine. I don't think I've changed anything, but they are no longer working from either.

I can connect to PPP OK, and on both cores I can ping the MiSTer's IP. I can't ping anything beyond the (router, anything else on my network, etc.).

It looks like something has gone wrong with the routing on the MiSTer side. Is there any way of checking?

An old thread suggested to add this to iptables.up.rules

Code: Select all

-A FORWARD -i ppp+ -o eth0 -j ACCEPT

I did try that and it didn't make any difference.

The only thing I can think of that I've knowingly done is added some lines to /sbin/uartmode to get faster Internet from MiniMig. I'm pretty sure that worked though as I tested it. My uartmode currently looks like this:

Code: Select all

#!/bin/bash

kill_all() {
	rm -f /tmp/uartmode*
	rm -f /tmp/ML_BAUD
	killall midilink
	killall pppd
	killall agetty
	killall login
	killall mt32d
	killall fluidsynth
	killall mpg123
}

conn_speed=115200
[ -f /tmp/UART_SPEED ] && conn_speed=$(cat /tmp/UART_SPEED)

echo "ttyS1: "$conn_speed

if [ "$1" == "1" ]; then
	if [ ! -f /tmp/uartmode1 ]; then
		kill_all
		echo "1" >/tmp/uartmode1
		(
			while true
			do
				if [ -f /media/fat/linux/ppp_options ]; then
					
				localip=$(ifconfig 2>/dev/null | sed -En 's/127.0.0.1//;s/.*inet (addr:)?(([0-9]*\.){3}[0-9]*).*/\2/p')
				remoteip=$(ifconfig 2>/dev/null | sed -En 's/127.0.0.1//;s/.*inet (addr:)?(([0-9]*\.){2}[0-9]*).*/\2/p').254

				if [ -z $localip ]; then
					echo cannot get local IP for PPP link.
					localip=0.0.0.0
					remoteip=0.0.0.0
				else
					echo "PPP link: $localip->$remoteip"
				fi

				echo "$localip:$remoteip" >/tmp/ppp_options
				cat /media/fat/linux/ppp_options >>/tmp/ppp_options

				echo 1 > /proc/sys/net/ipv4/ip_forward
				[ -f /tmp/CORENAME ] && core_name=$(cat /tmp/CORENAME)
					if [ "$core_name" == "Minimig" ]; then
    					taskset 1 pppd 230400 file /tmp/ppp_options
					else
    					taskset 1 pppd $conn_speed file /tmp/ppp_options
					fi
#					taskset 1 pppd $conn_speed file /tmp/ppp_options
				else
					echo "skip pppd"
					exit 0
				fi

			[ ! -f /tmp/uartmode1 ] && exit 0

			echo respawn pppd
			sleep 1
		done
	) &
fi
elif [ "$1" == "2" ]; then
	if [ ! -f /tmp/uartmode2 ]; then
		kill_all
		echo "1" >/tmp/uartmode2
		(
			while true
			do
				taskset 1 agetty $conn_speed ttyS1 -h &
				wait $!

			[ ! -f /tmp/uartmode2 ] && exit 0

			echo respawn console
			sleep 1
		done 
	) &
fi
elif [ "$1" == "3" ]; then
	if [ ! -f /tmp/uartmode3 ]; then
		kill_all
		echo "1" >/tmp/uartmode3
		(
			while true
			do
				taskset 1 midilink MENU QUIET &
				wait $!
			
			[ ! -f /tmp/uartmode3 ] && exit 0
		
			echo respawn midilink
			sleep 1
		done 
	) &
fi
elif [ "$1" == "4" ]; then
	if [ ! -f /tmp/uartmode4 ]; then
		kill_all
		echo "1" >/tmp/uartmode4
		(
			while true
			do
				taskset 1 midilink MENU QUIET &
				wait $!

			[ ! -f /tmp/uartmode4 ] && exit 0

			echo respawn midilink
			sleep 1
		done 
	) &
fi
elif [ "$1" == "5" ]; then
	if [ ! -f /tmp/uartmode5 ]; then
		kill_all
		echo "1" >/tmp/uartmode5
		(
			while true
			do
				taskset 1 midilink UDP QUIET BAUD $conn_speed 
				wait $!

			[ ! -f /tmp/uartmode5 ] && exit 0

			echo respawn midilink
			sleep 1
		done 
	) &
fi
else
	if [ -f /tmp/uartmode* ]; then
		kill_all
	fi
fi


Re: PPP not routing to network

Posted: Tue Sep 24, 2024 2:57 pm
by thera34

Can you post the result of ifconfig and route commands from MiSTer's ARM linux after you are also connected to PPP from Minimig/ao486 ?

P.S. /sbin/uartmode looks fine and identical to mine, except an extra commented out taskset line, but that would not be of any issue


Re: PPP not routing to network

Posted: Tue Sep 24, 2024 3:08 pm
by chrisy

Sure, here you go:

Code: Select all

/root# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.88  netmask 255.255.255.0  broadcast 192.168.0.255
        ether 2e:e6:a0:fe:76:7a  txqueuelen 1000  (Ethernet)
        RX packets 148  bytes 16023 (15.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 125  bytes 13028 (12.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 39  base 0xe000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 128  bytes 9472 (9.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 128  bytes 9472 (9.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 192.168.0.88  netmask 255.255.255.255  destination 192.168.0.254
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 8  bytes 114 (114.0 B)
        RX errors 1  dropped 0  overruns 0  frame 0
        TX packets 9  bytes 118 (118.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

/root# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    1002   0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     1002   0        0 eth0
192.168.0.254   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0

Re: PPP not routing to network

Posted: Tue Sep 24, 2024 3:16 pm
by thera34

Looks fine to me... ping 8.8.8.8 returns anything (both from ARM and core side) ?


Re: PPP not routing to network

Posted: Tue Sep 24, 2024 3:21 pm
by chrisy

In Linux, yes, on ao486/Mimimig, no.

tracert from ao486 gets as far as 192.168.0.88 and then times out.


Re: PPP not routing to network

Posted: Tue Sep 24, 2024 4:06 pm
by chrisy

I've just realised what the problem is - the MiSTer always assigns 192.168.0.254 to the core. I added an old repeater to my network and gave it that IP a while back. Duh! Thanks for your help anyway - hopefully this thread will come up when somebody else does the same stupid thing :)