They seem to be RFC 1662 encoded PPP frames.
I was too lazy to see if CRC's match.
A frame is delimited by 0x7e characters. I there are
back-to-back frames, only one delimiter is enough.
0x7d is an escape character, telling that the next byte
is to exclusive-or'ed witc 0x20.
--
-TV
On 19.3.19 22:09, jumpjack wrote:
> ..is this thread too old to have a reply? :-)
> It looks like it's quite hatd to figure out what's going on with my G600
> GSM/GPRS module: I have SIMILAR data, but how to decode them?
> MCU to modem:
> 7E 3F 7D 23 3F 21 7D 21 7D 21 7D 20 7D 34 7D 22 7D 26 7D 20 7D 20 7D 20 7D
> 20 7D 25 7D 26 65 67 6C 6A 7D
>
> Response:
> 7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D
> 20 7D 23 7D 24 C0 23 7D 27 7DÂ
>
> Why these slight differences?
>
> Full sequence sent:
> [code]
> 7E3F7D233F21
> 7D217D217D207D347D227D267D207D
> 207D207D207D257D2665676C6A7D277D
> 227D287D223F6D7E
> 7E3F
> 7D233F217D227D217D207D327D227D26
> 7D207D207D207D207D237D243F237D
> 277D227D287D223F3F7E
> 7E3F230102475052537E3F7D233F217D217D23
> 7D207D2E7D227D267D207D207D207D
> 207D277D227D287D222A3F7E
> 7E3F2301047E
> 7E3F2101057E3F2101062F7E
> 7E3F21010703067E3F2102017E3F2101083F3F7E
> 7E21453F04
> 5F6E3F16042D073F0102080928083F617E
> 7E2145
> 3F04
> 5F6E3F160478053F010104026C737E
> 7E2145303F160402203F3F7E
> 7E2145
> 7D5D
> 3F04
> 5F6E3F1604123456780204053F010104024A677E
> 7E21456E3F16047002203F3F7E
> 7E214506
> 7B
> 3F04
> 5F6E3F1604123456787E21
> 455F6E3F160404023F3F7E
> 7E21450B3F123456787E
> 214504
> 5F6E3F16040104023F3F7E
> 7E21453F717E21453F04
> 5F6E3F16043F01010402493A7E
> 7E2145047E
> 7E214574
> 3F04
> 5F6E3F160478053F010104026F2E7E
> 7E2145303F160402203F7E[/code]
>
> Full response:
> [code]
> 7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D
> 20 7D 23 7D 24 C0 23 7D 27 7D 22 7D 28 7D 22 DD 94 7E 7E FF 7D 23 C0 21 7D
> 24 7D 21 7D 20 7D 2A 7D 25 7D 26 65 67 6C 6A 60 85 7E 7E FF 7D 23 C0 21 7D
> 22 7D 23 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28
> 7D 22 7D 34 BC 7E 7E C0 23 02 04 00 05 00 AA 5E 7E 7E 80 21 03 05
> 00030600000000C6A17E7E8021030600030600000000C1777E7E802101010004BB997E7E80210307000306B506E685837E7E80210208000306B506E68A397E
> [/code]
>
>
>
> ---------------------------------------
> Posted through http://www.EmbeddedRelated.com
>
Reply by jumpjack●March 19, 20192019-03-19
..is this thread too old to have a reply? :-)
It looks like it's quite hatd to figure out what's going on with my G600
GSM/GPRS module: I have SIMILAR data, but how to decode them?
MCU to modem:
7E 3F 7D 23 3F 21 7D 21 7D 21 7D 20 7D 34 7D 22 7D 26 7D 20 7D 20 7D 20 7D
20 7D 25 7D 26 65 67 6C 6A 7D
Response:
7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D
20 7D 23 7D 24 C0 23 7D 27 7D
Why these slight differences?
Full sequence sent:
[code]
7E3F7D233F21
7D217D217D207D347D227D267D207D
207D207D207D257D2665676C6A7D277D
227D287D223F6D7E
7E3F
7D233F217D227D217D207D327D227D26
7D207D207D207D207D237D243F237D
277D227D287D223F3F7E
7E3F230102475052537E3F7D233F217D217D23
7D207D2E7D227D267D207D207D207D
207D277D227D287D222A3F7E
7E3F2301047E
7E3F2101057E3F2101062F7E
7E3F21010703067E3F2102017E3F2101083F3F7E
7E21453F04
5F6E3F16042D073F0102080928083F617E
7E2145
3F04
5F6E3F160478053F010104026C737E
7E2145303F160402203F3F7E
7E2145
7D5D
3F04
5F6E3F1604123456780204053F010104024A677E
7E21456E3F16047002203F3F7E
7E214506
7B
3F04
5F6E3F1604123456787E21
455F6E3F160404023F3F7E
7E21450B3F123456787E
214504
5F6E3F16040104023F3F7E
7E21453F717E21453F04
5F6E3F16043F01010402493A7E
7E2145047E
7E214574
3F04
5F6E3F160478053F010104026F2E7E
7E2145303F160402203F7E[/code]
Full response:
[code]
7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D
20 7D 23 7D 24 C0 23 7D 27 7D 22 7D 28 7D 22 DD 94 7E 7E FF 7D 23 C0 21 7D
24 7D 21 7D 20 7D 2A 7D 25 7D 26 65 67 6C 6A 60 85 7E 7E FF 7D 23 C0 21 7D
22 7D 23 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28
7D 22 7D 34 BC 7E 7E C0 23 02 04 00 05 00 AA 5E 7E 7E 80 21 03 05
00030600000000C6A17E7E8021030600030600000000C1777E7E802101010004BB997E7E80210307000306B506E685837E7E80210208000306B506E68A397E
[/code]
---------------------------------------
Posted through http://www.EmbeddedRelated.com
To keep it simple:
As a customer of Round Solutions you will enjoy a huge community based
on the biggest GSM module user forum in the Internet with FAQ and a lot
of postings. You will get factory support and you will see that users
help users as well. You will stay in a community with more then 2100
members around the world. A big "technical family" that grows each day.
Regards
Meff
www.gsm-modem.de
P.S: I am the admin of the Round Solutions forum.
Reply by Stef●January 19, 20062006-01-19
In comp.arch.embedded,
Paul Carpenter <paul$@pcserviceselectronics.co.uk> wrote:
>On Thursday, in article <dqofjn$1vvr$1@pyrite.mv.net>
> pklos@osmium.mv.net "Patrick Klos" wrote:
>>
>>Are you sure you have the correct user ID and password for the ISP?? It's
>>a thought...
>
>From the info I have not tried personally there is a username and password
>expected, I suggest you test it and check for capital letters.
>
Always a posibility, but I have got the correct ones. For our vodafone
network it's user:vodafone pass:vodafone. This works with modem in IP mode.
>If you go to this page for a GPRS modem and get the zip file of all
>technical documents, it contains a web page listing of lots of known settings
>for user, password, APN, DNS for various operators and countries.
>
> <http://www.roundsolutions.com/GM862/index.htm>
>
Lots of datasheets there, downloading now, thanks.
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
The little town that time forgot,
Where all the women are strong,
The men are good-looking,
And the children above-average.
-- Prairie Home Companion
Reply by ●January 19, 20062006-01-19
On Thursday, in article <dqofjn$1vvr$1@pyrite.mv.net>
pklos@osmium.mv.net "Patrick Klos" wrote:
>>ATZ
>>AT S0=0 E0
>>AT+CGDCONT=1,"IP","web.vodafone.nl"
>>ATDT*99#
>>
>>But there are many more settings to GPRS.
>
>Are you sure you have the correct user ID and password for the ISP?? It's
>a thought...
From the info I have not tried personally there is a username and password
expected, I suggest you test it and check for capital letters.
If you go to this page for a GPRS modem and get the zip file of all
technical documents, it contains a web page listing of lots of known settings
for user, password, APN, DNS for various operators and countries.
<http://www.roundsolutions.com/GM862/index.htm>
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info
<http://www.badweb.org.uk/> For those web sites you hate
Reply by Stef●January 19, 20062006-01-19
In comp.arch.embedded,
Patrick Klos <pklos@osmium.mv.net> wrote:
>In article <e6643$43cfa4aa$54f63171$17770@publishnet.news-service.com>,
>Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>>In comp.arch.embedded,
>>Patrick Klos <pklos@osmium.mv.net> wrote:
>>>In article <4fdd5$43ced14f$54f63171$12292@publishnet.news-service.com>,
>>>Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>>>The information below looks like a normal basic negotiation. First LCP
>>>is negotiated. Then the peer is authenticated with PAP. Then IPCP is
>>>negotiated. Your client first asks for several options that the "server"
>>>doesn't care for, but they finally swap IP addresses and should be ready
>>>to send IP traffic. Then for some unknown reason, the "server" simply
>>>sends a Terminate-Request to the "client". How long does the whole process
>>>take??
>>>
>>Thanks, but how can you tell?
>
>Years of experience looking at PPP packets! ;^)
>
Ah, that explains it! My experience in this field is a few days. ;-)
>>If I look at RFC1661 and my data, about the
>>only thing I can make sense of is the 'C021' and 'C023', but the data
>>following those does not look like what I expect from RFC1661. If you can
>>point me to a site that explains the data, I'd be very thankfull.
>
>The RFC is the primary source. The frames are pretty straightforward
>once you get used to the FLAG and ESCAPE mechanisms.
>
OK, just keep going then.
>>The whole process takes about 5 seconds.
>>This Terminate-request" is one of last data packets before I get "ERROR"?
>
>Are you aware of any system or device that works with this device and
>ISP correctly? If so, can you get a trace of what it's doing?
>
Yes, and it is..... This modem!
I've had a talk with our local distributor today and it turns out that
there is another AT command set manual for this modem. The one for the
internal IP stack! The datasheet fails to mention the 'minor' fact that
the modem has an IP stack built in. So I can do FTP comms using AT
commands and serial data. No need for IP stack and PPP on the target.
I'm not sure I can do all I need with the internal IP stack, but the
FTP is the most important right now.
So just now I downloaded a file from an ftp server using only
hyperterminal to type a few AT commands.
For now I will continue with the internal stack, but I would like to
get the PPP stuff working at a later stage.
>>With the debug on, there is data loss because it turns off interrupts
>>while printing the messages over another serial port. But when turned
>>on, it mostly complains about invalid FCS for 'C023' and 'C021'
>>packets. But due to the data loss, I do not trust it that much.
>
>Can you modify the debug output to go to a memory buffer instead of the
>serial port (or severely abbreviate the debug messages)??
>
That is what I've already done to log the serial data you saw earlier.
I logged it to a buffer and spit it out in a hex-dump like format when
the connection dies. I've also redirected one debug function to use a
normal serial port that does not stop interrupts, but debug data keeps
coming on that blocking channel from other places in LWIP when debug
is turned on. So I would have to go through all the LWIP sources
to find out where it's coming from.
>>Is there a way to calculate the FCS manually (or programmatically in
>>my debuggging code)? A page discribing how it is calculated would be
>>very welcome.
>
>This page looks reasonable, but I haven't tried it myself:
>
> http://www.netfor2.com/fcs.htm
>
That looks very good indeed. And pressing 'previous' gets me to a page
that I've been looking for for the last few days: A detailed PPP packet
example. Thanks for that link.
>>We now also tried to get this modem (multitech MTSMC-G-F1) to work with
>>windows, but the results are a bit simular. Only thing is that there is
>>about twice as much data between "Welcome!" and "ERROR". But also hangs
>>up after a few seconds.
>
>As others know better than I, GPRS modems can act a little strange.
>Maybe someone else will have some insight on that aspect of your problem?
>
>
Yes, this one seems to need an AT+CGATT=1 to get on the network. And i've
found at least 4 AT commands/dial strings to start the actual connection,
but which is 'right'?
OK, I can do my FTP for now and come back to the PPP when that is done.
Thanks for your help.
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
Cutler Webster's Law:
There are two sides to every argument, unless a person
is personally involved, in which case there is only one.
Reply by Patrick Klos●January 19, 20062006-01-19
In article <e6643$43cfa4aa$54f63171$17770@publishnet.news-service.com>,
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>In comp.arch.embedded,
>Patrick Klos <pklos@osmium.mv.net> wrote:
>>In article <4fdd5$43ced14f$54f63171$12292@publishnet.news-service.com>,
>>Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>>The information below looks like a normal basic negotiation. First LCP
>>is negotiated. Then the peer is authenticated with PAP. Then IPCP is
>>negotiated. Your client first asks for several options that the "server"
>>doesn't care for, but they finally swap IP addresses and should be ready
>>to send IP traffic. Then for some unknown reason, the "server" simply
>>sends a Terminate-Request to the "client". How long does the whole process
>>take??
>>
>Thanks, but how can you tell?
Years of experience looking at PPP packets! ;^)
>If I look at RFC1661 and my data, about the
>only thing I can make sense of is the 'C021' and 'C023', but the data
>following those does not look like what I expect from RFC1661. If you can
>point me to a site that explains the data, I'd be very thankfull.
The RFC is the primary source. The frames are pretty straightforward
once you get used to the FLAG and ESCAPE mechanisms.
>The whole process takes about 5 seconds.
>This Terminate-request" is one of last data packets before I get "ERROR"?
Are you aware of any system or device that works with this device and
ISP correctly? If so, can you get a trace of what it's doing?
>With the debug on, there is data loss because it turns off interrupts
>while printing the messages over another serial port. But when turned
>on, it mostly complains about invalid FCS for 'C023' and 'C021'
>packets. But due to the data loss, I do not trust it that much.
Can you modify the debug output to go to a memory buffer instead of the
serial port (or severely abbreviate the debug messages)??
>Is there a way to calculate the FCS manually (or programmatically in
>my debuggging code)? A page discribing how it is calculated would be
>very welcome.
>We now also tried to get this modem (multitech MTSMC-G-F1) to work with
>windows, but the results are a bit simular. Only thing is that there is
>about twice as much data between "Welcome!" and "ERROR". But also hangs
>up after a few seconds.
As others know better than I, GPRS modems can act a little strange.
Maybe someone else will have some insight on that aspect of your problem?
>So maybe there is a problem with the mode settings? Looking for GPRS
>settings on the net provides me with many different answers, but this
>is what I'm using now:
>
>ATZ
>AT S0=0 E0
>AT+CGDCONT=1,"IP","web.vodafone.nl"
>ATDT*99#
>
>But there are many more settings to GPRS.
Are you sure you have the correct user ID and password for the ISP?? It's
a thought...
Patrick
========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
Patrick Klos Email: patrick@klos.com
Klos Technologies, Inc. Web: http://www.klos.com/
==================== http://www.loving-long-island.com/ ====================
Reply by Stef●January 19, 20062006-01-19
In comp.arch.embedded,
Patrick Klos <pklos@osmium.mv.net> wrote:
>In article <4fdd5$43ced14f$54f63171$12292@publishnet.news-service.com>,
>Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>>
>>For experts in debugging PPP communication, can you make any sense of the
>>following log data? I had to capture sending and receiving to the modem
>>separately, so the below parts should be intermixed.
>
>The information below looks like a normal basic negotiation. First LCP
>is negotiated. Then the peer is authenticated with PAP. Then IPCP is
>negotiated. Your client first asks for several options that the "server"
>doesn't care for, but they finally swap IP addresses and should be ready
>to send IP traffic. Then for some unknown reason, the "server" simply
>sends a Terminate-Request to the "client". How long does the whole process
>take??
>
Thanks, but how can you tell? If I look at RFC1661 and my data, about the
only thing I can make sense of is the 'C021' and 'C023', but the data
following those does not look like what I expect from RFC1661. If you can
point me to a site that explains the data, I'd be very thankfull.
The whole process takes about 5 seconds.
This Terminate-request" is one of last data packets before I get "ERROR"?
>>There seems to be some communication and even user/pass sending and I get
>>a "Welcome!", but after that it dies somewhere.
>>
>>If I turn on LWIP debugging, I see lots of "invalid" FCS messages. But
>>debugging uses diag_printf(), which turns off interrupts and therefore
>>might introduce character loss.
>
>Where is the LWIP output log? I can't check the FCS by hand so I'll
>have to trust the LWIP debug output.
>
With the debug on, there is data loss because it turns off interrupts
while printing the messages over another serial port. But when turned
on, it mostly complains about invalid FCS for 'C023' and 'C021'
packets. But due to the data loss, I do not trust it that much.
Is there a way to calculate the FCS manually (or programmatically in
my debuggging code)? A page discribing how it is calculated would be
very welcome.
We now also tried to get this modem (multitech MTSMC-G-F1) to work with
windows, but the results are a bit simular. Only thing is that there is
about twice as much data between "Welcome!" and "ERROR". But also hangs
up after a few seconds.
So maybe there is a problem with the mode settings? Looking for GPRS
settings on the net provides me with many different answers, but this
is what I'm using now:
ATZ
AT S0=0 E0
AT+CGDCONT=1,"IP","web.vodafone.nl"
ATDT*99#
But there are many more settings to GPRS.
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
We just joined the civil hair patrol!
Reply by Patrick Klos●January 19, 20062006-01-19
In article <4fdd5$43ced14f$54f63171$12292@publishnet.news-service.com>,
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>Hello,
>
>I'm trying to get a GPRS PPP connection going in eCos using the LwIP
>stack, but no luck so far.
>
>It seems that my provider and the LwIP PPP code do not understand each
>other. I', trying to find examples of correct communication but have
>had no luck so far and RFC1661 is a bit hard to decode. Does anyone
>know good links to information on this subject? Google has not come
>up with many insightfull links for me.
>
>For experts in debugging PPP communication, can you make any sense of the
>following log data? I had to capture sending and receiving to the modem
>separately, so the below parts should be intermixed.
The information below looks like a normal basic negotiation. First LCP
is negotiated. Then the peer is authenticated with PAP. Then IPCP is
negotiated. Your client first asks for several options that the "server"
doesn't care for, but they finally swap IP addresses and should be ready
to send IP traffic. Then for some unknown reason, the "server" simply
sends a Terminate-Request to the "client". How long does the whole process
take??
>There seems to be some communication and even user/pass sending and I get
>a "Welcome!", but after that it dies somewhere.
>
>If I turn on LWIP debugging, I see lots of "invalid" FCS messages. But
>debugging uses diag_printf(), which turns off interrupts and therefore
>might introduce character loss.
Where is the LWIP output log? I can't check the FCS by hand so I'll
have to trust the LWIP debug output.
Good luck!
Patrick
========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
Patrick Klos Email: patrick@klos.com
Klos Technologies, Inc. Web: http://www.klos.com/
==================== http://www.loving-long-island.com/ ====================
Reply by Stef●January 18, 20062006-01-18
Hello,
I'm trying to get a GPRS PPP connection going in eCos using the LwIP
stack, but no luck so far.
It seems that my provider and the LwIP PPP code do not understand each
other. I', trying to find examples of correct communication but have
had no luck so far and RFC1661 is a bit hard to decode. Does anyone
know good links to information on this subject? Google has not come
up with many insightfull links for me.
For experts in debugging PPP communication, can you make any sense of the
following log data? I had to capture sending and receiving to the modem
separately, so the below parts should be intermixed.
There seems to be some communication and even user/pass sending and I get
a "Welcome!", but after that it dies somewhere.
If I turn on LWIP debugging, I see lots of "invalid" FCS messages. But
debugging uses diag_printf(), which turns off interrupts and therefore
might introduce character loss.
Sent to modem:
0000 41 54 5A 0A 41 54 20 53 30 3D 30 20 45 30 0A 41 ATZ.AT S0=0 E0.A
0010 54 2B 43 47 44 43 4F 4E 54 3D 31 2C 22 49 50 22 T+CGDCONT=1,"IP"
0020 2C 22 77 65 62 2E 76 6F 64 61 66 6F 6E 65 2E 6E ,"web.vodafone.n
0030 6C 22 0A 41 54 44 54 2A 39 39 23 0A 7E FF 7D 23 l".ATDT*99#.~.}#
0040 C0 21 7D 21 7D 21 7D 20 7D 34 7D 22 7D 26 7D 20 .!}!}!} }4}"}&}
0050 7D 20 7D 20 7D 20 7D 25 7D 26 52 7D 38 7D 30 44 } } } }%}&R}8}0D
0060 7D 27 7D 22 7D 28 7D 22 6E E1 7E FF 7D 23 C0 21 }'}"}(}"n.~.}#.!
0070 7D 21 7D 22 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 }!}"} }.}"}&} }
0080 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 87 3A 7E 7E } } }'}"}(}".:~~
0090 FF 7D 23 C0 21 7D 22 7D 21 7D 20 7D 36 7D 21 7D .}#.!}"}!} }6}!}
00A0 24 7D 25 DC 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 $}%.}"}&} } } }
00B0 7D 27 7D 22 7D 28 7D 22 7D 23 7D 24 C0 23 D0 47 }'}"}(}"}#}$.#.G
00C0 7E FF 03 C0 23 01 01 00 16 08 76 6F 64 61 66 6F ~...#.....vodafo
00D0 6E 65 08 76 6F 64 61 66 6F 6E 65 9D D5 7E 7E FF ne.vodafone..~~.
00E0 03 80 21 01 01 00 16 03 06 00 00 00 00 81 06 00 ..!.............
00F0 00 00 00 83 06 00 00 00 00 6E DB 7E FF 03 80 21 .........n.~...!
0100 02 01 00 0A 03 06 C0 A8 6F 6F DA D3 7E FF 03 80 ........oo..~...
0110 21 01 02 00 10 03 06 00 00 00 00 83 06 00 00 00 !...............
0120 00 28 15 7E FF 03 80 21 01 03 00 0A 03 06 00 00 .(.~...!........
0130 00 00 E9 B3 7E FF 03 80 21 01 04 00 0A 03 06 C0 ....~...!.......
0140 A8 6F 70 DD 3D 7E FF 7D 23 C0 21 7D 26 7D 22 7D .op.=~.}#.!}&}"}
0150 20 7D 24 94 7D 2D 7E }$.}-~
Received from modem:
E2 0A 0A 4F 4B 0A 0A 41 54 ...OK..AT
0160 20 53 30 3D 30 20 45 30 0A 0A 0A 4F 4B 0A 0A 0A S0=0 E0...OK...
0170 0A 4F 4B 0A 0A 0A 0A 43 4F 4E 4E 45 43 54 20 39 .OK....CONNECT 9
0180 36 30 30 0A 0A 7E FF 7D 23 C0 21 7D 21 7D 21 7D 600..~.}#.!}!}!}
0190 20 7D 36 7D 21 7D 24 7D 25 DC 7D 22 7D 26 7D 20 }6}!}$}%.}"}&}
01A0 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 7D 23 } } } }'}"}(}"}#
01B0 7D 24 C0 23 26 B4 7E 7E FF 7D 23 C0 21 7D 24 7D }$.#&.~~.}#.!}$}
01C0 21 7D 20 7D 2A 7D 25 7D 26 52 7D 38 7D 30 44 B4 !} }*}%}&R}8}0D.
01D0 C5 7E 7E FF 7D 23 C0 21 7D 22 7D 22 7D 20 7D 2E .~~.}#.!}"}"} }.
01E0 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 }"}&} } } } }'}"
01F0 7D 28 7D 22 B9 B9 7E 7E FF 7D 23 C0 21 7D 21 7D }(}"..~~.}#.!}!}
0200 21 7D 20 7D 36 7D 21 7D 24 7D 25 DC 7D 22 7D 26 !} }6}!}$}%.}"}&
0210 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 } } } } }'}"}(}"
0220 7D 23 7D 24 C0 23 26 B4 7E 7E C0 23 7D 22 7D 21 }#}$.#&.~~.#}"}!
0230 7D 20 7D 2D 7D 28 57 65 6C 63 6F 6D 65 21 4E BC } }-}(Welcome!N.
0240 7E 7E 80 21 7D 21 7D 21 7D 20 7D 2A 7D 23 7D 26 ~~.!}!}!} }*}#}&
0250 C0 A8 6F 6F CD 49 7E 7E 80 21 7D 24 7D 21 7D 20 ..oo.I~~.!}$}!}
0260 7D 2A 81 7D 26 7D 20 7D 20 7D 20 7D 20 22 57 7E }*.}&} } } } "W~
0270 7E 80 21 7D 24 7D 22 7D 20 7D 2A 83 7D 26 7D 20 ~.!}$}"} }*.}&}
0280 7D 20 7D 20 7D 20 73 89 7E 7E 80 21 7D 23 7D 23 } } } s.~~.!}#}#
0290 7D 20 7D 2A 7D 23 7D 26 C0 A8 6F 70 7D 2F 62 7E } }*}#}&..op}/b~
02A0 7E FF 7D 23 C0 21 7D 25 7D 22 7D 20 7D 24 59 28 ~.}#.!}%}"} }$Y(
02B0 7E 0A 0A 45 52 52 4F 52 0A 0A 0A 0A 4E 4F 20 43 ~..ERROR....NO C
02C0 41 52 52 49 45 52 0A 0A ARRIER..
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
I think I'll KILL myself by leaping out of this 14th STORY WINDOW while
reading ERICA JONG'S poetry!!