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

[Felipe Provenzano]

Hello Sylvain

Good to know the bug is solved :)
Unfortunately my hardware do not have flow control pins wired.
In this tests, to change the USB serial converter and avoid USB hubs made the 
trick. No more corrupted packages. \o/

I have my hardware working in the windows 7 and for the moment everything 
works, so I consider it a good day, 

Thank you for the help again


Felipe Provenzano 

> Em 14/01/2014, às 15:42, Sylvain Rochet <address@hidden> escreveu:
> 
> 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
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users