4 ms·

Out of interest, why didn't you just bridge the two interfaces? Did you want everything on a separate subnet? (maybe I missed that but but you mentioned before

Out of interest, why didn't you just bridge the two interfaces? Did you want everything on a separate subnet? (maybe I missed that but but you mentioned before how everything used to be directly plugged in anyway)

eqvinox 5y ago
You can't bridge regular 802.11 wireless into ethernet at the client side. The on-air addressing requires the client MAC address to be the same as the ethernet packet's sender. 802.11 has the concept of "transmitter address" and "receiver address" in addition to source and destination. Those are MAC addresses too, but they're relevant for the on-air radio management. Things like RTS, CTS, ACKs, and fancier things like beamforming and sounding. The problem is that the design only includes 3 address fields in on-air frames; the AP can specify separate SA and TA (i.e. send a packet for somebody else, SA=real source, TA=AP MAC, RA=DA=client.) There is no mechanism for the client to do the same thing; that would require 4 address fields. Coincidentally, 4 address fields is exactly what you get with "WDS" / "Wireless Extender" / ... modes. However, these need to be supported, enabled and configured on both the AP and client. The author of the post seems to have no access to the AP to do so (and the AP possibly doesn't support it anyway.)
- amaccuish 5y ago
  How did my AirPort Express or do my Sonos do it? Just rewrite the MAC Address? (is that then not technically bridging from terminology pov?)
  - eqvinox 5y ago
    Yes, one of the worst hacks in all of home networking is exactly this... rewriting the MAC address. aka "MAC NAT." Alternatively, proxy ARP + proxy ND can also work. The Apple stuff may be able to autonegotiate over some proprietary handshake if it's an Apple AP and Apple Extender. There is also a new standard that covers 4-address frames, 802.11ak; I have no idea how widely that is adopted though — it was only released in 2018[1]. [1] https://standards.ieee.org/news/2018/ieee_802_11ak-2018.html https://standards.ieee.org/news/2018/ieee_802_11ak-2018.html
    - amaccuish 5y ago
      Thank you for your expertise! Out of interest, why is it a hack? Does it break things elsewhere? Why is it better to do it at the IP level?
      - eqvinox 5y ago
        NAT, in general, is a hack that requires holding a lot of state in order to squeeze multiple devices into a limited number space. On a technical/complexity level, IP NAT is much worse because you need to hold much more state, i.e. you need the UDP/TCP flow information to rewrite correctly. However, MAC NAT is the pinnacle of stupidity for an entirely different reason: there should be no need for it. MAC addresses only have local significance, and while there are some long-term concerns about them running out, there is absolutely enough of them right now. There should simply be no need to do MAC NAT, if only it wasn't for the shortsighted 802.11 design decision to go with 3 addresses in the header. FWIW, MAC NAT is almost the same thing as a router with ARP/ND proxying turned on, though possibly implemented on a different level. This is the technical reason it's an extremely stupid hack: proxy ND/ARP provides pretty much the same thing, but in a much cleaner way. (The difference is that with proxy ND/ARP, the "router-ish-bridge" assumes ownership of the lower-layer exchanges, i.e. ARP & ND, and just does normal routing with that. MAC NAT, meanwhile, tries to be clever and just forward ARP and ND. Reasons for doing that are ... extremely thin IMHO.)
        dboreham 5y ago
        > pinnacle of stupidity Thanks for that. Filed away for future use.

eqvinox 5y ago

You can't bridge regular 802.11 wireless into ethernet at the client side. The on-air addressing requires the client MAC address to be the same as the ethernet packet's sender. 802.11 has the concept of "transmitter address" and "receiver address" in addition to source and destination. Those are MAC addresses too, but they're relevant for the on-air radio management. Things like RTS, CTS, ACKs, and fancier things like beamforming and sounding. The problem is that the design only includes 3 address fields in on-air frames; the AP can specify separate SA and TA (i.e. send a packet for somebody else, SA=real source, TA=AP MAC, RA=DA=client.) There is no mechanism for the client to do the same thing; that would require 4 address fields. Coincidentally, 4 address fields is exactly what you get with "WDS" / "Wireless Extender" / ... modes. However, these need to be supported, enabled and configured on both the AP and client. The author of the post seems to have no access to the AP to do so (and the AP possibly doesn't support it anyway.)

amaccuish 5y ago
How did my AirPort Express or do my Sonos do it? Just rewrite the MAC Address? (is that then not technically bridging from terminology pov?)
- eqvinox 5y ago
  Yes, one of the worst hacks in all of home networking is exactly this... rewriting the MAC address. aka "MAC NAT." Alternatively, proxy ARP + proxy ND can also work. The Apple stuff may be able to autonegotiate over some proprietary handshake if it's an Apple AP and Apple Extender. There is also a new standard that covers 4-address frames, 802.11ak; I have no idea how widely that is adopted though — it was only released in 2018[1]. [1] https://standards.ieee.org/news/2018/ieee_802_11ak-2018.html https://standards.ieee.org/news/2018/ieee_802_11ak-2018.html
  - amaccuish 5y ago
    Thank you for your expertise! Out of interest, why is it a hack? Does it break things elsewhere? Why is it better to do it at the IP level?
    - eqvinox 5y ago
      NAT, in general, is a hack that requires holding a lot of state in order to squeeze multiple devices into a limited number space. On a technical/complexity level, IP NAT is much worse because you need to hold much more state, i.e. you need the UDP/TCP flow information to rewrite correctly. However, MAC NAT is the pinnacle of stupidity for an entirely different reason: there should be no need for it. MAC addresses only have local significance, and while there are some long-term concerns about them running out, there is absolutely enough of them right now. There should simply be no need to do MAC NAT, if only it wasn't for the shortsighted 802.11 design decision to go with 3 addresses in the header. FWIW, MAC NAT is almost the same thing as a router with ARP/ND proxying turned on, though possibly implemented on a different level. This is the technical reason it's an extremely stupid hack: proxy ND/ARP provides pretty much the same thing, but in a much cleaner way. (The difference is that with proxy ND/ARP, the "router-ish-bridge" assumes ownership of the lower-layer exchanges, i.e. ARP & ND, and just does normal routing with that. MAC NAT, meanwhile, tries to be clever and just forward ARP and ND. Reasons for doing that are ... extremely thin IMHO.)
      - dboreham 5y ago
        > pinnacle of stupidity Thanks for that. Filed away for future use.