I see a strange behaviour of the pppd v2.3.5 (TCP/IP v5.0).
If there is an option to proxy ARP - the second call to the server will not have the operational IP-trafficing. For this to happen the second call must happen within 0~15 minutes window since the first one. Later on - everything starts working properly.
Here is the snip of syslog.
Notice the “Aug 13 16:43:32” record.
If “proxyarp” option is removed - calls may follow at any rate successfully.
Aug 13 16:33:24 localhost pppd[14498]: Could not set session: Operation not permitted
Aug 13 16:33:24 localhost pppd[14498]: pppd 2.3.5 started by System, uid 0
Aug 13 16:33:24 localhost pppd[14498]: Using interface vp0
Aug 13 16:33:24 localhost pppd[14498]: Connect: vp0 <–> //3/dev/ser2
Aug 13 16:33:27 localhost pppd[14498]: found interface en1 for proxy arp
Aug 13 16:33:27 localhost pppd[14498]: local IP address 192.168.40.40
Aug 13 16:33:27 localhost pppd[14498]: remote IP address 192.168.40.41
Aug 13 08:33:29 node<<3>> ntp[14962]: 192.168.40.41: delay:1.599791 offset:-0.827464 Fri Aug 13 08:33:28 2004
Aug 13 16:34:14 localhost pppd[14498]: LCP terminated by peer (y^]jM-p^@<M-Mt^@^@^@^@)
Aug 13 16:34:14 localhost pppd[14498]: Hangup (SIGHUP)
Aug 13 16:34:17 localhost pppd[14498]: Connection terminated.
Aug 13 16:34:17 localhost pppd[14498]: Exit.
Aug 13 16:43:29 localhost pppd[18790]: Could not set session: Operation not permitted
Aug 13 16:43:29 localhost pppd[18790]: pppd 2.3.5 started by System, uid 0
Aug 13 16:43:29 localhost pppd[18790]: Using interface vp0
Aug 13 16:43:29 localhost pppd[18790]: Connect: vp0 <–> //3/dev/ser2
Aug 13 16:43:32 localhost pppd[18790]: Couldn’t set interface address: Address 192.168.40.40 already exists
Aug 13 16:43:32 localhost pppd[18790]: found interface en1 for proxy arp
Aug 13 16:43:32 localhost pppd[18790]: local IP address 192.168.40.40
Aug 13 16:43:32 localhost pppd[18790]: remote IP address 192.168.40.41
Aug 13 08:43:42 node<<3>> ntp[18905]: Timeout
Aug 13 08:43:52 node<<3>> ntp[18905]: Timeout
Aug 13 08:43:52 node<<3>> ntp[18905]: Host 192.168.40.41 is not responding
Aug 13 16:46:31 localhost pppd[18790]: LCP terminated by peer (#M-3(M-^[^@<M-Mt^@^@^@^@)
Aug 13 16:46:31 localhost pppd[18790]: Hangup (SIGHUP)
Aug 13 16:46:34 localhost pppd[18790]: Connection terminated.
Aug 13 16:46:34 localhost pppd[18790]: Exit.
I do not remember this happening with pppd v2.3.0 (TCP/IP v4.25D), however I cannot garantee it right now.
Running “netstat -in” after the first call is completed shows vp0 as “vp0*”, i.e. collapsed rather then as other other operational interfaces (en1 and lo0).
Is it a “feature” or a bug?
If it’s a feature - how do I control the timeout nesessary for Tcpip to reset itself?
Tony.
PS The name resolution depends on /etc/hosts file, not on DNS server’s replyed (I have not got it on that segment). All the names (local to the server and remote) ARE in the file.
/etc/ppp/options is as follows:
+pap
defaultroute
proxyarp
ppp_server:
/etc/ppp/options.ser2 is as follows:
:ppp_client
/etc/hosts has these:
192.168.40.40 ppp_server
192.168.40.41 ppp_client
I see a strange behaviour of the pppd v2.3.5 (TCP/IP v5.0).
If there is an option to proxy ARP - the second call to the server will
not have the operational IP-trafficing. For this to happen the second call
must happen within 0~15 minutes window since the first one. Later on -
everything starts working properly.
Here is the snip of syslog.
Notice the “Aug 13 16:43:32” record.
If “proxyarp” option is removed - calls may follow at any rate
successfully.
Aug 13 16:33:24 localhost pppd[14498]: Could not set session: Operation
not permitted
Aug 13 16:33:24 localhost pppd[14498]: pppd 2.3.5 started by System, uid 0
Aug 13 16:33:24 localhost pppd[14498]: Using interface vp0
Aug 13 16:33:24 localhost pppd[14498]: Connect: vp0 <–> //3/dev/ser2
Aug 13 16:33:27 localhost pppd[14498]: found interface en1 for proxy arp
Aug 13 16:33:27 localhost pppd[14498]: local IP address 192.168.40.40
Aug 13 16:33:27 localhost pppd[14498]: remote IP address 192.168.40.41
Aug 13 08:33:29 node<<3>> ntp[14962]: 192.168.40.41: delay:1.599791
offset:-0.827464 Fri Aug 13 08:33:28 2004
Aug 13 16:34:14 localhost pppd[14498]: LCP terminated by peer
(y^]jM-p^@<M-Mt^@^@^@^@)
Aug 13 16:34:14 localhost pppd[14498]: Hangup (SIGHUP)
Aug 13 16:34:17 localhost pppd[14498]: Connection terminated.
Aug 13 16:34:17 localhost pppd[14498]: Exit.
Aug 13 16:43:29 localhost pppd[18790]: Could not set session: Operation
not permitted
Aug 13 16:43:29 localhost pppd[18790]: pppd 2.3.5 started by System, uid 0
Aug 13 16:43:29 localhost pppd[18790]: Using interface vp0
Aug 13 16:43:29 localhost pppd[18790]: Connect: vp0 <–> //3/dev/ser2
Aug 13 16:43:32 localhost pppd[18790]: Couldn’t set interface address:
Address 192.168.40.40 already exists
Aug 13 16:43:32 localhost pppd[18790]: found interface en1 for proxy arp
Aug 13 16:43:32 localhost pppd[18790]: local IP address 192.168.40.40
Aug 13 16:43:32 localhost pppd[18790]: remote IP address 192.168.40.41
Aug 13 08:43:42 node<<3>> ntp[18905]: Timeout
Aug 13 08:43:52 node<<3>> ntp[18905]: Timeout
Aug 13 08:43:52 node<<3>> ntp[18905]: Host 192.168.40.41 is not responding
Aug 13 16:46:31 localhost pppd[18790]: LCP terminated by peer
(#M-3(M-^[^@<M-Mt^@^@^@^@)
Aug 13 16:46:31 localhost pppd[18790]: Hangup (SIGHUP)
Aug 13 16:46:34 localhost pppd[18790]: Connection terminated.
Aug 13 16:46:34 localhost pppd[18790]: Exit.
I do not remember this happening with pppd v2.3.0 (TCP/IP v4.25D), however
I cannot garantee it right now.
Running “netstat -in” after the first call is completed shows vp0 as
“vp0*”, i.e. collapsed rather then as other other operational interfaces
(en1 and lo0).
Is it a “feature” or a bug?
If it’s a feature - how do I control the timeout nesessary for Tcpip to
reset itself?
Tony.
PS The name resolution depends on /etc/hosts file, not on DNS server’s
replyed (I have not got it on that segment). All the names (local to the
server and remote) ARE in the file.
/etc/ppp/options is as follows:
+pap
defaultroute
proxyarp
ppp_server:
/etc/ppp/options.ser2 is as follows:
:ppp_client
/etc/hosts has these:
192.168.40.40 ppp_server
192.168.40.41 ppp_client
On Mon, 16 Aug 2004 22:42:06 -0400, Xiaodan Tang <xtang@qnx.com> wrote:
Sounds like an ARP timeout (usually it took 20 minutes). Before start second
call, try a
“arp -d 192.168.40.41”
and see if it helps?
I cannot do it - the host is really remote…
Is it worth putting this into /etc/ppp/ip-down script?
Or I should put it into /etc/ppp/auth-up script?
On Mon, 16 Aug 2004 22:42:06 -0400, Xiaodan Tang <> xtang@qnx.com> > wrote:
Sounds like an ARP timeout (usually it took 20 minutes). Before start
second
call, try a
“arp -d 192.168.40.41”
and see if it helps?
I cannot do it - the host is really remote…
Is it worth putting this into /etc/ppp/ip-down script?
Or I should put it into /etc/ppp/auth-up script?
My /etc/ppp/ip-up is:
#! /bin/ksh
/usr/ucb/ntp -s $5 2>&1 | /usr/bin/logger -it ntp
My /etc/ppp/ip-down is:
#! /bin/ksh
/usr/ucb/arp -d $5 2>&1 | /usr/bin/logger -it arp
As you remember, “$5” is “remote IP” when pppd calls those scripts.
In my case it is 192.168.40.41
Here is a snip of three successive calls. The first was made without “arp -d $5”, the second and the third were made with “arp -d remote_IP” in /etc/ppp/ip-down.
Note “Aug 18 16:21:20” and “Aug 18 16:23:20” records.
Aug 18 16:15:16 localhost pppd[20180]: Could not set session: Operation not permitted
Aug 18 16:15:16 localhost pppd[20180]: pppd 2.3.5 started by System, uid 0
Aug 18 16:15:16 localhost pppd[20180]: Using interface vp0
Aug 18 16:15:16 localhost pppd[20180]: Connect: vp0 <–> //3/dev/ser2
Aug 18 16:15:21 localhost pppd[20180]: found interface en1 for proxy arp
Aug 18 16:15:21 localhost pppd[20180]: local IP address 192.168.40.40
Aug 18 16:15:21 localhost pppd[20180]: remote IP address 192.168.40.41
Aug 18 08:15:21 node<<3>> ntp[20331]: 192.168.40.41: delay:0.199891 offset:-0.044809 Wed Aug 18 08:15:21 2004
Aug 18 16:16:08 localhost pppd[20180]: LCP terminated by peer (~M-^Y^B^@<M-Mt^@^@^@^@)
Aug 18 16:16:08 localhost pppd[20180]: Hangup (SIGHUP)
Aug 18 16:16:11 localhost pppd[20180]: Connection terminated.
Aug 18 16:16:11 localhost pppd[20180]: Exit.
Aug 18 16:21:17 localhost pppd[22250]: Could not set session: Operation not permitted
Aug 18 16:21:17 localhost pppd[22250]: pppd 2.3.5 started by System, uid 0
Aug 18 16:21:17 localhost pppd[22250]: Using interface vp0
Aug 18 16:21:17 localhost pppd[22250]: Connect: vp0 <–> //3/dev/ser2
Aug 18 16:21:20 localhost pppd[22250]: Couldn’t set interface address: Address 192.168.40.40 already exists
Aug 18 16:21:20 localhost pppd[22250]: found interface en1 for proxy arp
Aug 18 16:21:20 localhost pppd[22250]: local IP address 192.168.40.40
Aug 18 16:21:20 localhost pppd[22250]: remote IP address 192.168.40.41
Aug 18 08:21:30 node<<3>> ntp[22701]: Timeout
Aug 18 08:21:40 node<<3>> ntp[22701]: Timeout
Aug 18 08:21:40 node<<3>> ntp[22701]: Host 192.168.40.41 is not responding
Aug 18 16:22:27 localhost pppd[22250]: LCP terminated by peer (yDs?^@<M-Mt^@^@^@^@)
Aug 18 08:22:27 node<<3>> arp[23461]: 192.168.40.41 (192.168.40.41) deleted
Aug 18 16:22:27 localhost pppd[22250]: Hangup (SIGHUP)
Aug 18 16:22:30 localhost pppd[22250]: Connection terminated.
Aug 18 16:22:30 localhost pppd[22250]: Exit.
Aug 18 16:23:13 localhost pppd[23689]: Could not set session: Operation not permitted
Aug 18 16:23:13 localhost pppd[23689]: pppd 2.3.5 started by System, uid 0
Aug 18 16:23:13 localhost pppd[23689]: Using interface vp0
Aug 18 16:23:13 localhost pppd[23689]: Connect: vp0 <–> //3/dev/ser2
Aug 18 16:23:20 localhost pppd[23689]: Couldn’t set interface address: Address 192.168.40.40 already exists
Aug 18 16:23:20 localhost pppd[23689]: found interface en1 for proxy arp
Aug 18 16:23:20 localhost pppd[23689]: local IP address 192.168.40.40
Aug 18 16:23:20 localhost pppd[23689]: remote IP address 192.168.40.41
Aug 18 08:23:30 node<<3>> ntp[23977]: Timeout
Aug 18 08:23:40 node<<3>> ntp[23977]: Timeout
Aug 18 08:23:40 node<<3>> ntp[23977]: Host 192.168.40.41 is not responding
Aug 18 16:23:54 localhost pppd[23689]: LCP terminated by peer (C=^g^@<M-Mt^@^@^@^@)
Aug 18 08:23:54 node<<3>> arp[24456]: 192.168.40.41 (192.168.40.41) deleted
Aug 18 16:23:55 localhost pppd[23689]: Hangup (SIGHUP)
Aug 18 16:23:57 localhost pppd[23689]: Connection terminated.
Aug 18 16:23:57 localhost pppd[23689]: Exit.
Me thinks, it’s not an ARP timeout.
This must be something else, pppd v2.3.5 complains regarding his local interface address being in use.
My setup:
Two computers running QNX 4 with TPCIP5.0 connected with serial line. One
computer is also connected to ethernet, let’s call him master. Let’s call
the other one slave.
On both I run pppd in endless loop, sth. like
while true
do
pppd args
done
pppd args for master are: proxyarp ethernet_ip: other_ip (eg.
192.168.147.88:192.168.147.244)
pppd args for client are: defaultroute
The problem arises when pppd on master restarts (either slay-ed, or the link
is broken) and there is some communication going on with slave.
While the link is down, arp entry on the master is added (address,
incomplete). Then after the link establishment with slave another arp entry
is added, so output from arp -a (on the master) looks like:
? (192.168.147.244) at (incomplete)
? (192.168.147.244) at MAC_address permanet published (proxy only)
When there are 2 entries (one of them incomplete) in arp table, then there
is no communication possible with slave. This seems to be the cause of the
problem.
If I manage to clear 192.168.147.244 address from arp cache while link is
down, after pppd start it fills the table with right data and everything
works as expected.
I tried both ip-up and ip-down to delete arp entries, but it didn’t help.
Sounds like an ARP timeout (usually it took 20 minutes). Before start
second
call, try a
“arp -d 192.168.40.41”
and see if it helps?
I cannot do it - the host is really remote…
Is it worth putting this into /etc/ppp/ip-down script?
Or I should put it into /etc/ppp/auth-up script?
On Wed, 18 Aug 2004 13:26:29 -0400, Xiaodan Tang <xtang@qnx.com> wrote:
The output below seems suggest the vp0 interface address is not cleared? I
guess, you want to output “arp -na”, “netstat -nr”, “netstat -ni” before you start
the second pppd, and see if there is anything not clearned out.
Those are the informational commands, I believe, they do not affect the Tcpip internals. I need a way to forcebly flush the interface table.
(I’ll put those commands in /etc/ppp/ip-down too and post what they return. However, I did try “netstat -in” and “netstat -nr” after the call is over, see my very first post, nothing unusual seen…)
Pavol posted saying he have similar problem, and “arp -d” in ip-down does
not work?
I am not sure why, but I guess you can try do it yourself after pppd
stopped. You should
also try a “arp -na” after “arp -d” so you know for sure the entry is
cleaned.
The output below seems suggest the vp0 interface address is not cleared? I
guess,
you want to output “arp -na”, “netstat -nr”, “netstat -ni” before you start
the second
pppd, and see if there is anything not clearned out.
My /etc/ppp/ip-up is:
#! /bin/ksh
/usr/ucb/ntp -s $5 2>&1 | /usr/bin/logger -it ntp
My /etc/ppp/ip-down is:
#! /bin/ksh
/usr/ucb/arp -d $5 2>&1 | /usr/bin/logger -it arp
As you remember, “$5” is “remote IP” when pppd calls those scripts.
In my case it is 192.168.40.41
Here is a snip of three successive calls. The first was made without
“arp -d $5”, the second and the third were made with “arp -d remote_IP” in
/etc/ppp/ip-down.
Note “Aug 18 16:21:20” and “Aug 18 16:23:20” records.
Aug 18 16:15:16 localhost pppd[20180]: Could not set session: Operation
not permitted
Aug 18 16:15:16 localhost pppd[20180]: pppd 2.3.5 started by System, uid 0
Aug 18 16:15:16 localhost pppd[20180]: Using interface vp0
Aug 18 16:15:16 localhost pppd[20180]: Connect: vp0 <–> //3/dev/ser2
Aug 18 16:15:21 localhost pppd[20180]: found interface en1 for proxy arp
Aug 18 16:15:21 localhost pppd[20180]: local IP address 192.168.40.40
Aug 18 16:15:21 localhost pppd[20180]: remote IP address 192.168.40.41
Aug 18 08:15:21 node<<3>> ntp[20331]: 192.168.40.41: delay:0.199891
offset:-0.044809 Wed Aug 18 08:15:21 2004
Aug 18 16:16:08 localhost pppd[20180]: LCP terminated by peer
(~M-^Y^B^@<M-Mt^@^@^@^@)
Aug 18 16:16:08 localhost pppd[20180]: Hangup (SIGHUP)
Aug 18 16:16:11 localhost pppd[20180]: Connection terminated.
Aug 18 16:16:11 localhost pppd[20180]: Exit.
Aug 18 16:21:17 localhost pppd[22250]: Could not set session: Operation
not permitted
Aug 18 16:21:17 localhost pppd[22250]: pppd 2.3.5 started by System, uid 0
Aug 18 16:21:17 localhost pppd[22250]: Using interface vp0
Aug 18 16:21:17 localhost pppd[22250]: Connect: vp0 <–> //3/dev/ser2
Aug 18 16:21:20 localhost pppd[22250]: Couldn’t set interface address:
Address 192.168.40.40 already exists
Aug 18 16:21:20 localhost pppd[22250]: found interface en1 for proxy arp
Aug 18 16:21:20 localhost pppd[22250]: local IP address 192.168.40.40
Aug 18 16:21:20 localhost pppd[22250]: remote IP address 192.168.40.41
Aug 18 08:21:30 node<<3>> ntp[22701]: Timeout
Aug 18 08:21:40 node<<3>> ntp[22701]: Timeout
Aug 18 08:21:40 node<<3>> ntp[22701]: Host 192.168.40.41 is not responding
Aug 18 16:22:27 localhost pppd[22250]: LCP terminated by peer
(yDs?^@<M-Mt^@^@^@^@)
Aug 18 08:22:27 node<<3>> arp[23461]: 192.168.40.41 (192.168.40.41)
deleted
Aug 18 16:22:27 localhost pppd[22250]: Hangup (SIGHUP)
Aug 18 16:22:30 localhost pppd[22250]: Connection terminated.
Aug 18 16:22:30 localhost pppd[22250]: Exit.
Aug 18 16:23:13 localhost pppd[23689]: Could not set session: Operation
not permitted
Aug 18 16:23:13 localhost pppd[23689]: pppd 2.3.5 started by System, uid 0
Aug 18 16:23:13 localhost pppd[23689]: Using interface vp0
Aug 18 16:23:13 localhost pppd[23689]: Connect: vp0 <–> //3/dev/ser2
Aug 18 16:23:20 localhost pppd[23689]: Couldn’t set interface address:
Address 192.168.40.40 already exists
Aug 18 16:23:20 localhost pppd[23689]: found interface en1 for proxy arp
Aug 18 16:23:20 localhost pppd[23689]: local IP address 192.168.40.40
Aug 18 16:23:20 localhost pppd[23689]: remote IP address 192.168.40.41
Aug 18 08:23:30 node<<3>> ntp[23977]: Timeout
Aug 18 08:23:40 node<<3>> ntp[23977]: Timeout
Aug 18 08:23:40 node<<3>> ntp[23977]: Host 192.168.40.41 is not responding
Aug 18 16:23:54 localhost pppd[23689]: LCP terminated by peer
(C=^g^@<M-Mt^@^@^@^@)
Aug 18 08:23:54 node<<3>> arp[24456]: 192.168.40.41 (192.168.40.41)
deleted
Aug 18 16:23:55 localhost pppd[23689]: Hangup (SIGHUP)
Aug 18 16:23:57 localhost pppd[23689]: Connection terminated.
Aug 18 16:23:57 localhost pppd[23689]: Exit.
Me thinks, it’s not an ARP timeout.
This must be something else, pppd v2.3.5 complains regarding his local
interface address being in use.
My setup:
Two computers running QNX 4 with TPCIP5.0 connected with serial line. One
computer is also connected to ethernet, let’s call him master. Let’s call
the other one slave.
On both I run pppd in endless loop, sth. like
while true
do
pppd args
done
pppd args for master are: proxyarp ethernet_ip: other_ip (eg.
192.168.147.88:192.168.147.244)
pppd args for client are: defaultroute
The problem arises when pppd on master restarts (either slay-ed, or the
link
is broken) and there is some communication going on with slave.
While the link is down, arp entry on the master is added (address,
incomplete). Then after the link establishment with slave another arp
entry
is added, so output from arp -a (on the master) looks like:
? (192.168.147.244) at (incomplete)
? (192.168.147.244) at MAC_address permanet published (proxy only)
When there are 2 entries (one of them incomplete) in arp table, then there
is no communication possible with slave. This seems to be the cause of the
problem.
If I manage to clear 192.168.147.244 address from arp cache while link is
down, after pppd start it fills the table with right data and everything
works as expected.
I tried both ip-up and ip-down to delete arp entries, but it didn’t help.
Hope this helps to track down this problem.
Pavol Kycina
“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:cft97n$lj0$> 1@inn.qnx.com> …
If there is a place, I would say the ip-down script.
Sounds like an ARP timeout (usually it took 20 minutes). Before
start
second
call, try a
“arp -d 192.168.40.41”
and see if it helps?
I cannot do it - the host is really remote…
Is it worth putting this into /etc/ppp/ip-down script?
Or I should put it into /etc/ppp/auth-up script?
My setup:
Two computers running QNX 4 with TPCIP5.0 connected with serial line.
One
computer is also connected to ethernet, let’s call him master. Let’s
call
the other one slave.
On both I run pppd in endless loop, sth. like
while true
do
pppd args
done
pppd args for master are: proxyarp ethernet_ip: other_ip (eg.
192.168.147.88:192.168.147.244)
pppd args for client are: defaultroute
The problem arises when pppd on master restarts (either slay-ed, or the
link
is broken) and there is some communication going on with slave.
While the link is down, arp entry on the master is added (address,
incomplete). Then after the link establishment with slave another arp
entry
is added, so output from arp -a (on the master) looks like:
? (192.168.147.244) at (incomplete)
? (192.168.147.244) at MAC_address permanet published (proxy only)
When there are 2 entries (one of them incomplete) in arp table, then
there
is no communication possible with slave. This seems to be the cause of
the
problem.
If I manage to clear 192.168.147.244 address from arp cache while link
is
down, after pppd start it fills the table with right data and everything
works as expected.
I tried both ip-up and ip-down to delete arp entries, but it didn’t
help.
Hope this helps to track down this problem.
Pavol Kycina
“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:cft97n$lj0$> 1@inn.qnx.com> …
If there is a place, I would say the ip-down script.
Sounds like an ARP timeout (usually it took 20 minutes). Before
start
second
call, try a
“arp -d 192.168.40.41”
and see if it helps?
I cannot do it - the host is really remote…
Is it worth putting this into /etc/ppp/ip-down script?
Or I should put it into /etc/ppp/auth-up script?
This issue is not proxyarp related. If proxyarp option IS used - the issue gets really veird, if not used - sometimes it takes to wait a 5~10 minutes to make a second call.
I judge this because it allways complains about LOCAL vp adapter’s address.
I’m reading socket programming cookbook - “Address already in use” is mentioned there and an advise is given:
// lose the pesky “Address already in use” error message
if (setsockopt(listener,SOL_SOCKET,SO_REUSEADDR,&yes,sizeof(int)) == -1) {
perror(“setsockopt”);
exit(1);
}
Your first post suggest if “proxyarp” is not on option, everything is fine.
You are saying it’s not the case?
Did you get those “netstat -ni”, “netstat -nr”, “arp -na” output after the
first dialing? That might be tell
use what’s wrong.
pppd does not create any socket and listen on it, so SO_REUSEADDR have
nothing to do
with this.
This issue is not proxyarp related. If proxyarp option IS used - the
issue gets really veird, if not used - sometimes it takes to wait a 5~10
minutes to make a second call.
I judge this because it allways complains about LOCAL vp adapter’s
address.
I’m reading socket programming cookbook - “Address already in use” is
mentioned there and an advise is given:
// lose the pesky “Address already in use” error message
if (setsockopt(listener,SOL_SOCKET,SO_REUSEADDR,&yes,sizeof(int)) == -1) {
perror(“setsockopt”);
exit(1);
}
I don’t know for sure what you are trying to say.
I mean that even if there is no “proxyarp” option - sometimes the timeout between the calls is needed still. Ocasionally.
Did you get those “netstat -ni”, “netstat -nr”, “arp -na” output after the
first dialing? That might be tell use what’s wrong.
Theese output a very common picture - at least I can see nothing wrong there…
pppd does not create any socket and listen on it, so SO_REUSEADDR have
nothing to do with this.
I did not know.
Did you get those “netstat -ni”, “netstat -nr”, “arp -na” output after
the
first dialing? That might be tell use what’s wrong.
Theese output a very common picture - at least I can see nothing wrong
there…
What I was interested in is things like, does the interface address deleted
after
pppd disconnected? How’s the routing table looks like (if proxyarp is set)?