NetBSD Problem Report #44032
From www@NetBSD.org Wed Nov 3 10:59:34 2010
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by www.NetBSD.org (Postfix) with ESMTP id AC31763BA50
for <gnats-bugs@gnats.NetBSD.org>; Wed, 3 Nov 2010 10:59:34 +0000 (UTC)
Message-Id: <20101103105934.48FC463B95F@www.NetBSD.org>
Date: Wed, 3 Nov 2010 10:59:34 +0000 (UTC)
From: gergely@egervary.hu
Reply-To: gergely@egervary.hu
To: gnats-bugs@NetBSD.org
Subject: pppd: proxyarp is not working
X-Send-Pr-Version: www-1.0
>Number: 44032
>Category: bin
>Synopsis: pppd: proxyarp is not working
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: bin-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Nov 03 11:00:00 +0000 2010
>Closed-Date: Sat Jun 08 13:18:46 +0000 2013
>Last-Modified: Thu Feb 25 03:25:01 +0000 2016
>Originator: Gergely Egervary
>Release: NetBSD-5
>Organization:
>Environment:
NetBSD galileo.poli.hu 5.1_RC2 NetBSD 5.1_RC2 (GALILEO) #0: Mon Aug 30 12:00:36 CEST 2010 root@galileo.poli.hu:/usr/src/sys/arch/i386/compile/GALILEO i386
>Description:
PPTP server internal network: 10.0.0.0/8 (bge0)
PPTP server internal if: 10.0.0.1
PPTP remote client if: 10.0.0.192
According to syslog, connection is set up properly:
Nov 3 11:46:39 galileo pptpd[17673]: CTRL: Starting call (launching pppd, opening GRE)
Nov 3 11:46:39 galileo pppd[16154]: pppd 2.4.4 started by root, uid 0
Nov 3 11:46:39 galileo pppd[16154]: Using interface ppp0
Nov 3 11:46:39 galileo pppd[16154]: Connect: ppp0 <--> /dev/ttyp0
Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #1
Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #2
Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #3
Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #4
Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #5
Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #6
Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #7
Nov 3 11:46:41 galileo pppd[16154]: MPPE 128-bit stateless compression enabled
Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #8
Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #9
Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #10
Nov 3 11:46:41 galileo pppd[16154]: found interface bge0 for proxy arp
Nov 3 11:46:41 galileo pppd[16154]: local IP address 10.0.0.1
Nov 3 11:46:41 galileo pppd[16154]: remote IP address 10.0.0.192
Routing on the client is okay. Client can reach 10.0.0.1, but not the full remote network. tcpdump on the server network shows there are no response to arp who-has requests. On the VPN box, `arp -na` shows no relevant entry.
This setup used to work on good old NetBSD-4 days...
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: bin/44032: pppd: proxyarp is not working
Date: Wed, 3 Nov 2010 10:45:26 -0400
On Nov 3, 11:00am, gergely@egervary.hu (gergely@egervary.hu) wrote:
-- Subject: bin/44032: pppd: proxyarp is not working
| Nov 3 11:46:39 galileo pptpd[17673]: CTRL: Starting call (launching pppd, opening GRE)
| Nov 3 11:46:39 galileo pppd[16154]: pppd 2.4.4 started by root, uid 0
| Nov 3 11:46:39 galileo pppd[16154]: Using interface ppp0
| Nov 3 11:46:39 galileo pppd[16154]: Connect: ppp0 <--> /dev/ttyp0
| Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #1
| Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #2
| Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #3
| Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #4
| Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #5
| Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #6
| Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #7
| Nov 3 11:46:41 galileo pppd[16154]: MPPE 128-bit stateless compression enabled
| Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #8
| Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #9
| Nov 3 11:46:41 galileo pptpd[17673]: GRE: accepting packet #10
| Nov 3 11:46:41 galileo pppd[16154]: found interface bge0 for proxy arp
| Nov 3 11:46:41 galileo pppd[16154]: local IP address 10.0.0.1
| Nov 3 11:46:41 galileo pppd[16154]: remote IP address 10.0.0.192
|
| Routing on the client is okay. Client can reach 10.0.0.1, but not the full remote network. tcpdump on the server network shows there are no response to arp who-has requests. On the VPN box, `arp -na` shows no relevant entry.
Can you determine if this is a kernel issue or a pppd issue?
christos
From: Egervary Gergely <gergely@egervary.hu>
To: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc:
Subject: Re: bin/44032: pppd: proxyarp is not working
Date: Sat, 22 Oct 2011 00:25:07 +0200
A year has passed, and it seems we still do not have proxyarp working
properly.
I'm now running on todays 5.1_STABLE.
[10.0.0.192]---ppp---[10.0.0.1]---ethernet---[10.0.0.2]
- pppd on 10.0.0.1 says:
pppd[1291]: found interface vlan10 for proxy arp
(looks okay)
- 10.0.0.192 can ping 10.0.0.1, but not 10.0.0.2 and vice versa
- on 10.0.0.1:
# arp 10.0.0.192
arp: 10.0.0.192 (10.0.0.192) -- no entry
# arp -s 10.0.0.192 00:11:22:33:44:55 pub
arp: set: proxy entry exists for non 802 device
- on 10.0.0.2:
# arp 10.0.0.192
arp: 10.0.0.192 (10.0.0.192) -- no entry
# tcpdump -i vlan10
00:17:47.028819 ARP, Request who-has 10.0.0.192 tell 10.0.0.2,
length 28
00:17:48.036521 ARP, Request who-has 10.0.0.192 tell 10.0.0.2,
length 28
...
Any ideas?
--
Gergely EGERVARY
From: christos@zoulas.com (Christos Zoulas)
To: Egervary Gergely <gergely@egervary.hu>, gnats-bugs@NetBSD.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: bin/44032: pppd: proxyarp is not working
Date: Fri, 21 Oct 2011 20:09:18 -0400
On Oct 22, 12:25am, gergely@egervary.hu (Egervary Gergely) wrote:
-- Subject: Re: bin/44032: pppd: proxyarp is not working
| A year has passed, and it seems we still do not have proxyarp working
| properly.
|
| I'm now running on todays 5.1_STABLE.
|
| [10.0.0.192]---ppp---[10.0.0.1]---ethernet---[10.0.0.2]
|
| - pppd on 10.0.0.1 says:
| pppd[1291]: found interface vlan10 for proxy arp
| (looks okay)
|
| - 10.0.0.192 can ping 10.0.0.1, but not 10.0.0.2 and vice versa
|
| - on 10.0.0.1:
| # arp 10.0.0.192
| arp: 10.0.0.192 (10.0.0.192) -- no entry
|
| # arp -s 10.0.0.192 00:11:22:33:44:55 pub
| arp: set: proxy entry exists for non 802 device
|
| - on 10.0.0.2:
| # arp 10.0.0.192
| arp: 10.0.0.192 (10.0.0.192) -- no entry
|
| # tcpdump -i vlan10
| 00:17:47.028819 ARP, Request who-has 10.0.0.192 tell 10.0.0.2,
| length 28
| 00:17:48.036521 ARP, Request who-has 10.0.0.192 tell 10.0.0.2,
| length 28
| ...
|
| Any ideas?
Can you put some debugging in sifproxyarp and see what's going on?
christos
From: christos@zoulas.com (Christos Zoulas)
To: Egervary Gergely <gergely@egervary.hu>
Cc: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/44032: pppd: proxyarp is not working
Date: Tue, 4 Dec 2012 17:01:51 -0500
On Dec 4, 9:50pm, gergely@egervary.hu (Egervary Gergely) wrote:
-- Subject: Re: bin/44032: pppd: proxyarp is not working
| Finally, I have done some debugging.
|
| - In sifproxyarp(), arpmsg.hwa contains the correct MAC address.
| - Socket write() succeeds with 112 bytes written, that looks good.
| - If I comment out the socket write(), and manually enter the
| arp entry (arp -s 10.0.0.192 <mac> pub proxy) then the kernel still
| does not respond to arp who-has requests.
|
| Now, some questions:
|
| - The proxy arp entries are not visible in `arp -a'. Should not they
| be visible? For example, on Linux they are visible.
should be visible I think. do you have a configuration for me to test?
| - Once I add an arp entry with `arp -s 10.0.0.192 <mac> pub proxy'
| I cannot remove it later. (arp: delete: can't locate 10.0.0.192)
| Is this normal?
Works for me:
[DING!] 2502#arp -s 192.168.2.200 00:01:02:03:04:05 pub proxy
[5:00pm] 2503#arp -a
stinky.astron.com (192.168.2.9) at 02:60:8c:f2:17:b8 on sk0
? (192.168.2.200) at 00:01:02:03:04:05 on sk0 permanent published (proxy only)
[5:00pm] 2504#arp -d 192.168.2.200
[5:00pm] 2505#arp -a
stinky.astron.com (192.168.2.9) at 02:60:8c:f2:17:b8 on sk0
| - Is proxy arp working good for somebody out there? Could you please
| test it?
Yes, just send me an example setup and I will test.
christos
From: Egervary Gergely <gergely@egervary.hu>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: bin/44032: pppd: proxyarp is not working
Date: Tue, 04 Dec 2012 21:50:25 +0100
> | A year has passed, and it seems we still do not have proxyarp working
> | properly.
> |
> | I'm now running on todays 5.1_STABLE.
> |
> | [10.0.0.192]---ppp---[10.0.0.1]---ethernet---[10.0.0.2]
> |
> | - pppd on 10.0.0.1 says:
> | pppd[1291]: found interface vlan10 for proxy arp
> | (looks okay)
> |
> | - 10.0.0.192 can ping 10.0.0.1, but not 10.0.0.2 and vice versa
> |
> | - on 10.0.0.1:
> | # arp 10.0.0.192
> | arp: 10.0.0.192 (10.0.0.192) -- no entry
> |
> | # arp -s 10.0.0.192 00:11:22:33:44:55 pub
> | arp: set: proxy entry exists for non 802 device
> |
> | - on 10.0.0.2:
> | # arp 10.0.0.192
> | arp: 10.0.0.192 (10.0.0.192) -- no entry
> |
> | # tcpdump -i vlan10
> | 00:17:47.028819 ARP, Request who-has 10.0.0.192 tell 10.0.0.2,
> | length 28
> | 00:17:48.036521 ARP, Request who-has 10.0.0.192 tell 10.0.0.2,
> | length 28
> | ...
> |
> | Any ideas?
>
> Can you put some debugging in sifproxyarp and see what's going on?
Finally, I have done some debugging.
- In sifproxyarp(), arpmsg.hwa contains the correct MAC address.
- Socket write() succeeds with 112 bytes written, that looks good.
- If I comment out the socket write(), and manually enter the
arp entry (arp -s 10.0.0.192 <mac> pub proxy) then the kernel still
does not respond to arp who-has requests.
Now, some questions:
- The proxy arp entries are not visible in `arp -a'. Should not they
be visible? For example, on Linux they are visible.
- Once I add an arp entry with `arp -s 10.0.0.192 <mac> pub proxy'
I cannot remove it later. (arp: delete: can't locate 10.0.0.192)
Is this normal?
- Is proxy arp working good for somebody out there? Could you please
test it?
Thank you.
--
Gergely EGERVARY
From: Egervary Gergely <gergely@egervary.hu>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: bin/44032: pppd: proxyarp is not working
Date: Tue, 04 Dec 2012 23:21:01 +0100
> | - The proxy arp entries are not visible in `arp -a'. Should not they
> | be visible? For example, on Linux they are visible.
>
> should be visible I think. do you have a configuration for me to test?
>
> | - Once I add an arp entry with `arp -s 10.0.0.192 <mac> pub proxy'
> | I cannot remove it later. (arp: delete: can't locate 10.0.0.192)
> | Is this normal?
>
> Works for me:
It has something to do with the ppp interface. Try setting an arp entry
on a ppp interface.
Test #1: non existent IP address
# arp -s 10.11.12.13 2c:27:d7:14:54:17 pub proxy
# arp 10.11.12.13
? (10.11.12.13) at 2c:27:d7:14:54:17 on vlan10 permanent published
(proxy only)
# arp -d 10.11.12.13
All is good.
Test #2: IP address of a ppp link (local endpoint)
# arp -s 10.0.0.192 2c:27:d7:14:54:17 pub proxy
# arp 10.0.0.192
arp: 10.0.0.192 (10.0.0.192) -- no entry
# arp -d 10.0.0.192
arp: delete: can't locate 10.0.0.192
It fails, but "something" is in the arp table. If I try to re-add the
entry:
# arp -s 10.0.0.192 2c:27:d7:14:54:17 pub proxy
arp: set: proxy entry exists for non 802 device
Maybe the entry is set up on the wrong interface?
--
Gergely EGERVARY
From: christos@zoulas.com (Christos Zoulas)
To: Egervary Gergely <gergely@egervary.hu>
Cc: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/44032: pppd: proxyarp is not working
Date: Tue, 4 Dec 2012 17:24:18 -0500
On Dec 4, 11:21pm, gergely@egervary.hu (Egervary Gergely) wrote:
-- Subject: Re: bin/44032: pppd: proxyarp is not working
| Maybe the entry is set up on the wrong interface?
And "arp -a" says? Now that you've showed me how to reproduce it I will try
it tonight.
christos
From: Egervary Gergely <gergely@egervary.hu>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: bin/44032: pppd: proxyarp is not working
Date: Tue, 04 Dec 2012 23:29:48 +0100
> | Maybe the entry is set up on the wrong interface?
>
> And "arp -a" says? Now that you've showed me how to reproduce it I will try
> it tonight.
"arp -a" says:
arp: 10.0.0.192 (10.0.0.192) -- no entry
Replace "local endpoint" to "remote endpoint" in my previous
email. Of course, I want to setup a proxy entry for the remote
site over the PPP link. Local endpoint is in the ARP table
with the physical address of the ethernet interface.
--
Gergely EGERVARY
From: =?UTF-8?B?RWdlcnbDoXJ5IEdlcmdlbHk=?= <gergely@egervary.hu>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: bin/44032: pppd: proxyarp is not working
Date: Wed, 05 Jun 2013 17:27:20 +0200
> Test #1: non existent IP address
>
> # arp -s 10.11.12.13 2c:27:d7:14:54:17 pub proxy
> # arp 10.11.12.13
> ? (10.11.12.13) at 2c:27:d7:14:54:17 on vlan10 permanent published
> (proxy only)
> # arp -d 10.11.12.13
>
> All is good.
>
> Test #2: IP address of a ppp link (local endpoint)
>
> # arp -s 10.0.0.192 2c:27:d7:14:54:17 pub proxy
> # arp 10.0.0.192
> arp: 10.0.0.192 (10.0.0.192) -- no entry
> # arp -d 10.0.0.192
> arp: delete: can't locate 10.0.0.192
>
> It fails, but "something" is in the arp table. If I try to re-add the
> entry:
>
> # arp -s 10.0.0.192 2c:27:d7:14:54:17 pub proxy
> arp: set: proxy entry exists for non 802 device
Now running on NetBSD 6.1, and still no good :(
For testing purposes, now I call pppd with "noproxyarp" option, and try
to set up ARP entries manually.
1.) If I add the ARP entry manually _before_ connecting the ppp
connection, the ARP entry looks good, and it pings as expected:
# arp 10.0.0.192
arp: 10.0.0.192 (10.0.0.192) -- no entry
# arp -s 10.0.0.192 2c:27:d7:14:54:17 pub proxy
# arp 10.0.0.192
? (10.0.0.192) at 2c:27:d7:14:54:17 on vlan10 permanent published (proxy
only)
2.) When I add the ARP entry manually _after_ connecting the ppp
connection, a "zombie" ARP entry is created:
# arp 10.0.0.192
arp: 10.0.0.192 (10.0.0.192) -- no entry
# arp -s 10.0.0.192 2c:27:d7:14:54:17 pub proxy
# arp 10.0.0.192
arp: 10.0.0.192 (10.0.0.192) -- no entry
# arp -s 10.0.0.192 2c:27:d7:14:54:17 pub proxy
arp: set: proxy entry exists for non 802 device
# arp -d 10.0.0.192
arp: delete: can't locate 10.0.0.192
Please, help me fix this one. I'm a network administrator not a
developer, my C knowledge is less than required :(
Thank you.
--
Egerváry Gergely
<gergely@egervary.hu>
From: christos@zoulas.com (Christos Zoulas)
To: =?UTF-8?B?RWdlcnbDoXJ5IEdlcmdlbHk=?= <gergely@egervary.hu>
Cc: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/44032: pppd: proxyarp is not working
Date: Wed, 5 Jun 2013 13:32:01 -0400
On Jun 5, 5:27pm, gergely@egervary.hu (=?UTF-8?B?RWdlcnbDoXJ5IEdlcmdlbHk=?=) wrote:
-- Subject: Re: bin/44032: pppd: proxyarp is not working
| Please, help me fix this one. I'm a network administrator not a
| developer, my C knowledge is less than required :(
Sorry, I forgot about it. I will try to look again at it over the weekend.
christos
State-Changed-From-To: open->feedback
State-Changed-By: christos@NetBSD.org
State-Changed-When: Thu, 06 Jun 2013 20:11:36 -0400
State-Changed-Why:
Although this is supposed to work, why don't you just add a route to the
host/net that you want to access on your default gateway that points to
the machine which has the ppp link?
From: =?ISO-8859-1?Q?Egerv=E1ry_Gergely?= <gergely@egervary.hu>
To: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, christos@NetBSD.org
Cc:
Subject: Re: bin/44032 (pppd: proxyarp is not working)
Date: Fri, 07 Jun 2013 09:33:26 +0200
> Although this is supposed to work, why don't you just add a route to the
> host/net that you want to access on your default gateway that points to
> the machine which has the ppp link?
Routing only works if you have a remote PPP peer in a different IP
subnet. Then, you do not need proxyarp, but you need routing.
In this scenario, I have a LAN subnet, called 10.0.0.0/8, with the PPP
server address 10.0.0.1. The remote PPP peer dials in via VPN, and picks
up an IP address (10.0.0.192) from the LAN subnet. This one requires
working proxyarp. Without proxyarp, LAN hosts cannot reach the remote
PPP peer, as they have a network route for this subnet on their LAN
interface, and won't go to their default gateway.
In a perfect world all WAN connections should use Layer 3 routing.
Actually, the world is not perfect - I cannot change the topology -
and it used to work this way for more than 15 years.
--
Egerváry Gergely
From: "Christos Zoulas" <christos@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/44032 CVS commit: src/sys/net
Date: Fri, 7 Jun 2013 22:42:56 -0400
Module Name: src
Committed By: christos
Date: Sat Jun 8 02:42:56 UTC 2013
Modified Files:
src/sys/net: route.c
Log Message:
PR/44032: Proxy entries stopped working with pppd. The issue here is that
the route entry was added, but the RTF_LLINFO bit was not set, making arp -a
not showing the entry, but netstat -rn -f inet showing it with the missing
L bit. The order of resolution in ifa_ifwithroute() is that if a destination
address is found, then the interface chosen for the route is that of the
destination. This does not work for link-level addresses since the ppp
interface does not arp (uses link_rtrequest, not arp_rtrequest), so the
bit is never set. The easy solution here is to check that the gateway is
a link address, and use the interface which we chose for the link address
as opposed to the interface that routes to the destination. This restores
the previous behavior, but is it correct?
To generate a diff of this commit:
cvs rdiff -u -r1.126 -r1.127 src/sys/net/route.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: =?ISO-8859-1?Q?Egerv=E1ry_Gergely?= <gergely@egervary.hu>
To: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc:
Subject: Re: PR/44032 CVS commit: src/sys/net
Date: Sat, 08 Jun 2013 11:28:33 +0200
> Log Message:
> PR/44032: Proxy entries stopped working with pppd. The issue here is that
> the route entry was added, but the RTF_LLINFO bit was not set, making arp -a
> not showing the entry, but netstat -rn -f inet showing it with the missing
> L bit. The order of resolution in ifa_ifwithroute() is that if a destination
> address is found, then the interface chosen for the route is that of the
> destination. This does not work for link-level addresses since the ppp
> interface does not arp (uses link_rtrequest, not arp_rtrequest), so the
> bit is never set. The easy solution here is to check that the gateway is
> a link address, and use the interface which we chose for the link address
> as opposed to the interface that routes to the destination. This restores
> the previous behavior, but is it correct?
Thank you very much for your work.
I have pulled the following files:
usr.sbin/arp/arp.c,v 1.51
usr.sbin/pppd/pppd/sys-bsd.c,v 1.66
sys/net/route.c,v 1.127
Results:
| pppd[799]: found interface wm0 for proxy arp
The correct interface is called vlan10 (with parent: wm0)
- previously pppd found vlan10. Is this intentional?
# arp 10.0.0.192
arp: 10.0.0.192 (10.0.0.192) -- no entry
# netstat -rn -f inet | grep 10.0.0.192
10.0.0.192 10.0.0.1 UH 0 52 - ppp0
10.0.0.192 11:22:33:44:55:66 UHSp 0 0 - wm0
Still no good response to ARP who-has requests.
--
Egerváry Gergely
Datacast Rendszerház Kft
From: =?ISO-8859-1?Q?Egerv=E1ry_Gergely?= <gergely@egervary.hu>
To: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gergely@egervary.hu
Cc:
Subject: Re: PR/44032 CVS commit: src/sys/net
Date: Sat, 08 Jun 2013 11:43:02 +0200
> Results:
> | pppd[799]: found interface wm0 for proxy arp
>
> The correct interface is called vlan10 (with parent: wm0)
> - previously pppd found vlan10. Is this intentional?
>
> # arp 10.0.0.192
> arp: 10.0.0.192 (10.0.0.192) -- no entry
>
> # netstat -rn -f inet | grep 10.0.0.192
> 10.0.0.192 10.0.0.1 UH 0 52 - ppp0
> 10.0.0.192 11:22:33:44:55:66 UHSp 0 0 - wm0
>
> Still no good response to ARP who-has requests.
Reverting back sys-bsd.c,v 1.66 all is good:
# arp 10.0.0.192
vpn01.intranet (10.0.0.192) at 11:22:33:44:55:66 on vlan10 permanent
published (proxy only)
# netstat -rn -f inet | grep 10.0.0.192
10.0.0.192 10.0.0.1 UH 0 76 - ppp0
10.0.0.192 11:22:33:44:55:66 UHLSp 0 0 - vlan10
Hallelujah!
Please revise the changes in sys-bsd.c
Thank you again!
--
Egerváry Gergely
Datacast Rendszerház Kft
From: christos@zoulas.com (Christos Zoulas)
To: =?ISO-8859-1?Q?Egerv=E1ry_Gergely?= <gergely@egervary.hu>,
gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: PR/44032 CVS commit: src/sys/net
Date: Sat, 8 Jun 2013 09:11:10 -0400
On Jun 8, 11:43am, gergely@egervary.hu (=?ISO-8859-1?Q?Egerv=E1ry_Gergely?=) wrote:
-- Subject: Re: PR/44032 CVS commit: src/sys/net
| > Results:
| > | pppd[799]: found interface wm0 for proxy arp
| >
| > The correct interface is called vlan10 (with parent: wm0)
| > - previously pppd found vlan10. Is this intentional?
| >
| > # arp 10.0.0.192
| > arp: 10.0.0.192 (10.0.0.192) -- no entry
| >
| > # netstat -rn -f inet | grep 10.0.0.192
| > 10.0.0.192 10.0.0.1 UH 0 52 - ppp0
| > 10.0.0.192 11:22:33:44:55:66 UHSp 0 0 - wm0
| >
| > Still no good response to ARP who-has requests.
|
| Reverting back sys-bsd.c,v 1.66 all is good:
|
| # arp 10.0.0.192
| vpn01.intranet (10.0.0.192) at 11:22:33:44:55:66 on vlan10 permanent
| published (proxy only)
|
| # netstat -rn -f inet | grep 10.0.0.192
| 10.0.0.192 10.0.0.1 UH 0 76 - ppp0
| 10.0.0.192 11:22:33:44:55:66 UHLSp 0 0 - vlan10
|
| Hallelujah!
|
| Please revise the changes in sys-bsd.c
| Thank you again!
Right. Thanks!
christos
State-Changed-From-To: feedback->closed
State-Changed-By: christos@NetBSD.org
State-Changed-When: Sat, 08 Jun 2013 09:18:46 -0400
State-Changed-Why:
reported verified it is fixed
From: "SAITOH Masanobu" <msaitoh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/44032 CVS commit: [netbsd-6] src/sys/net
Date: Mon, 29 Jul 2013 05:43:13 +0000
Module Name: src
Committed By: msaitoh
Date: Mon Jul 29 05:43:13 UTC 2013
Modified Files:
src/sys/net [netbsd-6]: route.c
Log Message:
Pull up following revision(s) (requested by christos in ticket #909):
sys/net/route.c: revision 1.127
PR/44032: Proxy entries stopped working with pppd. The issue here is that
the route entry was added, but the RTF_LLINFO bit was not set, making arp -a
not showing the entry, but netstat -rn -f inet showing it with the missing
L bit. The order of resolution in ifa_ifwithroute() is that if a destination
address is found, then the interface chosen for the route is that of the
destination. This does not work for link-level addresses since the ppp
interface does not arp (uses link_rtrequest, not arp_rtrequest), so the
bit is never set. The easy solution here is to check that the gateway is
a link address, and use the interface which we chose for the link address
as opposed to the interface that routes to the destination. This restores
the previous behavior, but is it correct?
To generate a diff of this commit:
cvs rdiff -u -r1.126 -r1.126.2.1 src/sys/net/route.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Ryota Ozaki" <ozaki-r@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/44032 CVS commit: src/tests/net/arp
Date: Thu, 25 Feb 2016 03:23:15 +0000
Module Name: src
Committed By: ozaki-r
Date: Thu Feb 25 03:23:15 UTC 2016
Modified Files:
src/tests/net/arp: t_arp.sh
Log Message:
Add basic tests for Proxy ARP
The tests don't much enough and need more realitic tests, for example
tests for a setup using ppp found in PR 44032.
To generate a diff of this commit:
cvs rdiff -u -r1.10 -r1.11 src/tests/net/arp/t_arp.sh
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home