lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] [ppp-new] Problems connection on Windows7


From: Felipe Provenzano
Subject: Re: [lwip-users] [ppp-new] Problems connection on Windows7
Date: Tue, 14 Jan 2014 14:58:02 -0200

Hi Sylvain, 

I have news,  just after send the last email, the equipment started to work with my computer. 
It was looking  suspicious because i was changing the windows register trying a lot of different stuff.
So i tried it in another "virgin"  computer with windows 7, and i had the log in the file "log.ppp". There is a lot of corrupted packages.

We changed it to use a physical connection and worked as well, i mean, i was able to ping the equipment.
So, maybe a good part of the problem was the usb-driver corrupting data, apparently.
I will make some more tests, but i do not understand why suddenly it started to work, spirits maybe? I will put it in quarantine before be sure that there is no problem :) 

After be able to ping the equipment i tried to open a connection, it worked in the direction equipment->pc  but not pc->equipment.
Entering in the code i saw the response was dropped at:
 
    case PPP_VJC_COMP:      /* VJ compressed TCP */
      PPPDEBUG(LOG_INFO, ("ppp_input[%d]: vj_comp in pbuf len=%d\n", pcb->num, pb->len));
      /*
       * Clip off the VJ header and prepend the rebuilt TCP/IP header and
       * pass the result to IP.
       */
      if ((vj_uncompress_tcp(&pb, &pcb->vj_comp) >= 0) && (pcb->netif.input)) {
        pcb->netif.input(pb, &pcb->netif);
        return;
      }
      /* Something's wrong so drop it. */
      PPPDEBUG(LOG_WARNING, ("ppp_input[%d]: Dropping VJ compressed\n", pcb->num));
      break;


Apparently pcb->netif.input was initialized with 0.


So, I changed from:
 if (!netif_add(&pcb->netif, &pcb->addrs.our_ipaddr, &pcb->addrs.netmask,
                 &pcb->addrs.his_ipaddr, (void *)pcb, ppp_netif_init_cb, NULL)) {
    memp_free(MEMP_PPP_PCB, pcb);
    PPPDEBUG(LOG_ERR, ("ppp_new[%d]: netif_add failed\n", pcb->num));
    return NULL;
  }

To:
 if (!netif_add(&pcb->netif, &pcb->addrs.our_ipaddr, &pcb->addrs.netmask,
                 &pcb->addrs.his_ipaddr, (void *)pcb, ppp_netif_init_cb, ip_input)) {
    memp_free(MEMP_PPP_PCB, pcb);
    PPPDEBUG(LOG_ERR, ("ppp_new[%d]: netif_add failed\n", pcb->num));
    return NULL;
  }

And it worked, my question is, can it cause some side effects?

PS: I am using the last version of ppp_new branch i found in the repository(downloaded a couple of days ago)

Thank you very much for your support!


Felipe


On Tue, Jan 14, 2014 at 2:02 PM, Sylvain Rochet <address@hidden> wrote:
Hi Felipe,


On Tue, Jan 14, 2014 at 01:06:12PM -0200, Felipe Provenzano wrote:
> Thank you Sylvain,
>
> Fortunately, yes, we have enough RAM/FLASH  for the extra log \o/
>
> [...]
>
> [   116:23: tcp] rcvd [proto=0x80fd] 01 02 00 0a 12 06 00 00 00 01
> [   116:23: tcp] Unsupported protocol 0x80fd received

Everything is fine until this point, 0x80fd is CCP, Compression Control
Protocol which is not supported for lwIP.


> [   116:23: tcp] sent [LCP ProtRej id=0x2 80 fd 01 02 00 0a 12 06 00 00 00 01]
> [   116:23: tcp] ppp_write[1]: len=24

So, we are refusing it, everything still fine.


> [   116:23: tcp] tcpip_thread: CALLBACK 6807cbf8
> [   116:23: tcp] rcvd [LCP ProtRej id=0x3 80 21 01 01 00 1c 02 06 00 2d 0f 01 03 06 00 00 00 00 81 06 00 00 00 00 83 06 00 00 00 00]
> [   116:23: tcp] Protocol-Reject for 0x8021 received

0x8021 is IPCP, we receive a frame telling us that IPCP is -not-
supported, this is weird. The windows host is rejecting our IPCP
request, wtf.


> [   116:37: tcp] --------------- Received 35
> [   116:37: tcp] pppos_input[1]: got 35 bytes
> [   116:23: tcp] tcpip_thread: CALLBACK 6807cbf8
> [   116:23: tcp] rcvd [LCP TermReq id=0x4 "Z\37777777742\032\37777777651\000<\37777777715t\000\000\000\000"]
> [   116:23: tcp] LCP terminated by peer (ZM-b^ZM-)^@<address@hidden@address@hidden@)

Packets looks corrupted, this might explain the previous behavior.

But this is strange... there is CRC16-CCITT on HDLC frames, parsing
corrupted frames is nearly-impossible.

Are they actually corrupted after low-level PPPoS checked the CRC and
before passing them to lwIP PPP stack ?  If yes, this looks like a
driver corruption issue.

I am not saying that this isn't my fault, we don't know yet, this is
just what it looks like :)


> If you need more logs i believe i still having some space to include it.

I guess you are using a RS232 link between your Windows host and your
target using some kind of USB to Serial convertir, so, could you dump
the binary stream by sniffing the Rx + Tx wires using two additional USB
to Serial converters ?  Or an oscilloscope with protocol decoding able to
export the Rx+Tx binary streams.


Sylvain

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users



--
"We all make choices, but in the end, our choices make us"

Attachment: log.ppp
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]