Port-arm archive

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

Re: Raspberry Pi Zero W almost useless (TL-WN725N very good!)

netbsd-raspa# ifconfig urtwn0
urtwn0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ssid MiFibra-3422 nwkey 65536:"",0xc81111000336c6e2b40b047cd2f5ef44,"",""
     powersave off
     bssid 60:8d:26:32:34:24 chan 1
     address: e4:fa:c4:52:ac:4c
     media: IEEE802.11 autoselect (OFDM54 mode 11g)
     status: active
     inet6 fe80::e6fa:c4ff:fe52:ac4c%urtwn0/64 flags 0 scopeid 0x1
     inet broadcast flags 0

I have been downloading many times the same 3.6 GB file from the internet with no failures just for testing. I have made a CVS checkout of the base system source and pkgsrc source fine.

Also have watched a 1h 30 m film using minidlna server in VLC over the local network with no failures at all.

With bwfm driver that was just impossible.

Great work!



After a week using the driver I can say that it works well downloading files massively but I noticed I have lost ssh connection two times (both 04:00 to 05:00 in the morning when the system was not doing anything but sending 15s interval pings) (I left a 15 s interval ping script that logged it in a file).Also investigating the logs of my other Zero W with Raspbian I could see that at the precise time the network was lost in the NetBSD ZeroW, the Raspbian ZeroW recorded an association event to the router.

Investigating further I noticed that they could be related to router WIFI channel change. "service network restart" a few times luckly restores connection but not always works. I tried also ifconfig urtwn0 up and down manually with no luck. "service wpa_supplicant" restart does not work either.

I have systematically reproduced the problem forcing a WIFI channel change from the router and network is always lost after that. If you return the router to the original channel it returns working sometimes. (Raspbian ZeroW always negociate ok channel changes)

Leaving the router at a fixed channel could be a "dirty" fix.

A channel change seems to be not very frequent, so the rebooting script when network fails could make sense...I do not know.

A bit tired of testing and out of ideas...


Home | Main Index | Thread Index | Old Index