Spudz76 <spud...@gmail.com> writes: > On Sun, 2010-01-10 at 12:02 +0100, Ferenc Wagner wrote: > >> Felix Fietkau <n...@openwrt.org> writes: >> >>> On 2010-01-08 6:24 PM, Ferenc Wagner wrote: >>> >>>> Stefan Bethke <s...@lassitu.de> writes: >>>> >>>>> Am 08.01.2010 um 16:57 schrieb Ferenc Wagner: >>>>> >>>>>> However, I failed to use it in client mode: it associates with the >>>>>> AP, but doesn't receive IP packets (I simply bridge it to the LAN, >>>>>> and try DHCP from the laptop). >>>>> >>>>> See the numerous forum posts on why client bridging does not work. >>>>> You'll need to run udhcp on the router itself, or configure a fixed >>>>> ip. >>>> >>>> Many thanks for the quick pointer! I guess you're referring to >>>> https://dev.openwrt.org/ticket/5749, right? I can accept that there are >>>> technical reasons which make client bridging impossible, but don't fully >>>> understand them from the ticket. And I'm curious, so I'd be grateful >>>> for some further explanation or pointers. Why is the source MAC address >>>> missing from "the" packet (travelling in which direction)? >>> >>> The source MAC is missing in packets from STA->AP >>> The destination MAC is missing in packets from AP->STA >>> These MACs are missing, because they are unnecessary when not using >>> bridging, so they left them out in the standard. This also serves as MAC >>> spoofing protection, as you cannot fake your MAC address without >>> associating with a different ID. >> >> Thanks for the explanation and the picture, I understand the problem >> now. Isn't this something that could be worked around by ebtables snat? >> Or is that what's considered "an ugly layer 2 nat hack" by nbd in the >> ticket? Why is this any worse than IPv4 NAT? I agree that WDS is the >> right tool for such jobs, but that isn't always an option. > > In many (most?) cases, the wifi driver does not allow you to modify the > MAC address. It's all about spoof protections as was mentioned before.
Sorry, I don't get why I'd want to modify the MAC address (of the wifi card?), would you please explain? Even if I did, that really shouldn't be a problem with the rise of softmac drivers, should it? > greater than the 24Mbit/s or so maximum you would otherwise see over > normal "54Mbit" 802.11g (wifi overhead plus tunnel overhead plus > bridge overhead brings it down to around 50% of the link rate because > each 1500-byte packet ends up being almost twice that). I don't get you again. Bridge overhead is zero (in packet size), as far as I know. OpenVPN overhead depends on the exact setup, but without security it can be less than 10 bytes. I don't know much about 802.11, but I feel like its overhead is in the 30 bytes range, not near 1 kB... -- Regards, Feri. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
