Connectity lost afer a while

smalldragoon

and

And connection is working

Gertjan

@smalldragoon said in Connectity lost afer a while:

After a while, the Wifi connection drops

and

so 'dpinger' is pining 192.168.1.1, the 4G/Wifi router, and this one is loosing the connection ?
Instead of using 8.8.8.4.4, can you ping the IP of the router / modems LAN interface 192.168.1.1 ?
This will show you if the Wifi goes bad ....
If the connection doesn't work, but it still shows a solid green "online" without moss, you'll know that the Wifi parts is good (the connection between pfSense over Wifi to the 4G/Wifi router). Then it must be the other side, the 4G.

stephenw10

Ok if you're seeing 'no carrier' in ifconfig for the wifi interface then it's the wifi that is dropping. Unless the 4G router is crashing entirely.

What does the system log show when it fails?

How do you recover from this? Resave the Orange interface? Reboot the 4G router?

Steve

smalldragoon

@stephenw10 hence my post trying to understand what was happening
I was assuming that the wifi logs are ONLY when we setup pfsense as acces point, not as a wifi client

I was pinging 8.8.4.4 and then , based on the first answers, I indeed changed to ping 192.168.1.1
so I'm now monitoring "just" the wifi connection with dpinger.

stephenw10

Mmm, I would have expected something in the wifi logs but almost no-one uses station mode like that. What do the system logs show though?

And what do you do or have you tried to recover when it does happen?

Steve

smalldragoon

@stephenw10
yes for your first statement, as I was able to connect, with a windows 10 machine to the 4G modem at the same time .
I have not so much in my logs, I was expecting something in the wireless logs.
To recover, I tried to reconnect, no result, tried to disable and re-enable interface, nothing.
if I reboot the pfsense, everything reconnects like a charm

stephenw10

Hmm, there must be something in the system logs at that point if the interface loses link. Anything there could be a clue.

USB wifi devices are not well thought of though. This could be a driver or even a hardware bug that we can't do anything about.

Steve

smalldragoon

@stephenw10
For ref , these are the dmesg entries for the card :

urtw0: rtl8187b rf rtl8225z2 hwrev e
urtw0: <RTL8187BWLANAdapter> on usbus0
urtw0 on uhub0
ugen0.3: <ManufacturerRealtek RTL8187BWLANAdapter> at usbus0
Root mount waiting for: usbus0 CAM
kbd2 at ukbd0

For system logs, I only get some info like

system.log:Jun 29 18:44:27 Bastion check_reload_status[377]: rc.newwanip starting urtw0_wlan0
system.log:Jun 29 18:44:28 Bastion php-fpm[121]: /rc.newwanip: rc.newwanip: Info: starting on urtw0_wlan0.
system.log:Jun 29 18:44:28 Bastion php-fpm[121]: /rc.newwanip: rc.newwanip: on (IP address: 192.168.1.21) (interface: ORANGE3GWIFI[opt3]) (real interface: urtw0_wlan0).
system.log:Jun 29 18:49:59 Bastion kernel: urtw0_wlan0: link state changed to DOWN
system.log:Jun 29 18:49:59 Bastion check_reload_status[377]: Linkup starting urtw0_wlan0
system.log:Jun 29 18:49:59 Bastion kernel: urtw0_wlan0: link state changed to UP
system.log:Jun 29 18:49:59 Bastion kernel: arpresolve: can't allocate llinfo for 192.168.1.1 on urtw0_wlan0
system.log:Jun 29 18:50:00 Bastion kernel: arpresolve: can't allocate llinfo for 192.168.1.1 on urtw0_wlan0
system.log:Jun 29 18:50:01 Bastion kernel: arpresolve: can't allocate llinfo for 192.168.1.1 on urtw0_wlan0
system.log:Jun 29 18:50:02 Bastion check_reload_status[377]: rc.newwanip starting urtw0_wlan0
system.log:Jun 29 18:50:03 Bastion php-fpm[11380]: /rc.newwanip: rc.newwanip: Info: starting on urtw0_wlan0.
system.log:Jun 29 18:50:03 Bastion php-fpm[11380]: /rc.newwanip: rc.newwanip: on (IP address: 192.168.1.21) (interface: ORANGE3GWIFI[opt3]) (real interface: urtw0_wlan0).
system.log:Jun 29 18:59:18 Bastion kernel: urtw0_wlan0: link state changed to DOWN
system.log:Jun 29 18:59:21 Bastion check_reload_status[377]: Linkup starting urtw0_wlan0
system.log:Jun 29 18:59:21 Bastion kernel: urtw0_wlan0: link state changed to UP
system.log:Jun 29 18:59:22 Bastion kernel: arpresolve: can't allocate llinfo for 192.168.1.1 on urtw0_wlan0
system.log:Jun 29 18:59:23 Bastion kernel: arpresolve: can't allocate llinfo for 192.168.1.1 on urtw0_wlan0
system.log:Jun 29 18:59:23 Bastion check_reload_status[377]: rc.newwanip starting urtw0_wlan0
system.log:Jun 29 18:59:24 Bastion php-fpm[49099]: /rc.newwanip: rc.newwanip: Info: starting on urtw0_wlan0.
system.log:Jun 29 18:59:24 Bastion php-fpm[49099]: /rc.newwanip: rc.newwanip: on (IP address: 192.168.1.21) (interface: ORANGE3GWIFI[opt3]) (real interface: urtw0_wlan0).

which doesn't really help as I know I lost the link.
Having that said, dpinger being set to 192.168.1.1, no more issues
Would be great anyway for pfsense to have some logs in wireless.log as client , don't know how to create a request for it. I can do some tests to help

smalldragoon

@stephenw10 hence my post trying to understand what was happening
I was assuming that the wifi logs are ONLY when we setup pfsense as access point, not as a wifi client

Gertjan

@smalldragoon

You saw :

....
system.log:Jun 29 18:49:59 Bastion kernel: urtw0_wlan0: link state changed to DOWN
system.log:Jun 29 18:49:59 Bastion kernel: urtw0_wlan0: link state changed to UP
....
system.log:Jun 29 18:59:18 Bastion kernel: urtw0_wlan0: link state changed to DOW
system.log:Jun 29 18:59:21 Bastion kernel: urtw0_wlan0: link state changed to UP
....

This is what you should call a non reliable connection.
You had the (start of the) answers all the time right in front of you ! The logs always tell you what's happening.

I know, we all love Wifi as it it so easy .... Just remind yourself that a 'cable' is a "set it and forget it solution" (for live). And won't break your connection every 10 minutes or so.

And keep in mind : it's not only the connection that is rebuild, but also a lot more : because it is a WAN type interface, a lot of code is triggered to reset and set a gateway, unbound (DNS) is probably restarted etc etc.

And Google this : "10 good reasons why not to use Realtek devices".
Or ask the FreeBSD community.

stephenw10

Mmm, wifi losing link could be a number of causes.

Those logs were generated without you doing anything manually? It looks like it reconnects there but you say you have to reboot to actually use the connection?

If you have another device connected to the 4G router at the same time does that also lose link?

Steve

smalldragoon

@stephenw10 sorry, did not get the notif of your reply ...
So yes, nothing manually.
The other host , a laptop, say always connected.
For now, everything is working fine when I monitor the 192.168.1.1. instead of an internet host. so from my side all good.
After, as I see you part of netgate, happy to do some tests/checks to help improve the software :D . Feel free !

stephenw10

Hmm, well, if that's working for you I would stay with it.