WEBVTT 00:00.000 --> 00:18.200 Hello everyone, next talk will be given by Jo Kina Madurka, and the name of the talk is APUP 00:18.200 --> 00:23.200 100 line hack to make Wi-Fi great again. 00:23.200 --> 00:30.200 Thank you for being here. 00:30.200 --> 00:39.560 So APUP is what I've been working into the last year, in the context of a grant we received 00:39.560 --> 00:47.200 from RDC, this radio amateur association of United States that granted ultramonded. 00:47.200 --> 00:55.840 And we developed a few things to make a machine at work easier for people also to 00:55.840 --> 01:07.880 mind time and deploy, and APUP is one of those pieces, let's get into it. 01:07.880 --> 01:18.120 So in early 2000s, we had 50K, 56K connection, can you remember those? 01:18.120 --> 01:30.880 If you don't remember, well, I unlock some memories. 01:30.880 --> 01:48.760 So there was no broadband, no Wikipedia, no lunch, no market place at the time, and 01:48.760 --> 01:58.600 not even worthy 54G, that little router that became a legend into hacker circles, because 01:58.600 --> 02:04.360 you can change it's firmware and install Linux on top of it. 02:04.360 --> 02:12.800 So it was a different word, but Wi-Fi, except for speed, and other things hasn't changed 02:12.800 --> 02:14.520 that much. 02:14.520 --> 02:22.320 So when people from the city returned to my small town, they were talking about EMEU, 02:22.320 --> 02:30.720 and it was like a wonder for me, I was just a kid, and so I said, don't know, we must have 02:30.720 --> 02:45.240 this ADSL in the small town, so I collected signature, and we managed to get the ISP 02:45.240 --> 02:54.000 ADSL in my small town, but it was even more expensive that 50K connection. 02:54.000 --> 03:03.700 So I thought what if we can share this connection between friends, and I recycled this 03:03.780 --> 03:16.180 all-dealing router, if you notice 11B, I don't know if someone steals this round, 03:16.180 --> 03:23.940 and then build some with yourself antennas, the photo is not mine, but what we did was 03:23.940 --> 03:29.680 not that much different, do you remember the Pringles can with the Wi-Fi angle inside 03:29.720 --> 03:39.080 more or less, and the things, and then I didn't even was capable to properly read English, 03:39.080 --> 03:45.840 but being in a cross-forum, etc, I managed to set up the things, so I could connect to my 03:45.840 --> 03:53.880 device to my own Wi-Fi from the other side of the town, but I discovered, sadly, that 03:53.960 --> 04:01.940 I could not connect with other devices except with cable, because to connect to my home 04:01.940 --> 04:10.180 Wi-Fi, I had to set up the router as a station, so it was not broadcasting a network 04:10.180 --> 04:19.860 anymore, it was just a dumb client, and I asked why, isn't this thing a router, an access 04:19.860 --> 04:28.800 point why is not broadcasting the network anymore, and so I started this journey studying 04:28.800 --> 04:38.440 Wi-Fi routers, it was a young liter hacker with few resources, and basically, how Wi-Fi 04:38.440 --> 04:46.200 works, we have CMA, every Wi-Fi device, when need to transmit something, it just, it's just 04:46.200 --> 04:51.380 like humans, it's ear-reforced, it's okay, no one's talking, I can talk, and send the 04:51.380 --> 04:57.940 Wi-Fi frame, otherwise if someone is talking, okay, let's just leap for a bit, around 04:57.940 --> 05:07.780 them, enter one, and then I'll try again, so quite simple, but work enough good, and 05:07.780 --> 05:14.820 what's inside those frames, we have the frame control, with a lot of bit fields, duration, 05:14.820 --> 05:21.540 address one, which is source, others two, which is the Wi-Fi destination, it's the macadras 05:21.540 --> 05:27.980 of the other Wi-Fi device, we suppose to receive that frame, then we have other three, 05:27.980 --> 05:38.180 which is the actual destination, because beyond that Wi-Fi device, there may be an ethernet device 05:38.180 --> 05:43.680 which is on macadras, which is not the one who transmitted or received directly the 05:43.920 --> 05:49.340 frame, then when it's control and address four, address four as you see, it's 05:49.340 --> 05:57.420 markets as optional, those bits, anyway, get transmitted, but they usually are 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0es, 05:57.420 --> 06:03.480 or they are polluting your spectrum to do nothing, they are there reserved for optional 06:03.480 --> 06:12.380 uses, but almost no one uses them. So, could you spot a reason why access point cannot 06:12.380 --> 06:18.700 talk each other in those Wi-Fi functioning? I didn't say why they cannot. There is 06:18.700 --> 06:29.980 doesn't seem to be a solid reason to not do that. So, here's one buy. I keep bringing 06:29.980 --> 06:37.500 this question up why a Wi-Fi access point cannot speak each other. Why is the actual solid 06:37.500 --> 06:44.540 reason? I could not find it. I kept bringing this argument at Wi-Fi related conference 06:44.540 --> 06:50.460 and so on. And no one had a convincing answer. 06:50.460 --> 06:57.020 Many say, oh, you guessed the standard. You can do that, but yes, why? Why? Okay. And in the 06:57.020 --> 07:04.140 meanwhile, while all those years, past buy many things come up. There was first this 07:04.140 --> 07:11.180 repeat or extend a thing that was like a mix. So, an app, you had another access point, 07:11.180 --> 07:17.180 but the access point behave also as a station. So, you have to configure it to connect 07:17.180 --> 07:21.820 to the other access point and then create a virtual access point on top of that, which is 07:21.820 --> 07:28.860 an actual, a pin put a nut in the middle. So, you can do it once at your house, but if you have to 07:28.860 --> 07:36.060 do it with 10 devices, it's like, and also you have this nut in the middle, which is 07:36.060 --> 07:43.740 untolerable. Then it come out wireless distribution system. The good thing about wireless distribution 07:45.740 --> 07:52.060 system that we will see later again is the fact that you remember that for address that is 07:52.140 --> 07:59.260 optional, wireless distribution system uses it, it's populated actually, and this make it 07:59.260 --> 08:05.340 capable to finally bridge Ethernet connection to Wi-Fi connection seamless without going crazy. 08:07.180 --> 08:14.220 But still, you are limited to a single access point and many, many, when a few stations that 08:14.300 --> 08:19.500 connect, you can't even connect three devices in a row with VDA, with WDS. 08:21.740 --> 08:27.420 Then, Adoc mode, IBSS, came, this was like, I'm many people, very, very 08:27.420 --> 08:34.380 helpful about this, but there was no vendors, but so you get Wi-Fi card, you plug it, you hack with your 08:34.380 --> 08:41.660 driver, but the firmware blob inside, the Wi-Fi card most likely doesn't support it. 08:42.460 --> 08:50.860 Time to precise time synchronization, it's vital to Adoc to work, and this is quite problematic 08:50.860 --> 08:59.660 in a distributed network, and even Linux implementation is terrible, and a maintenance here. Normal 08:59.660 --> 09:05.900 normal devices may have a hard time, if you have an Adoc network, if you, they probably don't even 09:05.980 --> 09:10.780 see it, if they see it, and you have to attempt to connect, they more, most probably crash. 09:13.500 --> 09:25.100 Then 11S got released, it was like an Adoc mode, but more with more modern stuff, but as 09:25.100 --> 09:31.340 cars vendor support, and they making it a bit bloat because they are coded, the routing protocol 09:31.420 --> 09:38.300 between Wi-Fi devices into the standard, and so into the driver, so if a vendor want to 09:38.300 --> 09:47.340 would like to support that, they have to put the routing protocol inside the driver, and another 09:47.340 --> 09:56.300 bad thing about 11S is that bridging it to Adoc network, it was a mess, you have to set up 09:56.300 --> 10:03.580 some node as proxy, you have limited number of proxy and so on, and again normal device doesn't 10:03.580 --> 10:11.580 tend to not support it. Then we got Wi-Fi pre-to-peer, that was from Google, the name was 10:11.580 --> 10:18.620 so-promising, whether so it is, oh, finally someone that doesn't think, but no, it was even greater 10:18.620 --> 10:25.900 delusion, not really pre-to-peer, after discovery, the peer just decided, I'll be the access 10:25.900 --> 10:33.580 point, I'll be the station, and that's it, and it's meant for a funeral, a flight transfer 10:33.580 --> 10:44.220 into between Android devices, and no more. Then multi-AP come out, it's basically nothing new 10:44.220 --> 10:51.660 under the sun, it's with WDS, a plus commercial branding, and over complication, the complication 10:51.660 --> 10:58.140 is tackled down, relying on a central point of control, so if you're central control point 10:58.140 --> 11:06.380 fail, your network say bye-bye, and it doesn't solve the thing again, and then, last one, 11:06.940 --> 11:14.380 easy mesh, again, I'm a shop between multi-AP and repeater, even more complicated, not a real mesh, 11:14.460 --> 11:24.220 not the mesh, we need it. So, 20 years has passed, and Wi-Fi alliance, with multi-billion dollar 11:25.580 --> 11:31.420 budget, couldn't make a proper solution of the real problem, probably because they are not 11:31.420 --> 11:36.540 interested into the real problem, they are more interested in selling you more devices. 11:36.540 --> 11:46.380 So, what's the real reason I'm obsessed point in Wi-Fi, you cannot exchange that 11:46.380 --> 11:53.900 a bit between each other, it's just because it's not written in the 1100A to 11 standard. 11:57.500 --> 12:03.820 So, how can we implement yet? How can we implement a 12:03.820 --> 12:11.740 access point access point communication? It looks something like that may be hard, but I think if we 12:13.580 --> 12:20.380 have two access point, what if the access point one, when it receive a beacon from access point two, 12:20.380 --> 12:26.300 be it like if that beacon was actually an association request from a station, and same goes 12:26.380 --> 12:37.900 from a P2, when a P1 received an beacon. So, I investigated how I could do that, 12:37.900 --> 12:43.820 what's actually deal with access point beacon is a step B, this is good, because a step D is also 12:43.820 --> 12:51.020 a deal with the association request, so we can fix the thing all in one place. The code is pretty 12:51.100 --> 13:03.100 convoluted, but studying it, I managed to to implement it unexpectedly, but it was possible. 13:04.540 --> 13:14.700 So, there is the code, that's actually what I said it. Okay, I'm fake file. 13:15.020 --> 13:22.860 Oh, now it's start the interesting part. 13:33.100 --> 13:44.540 Okay, PPC. So, basically this function, a PUP process beacon, get an access point 13:44.620 --> 13:55.980 beacon, and I'm going to start the struct, and it first of all, it can compare if the address 13:55.980 --> 14:11.100 is over, so maybe we got a frame mirror, so in that case you know it, and then check if SSID is the same 14:11.180 --> 14:20.620 of our SSID. This way, basically, it's executed only if the beacon received, that's the same SSID, 14:20.620 --> 14:33.180 so the same network name. Then it extracts, basically, and get the Macadras, and put it into the 14:33.340 --> 14:40.140 station list, which is a struct of the OSTAP demand time, where it keep all the station in OSTAP about. 14:45.100 --> 14:55.100 It extracts a few fields, so this just add this a station, put this flag. So, basically, 14:55.740 --> 15:01.660 we are pretending a station is associated with, but an access point will not do that by itself. 15:02.540 --> 15:10.380 So, we are, do you see this flag? Bullan station outrised? We are setting that flag in the 15:10.380 --> 15:15.500 station structure, so I'm saying, okay, this is an access point with my same SSID. Let's 15:15.500 --> 15:17.980 read in as a, as a, as a, as a, as a, as a station. 15:23.500 --> 15:29.820 In the, emit this event, basically, let's say, oh, I have outrised a new station, so all the other 15:29.820 --> 15:35.180 part of the code, even the kernel, get notified about a new station getting outrised. 15:36.220 --> 15:42.780 So, it sets that autorization mechanism is open, because encryption is not yet supported. 15:44.460 --> 15:51.740 And then extract the capability, so the, the, the funny things is that you know, in a beacon, 15:51.740 --> 15:57.660 you get almost everything you get in an association request, all the data, so the capability, 15:57.820 --> 16:05.340 the bandwidth support, all everything, as a, an authorization request, contain, but in a different 16:06.460 --> 16:11.340 order. So, you basically extract all those fields and sort them out, 16:12.780 --> 16:18.780 fully most of the function to do that are already inside of that, because it does this kind of 16:18.780 --> 16:26.460 things for other, for other stuff, then copy the, supported rates, copy the capability. This is 16:26.540 --> 16:35.500 one of the little differences. So, if a station support 11 and rates, the association request, 16:35.500 --> 16:44.540 we left this flag, WMM, set it, while in case of an access point, even it's support 11 and 16:44.540 --> 16:50.380 rates, we will not have this flag set. So, we just check if there is 11 and capabilities, 16:50.380 --> 17:01.820 we check, we set that flag manually. Copy order, capability is, copy 11, AC, 17:01.820 --> 17:12.460 capabilities, copy, AC, capabilities, which is A, X, 11, A, X, capabilities, 11, B, E, 17:12.540 --> 17:25.020 capabilities, and so on, then update some state, get the station ID, and finally set this flag. 17:25.580 --> 17:33.580 Ah, the association request has been accepted successfully, and then set the 17:34.540 --> 17:38.700 timeout to null function. This is an internal set of the functioning, basically it 17:39.660 --> 17:46.060 will do every time a station send a packet, this pointer gets reset to null function. 17:47.020 --> 17:56.300 So, it means for a bit of time, this station will not timeout, but if a bit more time passes, 17:56.300 --> 18:03.420 at next iteration, the pointer will not be a self-null function, so we will timeout it. 18:03.980 --> 18:09.660 It's like a pretty complex way to just put time to leave to a station, 18:11.260 --> 18:18.300 relying on a function pointer. Okay, set the autorized flag, it's the associated flag, 18:18.300 --> 18:24.460 and finally, add it as a proper station, autorized station with all these capability and so on. 18:24.460 --> 18:30.060 You can see all those, all those flags and information we extracted, six years and blah blah, 18:31.020 --> 18:37.260 at least at the year. We said, we call this function which again, set it as autorized, 18:38.540 --> 18:47.500 set the flag, create a new interface, because it is using forever's mode, so we need to create 18:47.500 --> 18:55.740 a new interface for just this, access point, peer connection, and set it as a VDS. Do you 18:55.740 --> 19:04.220 remember, I said, when WDS, we will see this again, because to work this work, we need to use 19:04.220 --> 19:10.620 for addressing mode that is just using that optional, reserved field, that for others, 19:10.620 --> 19:19.100 that already in the standard Wi-Fi frame. And that's this set with WDS, STA, is what 19:19.660 --> 19:31.980 make that actual. And that's it. This is the function that actually make an access point beacon, 19:31.980 --> 19:42.220 BF, lag, and association requests, not much, not much code, but when where we get this, 19:42.220 --> 19:53.500 this function called, OSTAPD have a loop that handle all the beacon that arrives from the kernel, 19:55.420 --> 20:02.060 and just do a bit of things with those beacon, add them, add the property of the access point 20:02.060 --> 20:09.660 to a list for Wi-Fi coexistence, and then call that function, and that's it, finish. 20:10.060 --> 20:18.700 No, no, not finish the presentation, finish the code, but we are about to finish the presentation. 20:22.700 --> 20:28.780 So it wasn't that difficult to make this work, and actually it's embedded and expected, 20:28.780 --> 20:36.780 and pretty elegant too, if you see like, supporting a new, when a new Wi-Fi standard came out, 20:36.780 --> 20:41.580 it's just adding a new line for supporting the new capabilities. Just a new line to copy the new 20:41.580 --> 20:52.140 flags, not not difficult to maintain at all. But what about performance? One of the criticism 20:52.140 --> 20:57.980 I got when I proposed this year. Yeah, you maybe you could do that, but performance would be shitty, 20:57.980 --> 21:03.500 because if there is no the central access point that do coordination, you see, it will be, 21:03.500 --> 21:11.020 well, so this is early testing with the very cheap devices. You can see like it's full speed, 21:11.900 --> 21:18.140 in normal app station mode, it gets this fast, and a PUP gets this fast too, 21:18.860 --> 21:26.060 is almost 200 megabit, the real TCP traffic, not just association, real TCP traffic, 21:26.060 --> 21:38.860 and then after a few fixes, we got up to more than 200 megabits per second, the real TCP traffic. 21:42.620 --> 21:51.100 So performance is not a problem. This is this as many advantages, although the previous solutions, 21:52.060 --> 21:58.060 there is no need for driver support. The support in the driver is the same as a P, the driver 21:58.060 --> 22:04.220 doesn't even know is running an a PUP network. It's just known is running a plane access point mode, 22:05.260 --> 22:13.900 and AP mode is very well supported in most Wi-Fi drivers. Every serious Wi-Fi driver support 22:13.900 --> 22:22.780 AP mode pretty well, because it's what everyone is using, and what works for AP mode, 22:22.780 --> 22:31.580 works also for a PUP too, and this means that it's seamless hardware of loading. So basically, 22:31.580 --> 22:39.260 a new Wi-Fi version to have this such great speed, many functionalities get off-loaded to the hardware, 22:39.260 --> 22:43.980 are directly implemented into the hardware, but they just work with AP and Station mode, 22:43.980 --> 22:50.060 not with 11S or other modes, and with a PUP, because it doesn't require any modification, 22:50.060 --> 22:56.620 the driver is actually believing it's gave us a plane AP, it works too, can bridge seamless with 22:56.620 --> 23:05.660 Ethernet like WDS, but you can also not do it, you can run a custom routing protocol in user space, 23:05.660 --> 23:12.460 whatever you like on top of a PUP, it's agnostic, you don't need for extra virtual access point network, 23:12.460 --> 23:23.180 and you name it. So, I know the problem, another crisis mode, but no one will accept this, 23:23.740 --> 23:31.500 okay, open WRT already merged this, and on the WRT it didn't have a need to do a pull request, 23:31.580 --> 23:38.620 they sell the patch online, and they included it, then I got notified by them because they find a 23:38.620 --> 23:44.380 typo, and said, ah, we find this typo on your patch, please fix it, and I fix it it, so I know because 23:44.380 --> 23:51.740 of that, I proposed it to OSTEPD mailing list, the only comment I got was about Tab and Space, 23:51.740 --> 23:58.220 Intent, Intent, or most irrelevant, basically their policies, if it's not in the standard, 23:58.220 --> 24:10.540 they try to not merge it, and so at this point, you can help too, we need, because interface is 24:10.540 --> 24:17.660 represented, those IP are created dynamically, we need better support in it native the dynamic device 24:17.660 --> 24:25.420 support in OpenWRT, also authentication and the encryption support not open, but the our 24:25.580 --> 24:32.140 with restructured authentication setups need to be implemented, and then please engage with Wi-Fi 24:32.140 --> 24:40.380 Alliance, so they consider to fix the standard once for all, and then merge it into OSTEPD. 24:43.020 --> 24:48.060 If you're interested, there are further reading, I'll publish this presentation later, so you can 24:48.140 --> 24:55.580 click the link, the notes, I took while implemented this, I implemented also a PUP support in 24:55.580 --> 25:02.780 LibreMesh, which is this meta-firmware that you can use it to create frameworks that 25:03.900 --> 25:08.860 once is started in the device, you can just put the device around and they self deploy, 25:08.860 --> 25:17.020 without, without more trickery, free-funk use a PUP2, and they posted about it, I got interviewed by 25:17.100 --> 25:22.700 Free-funk Radio, also there is another talk about the issue, which has been recorded, and 25:23.660 --> 25:25.340 let's see, do you have some questions? 25:38.060 --> 25:46.620 Hi, great, great stuff really, thank you, it happened with LTE also, but also with TLS protocol, 25:46.700 --> 25:51.820 like it got written to be much simpler, do you think we're going to get 8 to 11? 25:53.900 --> 25:58.300 Is that that to be like very simple thing, finally? 26:00.940 --> 26:09.180 I'm not expert of LTE protocol, for what I studied of these things, in general, because 26:09.260 --> 26:18.940 it's happened like Wi-Fi alliance, the big voices inside the alliance is not the actual developers 26:18.940 --> 26:24.780 or hackers, it's big companies, which have other kind of interests, the interests is to 26:25.580 --> 26:32.060 and also another kind of mindset, the mindset is, there must be a manager on top of me, the mega 26:32.140 --> 26:40.380 hyper-special director will say you have to implement like this now, so there is always this 26:40.380 --> 26:46.700 hierarchy in this kind of standards, but it's pretty arbitrary, I mean, I think there is no 26:46.700 --> 26:53.260 arteries on why mobile-foying in these rooms could not use LTE network to communicate directly 26:53.260 --> 26:58.060 between each other, and in fact, it could be even convenient in some situation, because 26:58.140 --> 27:05.260 you need very, very much less power to send a frame from your mobile from there to a mobile 27:05.260 --> 27:11.900 for another than sending the frame to a station to a base station that we don't know where it is 27:11.900 --> 27:23.580 and then come back, so I mean, I think it's a mindset stuff, and you can see also when talking 27:23.660 --> 27:29.660 to them, it's like they cannot even realize that's possible, but actually they made it possible, 27:29.660 --> 27:35.660 because I'm not the mentor of CMCACA and the frame Wi-Fi frame structure, that was already existing. 27:42.380 --> 27:52.700 So it seems like you are still relying on WDS in the driver to all drivers support that properly, 27:54.540 --> 28:04.060 so we don't rely on WDS, but we rely just on on feeling that for others, I'd use the 28:04.060 --> 28:11.180 OSTEPD function that's called the set-up VDS station, WDS station, but it's just to enable the 28:11.180 --> 28:20.460 feeling of that for address field, which is already present in the frame, so the driver actually 28:20.540 --> 28:26.140 do nothing, I didn't touch them, I didn't touch the kernel, just feed the feed with OSTEPD. 28:28.780 --> 28:32.780 You talk about authentication and encryption that is still as to be implemented, do you think 28:32.780 --> 28:37.420 there is going to come soon? Is it difficult or is going to create other problems? 28:40.220 --> 28:47.660 Every piece you implement, you are going to encounter many things structured that way with that mindset, 28:47.740 --> 28:53.980 that there is one which is the manager and another which is manager, but most of the things 28:55.180 --> 29:04.540 really need the slight modification to work in another thing, so I don't think it will be 29:04.540 --> 29:11.260 difficult to implement it, and most likely we could reuse, mostly reuse code that is already present 29:11.260 --> 29:23.820 on OSTEPD. When the AP acting as the station, would that AP still work as an AP with its stations, 29:23.820 --> 29:31.100 and how would that work when those two APs provide beacons on different channels? 29:34.060 --> 29:40.700 Yeah, the station will the stations keep seeing it as a normal AP, they keep being treated as 29:40.780 --> 29:48.540 normal stations, so for them it is completely seamless, this modification is just 29:49.740 --> 29:58.060 basically the AP, the other AP gets treated almost like a station too, so for the station is the same, 29:58.700 --> 30:05.820 if the access point are on different channels, well they will not see each other, but that's like 30:05.820 --> 30:12.300 its basic station need to configure themselves in the same channel to connect to an exit point. 30:17.340 --> 30:26.620 I have about four open WRTs in my house, as a practical thing if I just turn on this feature 30:26.700 --> 30:36.700 will I be able to get the best closest AP and all, you know, that's what 8 or 2 we love and 30:36.700 --> 30:45.980 ask for a supposed to fix, right, the machine is that that happens seamlessly with your patch. 30:47.820 --> 30:54.540 This will happen seamlessly, the station, depending on their implementation, at some points 30:55.500 --> 31:01.260 from an AP to another one, this is just part of the standard roaming between different 31:01.260 --> 31:08.860 access points of the same SSID, so basically what this add is that what basically it's 31:08.860 --> 31:17.020 obsolete 11S and all this stuff to make the access point talk each other, so if you can run a cable, 31:17.580 --> 31:22.780 it's always better to run a cable, but if you cannot, or if your is in practical, 31:22.860 --> 31:35.340 your access point will talk each other via Wi-Fi, I was curious whether we can get the RSSID signal 31:35.340 --> 31:44.620 strength of your access point, connect PIGP and sorry, the this protocol from user space, 31:45.580 --> 31:55.980 basically what happens it's all the other things, treat these things as they were normal 31:55.980 --> 32:04.700 stations, so with the IW command, you see when you get do the as a damp the association list, 32:04.700 --> 32:12.860 you will get also the other access point with the signal noise ratio and packet loss resolution 32:13.180 --> 32:24.220 and so on. My question would be what happens if you have not to stay, two access points on 32:24.220 --> 32:31.900 the same channel, but three or four and could it be that you create a loop and then the whole network 32:32.140 --> 32:45.260 breaks down. Sure, you can create a loop. There was an in as light, the second test was made 32:45.260 --> 32:54.780 in a network which was I don't know if 15 or 20 routers in sparse in a place, so many routers 32:54.860 --> 33:03.420 each other, so basically a PUP, if you don't, don't disable the automatic bridging flag, 33:04.140 --> 33:11.580 it will automatically create a bridge that works in simple technologies, but if there is loop, 33:12.140 --> 33:19.260 you just disable the bridging flag and you run whatever route in protocol you want on top of it, 33:19.500 --> 33:27.660 so it just provide to you for each access point inside, it provides a new internet interface, 33:27.660 --> 33:33.260 so you can feed that interface to a routing protocol, for example, but when advanced, 33:33.260 --> 33:41.180 if you want to have a layer to broadcast the main experience, or I mean bubble, 33:41.180 --> 33:46.220 or whatever route in protocol you want to run on top of that, so if you have an network with loops, 33:46.860 --> 33:56.620 you can run whatever route in protocol you want on top of it, just to go from, if I already have 33:56.620 --> 34:05.180 a home network which is protected with WPA, I can't use this right now at least, you can 34:06.140 --> 34:17.180 but the connection between access points will be unangripted, it wasn't something I did on 34:17.180 --> 34:25.260 propose, but people that tested it reported it to me, what they noticed for some reason, 34:26.620 --> 34:33.580 the performance was lower in the links between a P in this case, but I mean, 34:33.660 --> 34:39.100 it's something that is not supposed to happen, but it's happen, and okay, it's not the bug, 34:39.100 --> 34:44.940 not the feature, something we will work on when enable encryption and authentication, 34:44.940 --> 34:51.820 probably what's going on, what I should post what's happening is that when encryption is enabled, 34:51.820 --> 35:02.700 an apple, part of it is of loaded to the hardware, so if frames get transmitted without encryption, 35:02.780 --> 35:09.580 get another path, without hardware of loading, so it's lower, but that's just an hypothesis, 35:09.580 --> 35:13.980 I haven't investigated it yet, 35:32.700 --> 35:43.100 thank you.