I figured out! Just running snapshot without the patch.
I went with rpi3 closest to AP. Just connected over tor. What really is happening is: if too far of AP and has loss of connectivity or some kind of frame loss is causing the issue. If you get far of AP, I think you will be able to reproduce. That's it. I am sure! 2017-08-28 14:24 GMT-03:00 R0me0 *** <[email protected]>: > Hi Stefan, > > I have improved the signal of the AP router, changed the power supply as > suggested by you, sent you an image of dongle and the ifconfig of urtwn0 to > provided as much I can with details of the environment. > > With snapshot of today every single time I try to bring up tor I had : > > rpibsd /bsd: urtwn0 device timeout urtwn0: RUN -> INIT ( and the device > hangs ) > > But with the patch below applied on sources from August 25, I was able to > build the tor circuit after I improved the signal and ensured not packet > loss. I am checking every single element involved on this. > > I will apply this patch to snapshot of today and perform more tests. From > now without the patch below the system hangs completely. > > > Thank you so much for spent time on this. > > > rtwn.c > =================================================================== > RCS file: /cvs/src/sys/dev/ic/rtwn.c,v > retrieving revision 1.33 > diff -u -p -r1.33 rtwn.c > --- rtwn.c 23 Aug 2017 09:25:17 -0000 1.33 > +++ rtwn.c 26 Aug 2017 10:33:43 -0000 > @@ -1375,7 +1375,8 @@ rtwn_watchdog(struct ifnet *ifp) > if (sc->sc_tx_timer > 0) { > if (--sc->sc_tx_timer == 0) { > printf("%s: device timeout\n", > sc->sc_pdev->dv_xname); > - task_add(systq, &sc->init_task); > + if (sc->chip & RTWN_CHIP_PCI) > + task_add(systq, &sc->init_task); > ifp->if_oerrors++; > return; > } > > 2017-08-28 13:41 GMT-03:00 Stefan Sperling <[email protected]>: > >> On Mon, Aug 28, 2017 at 01:09:17PM -0300, R0me0 *** wrote: >> > This is snapshot from today: >> > >> > Aug 28 16:05:25 rpibsd Tor[54551]: Bootstrapped 50%: Loading relay >> > descriptors >> > urtwn0: device timeout >> > Aug 28 16:05:30 rpibsd /bsd: urtwn0: device timeout >> >> This again works fine here without device timeout messages: >> >> $ tail /var/log/messages >> Aug 28 15:47:19 carberry Tor[69953]: Bootstrapped 56%: Loading relay >> descriptors >> Aug 28 15:47:21 carberry Tor[69953]: Bootstrapped 63%: Loading relay >> descriptors >> Aug 28 15:47:22 carberry Tor[69953]: Bootstrapped 68%: Loading relay >> descriptors >> Aug 28 15:47:22 carberry Tor[69953]: Bootstrapped 75%: Loading relay >> descriptors >> Aug 28 15:47:22 carberry Tor[69953]: Bootstrapped 80%: Connecting to the >> Tor network >> Aug 28 15:47:23 carberry Tor[69953]: Bootstrapped 85%: Finishing >> handshake with first hop >> Aug 28 15:47:23 carberry Tor[69953]: Bootstrapped 90%: Establishing a Tor >> circuit >> Aug 28 15:47:24 carberry Tor[69953]: Tor has successfully opened a >> circuit. Looks like client functionality is working. >> Aug 28 15:47:24 carberry Tor[69953]: Bootstrapped 100%: Done >> $ date >> Mon Aug 28 18:31:52 CEST 2017 >> >> Ping test has been running fine as well: >> 9851 packets transmitted, 9828 packets received, 3 duplicates, 0.2% >> packet loss >> round-trip min/avg/max/std-dev = 2.759/114.881/3848.698/1285.292 ms >> >> I am not convinced that the urtwn driver is part of your problem. >> Unless you can show convincing evidence that it's a driver problem I >> am not going to spend more time on this. >> >> Have you already tried using this urtwn device in another machine? >> I suspect it will work just fine. >> >> It seems your hardware is not behaving as expected. >> Have you already tried using a different electrical power supply for your >> rpi3? >> > >
