I am running OpenBSD 3.5 and have a sympatico ADSL connection. I have been running
OpenBSD for almost 2 years now with no problems. Recently, when my ADSL connection
"hangs", I have been unable to restart it. In the past, I have always successfully
used `kill -2 <pid_of_ppp>` to drop the current connection and reinitiate it.
However, recently, this has stopped working. My pppoe connection is started via:

/usr/sbin/ppp -ddial pppoe

when running, `ps -ax | grep ppp` returns:
31978 ?? Is 0:00.25 /usr/sbin/ppp -ddial pppoe
11480 ?? I 0:00.06 /usr/sbin/pppoe -i tx0

and `ifconfig tun0` returns:
tun0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1492
inet xx.xx.xx.xx --> xx.xx.xx.xx netmask 0xffffffff

when the connection "hangs" (no response to internet requests), both of the above
commands still return the same answers. In the past, `kill -2 31978` would always
restart ppp and my pppoe connection and all would be good.

My questions are:
1) Am I restarting the ppp connection properly?
2) Any ideas on what may be happening?

Thanks in advance.
../ToZ

try kill -9
and restart it manually


"Tony Paulic" <tpaulic@gateway.paulic.home> wrote in message
news:slrncj43ur.k7q.tpaulic@gateway.paulic.home...
>I am running OpenBSD 3.5 and have a sympatico ADSL connection. I have been
>running
> OpenBSD for almost 2 years now with no problems. Recently, when my ADSL
> connection
> "hangs", I have been unable to restart it. In the past, I have always
> successfully
> used `kill -2 <pid_of_ppp>` to drop the current connection and reinitiate
> it.
> However, recently, this has stopped working. My pppoe connection is
> started via:
>
> /usr/sbin/ppp -ddial pppoe
>
> when running, `ps -ax | grep ppp` returns:
> 31978 ?? Is 0:00.25 /usr/sbin/ppp -ddial pppoe
> 11480 ?? I 0:00.06 /usr/sbin/pppoe -i tx0
>
> and `ifconfig tun0` returns:
> tun0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1492
> inet xx.xx.xx.xx --> xx.xx.xx.xx netmask 0xffffffff
>
> when the connection "hangs" (no response to internet requests), both of
> the above
> commands still return the same answers. In the past, `kill -2 31978` would
> always
> restart ppp and my pppoe connection and all would be good.
>
> My questions are:
> 1) Am I restarting the ppp connection properly?
> 2) Any ideas on what may be happening?
>
> Thanks in advance.
> ./ToZ
>

On Sun, 29 Aug 2004 17:18:18 GMT, Tony Paulic
<tpaulic@gateway.paulic.home> wrote:

>I am running OpenBSD 3.5 and have a sympatico ADSL connection. I have been running
>OpenBSD for almost 2 years now with no problems. Recently, when my ADSL connection
>"hangs"

[...]

>2) Any ideas on what may be happening?

Ask the sympatico people if they changed anything on their end.

Peter Matulis <petermatulis@yahoo.ca> wrote in message news:<coh6j05oujcn5h19j3ce5cf7l9ub9f7bp1@4ax.com>. ..
> On Sun, 29 Aug 2004 17:18:18 GMT, Tony Paulic
> <tpaulic@gateway.paulic.home> wrote:
>
> >I am running OpenBSD 3.5 and have a sympatico ADSL connection. I have been running
> >OpenBSD for almost 2 years now with no problems. Recently, when my ADSL connection
> >"hangs"
>
> [...]
>
> >2) Any ideas on what may be happening?
>
> Ask the sympatico people if they changed anything on their end.

I have the same problem (openbsd 3.4), more than 2 years whitout any
problem.

I just asked then if they change something and they say nothing as
change.

No help over there, only support widoze and Mac

I've got this in the log file: "tun0: Phase: deflink: Already in
NETWORK phase", back to the Man Page

Tony Paulic wrote:
> I am running OpenBSD 3.5 and have a sympatico ADSL connection.

I'm in Manitoba and MTS/Sympatico is here so here are my conf's in case
we are on the same (or similar) network as I have no problems.

But, you may want to get your line checked for noise. A while back I
had some interesting issues and the problem was too much line noise, or
so they said. The problems only started after my little ISP (which
supported the *BSD's) sold there accounts to MTS (which doesn't).
Coincidence, I think not. So, your ISP may have changed something that
had an unintended affect. Or I just may be talking out of my...

Anyway, here's the conf's.

rc.local:
if [ -x /usr/sbin/pppoe ]; then
echo "starting pppoe"
/usr/sbin/ppp -ddial pppoe &
fi

#the wait here is so that tun0 gets an ip before pf
# does its thing. errors abound if no wait
echo "waiting 5 seconds for net connect"
sleep 5

if [ -e /etc/pf.conf ]; then
if [ -x /sbin/pfctl ]; then
echo "loading pf rules"
/sbin/pfctl -e -f /etc/pf.conf
fi
fi

ppp.conf:
default:
set log Phase Chat LCP IPCP CCP tun command
set redial 15 0
set reconnect 15 10000

pppoe:
set device "!/usr/sbin/pppoe -n Shasta_1 -i dc0"
set mtu max 1452
set speed sync
disable acfcomp protocomp
deny acfcomp
enable lqr
set lqrperiod 5
set cd 5
set dial
set login
set timeout 0
set authname xxxx
set authkey xxxx
add! default HISADDR
enable dns
enable mssfixup


I also had problems with my nat not routing anything. Adding this to my
pf rules resolved that issue:

scrub in all max-mss 1452
scrub out all max-mss 1452

On Tue, 14 Sep 2004 16:42:33 -0500, Reid Nichol
<rnichol_rrc@yahoo.com> wrote:

[...]

>So, your ISP may have changed something that
>had an unintended affect. Or I just may be talking out of my...

[...]

> set mtu max 1452

[...]

>I also had problems with my nat not routing anything. Adding this to my
>pf rules resolved that issue:
>
>scrub in all max-mss 1452
>scrub out all max-mss 1452

You seem to be treating MTU and MSS as the same thing. They're not.

For PPPoE the MTU should be around 48 bytes larger than the MSS value.

/pm

Peter Matulis wrote:
> You seem to be treating MTU and MSS as the same thing. They're not.
>
> For PPPoE the MTU should be around 48 bytes larger than the MSS value.

I got that suggestion a while back from someone on this newsgroup. And
although it worked I only conjectured why it worked. So, question:

Is the 48 bytes extra because of some extra headers that PPPoE needs?

My assumption was backwards here. I would assume that MSS would need to
be the bigger one. Could you shed some light on this?

Or provide a link please?

On Tue, 14 Sep 2004 21:07:06 -0500, Reid Nichol
<rnichol_rrc@yahoo.com> wrote:

>Peter Matulis wrote:
>> You seem to be treating MTU and MSS as the same thing. They're not.
>>
>> For PPPoE the MTU should be around 48 bytes larger than the MSS value.
>
>I got that suggestion a while back from someone on this newsgroup. And
>although it worked I only conjectured why it worked. So, question:
>
>Is the 48 bytes extra because of some extra headers that PPPoE needs?

The MSS is a TCP value that is agreed upon during the TCP handshake.
It does not take into account the TCP header and since IP encapsulates
TCP it also does not take into account the IP header. Each of these
headers is 20 bytes each if their options fields are not used (which
are rarely used to my understanding). The PPPoE encapsulates IP and
this requires an extra 8 bytes. So that's the 48 bytes.

>My assumption was backwards here. I would assume that MSS would need to
>be the bigger one.

Why did you assume this?

> Could you shed some light on this?

You can determine your MTU using the ICMP protocol. Do this by
employing the ping command. Ping some internet server and stipulate
no fragmentation as well as the IP payload size.

In the first example a payload of 1473 bytes is too large:

$ ping -q -c 1 -D -s 1473 yahoo.ca
PING yahoo.ca (66.218.71.198): 1473 data bytes
ping: sendto: Message too long
ping: wrote yahoo.ca 1501 chars, ret=-1
--- yahoo.ca ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss

In this second example a payload of one byte less passes into the
TCP/IP stack of the destination host without difficulty:

$ ping -q -c 1 -D -s 1472 yahoo.ca
PING yahoo.ca (66.218.71.198): 1472 data bytes
--- yahoo.ca ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 806.500/806.500/806.500/0.000 ms

Since we are specifying payloads, in order to determine the actual MTU
we need to add 20 bytes for an IP header (without any options set) and
8 bytes for ICMP echo message data (strictly speaking there is no such
thing as an ICMP header; for echo we have the type field [1 byte];
code field [1 byte]; checksum field [2 bytes]; identifier field [2
bytes]; and sequence number field [2 bytes]). So in the example the
MTU is 1472 + 28 = 1500.

Now for PPPoE the additional 8 bytes are added after the operating
system has originated the packet. So the ping command and the
underlying operating system have no knowledge of PPPoE. This means
that you will need to probably use a payload of 1464 for this test.

Caveat: for OpenBSD's ping command, when specifying DF (don't
fragment; the -D switch) it appears that the 8 ICMP bytes are included
in the specified IP payload. This suggests that we should only add 20
bytes to the payload and not 28 but this doesn't agree with my packet
capture results (I *do* need to add 28).

Can anyone concur any of this stuff?

/pm

On 15/09/2004 3:35 AM, Peter Matulis wrote:

[...]
>
> You can determine your MTU using the ICMP protocol. Do this by
> employing the ping command. Ping some internet server and stipulate
> no fragmentation as well as the IP payload size.
>
> In the first example a payload of 1473 bytes is too large:
>
> $ ping -q -c 1 -D -s 1473 yahoo.ca
> PING yahoo.ca (66.218.71.198): 1473 data bytes
> ping: sendto: Message too long
> ping: wrote yahoo.ca 1501 chars, ret=-1
> --- yahoo.ca ping statistics ---
> 1 packets transmitted, 0 packets received, 100.0% packet loss
>
> In this second example a payload of one byte less passes into the
> TCP/IP stack of the destination host without difficulty:
>
> $ ping -q -c 1 -D -s 1472 yahoo.ca
> PING yahoo.ca (66.218.71.198): 1472 data bytes
> --- yahoo.ca ping statistics ---
> 1 packets transmitted, 1 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 806.500/806.500/806.500/0.000 ms
>
Cool. I've put that in my network toolkit for future use.

> Since we are specifying payloads, in order to determine the actual MTU
> we need to add 20 bytes for an IP header (without any options set) and
> 8 bytes for ICMP echo message data (strictly speaking there is no such
> thing as an ICMP header; for echo we have the type field [1 byte];
> code field [1 byte]; checksum field [2 bytes]; identifier field [2
> bytes]; and sequence number field [2 bytes]). So in the example the
> MTU is 1472 + 28 = 1500.
>
> Now for PPPoE the additional 8 bytes are added after the operating
> system has originated the packet. So the ping command and the
> underlying operating system have no knowledge of PPPoE. This means
> that you will need to probably use a payload of 1464 for this test.
>
Thanks for the clear description.

Just so my own understanding of this is correct, I came up with an MTU
of 1492 (1464 + 28) which I set in my ppp.conf via "set mtu max ...",
along with "enable mssfixup" to tell ppp to adjust the MSS to no greater
than the MTU.

That is, I want things set such that my tun0 device reports an mtu of
1492, given that the ping tests above return 0% packet loss at an MTU of
1464, but fail at 1465.

Does this sound reasonable?

On Wed, 15 Sep 2004 12:10:30 -0400, clvrmnky
<clvrmnky-uunet@coldmail.com.invalid> wrote:

>Just so my own understanding of this is correct, I came up with an MTU
>of 1492 (1464 + 28) which I set in my ppp.conf via "set mtu max ...",
>along with "enable mssfixup" to tell ppp to adjust the MSS to no greater
>than the MTU.
>
>That is, I want things set such that my tun0 device reports an mtu of
>1492, given that the ping tests above return 0% packet loss at an MTU of
>1464, but fail at 1465.
>
>Does this sound reasonable?

Yes it does.

You may want to set the MRU along with the MTU (yes, there is an MRU)
since the MRU default is the same as the MTU default: 1500. The MRU
(maximum receive unit) is essentially the same as the MTU (maximum
transmit unit).

So add:

set mru max 1492

Keep in mind what "enable mssfixup" really does. The ppp man page is
not very clear:

[tcp]mssfixup
Default: Enabled. This option tells ppp to adjust TCP
SYN packets so that the maximum receive segment size is not
greater than the amount allowed by the interface MTU.

Is it talking about MRU or MSS? Most sites say that what this does is
adjust the MTU of internal lan clients who are presumably on straight
Ethernet (i.e. MTU = 1500) to the proper value of your PPPoE MTU. The
alternative would be to adjust the MTU values of all internal clients.

A problem related to this discussion may interest you. It is called
the Path MTU Discovery Black Hole and is well described here:

http://www.usenix.org/events/lisa02/...nderberg_html/

/pm