freebsd stable - Oct 2017 - ppp routing bug ?

On 26.10.2017 04:10, Mike Tancsa wrote:
> On 10/25/2017 4:54 PM, Mike Tancsa wrote:
>> While testing out our nanobsd RELENG11 images, I noticed a strange
>> routing issue.  Using a standard pppoe config that has been working
fine
>> on RELENG8,9,10 I am getting bogus routing entries.
>> having the commands in ppp.linkup
>>
>> pppoe:
>>  add 192.168.134.2/32 HISADDR
>>  add 192.168.134.3/32 HISADDR
>>  add 192.168.134.4/32 HISADDR
>>  add 192.168.134.5/32 HISADDR
> 
> Upping the logs with debug
> 
> 
> ppp[60212]: tun0: Command: pppoe: add 192.168.134.2/32 HISADDR
> ppp[60212]: tun0: Debug: wrote 124: cmd = Add, dst = 192.168.134.2,
> gateway = 64.7.128.7
> 
> The gateway is correct. Seems right, but its not installing it right.
> 
> 
> 
> 
> It also borkes on the ipv6 addr which I have disabled
> 
> ppp[60212]: tun0: Warning: ff02::: Change route failed: errno: Value too
> large to be stored in data type
> ppp[60212]: tun0: Debug: deflink: DescriptorRead: read 14/2048 from 1
> ppp[60212]: tun0: Debug: proto_LayerPull: unknown -> 0xc021
> ppp[60212]: tun0: Debug: link_PullPacket: Despatch proto 0xc021
> 
> 
> Any ideas ?
Are you sure that:

1) your ppp(8) binary is in sync with the kernel in the Nanobsd build ?
Generally that would be /usr/sbin/ppp but in your case I'd check twice if
this is the case.

2) your /sbin/route and /usr/bin/netstat are in sync too?

Try using "route -n monitor" in the background to see what
"ppp" really sends to the kernel.
Try using "mpd5" instead of "ppp" to make PPPoE connection
and see if it runs into same problem.

On 10/26/2017 6:17 AM, Eugene Grosbein wrote:
>>
>>
>> Any ideas ?
> 
> Are you sure that:
<are binaries in sync>

Hi,
	Yes I have rebuilt all a number of times. Also, this is i386. I think I
will try and build and AMD64 image to see if it follows there too.
> 
> Try using "route -n monitor" in the background to see what
"ppp" really sends to the kernel.
> Try using "mpd5" instead of "ppp" to make PPPoE
connection and see if it runs into same problem.
It seems to be routes that are /32s that are at issue.  If I have a /30,
the route gets installed correctly.

In ppp.linkup if I put

pppoe:
 add 192.168.134.2/32 HISADDR
 add 192.168.134.4/30 HISADDR
 ! /sbin/route add 192.168.135.0/24 HISADDR
 ! /sbin/route add 192.168.136.1 HISADDR
 ! /sbin/route add 192.168.137.1/32 HISADDR



The first route does not get installed, the rest do.

0.0.0.0&0x17040000 64.7.128.7         US            0   1492       tun0
192.168.134.4/30   64.7.128.7         US            0   1492       tun0
192.168.135.0/24   64.7.128.7         US            0   1492       tun0
192.168.136.1      64.7.128.7         UHS           0   1492       tun0
192.168.137.1/32   64.7.128.7         US            0   1492       tun0

route monitor shows two statements per entry.  comparing 134.2 and
137.1.  the HOST flag is not set for the bogus entry.


got message of size 124 on Thu Oct 26 09:37:40 2017
RTM_ADD: Add Route: len 124, pid: 23810, seq 4, errno 0,
flags:<UP,GATEWAY,DONE,STATIC>
locks:  inits:
sockaddrs: <DST,GATEWAY>
 192.168.134.2 64.7.128.7


got message of size 196 on Thu Oct 26 09:37:40 2017
RTM_CHANGE: Change Metrics or flags: len 196, pid: 23810, seq 8, errno
0, flags:<UP,DONE,STATIC>
locks:  inits: <mtu>
sockaddrs: <DST,GATEWAY,IFP,IFA>
 192.168.134.2 64.7.128.7 tun0 98.159.244.185

vs

got message of size 124 on Thu Oct 26 09:37:40 2017
RTM_ADD: Add Route: len 124, pid: 24236, seq 1, errno 0,
flags:<UP,GATEWAY,HOST,DONE,STATIC>
locks:  inits:
sockaddrs: <DST,GATEWAY>
 192.168.136.1 64.7.128.7

got message of size 196 on Thu Oct 26 09:37:40 2017
RTM_CHANGE: Change Metrics or flags: len 196, pid: 23810, seq 11, errno
0, flags:<UP,DONE,STATIC>
locks:  inits: <mtu>
sockaddrs: <DST,GATEWAY,IFP,IFA>
 192.168.136.1 64.7.128.7 tun0 98.159.244.185


got message of size 212 on Thu Oct 26 09:37:40 2017
RTM_CHANGE: Change Metrics or flags: len 212, pid: 23810, seq 12, errno
0, flags:<UP,DONE,STATIC>
locks:  inits: <mtu>
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
 192.168.137.1 64.7.128.7 255.255.255.255 tun0 98.159.244.185






-- 
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike at sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/