Rr-pppoe-server script bugs

For Developers
1

I have found several bugs (a couple minor, one rendering the package unusable for me) in the rr-pppoe-server package.

I can outline the problem I'm seeing (although the minor bugs are very obviously typos), however I'm asking this question here because I'm not sure which repo I should be submitting an issue + PR to. The script in question is the the one that ends up being put in the /etc/init.d/pppoe-server (after installing luci-app-rp-pppoe-server luci-app-rp-pppoe-server rp-pppoe-server ppp ppp-mod-pppoe) and that script has a header line in it indicating it's copyright openwrt (# Copyright (C) 2006-2011 OpenWrt.org) which makes me assume it is not part of the rr-pppoe-server project (which as an aside has a dead maintainer page).

There is also another problem which extends further into openwrt territory: there is a call in that startup script: network_get_physdev device $interface || return 1 which is defined in . /lib/functions/network.sh which appears to be part of core openwrt project.

I've tried to manually use that call to no avail: I get no output at all despite clearly having a working system with many interfaces. I've dived in and checked the output of ubus call network.interface dump to ensure that it is indeed outputing stuff (it is).

All in all, I have a pretty convoluted situation which I am willing to put elbow grease into, I would just like some guidance as to which projects I need to be delving into (specifically for the issue+PR workflow).

Thank you for your time.

2

I'll just comment on this part:

If you look at the implementation in /lib/functions/network.sh, you'll notice that most internal functions, including network_get_physdev, assign output to a variable, rather than printing it to STDOUT. Presumably the intention is to avoid creating unnecessary subshells. So this is how one would test this function:

myinterface="something" my_phys_device=''
. /lib/functions/network.sh
network_get_physdev my_phys_device "$myinterface"
echo "phys device for interface '$myinterface': '$my_phys_device'"
3

I'm getting the following:

root@radio-backhaul-001:~# . /lib/functions/network.sh 
root@radio-backhaul-001:~# myinterface="br-lan.4" my_phys=''
root@radio-backhaul-001:~# network_get_physdev my_phys "$myinterface"
root@radio-backhaul-001:~# echo $my_phys

root@radio-backhaul-001:~# myinterface="br-lan.4@br-lan" my_phys=''
root@radio-backhaul-001:~# network_get_physdev my_phys "$myinterface"
root@radio-backhaul-001:~# echo $my_phys

root@radio-backhaul-001:~# ip a | grep br-lan.4
70: br-lan.4@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    inet 10.4.0.1/24 brd 10.4.0.255 scope global br-lan.4

pebkac?

(edit, I can add the output as well, but both calls return $? => 1, which is why the most proximal reason why the pppoe-server start script fails silently)

4

I'm not sure where this name br-lan.4@br-lan comes from but it looks odd and maybe (?) this is causing the issue. Did you name it this way or are you using something like VLAN's and that name was created automatically? What happens if you query for br-lan instead?

Also what is the output of ubus call network.interface dump?

5

Please note, I've done both the br-lan.4 and the br-lan.4@br-lan queries. The latter is simply a named alias in linux land.

I had previously done the ubus dump but had not noticed this: the get_network_physdev is looking for openwrt interface names, not linux interfaces (e.g. physdev). This actually explains what the problem is: this line here is retreiving an entry from the configuration set by the luci-app-rp-pppoe-server front end. However, on that frontend, the drop down is populated with devices, not interfaces. And the configuration will put br-lan.4 which in this case should be PPPoE. If I use interface names like so:

root@radio-backhaul-001:~# network_get_physdev my_phys "wan" ; echo $my_phys
br-lan.2
root@radio-backhaul-001:~# network_get_physdev my_phys "PPPoE" ; echo $my_phys
br-lan.4

I get the correct behaviour.

Alright, so there are now 4 issues which I can document in a issue report on openwrt project for the rp-pppoe package, and 2 of them are due to a mismatch between configuration format and the LuCI app output format.

I am not yet sure where the LuCI implementation lives, but I can definitely put the issue in for the package.

For reference to your question, dumps below:

root@radio-backhaul-001:~# ip a 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 96:af:70:e1:b3:c8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::94af:70ff:fee1:b3c8/64 scope link 
       valid_lft forever preferred_lft forever
3: lan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether f4:1e:57:e8:51:11 brd ff:ff:ff:ff:ff:ff
4: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether f4:1e:57:e8:51:11 brd ff:ff:ff:ff:ff:ff
5: br-lan.10@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether f4:1e:57:e8:51:11 brd ff:ff:ff:ff:ff:ff
    inet 10.10.0.2/24 brd 10.10.0.255 scope global br-lan.10
       valid_lft forever preferred_lft forever
    inet6 fe80::f61e:57ff:fee8:5111/64 scope link 
       valid_lft forever preferred_lft forever
6: br-lan.2@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether f4:1e:57:e8:51:11 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.101/24 brd 192.168.1.255 scope global br-lan.2
       valid_lft forever preferred_lft forever
    inet6 fe80::f61e:57ff:fee8:5111/64 scope link 
       valid_lft forever preferred_lft forever
8: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1520 qdisc noqueue master br-lan state UP qlen 1000
    link/ether f4:1e:57:e8:51:12 brd ff:ff:ff:ff:ff:ff
70: br-lan.4@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether f4:1e:57:e8:51:11 brd ff:ff:ff:ff:ff:ff
    inet 10.4.0.1/24 brd 10.4.0.255 scope global br-lan.4
       valid_lft forever preferred_lft forever
    inet6 fe80::f61e:57ff:fee8:5111/64 scope link 
       valid_lft forever preferred_lft forever
71: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN qlen 3
    link/ppp 
    inet6 fe80::cdf1:78d4:e1e2:e732/128 scope link flags 02 
       valid_lft forever preferred_lft forever
81: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1484 qdisc fq_codel state UNKNOWN qlen 3
    link/ppp 
    inet 10.4.0.1 peer 10.4.0.10/32 scope global ppp1
       valid_lft forever preferred_lft forever
    inet6 fe80::f4f1:d059:88c0:1285/128 scope link flags 02 
       valid_lft forever preferred_lft forever
root@radio-backhaul-001:~# ubus call network.interface dump
{
	"interface": [
		{
			"interface": "PPPoE",
			"up": true,
			"pending": false,
			"available": true,
			"autostart": true,
			"dynamic": false,
			"uptime": 4383,
			"l3_device": "br-lan.4",
			"proto": "static",
			"device": "br-lan.4",
			"updated": [
				"addresses"
			],
			"metric": 0,
			"dns_metric": 0,
			"delegation": true,
			"ipv4-address": [
				{
					"address": "10.4.0.1",
					"mask": 24
				}
			],
			"ipv6-address": [
				
			],
			"ipv6-prefix": [
				
			],
			"ipv6-prefix-assignment": [
				
			],
			"route": [
				
			],
			"dns-server": [
				
			],
			"dns-search": [
				
			],
			"neighbors": [
				
			],
			"inactive": {
				"ipv4-address": [
					
				],
				"ipv6-address": [
					
				],
				"route": [
					
				],
				"dns-server": [
					
				],
				"dns-search": [
					
				],
				"neighbors": [
					
				]
			},
			"data": {
				
			}
		},
		{
			"interface": "administration",
			"up": true,
			"pending": false,
			"available": true,
			"autostart": true,
			"dynamic": false,
			"uptime": 347392,
			"l3_device": "br-lan.10",
			"proto": "dhcp",
			"device": "br-lan.10",
			"metric": 0,
			"dns_metric": 0,
			"delegation": true,
			"ipv4-address": [
				{
					"address": "10.10.0.2",
					"mask": 24
				}
			],
			"ipv6-address": [
				
			],
			"ipv6-prefix": [
				
			],
			"ipv6-prefix-assignment": [
				
			],
			"route": [
				
			],
			"dns-server": [
				"10.10.0.1"
			],
			"dns-search": [
				"lan"
			],
			"neighbors": [
				
			],
			"inactive": {
				"ipv4-address": [
					
				],
				"ipv6-address": [
					
				],
				"route": [
					{
						"target": "0.0.0.0",
						"mask": 0,
						"nexthop": "10.10.0.1",
						"source": "10.10.0.2/32"
					}
				],
				"dns-server": [
					
				],
				"dns-search": [
					
				],
				"neighbors": [
					
				]
			},
			"data": {
				"dhcpserver": "10.10.0.1",
				"hostname": "radio-backhaul-001",
				"leasetime": 43200
			}
		},
		{
			"interface": "loopback",
			"up": true,
			"pending": false,
			"available": true,
			"autostart": true,
			"dynamic": false,
			"uptime": 412680,
			"l3_device": "lo",
			"proto": "static",
			"device": "lo",
			"updated": [
				"addresses"
			],
			"metric": 0,
			"dns_metric": 0,
			"delegation": true,
			"ipv4-address": [
				{
					"address": "127.0.0.1",
					"mask": 8
				}
			],
			"ipv6-address": [
				
			],
			"ipv6-prefix": [
				
			],
			"ipv6-prefix-assignment": [
				
			],
			"route": [
				
			],
			"dns-server": [
				
			],
			"dns-search": [
				
			],
			"neighbors": [
				
			],
			"inactive": {
				"ipv4-address": [
					
				],
				"ipv6-address": [
					
				],
				"route": [
					
				],
				"dns-server": [
					
				],
				"dns-search": [
					
				],
				"neighbors": [
					
				]
			},
			"data": {
				
			}
		},
		{
			"interface": "wan",
			"up": true,
			"pending": false,
			"available": true,
			"autostart": true,
			"dynamic": false,
			"uptime": 346827,
			"l3_device": "br-lan.2",
			"proto": "dhcp",
			"device": "br-lan.2",
			"metric": 0,
			"dns_metric": 0,
			"delegation": true,
			"ipv4-address": [
				{
					"address": "192.168.1.101",
					"mask": 24
				}
			],
			"ipv6-address": [
				
			],
			"ipv6-prefix": [
				
			],
			"ipv6-prefix-assignment": [
				
			],
			"route": [
				{
					"target": "0.0.0.0",
					"mask": 0,
					"nexthop": "192.168.1.1",
					"source": "192.168.1.101/32"
				}
			],
			"dns-server": [
				"192.168.1.1"
			],
			"dns-search": [
				
			],
			"neighbors": [
				
			],
			"inactive": {
				"ipv4-address": [
					
				],
				"ipv6-address": [
					
				],
				"route": [
					
				],
				"dns-server": [
					
				],
				"dns-search": [
					
				],
				"neighbors": [
					
				]
			},
			"data": {
				"dhcpserver": "192.168.1.1",
				"leasetime": 86400
			}
		}
	]
}
6

I'm adding LuCI + config output for reference:

root@radio-backhaul-001:~# cat /etc/config/pppoe 

config pppoe_server
	option interface 'br-lan.4'
	option enabled '1'
	option localip '10.4.0.1'
	option firstremoteip '10.4.0.10'
	option optionsfile '/etc/ppp/pppoe-server-options'
	option maxsessionsperpeer '10'
	option maxsessions '90'
	list service_name 'RabitNet'

image
image1800×1761 315 KB

7

just opened #26616 (https://github.com/openwrt/packages/issues/26616)

8

This sounds like a bug in the frontend then. That said, this presumably example config (?) also references a physical device (eth1) in option "interface".

Luci frontends live in a separate repo.

9

Thanks. I will open a issue in the frontend repo as well.

Do note, however, that there are several other typos in that script and I think it would be prudent to add some systems logging too.

I've outlined the things I think would make sense to change in the issue report.

10

btw, appears the device bug already open here https://github.com/openwrt/luci/issues/7695

1 Like