ok good. So the question is why doesn't it respond to Neighbor Solicitation. The controlling factor should be the settings for the bridge not the wlan device, because that becomes slaved to the bridge. But we've already established I think that the bridge does respond to NS with a NA message because you can ping from the router, at least it does so over the ethernet port.
I'm a little flummoxed honestly. WDYT @vgaetera any ideas?
If I remove the wlan0 of the bridge, and ping from A->B or B->A, the ping works.
But I need a bridge there. So yeah, it must be bridge settings. Don't know which one, but bridge settings for sure. This post is my only hope for fixing it, as the scenario I'm using is a bit tricky and I've not found anything similar.
bridge with wireless-ethernet where the wireless is in OCB mode. But to be honest, don't think OCB and 802.11p are the problem here, as they can transmit the messages and the ping works without the bridge.
Well the trickiness here is whether OCB mode works similar to AP type mode. It's clearly possible to bridge an AP to ethernet, this is the normal way that OpenWrt configures its access points, but maybe OCB doesn't bridge to ethernet properly for some reason. Relatively few people will have experience with OCB.
But I think the most likely thing is that you need to tune some bridge settings.
Here's a question for you that may elucidate a problem which you could look into.
Suppose you've got C which is on the ethernet wired to B...
C sends a packet ideally destined for A. Suppose somehow B manages to bridge it over to A...
Now A sees that it needs to talk to C so it sends out a neighbor solicitation... and receives a neighbor response. So it knows that C is at MAC address CCCC
So A sends out a packet to MAC address CCCC... why would B receive this and bridge it to ethernet? How does B know to do anything at all with this packet?
In AP mode, the AP is "in charge" and it knows it needs to send packets between devices... but in OCB mode it seems it's designed to just have different devices talking directly to each other, so in OCB mode we expect that if a packet isn't MAC addressed to B then B won't do anything with it... right?
I think this may be the main issue with your setup. let me know what you figure out in answer to these questions, I'm interested to know.
Oh, I think I get it. I’ll draw a schema of my desired scenario later, so maybe you have the solution for it, because I can maybe remove the bridge and use some kind of routing. Or maybe it’s possible to configure some parameters of the bridge but I completely have no idea about it.
There is the scenario with the main idea. The final goal is to communicate A machine with C, via B.
I think it's pretty easy to understand but if you have any doubt I'll answer it super fast. I'm also thinking that probably bridge is not working correctly, so the options are configuring it or some kind of routing.
Yes I think routing is likely to work a lot better, because packets will be mac addressed to the router and hence B will hear the packets sent to it for routing purposes.
To do this you need to assign a prefix to the B machine wlan interface, and B should advertise that prefix on the wlan, and should advertise that prefix with the "on link" option set to false on the ethernet to C... Then C will know to send packets to B on ethernet for delivery to the prefix that A is on.
Oh! Okay, it sounds good. Where's the place to configure those options, /network file?
Because I've seen some options for ipv6 in those files, but for example "ip6assign" is normally used when you're a router and want to distribute some subnets, right?
Yes you can request say a /60 from C and then assign a /64 subnet to B ethernet and a different one to B's 802.11p wlan
Could I divide it into something smaller than /64? Because I already was assigned a /64 to do it (I'm working on a bigger project).
64 is the smallest compliant subnet in IPv6. There is no shortage of IPv6 address space you should be able to get more subnets. Maybe just request one more /64 manually and do static routing?
Mmmmm, and if I choose the two different /64 subnets for eth1/wlan0, for example
:3::/64 for eth1
:4::/64 for wlan0
I should put that on /network file with the ip6assign option?
If you're doing it statically just set up the interface statically. Ip6assign is for when you're doing prefix delegation by asking upstream to give you a block via dhcpv6
So literally not autoconf (SLAAC) or DHCPv6, just literally static assignation on interfaces in /network file right?
On router B yes. If possible. Basically router B just puts a /64 on the wlan 802.11p interface, and has a different one which it gets from C presumably for the ethernet interface. Then it advertises on the ethernet that it routes off link for the 802.11p prefix. That way people on the ethernet will know how to talk to the wifi
Ohhhhh! Amazing. Didnt know about this off link functionality. I will test it tomorrow morning and i will put the results here.
Yes, I'm not sure whether odhcpd does the right thing here. If it knows the prefix for the 802.1p network, does it advertise it with the on-link flag false on the ethernet? I don't know. This might be something that OpenWrt doesn't/can't do at the moment, or it might be the default thing and automatically works. I'm not sure.
I've some questions before implementing it:
1 - Does machine B acts as a router now? Because if I put two different subnets /64 on the two interfaces (for example 3:: for wlan0 and 4:: for eth1), I should "explain" to the real router that machine B is his gateway to get wlan0 subnet, right?
2 - B needs to receive the two prefixes (::4/64 ::3/64) in order to assign them? How am I sure that it receives both? What happens if B only gets, for example, ::4 via router advertisement. How can he assign another prefix that (in theory) he doesn't know. Or can he?
3 - B will send :3::/64 prefix for the wlan0 interface, so A will receive it and autoconfigure, right? But in that case, does machine B needs accept_ra=2 and forwarding enabled? Otherwise B won't send the prefix to A, no?
4 - Where do I have to modify that onlink option? I mean, where's that located? EDIT: In the network file I found it.
Sorry for the mess! 
Yes B is now a router. The simplest thing is for B to be set up statically. You will be in charge of determining the prefixes and B doesn't need accept RA. Ideally B would advertise it's prefixes and C would accept RA =2 on the B-C link and that's how it would learn about B and the wlan prefix.
I'm not sure if odhcpd is going to do the right thing but it should advertise the wlan prefix as not on-link to C.
This topic was automatically closed 0 minutes after the last reply. New replies are no longer allowed.