Just one device A that needs to communicate to B.
B has a bridge between eth1-wlan0, but not sure if the packets received by wlan0 (when I ping from A to B) can pass through the bridge and go to eth1. I say that because wlan0 has no ipv6 address BUT the br-lan has.
And, by the way, B allows A to access to some virtual machines I have in other subnets that B knows but not A, (by routing).
@vgaetera Okay, gonna remove wlan0 from ifname.
None of the "ports" in the bridge get ip addresses, only the bridge itself so this is normal.
Ok so nothing special is needed just have B in AP mode and A in client mode.WDS is only needed if A needs to bridge to its own ethernet network.
Oh, okay, but when you mean "AP mode" is not like real access point mode, right? Because they are in OCB mode.
Gotcha I hadn't read about OCB until just now. I'm afraid I don't know how that works even after reading a little. The question is does OCB allow broadcast/multicast packets? If so then router advertisements will traverse the link, if not then RA will not arrive at station A and it won't know about the prefix.
When you make sure that ip_forwarding is off and accept_ra=1 on station A does it get an IPv6? If you wireshark on station A do you see the RA packets?
Well, multicast/broadcast packets are allowed because they belong to a superior layer. But yeah, I actually have the two machines in channel 180 (5900MHZ) and in machine A i don't receive nothing, I'm looking with "tcpdump" but I receive nothing (RA is what I want).
IPv6 multicast packets are sent with a special MAC address destination, the question is does the layer 2 deliver those ? Apparently the answer is no? That seems like a huge flaw. If you capture on the ethernet port on station B do you see RA packets? If you see them there and not at station A it indicates an issue with multicast that prevents RA over 802.11p
I just did it but "brctl show" only shows that br-lan is a bridge with eth1 interface. It does not have wlan0 in it.
Explains the MAC layer for IPv6 multicast. The question is does OCB send these frames and does station A receive them?
Now machine A has IPv6 global address, and tcpdump shows a lot of messages, so I guess the communication is working. The strange part is that I can't communicate between them with a ping, I'll try to guess why.
are you doing ping6 GLOBALADDRHERE or maybe you use ping and it only does ipv4 on openwrt? I'm not sure. try ping6
Verify that you have attached the wireless interface to the network:
uci show wireless
The wireless interface is not created on uci wireless file, because I had to create it with custom settings from command line. In machine B, where I have the bridge, I created the interface in a "basic way" in /etc/config/wireless and then customized it later.
But not in machine A, in this machine my wireless file is completely useless.
I'm using ping6 ofc.
When I write "ip neigh" to see neighbours, in both machines I can see the other BUT marked as "FAILED", not as "REACHABLE".
sounds like it's time for a packet capture.
I did, and A machine receive two different Router Advertisement. One from :1499 (machine B) and another from :7211 (the router of the subnet of B). Of course B also receive RA from that :7211 router.
The problem is that, I don't know why, they are unreachable. Is like A and B know each other as neighbors but they can't communicate via ping6 or traceroute6.
I've read that maybe the problem is that B needs to pass A a subrange of the prefix he has, for example if B gets a /64 maybe he should send a subnet prefix range (for example 86, i dont know) to A. Because A maybe thinks he is already in B subnet and the communication is "direct" when in reality it isn't.
Am I right? How can I do this on B?
PS: And by the way, I fixed the bridge problem adding manually the interface wlan0 to the bridge with "brctl addif br-lan wlan0".
B shouldn't be sending RA at all if it's not a router.
What you need to packet capture is the neighbor discovery packets. Connect everything up and then packet capture on both ends and then try to ping... You need to see those neighbor discovery packets going across the radio link and being processed
I removed the "router behaviour" from B machine. Now A only receives RA from the real router, and B does aswell. With wireshark I saw the neighbor discovery packets in machine A (so they come 100% through radio link, as is the only interface connected).
The conclusion is that A and B know eachother as neighbors but they can't communicate. I don't know the reason.
As you can see, they send to each other neighbor messages.
Machine A: 5483
Machine B: 1499
I tried a ping6 from A to B. It didn't work but when I see the capture I see those messages.
After the flurry of ND packets does ip -6 neigh show that the devices indeed know each other? Perhaps there's a firewall issue that prevents the ND packets from being received by the kernel?
Yup, ip -6 neigh shows that they know eachother but it's marked as FAILED, a.k.a they can't communicate eachother via ping6. That's so strange, to be honest I don't know what more to do.
