🚀 go-pugleaf

In article <874397597snz@edlyn.demon.co.uk>, Eddie Shave
<Eddie@edlyn.demon.co.uk> writes

>I am writing some tcp/ip software from scratch.
>I am at the stage where I have negotiated an open ppp link and can succesfully
>send and receive lcp echo request/reply.
>I now need to test my initial ip code by sending and receiving ICMP echo
>messages. (sort of ping I suppose)
>My problem is there is no response to my ICMP echo message.
>Hard as I try I can find no errors in whats sent.

you could post the packet content here and we could comment. Better yet
would be to post what was on the wire, since its possible you've packed
it up wrong for the PPP (though if you've got the link up as far as LCP
that does seem unlikely)

>Because there is no response there are no clues as to why the packet is being
>discarded. I'm wondering if there is a service anywhere on the net that 
>returns an error message for packets that would normaly be silently discarded?

I'm not aware of one... and if you're making malformed packets you might
have some problem arranging for your packets to reach it :)

>Failing that does anyone reading this have the wherewithal and inclination
>to receive my packet and email me the reason for rejection?

Someone with link level logging could do this over a direct link... you
could consider using KA9Q for this on a second machine - it has a great
deal of logging which can be turned on quite easily without even needing
to recompile it.

However if you arrange to produce a trace at the deepest level, just
before you put the bytes on the wire, I (and doubtless others) would be
happy to look at the problem. I think it would raise the tone of the
newsgroup no end :)

-- 
richard                      richard.clayton    @    T U R N P I K E .com
                                                     tel: +44 1306 732300
"Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM

In article <2nWSWIBi8kH0EAkE@turnpike.com>
           richard@turnpike.com "Richard Clayton" writes:

> In article <874397597snz@edlyn.demon.co.uk>, Eddie Shave
> <Eddie@edlyn.demon.co.uk> writes
> 
> >I am writing some tcp/ip software from scratch.
> >I am at the stage where I have negotiated an open ppp link and can succesfully
> >send and receive lcp echo request/reply.
> >I now need to test my initial ip code by sending and receiving ICMP echo
> >messages. (sort of ping I suppose)
> >My problem is there is no response to my ICMP echo message.
> >Hard as I try I can find no errors in whats sent.
> 
> you could post the packet content here and we could comment. Better yet
> would be to post what was on the wire, since its possible you've packed
> it up wrong for the PPP (though if you've got the link up as far as LCP
> that does seem unlikely)
> 
> >Because there is no response there are no clues as to why the packet is being
> >discarded. I'm wondering if there is a service anywhere on the net that 
> >returns an error message for packets that would normaly be silently discarded?
> 
> I'm not aware of one... and if you're making malformed packets you might
> have some problem arranging for your packets to reach it :)
> 
> >Failing that does anyone reading this have the wherewithal and inclination
> >to receive my packet and email me the reason for rejection?
> 
> Someone with link level logging could do this over a direct link... you
> could consider using KA9Q for this on a second machine - it has a great
> deal of logging which can be turned on quite easily without even needing
> to recompile it.
> 
> However if you arrange to produce a trace at the deepest level, just
> before you put the bytes on the wire, I (and doubtless others) would be
> happy to look at the problem. I think it would raise the tone of the
> newsgroup no end :)
> 

Your wish is my command... :)

HEX         DESCRIPTION
--------    -----------------------------------------------
45          IP_Version=4        IP_Internet-Header-Length=5
00          IP_Type-Of-Service
001C        IP_Total-Length
0000        IP_Identification
0000        IP_Flags=0  IP_Fragment-Offset=0
3F          IP_Time-To-Live
01          IP_Protocol=ICMP
7D25        IP_Header-Checksum (Is this checksum correct?)
9E98BFAD    IP_Source-Address (158.152.191.173 My IP address
9E9801DE    IP_Destination-Address (158.152.1.222 A gateway
                                    belonging to my ISP)
08          ICMP_Type=Echo-Message
00          ICMP_Code
F7FF        ICMP_Checksum (Is this checksum correct?)
0000        ICMP_Identifier (may be zero?)
0000        ICMP_Sequence-Number (may be zero?)

--------------------------------------------------


As above but off the wire...

    7E FF 7D 23 7D 20 21 45 7D 20 7D 20 7D 3C 7D 20
    7D 20 7D 20 7D 20 3F 7D 21 7D 5D 25 9E 98 BF AD
    9E 98 7D 21 DE 7D 28 7D 2O F7 FF 7D 20 7D 20 7D
    20 7D 20 41 7D 3F 7E 

    PPP is set for default operation, ie. no options negotiated.
    On transmit I am escaping all chr's < 32 as well as 7D & 7E (ESC & Flag).


As a further confidence test I substituted the ppp protocol field with an
invalid number (00cf). This cause the peer to send a lcp protocol reject, which
contained a copy of my sent ip packet. For completeness I include a copy of the
protocol reject packet off the wire.

    7E FF 7D 23 C0 21 7D 28 7D 23 7D 20 22 7D 20 CF
    45 7D 20 7D 20 7D 3C 7D 20 7D 20 7D 20 7D 20 3F
    7D 21 7D 5D 25 9E 98 BF AD 9E 98 7D 21 DE 7D 28
    7D 2O F7 FF 7D 20 7D 20 7D 20 7D 20 52 7D 35 7E 

From this I make the following assumptions...

 Because the peers ppp module carries out accm (escape) decoding on receipt
 and recodes on transmit and the data is returned as sent, then my accm code
 is ok.

 That the packet was received by the peer with a valid FCS. And that although
 this does not prove the packet with the correct protocol field is sent with
 a valid FCS it seems likely.

 That I'm going to look daft when someone points to the simple/obvious solution.


Oh yes... I have a copy of KA9Q but no second machine. (may be able to
borrow one). However I have used it to ping the same address I'm sending my
packet, and can confirm that it does in fact respond correctly.
A dump of the ping output from KA9Q also confirms that it is using the same
ICMP echo message as my packet accept that it includes 4 bytes of data in the
form of a time stamp. I suppose I better include a copy of the KA9Q dump.

    FF 03 00 21 45 00 00 20 00 FA 00 00 3F 01 7C 27
    9E 98 BF AD 9E 98 01 DE 08 00 BD E0 00 88 00 AF
    34 E8 04 00


To anyone still with me, whether you can help or not, thanks for the time :).
Don't hesitate to ask for any further information as I am really stuck..!

Regards

-- 
Eddie Shave (Derbyshire uk)
eshave@edlyn.demon.co.uk