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

[Sylvain Rochet]

Hi Felipe,


On Tue, Jan 14, 2014 at 02:58:02PM -0200, Felipe Provenzano wrote:
> 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.

Oh dear, so much dead packets, this is pretty sad :)

Well, this is kind of a lossy link, you cannot expect to set up a PPP 
tunnel with such crap. Anyway, this doesn't explain why we get good 
checksums with such packets, maybe we are stressing the CRC16 over its 
limit.


> 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.

Are you using CTS/RTS flow control ?

I guess the Windows PPP stack expect CTS and RTS signals to be wired by 
default, because POTS modems use them by default. Anyway, there is 
no hope of having a working PPP serial link without any flow control, 
either using CTS/RTS or XON/XOFF. I personally prefer the CTS/RTS way 
since embedded USART usually handle that by hardware.


> 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)

Good catch !, this is obviously a bug, which is now fixed in the ppp_new 
branch. Thank you.


> Thank you very much for your support!

You are welcome :)


Sylvain

signature.asc
Description: Digital signature