* Re: LCP Renegotiates After IP Connection
2008-04-01 20:57 LCP Renegotiates After IP Connection Tyler Sutherland
@ 2008-04-01 21:44 ` Bill Unruh
2008-04-01 21:53 ` James Cameron
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Bill Unruh @ 2008-04-01 21:44 UTC (permalink / raw)
To: linux-ppp
On Tue, 1 Apr 2008, Tyler Sutherland wrote:
> Hi There,
>
> I have a situation where I'm trying to maintain a PPP connection from my
> Linux PC to an embedded Linux device.
>
> I am able to get the PPP connection working such that each end has an IP
> address and I can ping the other end for twenty seconds, but then I
> receive an [LCP ConfReq] packet and the PPP connection sets itself up
What packet do you receive? And from where--- the embedded device?
Show us the output ( put debug into /etc/ppp/options, and
daemon.*;local2.* /var/log/daemonlog
into /etc/syslog.conf
and then do
killall -1 syslogd
> again. This interrupts the IP connection and breaks my ability to ping.
>
> I'm trying to figure out why this is happening, because I want to have a
> stable PPP connection. If someone can help me I'd appreciate it very
> much.
>
> The embedded device seems to want to restart the connection every 20
> seconds. This is what the pppd debug log looks like from my end:
>
> ~ # pppd nodetach file /etc/ppp/options.pppUSB1
> pppd options in effect:
> nodetach # (from command line)
> debug # (from /etc/ppp/options.pppUSB1)
> dump # (from /etc/ppp/options.pppUSB1)
This is there why?
> noauth # (from /etc/ppp/options.pppUSB1)
> /dev/ttyUSB1 # (from /etc/ppp/options.pppUSB1)
> 57600 # (from /etc/ppp/options.pppUSB1)
> lock # (from /etc/ppp/options.pppUSB1)
> noaccomp # (from /etc/ppp/options.pppUSB1)
> asyncmap ffffffff # (from /etc/ppp/options.pppUSB1)
> nopcomp # (from /etc/ppp/options.pppUSB1)
> 10.2.10.5:10.2.10.20 # (from /etc/ppp/options.pppUSB1)
> nobsdcomp # (from /etc/ppp/options.pppUSB1)
> nodeflate # (from /etc/ppp/options.pppUSB1)
> using channel 18
????
> Using interface ppp0
> Connect: ppp0 <--> /dev/ttyUSB1
> sent [LCP ConfReq id=0x1 <magic 0x913429f5>]
> rcvd [LCP ConfAck id=0x1 <magic 0x913429f5>]
> sent [LCP ConfReq id=0x1 <magic 0x913429f5>]
> rcvd [LCP ConfAck id=0x1 <magic 0x913429f5>]
> sent [LCP ConfReq id=0x1 <magic 0x913429f5>]
> rcvd [LCP ConfAck id=0x1 <magic 0x913429f5>]
> sent [LCP ConfReq id=0x1 <magic 0x913429f5>]
> rcvd [LCP ConfAck id=0x1 <magic 0x913429f5>]
> sent [LCP ConfReq id=0x1 <magic 0x913429f5>]
> rcvd [LCP ConfAck id=0x1 <magic 0x913429f5>]
Those are all just refections. Ie you are talking to yourself.
> rcvd [LCP ConfReq id=0x6c <asyncmap 0x0> <magic 0xa5a44a5a>]
> sent [LCP ConfAck id=0x6c <asyncmap 0x0> <magic 0xa5a44a5a>]
They say asyncmap 0, why do you have asyncmap fffffff in your options?
> sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 10.2.10.5>]
> sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 10.2.10.5>]
> rcvd [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 10.2.10.5>]
> rcvd [IPCP ConfReq id=0x6d <addr 10.2.10.20>]
> sent [IPCP ConfAck id=0x6d <addr 10.2.10.20>]
> local IP address 10.2.10.5
> remote IP address 10.2.10.20
>
> (there's 20 seconds here where I can ping the other side.)
>
> rcvd [LCP ConfReq id=0x6e <asyncmap 0x0> <magic 0xa5a44a5a>]
Well, since they are demanding asyncmap 0 maybe they are upset that you
never said you were willing to have asyncmap 0. Remove that option from
your list of options, and replace with asyncmap 0
> Connect time 0.3 minutes.
> Sent 0 bytes, received 0 bytes.
> sent [LCP ConfReq id=0x2 <magic 0x1cba1779>]
> sent [LCP ConfAck id=0x6e <asyncmap 0x0> <magic 0xa5a44a5a>]
> rcvd [LCP ConfAck id=0x2 <magic 0x1cba1779>]
> sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 10.2.10.5>]
> sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 10.2.10.5>]
> rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 10.2.10.5>]
> rcvd [IPCP ConfReq id=0x6f <addr 10.2.10.20>]
> sent [IPCP ConfAck id=0x6f <addr 10.2.10.20>]
> local IP address 10.2.10.5
> remote IP address 10.2.10.20
>
> (there's 20 seconds here where I can ping the other side.)
>
> rcvd [LCP ConfReq id=0x70 <asyncmap 0x0> <magic 0xa5a44a5a>]
> Connect time 0.3 minutes.
> Sent 0 bytes, received 0 bytes.
> sent [LCP ConfReq id=0x3 <magic 0xf53f0cb6>]
> sent [LCP ConfAck id=0x70 <asyncmap 0x0> <magic 0xa5a44a5a>]
> rcvd [LCP ConfAck id=0x3 <magic 0xf53f0cb6>]
> sent [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 10.2.10.5>]
> sent [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 10.2.10.5>]
> rcvd [IPCP ConfAck id=0x3 <compress VJ 0f 01> <addr 10.2.10.5>]
> rcvd [IPCP ConfReq id=0x71 <addr 10.2.10.20>]
> sent [IPCP ConfAck id=0x71 <addr 10.2.10.20>]
> local IP address 10.2.10.5
> remote IP address 10.2.10.20
>
> (and it repeats to inifinity.)
>
> Any ideas would be great.
>
> Thanks,
>
> Tyler
> tsutherland@iders.ca
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324
UBC, Vancouver,BC | Program in Cosmology | unruh@physics.ubc.ca
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: LCP Renegotiates After IP Connection
2008-04-01 20:57 LCP Renegotiates After IP Connection Tyler Sutherland
2008-04-01 21:44 ` Bill Unruh
@ 2008-04-01 21:53 ` James Cameron
2008-04-01 22:05 ` James Carlson
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: James Cameron @ 2008-04-01 21:53 UTC (permalink / raw)
To: linux-ppp
G'day Tyler,
I've had that situation on a Maxon MM-5100 USB CDMA modem. An LCP
ConfReq packet appears out of the blue. My prior postings on that in
early 2005 here ... determined that pppd is reacting properly, and that
you have to find a way to prevent the packet from appearing.
(In my case the triggering condition was to send a packet out the
interface that had a source IP address different to that negotiated.
Once I added iptables rules to block such packets, the trigger was
removed.)
So for a wild guess, use tcpdump to ensure that nothing unexpected is
being sent out your new network interface.
Now, looking at your log in more detail ... I'm surprised that you get
an LCP ConfReq and ConfAck sequence up front consisting of 10 pairs of
packets, each with the same id and magic number. It is as if the
embedded device is echoing the packets back to your host. But I thought
pppd had code to detect that, and there's no sign of that detection
triggering.
I suggest you use the record option and use pppdump or wireshark on the
result, so as to find out what is happening.
Other than that ... sounds like the embedded device wants something
different. If it works in a stable fashion with something else, a dump
of that data stream may be handy for comparison.
--
James Cameron http://quozl.netrek.org/
HP Open Source, Volunteer http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: LCP Renegotiates After IP Connection
2008-04-01 20:57 LCP Renegotiates After IP Connection Tyler Sutherland
2008-04-01 21:44 ` Bill Unruh
2008-04-01 21:53 ` James Cameron
@ 2008-04-01 22:05 ` James Carlson
2008-04-01 23:18 ` Bill Unruh
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: James Carlson @ 2008-04-01 22:05 UTC (permalink / raw)
To: linux-ppp
James Cameron writes:
> Now, looking at your log in more detail ... I'm surprised that you get
> an LCP ConfReq and ConfAck sequence up front consisting of 10 pairs of
> packets, each with the same id and magic number. It is as if the
That's not a pppd problem. We're sending Configure-Request (over and
over on the normal restart timer), and the peer is sending
Configure-Ack each time, but isn't bothering to send
Configure-Request.
The peer is either confused or broken. Based on the combination of
symptoms, that's not too surprising.
> embedded device is echoing the packets back to your host.
No, it's not. It's sending Configure-Ack in response. I don't see
anything wrong here, other than the fact that we're stuck in AckRcvd
state because the peer won't send Configure-Request.
> But I thought
> pppd had code to detect that, and there's no sign of that detection
> triggering.
There's no loopback here, so nothing to detect.
> I suggest you use the record option and use pppdump or wireshark on the
> result, so as to find out what is happening.
>
> Other than that ... sounds like the embedded device wants something
> different. If it works in a stable fashion with something else, a dump
> of that data stream may be handy for comparison.
I guess it depends on your tolerance level for broken devices and how
much you value your time. ;-}
--
James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: LCP Renegotiates After IP Connection
2008-04-01 20:57 LCP Renegotiates After IP Connection Tyler Sutherland
` (2 preceding siblings ...)
2008-04-01 22:05 ` James Carlson
@ 2008-04-01 23:18 ` Bill Unruh
2008-04-02 11:09 ` James Carlson
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Bill Unruh @ 2008-04-01 23:18 UTC (permalink / raw)
To: linux-ppp
On Tue, 1 Apr 2008, James Carlson wrote:
> James Cameron writes:
>> Now, looking at your log in more detail ... I'm surprised that you get
>> an LCP ConfReq and ConfAck sequence up front consisting of 10 pairs of
>> packets, each with the same id and magic number. It is as if the
>
> That's not a pppd problem. We're sending Configure-Request (over and
Who is we? Are you part of this or is this a sort of royal we?
> over on the normal restart timer), and the peer is sending
> Configure-Ack each time, but isn't bothering to send
> Configure-Request.
Sould not your side start to send a ConfReq with something other than
magic?
>
> The peer is either confused or broken. Based on the combination of
> symptoms, that's not too surprising.
>
>> embedded device is echoing the packets back to your host.
>
> No, it's not. It's sending Configure-Ack in response. I don't see
> anything wrong here, other than the fact that we're stuck in AckRcvd
> state because the peer won't send Configure-Request.
>
>> But I thought
>> pppd had code to detect that, and there's no sign of that detection
>> triggering.
>
> There's no loopback here, so nothing to detect.
>
>> I suggest you use the record option and use pppdump or wireshark on the
>> result, so as to find out what is happening.
>>
>> Other than that ... sounds like the embedded device wants something
>> different. If it works in a stable fashion with something else, a dump
>> of that data stream may be handy for comparison.
>
> I guess it depends on your tolerance level for broken devices and how
> much you value your time. ;-}
Or the pressure to make it work by higherups.
>
>
--
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324
UBC, Vancouver,BC | Program in Cosmology | unruh@physics.ubc.ca
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: LCP Renegotiates After IP Connection
2008-04-01 20:57 LCP Renegotiates After IP Connection Tyler Sutherland
` (3 preceding siblings ...)
2008-04-01 23:18 ` Bill Unruh
@ 2008-04-02 11:09 ` James Carlson
2008-04-02 15:38 ` Bill Unruh
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: James Carlson @ 2008-04-02 11:09 UTC (permalink / raw)
To: linux-ppp
Bill Unruh writes:
> On Tue, 1 Apr 2008, James Carlson wrote:
>
> > James Cameron writes:
> >> Now, looking at your log in more detail ... I'm surprised that you get
> >> an LCP ConfReq and ConfAck sequence up front consisting of 10 pairs of
> >> packets, each with the same id and magic number. It is as if the
> >
> > That's not a pppd problem. We're sending Configure-Request (over and
>
> Who is we? Are you part of this or is this a sort of royal we?
"We" are the local node for which the original poster supplied logs.
"They" are the other node -- the one that doesn't speak PPP so well
and for which we have no logs.
I can certainly use other words if those two offend you in some way.
> > over on the normal restart timer), and the peer is sending
> > Configure-Ack each time, but isn't bothering to send
> > Configure-Request.
>
> Sould not your side start to send a ConfReq with something other than
> magic?
No.
When "we" send the very first Configure-Request, we're in Req-Sent
state. We then get Configure-Ack from the peer, and we enter Ack-Rcvd
state. The peer does nothing, and time passes. Eventually, after 3
seconds by default, we get TO+. That (per the state machine) causes
us to invoke action "scr" -- Send-Configure-Request -- and return to
Req-Sent state, and the cycle starts over.
If you read section 5.1 ("Configure-Request") of RFC 1661, it
discusses how the Identifier is chosen, and explains that
implementations are permitted to leave the ID field unchanged.
Retransmit can be exactly that: retransmit, don't generate a new one
from scratch. That's how pppd does it.
The fail-safe here is TO-, the maximum restart count. If we hit that,
we fail with the familiar "LCP: timeout sending Config-Requests"
message.
In other words, the problem in the following sequence (shown by the
original poster) is not in pppd; it's in the peer that isn't bothering
to send Configure-Request, even though it's (inexplicably) able to
respond with Configure-Ack. My guess is that it has severe
implementation flaws, and thus should not be used if the data to be
carried or the time or health of the users are at all valuable.
sent [LCP ConfReq id=0x1 <magic 0x913429f5>]
rcvd [LCP ConfAck id=0x1 <magic 0x913429f5>]
sent [LCP ConfReq id=0x1 <magic 0x913429f5>]
rcvd [LCP ConfAck id=0x1 <magic 0x913429f5>]
(But do feel free to press on if seeing grotesque bugs doesn't make
you wary.)
> > I guess it depends on your tolerance level for broken devices and how
> > much you value your time. ;-}
>
> Or the pressure to make it work by higherups.
"No problem. Here's a purchase order for a different device that
actually implements PPP rather than just claiming to ..."
:-/
--
James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: LCP Renegotiates After IP Connection
2008-04-01 20:57 LCP Renegotiates After IP Connection Tyler Sutherland
` (4 preceding siblings ...)
2008-04-02 11:09 ` James Carlson
@ 2008-04-02 15:38 ` Bill Unruh
2008-04-02 16:09 ` James Carlson
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Bill Unruh @ 2008-04-02 15:38 UTC (permalink / raw)
To: linux-ppp
On Wed, 2 Apr 2008, James Carlson wrote:
> Bill Unruh writes:
>> On Tue, 1 Apr 2008, James Carlson wrote:
>>
>>> James Cameron writes:
>>>> Now, looking at your log in more detail ... I'm surprised that you get
>>>> an LCP ConfReq and ConfAck sequence up front consisting of 10 pairs of
>>>> packets, each with the same id and magic number. It is as if the
>>>
>>> That's not a pppd problem. We're sending Configure-Request (over and
>>
>> Who is we? Are you part of this or is this a sort of royal we?
>
> "We" are the local node for which the original poster supplied logs.
> "They" are the other node -- the one that doesn't speak PPP so well
> and for which we have no logs.
Since "James Cameron" was not the original poster, your suddenly using "we"
was confusing. It was not at all clear that you were in any way related to
the original poster, and it was not clear whether your descriptions were
hypothetical or based on some facts.
>
> I can certainly use other words if those two offend you in some way.
Nope, clarification is sufficient. So when you make statements as to what
happens in the negotiation attempts, we are to take them as having some
basis in fact and personal experience.
>
>>> over on the normal restart timer), and the peer is sending
>>> Configure-Ack each time, but isn't bothering to send
>>> Configure-Request.
>>
>> Sould not your side start to send a ConfReq with something other than
>> magic?
>
> No.
>
> When "we" send the very first Configure-Request, we're in Req-Sent
> state. We then get Configure-Ack from the peer, and we enter Ack-Rcvd
> state. The peer does nothing, and time passes. Eventually, after 3
> seconds by default, we get TO+. That (per the state machine) causes
> us to invoke action "scr" -- Send-Configure-Request -- and return to
> Req-Sent state, and the cycle starts over.
>
> If you read section 5.1 ("Configure-Request") of RFC 1661, it
> discusses how the Identifier is chosen, and explains that
> implementations are permitted to leave the ID field unchanged.
> Retransmit can be exactly that: retransmit, don't generate a new one
> from scratch. That's how pppd does it.
Can be. But why make it so.
>
> The fail-safe here is TO-, the maximum restart count. If we hit that,
> we fail with the familiar "LCP: timeout sending Config-Requests"
> message.
>
> In other words, the problem in the following sequence (shown by the
> original poster) is not in pppd; it's in the peer that isn't bothering
> to send Configure-Request, even though it's (inexplicably) able to
> respond with Configure-Ack. My guess is that it has severe
> implementation flaws, and thus should not be used if the data to be
> carried or the time or health of the users are at all valuable.
Probably true. What is that "other side"? Maybe someone here has experience
with it, rather than everyone having to guess at what is going on.
>
> sent [LCP ConfReq id=0x1 <magic 0x913429f5>]
> rcvd [LCP ConfAck id=0x1 <magic 0x913429f5>]
> sent [LCP ConfReq id=0x1 <magic 0x913429f5>]
> rcvd [LCP ConfAck id=0x1 <magic 0x913429f5>]
>
> (But do feel free to press on if seeing grotesque bugs doesn't make
> you wary.)
>
>>> I guess it depends on your tolerance level for broken devices and how
>>> much you value your time. ;-}
>>
>> Or the pressure to make it work by higherups.
>
> "No problem. Here's a purchase order for a different device that
> actually implements PPP rather than just claiming to ..."
Then I would follow that. Agreed. But it could have been "We just purchased
5000 of those things at a really cheap non-returnable deal. You better make
them work."
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: LCP Renegotiates After IP Connection
2008-04-01 20:57 LCP Renegotiates After IP Connection Tyler Sutherland
` (5 preceding siblings ...)
2008-04-02 15:38 ` Bill Unruh
@ 2008-04-02 16:09 ` James Carlson
2008-04-02 21:30 ` James Cameron
2008-04-03 4:13 ` Paul Mackerras
8 siblings, 0 replies; 10+ messages in thread
From: James Carlson @ 2008-04-02 16:09 UTC (permalink / raw)
To: linux-ppp
Bill Unruh writes:
> > I can certainly use other words if those two offend you in some way.
>
> Nope, clarification is sufficient. So when you make statements as to what
> happens in the negotiation attempts, we are to take them as having some
> basis in fact and personal experience.
Or perhaps with reference to the original poster's message ... ?
> > If you read section 5.1 ("Configure-Request") of RFC 1661, it
> > discusses how the Identifier is chosen, and explains that
> > implementations are permitted to leave the ID field unchanged.
> > Retransmit can be exactly that: retransmit, don't generate a new one
> > from scratch. That's how pppd does it.
>
> Can be. But why make it so.
Because that's how pppd works. See fsm_timeout(), and the
REQSENT/ACKRCVD/ACKSENT states. These call fsm_sconfreq(f, 1), which
then tells fsm_sconfreq() to avoid generating a new ID.
The FSM also invokes the `retransmit' callback when it processes the
TO+ event, so it's possible for xCP implementations to alter the
packet before resending. In lcp_callbacks, though, this function
pointer is NULL, meaning that LCP does nothing to alter the packet on
retransmit.
I checked the CVS repository, and this logic dates back to at least
1993 when the code was first imported to CVS. I suspect it dates back
much further, probably to the mid-80's original Carnegie-Mellon
implementation.
> Probably true. What is that "other side"? Maybe someone here has experience
> with it, rather than everyone having to guess at what is going on.
The original poster claims this:
I have a situation where I'm trying to maintain a PPP connection from my
Linux PC to an embedded Linux device.
I have my doubts about the peer being a "Linux" device. If it is, it
looks like it's been extensively hacked by the vendor (it sure doesn't
behave like normal pppd), and he should probably contact them for
help.
> > "No problem. Here's a purchase order for a different device that
> > actually implements PPP rather than just claiming to ..."
>
> Then I would follow that. Agreed. But it could have been "We just purchased
> 5000 of those things at a really cheap non-returnable deal. You better make
> them work."
"It's a darned shame our acceptance testing and product evaluation
process is so shoddy, isn't it? Oh well. It's like all other
reviews; you can pay me now or pay me later, but it'll cost much more
later."
--
James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: LCP Renegotiates After IP Connection
2008-04-01 20:57 LCP Renegotiates After IP Connection Tyler Sutherland
` (6 preceding siblings ...)
2008-04-02 16:09 ` James Carlson
@ 2008-04-02 21:30 ` James Cameron
2008-04-03 4:13 ` Paul Mackerras
8 siblings, 0 replies; 10+ messages in thread
From: James Cameron @ 2008-04-02 21:30 UTC (permalink / raw)
To: linux-ppp
On Wed, Apr 02, 2008 at 12:09:46PM -0400, James Carlson wrote:
> Bill Unruh writes:
> [...]
Chuckle. But I understand better now, thanks.
I'd love to know what this embedded device is so that I can add it to my
list of "don't buy, sounds dodgy". ;-)
--
James Cameron
http://ftp.hp.com.au/sigs/jc/
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: LCP Renegotiates After IP Connection
2008-04-01 20:57 LCP Renegotiates After IP Connection Tyler Sutherland
` (7 preceding siblings ...)
2008-04-02 21:30 ` James Cameron
@ 2008-04-03 4:13 ` Paul Mackerras
8 siblings, 0 replies; 10+ messages in thread
From: Paul Mackerras @ 2008-04-03 4:13 UTC (permalink / raw)
To: linux-ppp
Bill Unruh writes:
> > If you read section 5.1 ("Configure-Request") of RFC 1661, it
> > discusses how the Identifier is chosen, and explains that
> > implementations are permitted to leave the ID field unchanged.
> > Retransmit can be exactly that: retransmit, don't generate a new one
> > from scratch. That's how pppd does it.
>
> Can be. But why make it so.
The main reason I made it like this is that this way, it has some
chance of working on a link where the round-trip latency is more than
the retransmit interval.
> Then I would follow that. Agreed. But it could have been "We just purchased
> 5000 of those things at a really cheap non-returnable deal. You better make
> them work."
Then you hack pppd for that particular situation (you have the source,
after all), but you don't pretend that your hack is necessarily a good
thing for everyone to use.
Paul.
^ permalink raw reply [flat|nested] 10+ messages in thread