| View previous topic :: View next topic |
| Author |
Message |
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
 Posted: Sat Oct 20, 2012 2:52 pm Post subject: |
 |
|
| mechtech wrote: | | Ok ive been working on this over the past couple weeks and still have nothing. I've tried different variations of the power management options in the kernel like you suggested, but it still does the same thing. |
mechtech ... I'm simply going by the information you provide, the better the information the better equiped I am to debug it.
| mechtech wrote: | Dmesg is reporting a new error though:
| Code: | | phy0: Failed to stop TX DMA, queues=0x001! |
|
... which *may* be the result of PS/PM having been disabled, however I can't tell as I have no idea of what kernel options were enabled/disabled, or if NetworkMunger was running, etc, etc, when this error occured.
| mechtech wrote: | | I've since installed xfce and a new network manager so iwconfig and wpa_supplicant are not in use anymore but the issue still persists. |
... and your assumption would be wrong, NetworkManager is just a frontend, it still uses wpa_supplicant for authentication.
| mechtech wrote: | | /proc/sys/net/ does not exist when CONFIG_ATH_DEBUG is enabled from what i can remember but i will double check that. |
As I said previously, I'm not sure if this option works with ath9k (I have an ath5k), but you will have a /proc/sys/net/ none the less. Anyhow, as you previously stated that "It WORKS!", but not with your home network, we can assume that its not powersave that is at issue, but something related to this network alone. So, again, you need to provide better information, like the specifics of the network (A,G,N ... G,N ... N only), if the AP is 'hidden', using WDS, QoS/WMM, etc, etc.
Also, does 'iwconfig wlan0' show high bitrates (ie > 54 Mb/s)
best ... khay |
|
| Back to top |
|
 |
Logicien
Veteran
Joined: 16 Sep 2005
Posts: 1555
Location: Montréal
|
| Posted: Sat Oct 20, 2012 5:42 pm Post subject: |
|
|
Hello,
I try to use more effeciently the Linux kernel built-in keepalive fonctionnality. It have reduce the latency when I connect to a web site with my browser after an idle period. The three keys concerned are
| Code: | net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_time = 5 |
A keepalive message is send after only 5 seconds of idle time and resend every 5 seconds. The kernel try 5 times to receice an answer before it consider the other point of the link disconnected. These values are only for test, has I could probably wait longer before the kernel send a keepalive message.
I have Internet on a cellular network and my local network is wireless with WPA2 version 1. So, if it help me in this network configuration, it could possibly help to keep a WPA connexion alive and advoid to use the ping command has I did before to reduce respond time after idle.
The values of the keepalive kernel options must be checked.
_________________
Paul |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Oct 20, 2012 7:05 pm Post subject: |
|
|
Logicien ...
I wouldn't suggest they adjust keepalive values as the problem is not wtih the transport layer but the link layer, it may (possibly) have some noticable effect but the underlying issue isn't addressed. In terms of wireless connectivity the radio transmission will determine the connection (assoc, disassoc) and so whatever the keepalive values the connection may still drop. So, really the question is why the link is dropping, and this is why I asked about the specific network, and what 'bitrate' the STA (client) was set to. This can then be lowered and so (hopefully) the connection stablised.
eg: /etc/conf.d/net
| Code: | | rate_wlan0="5.5M auto" |
... values of 1 Mb/s, 2 Mb/s, 5.5 Mb/s, 11 Mb/s, 18 Mb/s, 24 Mb/s, 36 Mb/s, 54 Mb/s, 6 Mb/s, 9 Mb/s, 12 Mb/s, 48 Mb/s, etc can all be tried (dependent on what the AP and STA support). I've seen N cards with > 140 Mb/s which will mean tighter packed data and so the potencial for data loss (and subsequently disassoc).
besides setting the bitrate in /etc/conf.d/net it can be set manually via iwconfig (or iw)
| Code: | | # iwconfig eth0 rate 5.5M auto |
So, I'd asked specifically about the network, and what bitrates iwconfig were reporting as that would be my next suggestion, but you've somewhat preempted me :)
best ... khay
ps. Logician's suggestions above are using /etc/sysctl.conf (which may not have been clear). See tcp keepalive HOWTO for further info. |
|
| Back to top |
|
|
Logicien
Veteran
Joined: 16 Sep 2005
Posts: 1555
Location: Montréal
|
| Posted: Sat Oct 20, 2012 9:31 pm Post subject: |
|
|
| mechtech wrote: | | I have done some more testing. If i have power management on, i can keep the connection going using ping and just letting it run (it does drop some packets tho). I guess its acting as a "keep alive". |
That's the reason why I think calibrating keepalive in the kernel can help. It did for me about respond after idle time and to not have pppd die. I modified permently the keepalive variables yes, in /etc/sysctl.conf.
The disassociation can have others causes like data rate. I do not think keepalive can be useless, at least it should be more occurate then the ping.
Note that the two points of my WPA links are Linux, Hostapd/Dnsmasq for server and wpa_supplicant/dhclient/dhcpcd for clients. I am never/rarely disconnected. The Bit Rate is 54 Mb/s on channel 2. Both links are bgn capables. Channel 2 is alone in the wireless neighberhood. So, on server side, the channel choose must be free if possible.
This is my connexion client configuration
| Code: | iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:"Quebec"
Mode:Managed Frequency:2.417 GHz Access Point: C8:3A:35:C5:6B:D9
Bit Rate=54 Mb/s Tx-Power=27 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=70/70 Signal level=-37 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:13 Invalid misc:117 Missed beacon:0 |
_________________
Paul |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Oct 21, 2012 1:19 pm Post subject: |
|
|
| Logicien wrote: | | mechtech wrote: | | I have done some more testing. If i have power management on, i can keep the connection going using ping and just letting it run (it does drop some packets tho). I guess its acting as a "keep alive". |
That's the reason why I think calibrating keepalive in the kernel can help. It did for me about respond after idle time and to not have pppd die. |
Logicien ... yes, but again its not the transport layer but the link layer that is the cause of the connection dropping. The ping/keepalive may add some level of stability because the traffic will cause an auto-negociation of bitrates to occur on the link, but if this can be fixed at the link level then the keepalive isn't needed.
| Logicien wrote: | | The disassociation can have others causes like data rate. I do not think keepalive can be useless, at least it should be more occurate then the ping. |
It is "useless" however if the issue can be fixed at the cause, and I'm fairly sure the cause is at the link layer.
| Logicien wrote: | | Note that the two points of my WPA links are Linux, Hostapd/Dnsmasq for server and wpa_supplicant/dhclient/dhcpcd for clients. I am never/rarely disconnected. The Bit Rate is 54 Mb/s on channel 2. Both links are bgn capables. Channel 2 is alone in the wireless neighberhood. So, on server side, the channel choose must be free if possible. |
OK, but this setup may not reflect that of the OP, I have seen clients with N cards whos bitrate is (auto-configured) in excess of 140Mb/s and as I stated higher bitrates equate to data being more more tightly packed and so more prone to error. So, there are other factors to be considered, such as how the AP is configured, the specific driver (kernel version, firmware, etc), ambient factors (location, weather, adjacent networks, etc).
| Logicien wrote: | This is my connexion client configuration
| Code: | iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:"Quebec"
Mode:Managed Frequency:2.417 GHz Access Point: C8:3A:35:C5:6B:D9
Bit Rate=54 Mb/s Tx-Power=27 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=70/70 Signal level=-37 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:13 Invalid misc:117 Missed beacon:0 |
|
... and your link quaility and signal level is good, I imagine bitrate auto-negociation rarely happens, or the STA never misses a beacon, but if you were to increase the bitrate to an inappropriately high value your client would no doubt be much more prone to disassoc, and that is my point.
best ... khay |
|
| Back to top |
|
|
Logicien
Veteran
Joined: 16 Sep 2005
Posts: 1555
Location: Montréal
|
| Posted: Mon Oct 22, 2012 12:43 am Post subject: |
|
|
I agree with you khayyam. It would be better to fix the link level than artificially keep the connexion alive with data transferts at the transport level.
In a public Access Point, with no encryption, key off, I only have to do a dhcp request to be connected to the Internet. No browser connexion is needed.The problem occur when I am disconnected from the AP. Even if I ping the AP, I am periodically disconnected. Next time I will try to reduce the bitrate and see if I stay connected longer.
Note that reduce the bitrate mean that the data transferts will take more time, everething equal, and will help to keep the connnexion alive by reducing the idle time. So it have to do with the transport level according to my understanding.
_________________
Paul |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Mon Oct 22, 2012 12:02 pm Post subject: |
|
|
| Logicien wrote: | | In a public Access Point, with no encryption, key off, I only have to do a dhcp request to be connected to the Internet. No browser connexion is needed. The problem occur when I am disconnected from the AP. Even if I ping the AP, I am periodically disconnected. Next time I will try to reduce the bitrate and see if I stay connected longer. |
Logicien ... its probably not a good idea to discuss this here as the thread really should focus on the OP's problem. However, a lot of changes to mac80211 seem to be in progress (from > 3.5.x) and I myself have noticed a slight increase in instability, and some minor oddities (like channel hopping being tempremental). Hopefully this will be improved in time.
| Logicien wrote: | | Note that reduce the bitrate mean that the data transferts will take more time, everething equal, and will help to keep the connnexion alive by reducing the idle time. So it have to do with the transport level according to my understanding. |
Bitrate is a trade-off between speed and stability ... but as no card is every sold on the premise of 'stability', the claims made, besides being misleading, are mostly about vendors making that trade-off so they can advertise stupid speeds on the box. If I understand you correctly I'd have to say your wrong, bitrate is operating at the link level, but of course what happens in the transport layer will have a knock on effect at the link layer (as we see with ping/keepalive causing the auto-negociation of bitrate to work harder and so keep the link active).
best ... khay |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
