Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
4.8.8878
#11
lonnie Wrote:If you want to run OLSR make CERTAIN you do not have any duplicate subnets. If you leave the typical 192.168.2.x on the second ethernet then you will have a problem.

If you remove the 2nd ether from olsr, then this problem won't happen.

Interface "wpci1" "wpci0" "eth0"
Reply
#12
lonnie Wrote:If you want to run OLSR make CERTAIN you do not have...
We don't run OLSR on the CPE's and don't want to. I was asking just because you had mentioned it, and I was wondering if you were suspecting it as some cause or some problem. It's never been part of our AP/CPE config.
Reply
#13
Lonnie - I'll email another .AVI showing what I'm seeing with 4.8 for the low-throughput part of the issue. The video shows client names and stuff - so those should be private, and no time to edit the video so I'll email the link. In any event, this is what the video will show:

One of our AP's (AP#49) which is a WAR1B, 2.4Ghz - this one is single pol - until it stops being winter here... All the connections seem to be fine(ish) and nothing looks obviously 'at a glance' wrong. Signals are right, rates look ok (although it's impossible to tell at a glance anymore with the 1Mbit RX rates) and there are people transferring data. So, just looking at it, nothing looks terribly amiss.

I then run a ''test10.49.bat'' batch file - which simply runs a ''starutil'' throughput test from my desktop to the AP, and then to each CPE. As you'll see, the test to the AP shows ample capacity (about 40 Mbit) left over on the backhaul at the moment, but when testing to each CPE - they get about 1 or 2 Mbit per second only. Some get a bit more, and some get less and/or won't even complete the test. Several of them won't even get 1.0 mbit and the throughput test breaks. This isn't a routing issue or an Ethernet issue to the AP - I get the same results if I run a throughput test from the AP to the CPE, or if I log into the CPE and test from the AP or test from a star-os server at the shop through our backhaul... any way I test the link over the air, it's the same results.

I then do a ''starutil IP PASS -a'' to do a straight activation. No setting changes, no config changes, no nothing - JUST an activation. When everyone re-associates, I run the same test10.49.bat file and some of the connections which couldn't pass 1-2 Mbit a few seconds earlier, can now pass 8 or 11 or 15 or 25 Mbit per second.

As typical, since this was just an activation, the problem(s) will appear again in a few hours typically. If I reboot, then the problem(s) will go way for a day or more, but they come back.

SO - I haven't seen the 0 Clients problem since 4.8 came out, but we also haven't run it for more than a couple days anywhere without rebooting it either.
Reply
#14
Thanks for the testing.
Reply
#15
OK. I know you've already said that you'd seen this problem in action on your test system, but I thought I'd send this new screen video capture along anyway, since I just recorded another example of what we see. This shows (I think) how tricky it is to even SEE or RECOGNIZE when there is a performance impacting problem. Sometimes things might even look fine, but in a real-world environment, the performance might be horrible nonetheless.

So - in this case, this AP everything 'looks' normal enough. All the signals and rates and everything look OK, and a couple clients are transferring at their 2 Mbit per second CBQ and so things seem to be working for them. At a glance, you might think this was fine and you wouldn't necessarily know that anything is wrong. This is not a '0 clients' situation, it's not a situation where the AP reboots, or resets, or where things are giant red flags going off of any sort. Looking at the AP, there is nothing terribly unusual looking happening - yet performance is horrible at this moment.

How do I know that? I have a 'test.bat' file - which does a throughput test from my desktop to the AP (to make sure the backhaul is OK) and then to each CPE in turn. I can adjust the batch file as to how long the duration of each CPE test, and how long it waits until spawning the next CPE test, which then controls how many simultaneous tests it's doing. So, in this case, it's set to test each CPE for 12 seconds, with a 3 second delay between spawning each test... so it'll be testing about 4 CPE's at the same time, climbing up from the lowest IP on the Access Point, up to the highest IP on the AP.

As mentioned, I have the AP association list open and sorted by IP so I can just see the testing ''climb the ladder'' up each CPE. Watching the screen video, you can notice that a few of the clients seem to test OK(ish), but many of the clients test way lower than they should, and a handful of the clients either test really slowly (at 80 KBytes or 40 KBytes / second) or they simply don't test at all, and the throughput test skips that client because they are currently unpingable. 10.10.3.110 and .116 are unpingable (and untestable) at the moment. Everyone is also testing way slower than normal, but in particular 10.10.3.131 .137 and .146 are testing at 1/10th of what they should be doing.

So - with 21 people on this sector, that's 5 that are essentially not functional, and the rest are just a fraction of what they should be working like. YET, at a glance, everything seems kinda OK and without knowing what to look for, you might think it was running fine because it hadn't reset, rebooted or gone to 0-clients.

So, I take one of those low performance clients (10.10.3.146) who has been pinging inconsistently, with long stretches of being un-reachable even. When he is pinging and reachable, I reboot him and wait for him to come back online, and there is no change in performance for him (or any of the other clients which are working poorly or unpingable at that moment) by rebooting him. So, it's not a situation where his CPE is in distress or anything like that. However, I then do a -a activation on the AP and everyone unlinks/relinks and then I immediately can test to that same 10.10.3.146 client at 11.5 Mbit over the air - and that's to a client which couldn't even complete a speed test just before the activate.

I then run my test.bat file again, immediately after an -a activate with no other changes, and you can watch it climb the list of the same CPE's again - but now it can test every single CPE, and the speeds are several times higher - with the clients collectively getting between 40 and 50 mbit per second combined across the AP. And with the test duration and delay, I've set it to test 4 or 5 CPE's at the same time with no issue and high throughput or with some clients dominating the AP over others.

Left unresolved, this likely would have resulted in an AP reboot or maybe a 0-client situation, but I'm not sure if that would have or not with 4.8 - regardless, the performance had degraded to the 'almost unusable' stage.

SO - my point is, this is the type of problem that you can't see 'at a glance'. If you didn't know what to look for, or how to test and recognize it, you'd never see it in an indoor test environment. You'd get clients phoning and complaining, but nothing visually looks amiss until you know how to re-produce the problem and how to test for it.

http://toddchamberlain.com/staros/C42803540392.avi
Reply
#16
ninedd Wrote:OK. I know you've already said that you'd seen this problem in action on your test system, but I thought I'd send this new screen video capture along anyway, since I just recorded another example of what we see. This shows (I think) how tricky it is to even SEE or RECOGNIZE when there is a performance impacting problem. Sometimes things might even look fine, but in a real-world environment, the performance might be horrible nonetheless.

So - in this case, this AP everything 'looks' normal enough. All the signals and rates and everything look OK, and a couple clients are transferring at their 2 Mbit per second CBQ and so things seem to be working for them. At a glance, you might think this was fine and you wouldn't necessarily know that anything is wrong. This is not a '0 clients' situation, it's not a situation where the AP reboots, or resets, or where things are giant red flags going off of any sort. Looking at the AP, there is nothing terribly unusual looking happening - yet performance is horrible at this moment.

How do I know that? I have a 'test.bat' file - which does a throughput test from my desktop to the AP (to make sure the backhaul is OK) and then to each CPE in turn. I can adjust the batch file as to how long the duration of each CPE test, and how long it waits until spawning the next CPE test, which then controls how many simultaneous tests it's doing. So, in this case, it's set to test each CPE for 12 seconds, with a 3 second delay between spawning each test... so it'll be testing about 4 CPE's at the same time, climbing up from the lowest IP on the Access Point, up to the highest IP on the AP.

As mentioned, I have the AP association list open and sorted by IP so I can just see the testing ''climb the ladder'' up each CPE. Watching the screen video, you can notice that a few of the clients seem to test OK(ish), but many of the clients test way lower than they should, and a handful of the clients either test really slowly (at 80 KBytes or 40 KBytes / second) or they simply don't test at all, and the throughput test skips that client because they are currently unpingable. 10.10.3.110 and .116 are unpingable (and untestable) at the moment. Everyone is also testing way slower than normal, but in particular 10.10.3.131 .137 and .146 are testing at 1/10th of what they should be doing.

So - with 21 people on this sector, that's 5 that are essentially not functional, and the rest are just a fraction of what they should be working like. YET, at a glance, everything seems kinda OK and without knowing what to look for, you might think it was running fine because it hadn't reset, rebooted or gone to 0-clients.

So, I take one of those low performance clients (10.10.3.146) who has been pinging inconsistently, with long stretches of being un-reachable even. When he is pinging and reachable, I reboot him and wait for him to come back online, and there is no change in performance for him (or any of the other clients which are working poorly or unpingable at that moment) by rebooting him. So, it's not a situation where his CPE is in distress or anything like that. However, I then do a -a activation on the AP and everyone unlinks/relinks and then I immediately can test to that same 10.10.3.146 client at 11.5 Mbit over the air - and that's to a client which couldn't even complete a speed test just before the activate.

I then run my test.bat file again, immediately after an -a activate with no other changes, and you can watch it climb the list of the same CPE's again - but now it can test every single CPE, and the speeds are several times higher - with the clients collectively getting between 40 and 50 mbit per second combined across the AP. And with the test duration and delay, I've set it to test 4 or 5 CPE's at the same time with no issue and high throughput or with some clients dominating the AP over others.

Left unresolved, this likely would have resulted in an AP reboot or maybe a 0-client situation, but I'm not sure if that would have or not with 4.8 - regardless, the performance had degraded to the 'almost unusable' stage.

SO - my point is, this is the type of problem that you can't see 'at a glance'. If you didn't know what to look for, or how to test and recognize it, you'd never see it in an indoor test environment. You'd get clients phoning and complaining, but nothing visually looks amiss until you know how to re-produce the problem and how to test for it.

http://toddchamberlain.com/staros/C42803540392.avi

That's really excellent, first-rate trouble shooting - thanks.
Reply
#17
Note that the first release of the 4.9 series has been posted. See the forums post for the link and description.

I am quite certain that the AP stall issue is GONE for good, but please help me and give it a try. As usual be careful until you have it running at a few sites and are sure it is solid enough. That means do not put your first unit as a wifi client, because if it is not compatible (I think it is, but be safe) then you cannot link back up. If you have access to the Ethernet then you can easily downgrade to an older firmware.
Reply
#18
lonnie Wrote:Have you any report on the stall issue?
As mentioned, none of the releases since 4.4.5.6 and 4.7.8771 has really run long enough to know if the AP Stall (if that's what you're calling 0 clients) is gone or not.

However, our AP#49 finally got to 2 days, 2 hours of runtime tonight, and it did the standard 0 clients issue. That is where throughput drops, ping times increase, performance degrades until it disassociates everyone 'due to inactivity'. Of course, the inactivity is the throughput dropping and being unable to even ping clients and everyone's performance falling till the point that there is 0 throughput to anyone (0.00 bps) and then everyone get's disassociated due to inactivity...

This AP is a WAR1B @ 2.4 ghz and is currently running 4.8.8848 - I had rolled back from 4.8.8878 because we couldn't get to 2 days with that build and I wanted to test of 8848 was better. However, the throughput dropped to 0.00 bps this evening, no clients working and it had disassociated nearly everyone (5 clients shown only) and so 4.8.x doesn't solve that.

SO - currently - there is no build that works with the WAR1B or with the APU.

I know Ive said this many times, but once again - AS FAR AS I KNOW, ALL THESE BUILDS (including even 4.4.5.6 for example) seem to work fine on a Laguna, on a WAR1A-SIAM, on a XScale-WAR2, XScale-WAR4, XScale-Metro, XScale-WP188, ALIX and X86-PC version. The only hardware that I'm aware of that has consistent problems are the WAR1B, the APU and the Ventana (from what I understand) although we don't have any Ventana's in service anymore.

It was 2 years ago (April 2015) that the WAR1A disappeared and there hasn't been a working Star-OS for 2 years.

The next message is what the chunk of KERNLOG looks like when the system de-auths everyone, when we do an 'activate' and when it re-auth's everyone. Of course, the de-auth is a result of performance being so poor that the CPE's aren't reachable and not really because no one is using the internet. Everything slows down to the point when everyone is only getting 20-40-80 KBytes per second (if anything) and some, then most are un-pingable, and DCHP requests aren't even getting back and forth so CPE's are losing their IP addresses... and then it eventually can't pass any data to any clients at all (0.00 bps) and then the AP finally does a De-Auth of everyone. SO, this is not just a de-auth 0-Clients issue, that's a symptom of things being FUBAR.
Reply
#19
Once performance has dropped till everything is un-reachable, the system deauth's everone

Code:
---[ Kernel Message Log ]-----------------------------------
Mar 13 22:47:07 dhcpd: DHCPREQUEST for 10.49.3.133 from 00:80:48:74:d1:30 via wpci0
Mar 13 22:47:07 dhcpd: DHCPACK on 10.49.3.133 to 00:80:48:74:d1:30 via wpci0
Mar 13 22:54:17 hostapd: wpci0: STA 00:80:48:74:d1:30 IEEE 802.11: disassociated due to inactivity
Mar 13 22:54:18 hostapd: wpci0: STA 00:80:48:74:d1:30 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 22:54:22 hostapd: wpci0: STA 00:80:48:6b:f1:6d IEEE 802.11: disassociated due to inactivity
Mar 13 22:54:23 hostapd: wpci0: STA 00:80:48:6b:f1:6d IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 22:55:38 hostapd: wpci0: STA 00:80:48:76:c1:34 IEEE 802.11: disassociated due to inactivity
Mar 13 22:55:39 hostapd: wpci0: STA 00:80:48:76:c1:34 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 22:55:42 hostapd: wpci0: STA 00:80:48:60:20:57 IEEE 802.11: disassociated due to inactivity
Mar 13 22:55:43 hostapd: wpci0: STA 00:80:48:60:20:57 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 22:55:52 hostapd: wpci0: STA 00:80:48:6a:3a:f4 IEEE 802.11: disassociated due to inactivity
Mar 13 22:55:53 hostapd: wpci0: STA 00:80:48:6a:3a:f4 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 22:56:03 hostapd: wpci0: STA 04:f0:21:10:46:81 IEEE 802.11: disassociated due to inactivity
Mar 13 22:56:04 hostapd: wpci0: STA 04:f0:21:10:46:81 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 22:57:57 hostapd: wpci0: STA 00:80:48:5e:b7:29 IEEE 802.11: disassociated due to inactivity
Mar 13 22:57:58 hostapd: wpci0: STA 00:80:48:5e:b7:29 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 22:58:40 hostapd: wpci0: STA 78:d3:8d:bf:ae:a3 IEEE 802.11: disassociated due to inactivity
Mar 13 22:58:41 hostapd: wpci0: STA 78:d3:8d:bf:ae:a3 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 22:58:41 hostapd: wpci0: STA 78:d3:8d:bf:b0:29 IEEE 802.11: disassociated due to inactivity
Mar 13 22:58:42 hostapd: wpci0: STA 78:d3:8d:bf:b0:29 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 22:58:54 hostapd: wpci0: STA 00:80:48:76:c1:c4 IEEE 802.11: disassociated due to inactivity
Mar 13 22:58:55 hostapd: wpci0: STA 00:80:48:76:c1:c4 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 22:59:00 hostapd: wpci0: STA 00:80:48:74:d4:f5 IEEE 802.11: disassociated due to inactivity
Mar 13 22:59:01 hostapd: wpci0: STA 00:80:48:74:d4:f5 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 22:59:10 hostapd: wpci0: STA 00:80:48:69:64:11 IEEE 802.11: disassociated due to inactivity
Mar 13 22:59:11 hostapd: wpci0: STA 00:80:48:69:64:11 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 23:00:54 hostapd: wpci0: STA 78:d3:8d:d0:03:a8 IEEE 802.11: disassociated due to inactivity
Mar 13 23:00:55 hostapd: wpci0: STA 78:d3:8d:d0:03:a8 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 23:00:59 hostapd: wpci0: STA 78:d3:8d:bf:af:bd IEEE 802.11: disassociated due to inactivity
Mar 13 23:00:59 hostapd: wpci0: STA 00:80:48:5f:ba:c5 IEEE 802.11: disassociated due to inactivity
Mar 13 23:01:00 hostapd: wpci0: STA 78:d3:8d:bf:af:bd IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 23:01:00 hostapd: wpci0: STA 00:80:48:5f:ba:c5 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 23:01:05 hostapd: wpci0: STA 00:80:48:6b:f5:ab IEEE 802.11: disassociated due to inactivity
Mar 13 23:01:06 hostapd: wpci0: STA 00:80:48:6b:f5:ab IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 23:01:12 hostapd: wpci0: STA 00:80:48:78:4b:78 IEEE 802.11: disassociated due to inactivity
Mar 13 23:01:13 hostapd: wpci0: STA 00:80:48:78:4b:78 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 23:01:18 hostapd: wpci0: STA 78:d3:8d:d0:00:c6 IEEE 802.11: disassociated due to inactivity
Mar 13 23:01:19 hostapd: wpci0: STA 78:d3:8d:d0:00:c6 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 23:03:12 hostapd: wpci0: STA 00:80:48:73:8b:7b IEEE 802.11: disassociated due to inactivity
Mar 13 23:03:13 hostapd: wpci0: STA 00:80:48:73:8b:7b IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 23:03:27 hostapd: wpci0: STA 04:f0:21:10:46:e3 IEEE 802.11: disassociated due to inactivity
Mar 13 23:03:28 hostapd: wpci0: STA 78:d3:8d:d0:00:7b IEEE 802.11: disassociated due to inactivity
Mar 13 23:03:28 hostapd: wpci0: STA 04:f0:21:10:46:e3 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 23:03:29 hostapd: wpci0: STA 78:d3:8d:d0:00:7b IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 23:05:57 hostapd: wpci0: STA 00:80:48:7a:49:02 IEEE 802.11: disassociated due to inactivity
Mar 13 23:05:58 hostapd: wpci0: STA 00:80:48:7a:49:02 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 23:06:24 hostapd: wpci0: STA 00:80:48:78:af:f7 IEEE 802.11: disassociated due to inactivity
Mar 13 23:06:25 hostapd: wpci0: STA 00:80:48:78:af:f7 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Reply
#20
and then we log in, do a save/activate (or just simply send a 'starutil IP PASS -a' to do an activate) and this is what the system does then

Code:
Mar 13 23:08:05 dropbear[23909]: Child connection from 10.2.4.65:64229
Mar 13 23:08:09 dropbear[23909]: Password auth succeeded for 'admin' from 10.2.4.65:64229
Mar 13 23:08:59 hostapd: wpci0: STA 78:d3:8d:d0:05:19 IEEE 802.11: disassociated due to inactivity
Mar 13 23:09:00 hostapd: wpci0: STA 78:d3:8d:d0:05:19 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mar 13 23:10:07 dropbear[23909]: Exit (admin): Exited normally
Mar 13 23:10:10 udhcpd: Received a SIGTERM
Mar 13 23:10:10 udhcpd: udhcp server (v0.9.8) started
Mar 13 23:10:16 hostapd: wpci0: STA 00:80:48:5f:ba:c5 IEEE 802.11: authenticated
Mar 13 23:10:16 hostapd: wpci0: STA 00:80:48:5f:ba:c5 IEEE 802.11: associated (aid 1)
Mar 13 23:10:16 hostapd: wpci0: STA 04:f0:21:10:46:81 IEEE 802.11: authenticated
Mar 13 23:10:16 hostapd: wpci0: STA 04:f0:21:10:46:81 IEEE 802.11: authenticated
Mar 13 23:10:16 hostapd: wpci0: STA 00:80:48:6b:f5:ab IEEE 802.11: authenticated
Mar 13 23:10:16 hostapd: wpci0: STA 00:80:48:6b:f5:ab IEEE 802.11: associated (aid 2)
Mar 13 23:10:16 hostapd: wpci0: STA 04:f0:21:10:46:81 IEEE 802.11: associated (aid 3)
Mar 13 23:10:17 hostapd: wpci0: STA 78:d3:8d:bf:af:bd IEEE 802.11: authenticated
Mar 13 23:10:17 hostapd: wpci0: STA 78:d3:8d:bf:af:bd IEEE 802.11: associated (aid 4)
Mar 13 23:10:17 hostapd: wpci0: STA 00:80:48:6b:f1:6d IEEE 802.11: authenticated
Mar 13 23:10:17 hostapd: wpci0: STA 00:80:48:6b:f1:6d IEEE 802.11: associated (aid 5)
Mar 13 23:10:17 hostapd: wpci0: STA 00:80:48:6a:3a:f4 IEEE 802.11: authenticated
Mar 13 23:10:17 hostapd: wpci0: STA 00:80:48:6a:3a:f4 IEEE 802.11: associated (aid 6)
Mar 13 23:10:17 hostapd: wpci0: STA 78:d3:8d:d0:05:19 IEEE 802.11: authenticated
Mar 13 23:10:17 hostapd: wpci0: STA 78:d3:8d:d0:05:19 IEEE 802.11: associated (aid 7)
Mar 13 23:10:17 hostapd: wpci0: STA 78:d3:8d:d0:00:7b IEEE 802.11: authenticated
Mar 13 23:10:17 hostapd: wpci0: STA 78:d3:8d:d0:00:7b IEEE 802.11: associated (aid 8)
Mar 13 23:10:17 hostapd: wpci0: STA 00:80:48:76:a2:43 IEEE 802.11: authenticated
Mar 13 23:10:17 hostapd: wpci0: STA 00:80:48:69:64:11 IEEE 802.11: authenticated
Mar 13 23:10:17 hostapd: wpci0: STA 00:80:48:76:a2:43 IEEE 802.11: associated (aid 9)
Mar 13 23:10:17 hostapd: wpci0: STA 00:80:48:6b:84:ce IEEE 802.11: authenticated
Mar 13 23:10:17 hostapd: wpci0: STA 00:80:48:69:64:11 IEEE 802.11: associated (aid 10)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:6b:84:ce IEEE 802.11: associated (aid 11)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:78:ae:ac IEEE 802.11: authenticated
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:78:ae:ac IEEE 802.11: authenticated
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:78:ae:ac IEEE 802.11: associated (aid 12)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:78:ae:ac IEEE 802.11: associated (aid 12)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:78:ae:ac IEEE 802.11: associated (aid 12)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:78:ae:ac IEEE 802.11: associated (aid 12)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:78:ae:ac IEEE 802.11: associated (aid 12)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:78:ae:ac IEEE 802.11: associated (aid 12)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:78:ae:ac IEEE 802.11: associated (aid 12)
Mar 13 23:10:18 hostapd: wpci0: STA 04:f0:21:10:46:e3 IEEE 802.11: authenticated
Mar 13 23:10:18 hostapd: wpci0: STA 04:f0:21:10:46:e3 IEEE 802.11: associated (aid 13)
Mar 13 23:10:18 hostapd: wpci0: STA 78:d3:8d:bf:b0:29 IEEE 802.11: authenticated
Mar 13 23:10:18 hostapd: wpci0: STA 78:d3:8d:bf:b0:29 IEEE 802.11: associated (aid 14)
Mar 13 23:10:18 hostapd: wpci0: STA 78:d3:8d:d0:03:a8 IEEE 802.11: authenticated
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:74:d1:30 IEEE 802.11: authenticated
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:74:d1:30 IEEE 802.11: authenticated
Mar 13 23:10:18 hostapd: wpci0: STA 78:d3:8d:d0:03:a8 IEEE 802.11: associated (aid 15)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:78:4b:78 IEEE 802.11: authenticated
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:74:d1:30 IEEE 802.11: associated (aid 16)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:74:d1:30 IEEE 802.11: associated (aid 16)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:74:d1:30 IEEE 802.11: associated (aid 16)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:74:d1:30 IEEE 802.11: associated (aid 16)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:74:d1:30 IEEE 802.11: associated (aid 16)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:74:d1:30 IEEE 802.11: associated (aid 16)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:74:d1:30 IEEE 802.11: associated (aid 16)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:74:d1:30 IEEE 802.11: associated (aid 16)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:78:4b:78 IEEE 802.11: associated (aid 17)
Mar 13 23:10:18 hostapd: wpci0: STA 78:d3:8d:d0:00:c6 IEEE 802.11: authenticated
Mar 13 23:10:18 hostapd: wpci0: STA 78:d3:8d:d0:00:c6 IEEE 802.11: associated (aid 18)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:7a:49:02 IEEE 802.11: authenticated
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:7a:49:02 IEEE 802.11: associated (aid 19)
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:76:c1:c4 IEEE 802.11: authenticated
Mar 13 23:10:18 hostapd: wpci0: STA 00:80:48:76:c1:c4 IEEE 802.11: associated (aid 20)
Mar 13 23:10:19 hostapd: wpci0: STA 00:80:48:76:c1:34 IEEE 802.11: authenticated
Mar 13 23:10:19 hostapd: wpci0: STA 00:80:48:76:c1:34 IEEE 802.11: authenticated
Mar 13 23:10:19 hostapd: wpci0: STA 00:80:48:76:c1:34 IEEE 802.11: associated (aid 21)
Mar 13 23:10:19 hostapd: wpci0: STA 00:80:48:76:c1:34 IEEE 802.11: associated (aid 21)
Mar 13 23:10:19 hostapd: wpci0: STA 00:80:48:76:c1:34 IEEE 802.11: associated (aid 21)
Mar 13 23:10:19 hostapd: wpci0: STA 78:d3:8d:bf:ae:a3 IEEE 802.11: authenticated
Mar 13 23:10:19 hostapd: wpci0: STA 78:d3:8d:bf:ae:a3 IEEE 802.11: associated (aid 22)
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:73:8b:7b IEEE 802.11: authenticated
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:78:af:20 IEEE 802.11: authenticated
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:78:af:20 IEEE 802.11: authenticated
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:78:ae:9e IEEE 802.11: authenticated
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:78:af:20 IEEE 802.11: authenticated
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:78:af:20 IEEE 802.11: associated (aid 23)
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:78:af:20 IEEE 802.11: associated (aid 23)
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:78:af:20 IEEE 802.11: associated (aid 23)
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:78:af:20 IEEE 802.11: associated (aid 23)
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:73:8b:7b IEEE 802.11: associated (aid 24)
Mar 13 23:10:21 dhcpd: Internet Systems Consortium DHCP Server 4.1.0p1
Mar 13 23:10:21 dhcpd: Copyright 2004-2009 Internet Systems Consortium.
Mar 13 23:10:21 dhcpd: All rights reserved.
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:78:af:20 IEEE 802.11: associated (aid 23)
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:78:af:20 IEEE 802.11: associated (aid 23)
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:78:ae:9e IEEE 802.11: associated (aid 25)
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:78:ae:9e IEEE 802.11: associated (aid 25)
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:78:ae:9e IEEE 802.11: associated (aid 25)
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:78:ae:9e IEEE 802.11: associated (aid 25)
Mar 13 23:10:21 hostapd: wpci0: STA 00:80:48:78:ae:9e IEEE 802.11: associated (aid 25)
Mar 13 23:10:21 dhcpd: Wrote 0 deleted host decls to leases file.
Mar 13 23:10:21 dhcpd: Wrote 0 new dynamic host decls to leases file.
Mar 13 23:10:21 dhcpd: Wrote 1 leases to leases file.
Mar 13 23:10:21 dhcpd:
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)