[OpenWrt-Devel] [PATCH] axs10x: initilaze network for wireless access-point
Alexey Brodkin
Alexey.Brodkin at synopsys.com
Mon Nov 23 11:20:46 EST 2015
Hi Jonas,
On Mon, 2015-11-23 at 16:54 +0100, Jonas Gorski wrote:
> On Mon, Nov 23, 2015 at 9:28 AM, Alexey Brodkin
> <Alexey.Brodkin at synopsys.com> wrote:
> > ARC SDP board sports only 1 network interface - eth0,
> > so to operate as an access point it requires at least
> > another interface (preferably wireless),
> > so USB Wi-Fi dongle is what we want.
> >
> > And with USB Wi-Fi dongle attached ARC SDP board could be
> > used as a "dumb" wireless access point.
> >
> > Now with modified network setup script it is only required
> > to enable wireless radio on the first boot with
> > -------------->8------------
> > uci set wireless.radio0.disabled=0
> > uci commit wireless
> > wifi
> > -------------->8------------
> >
> > Note if by the time initscripts are executed USB Wi-Fi
> > dongle not yet recognized and set up by Linux kernel
> > its autodetection by "wifi" tool may not happen
> > automatically. In that case before issuing command above
> > one needs to populate /etc/config/wireless config:
> > -------------->8------------
> > wifi detect > /etc/config/wireless
> > -------------->8------------
> >
> > Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
> > Cc: Felix Fietkau <nbd at openwrt.org>
> > Cc: Jo-Philipp Wich <jow at openwrt.org>
> > Cc: Jonas Gorski <jogo at openwrt.org>
> > ---
> > target/linux/arc770/base-files/etc/uci-defaults/02_network | 12 +++++++++++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/target/linux/arc770/base-files/etc/uci-defaults/02_network b/target/linux/arc770/base-files/etc/uci
> > -defaults/02_network
> > index 87cfe81..7503f85 100644
> > --- a/target/linux/arc770/base-files/etc/uci-defaults/02_network
> > +++ b/target/linux/arc770/base-files/etc/uci-defaults/02_network
> > @@ -14,7 +14,17 @@ ucidef_set_interface_loopback
> >
> > case "$( arc_board_name )" in
> > "arc-sdp"*)
> > - ucidef_set_interface_raw "lan" "eth0" "dhcp"
>
> Keep this line instead
>
> > + uci set network.lan.type='bridge'
>
> And only add this line.
>
> > + uci set network.lan.ifname='eth0 wlan0'
>
> This is unneeded, as netifd will automatically join the wifi interface
> to the bridge in the default config (with the option network 'lan'
> line in /etc/config/wireless).
Yep, I did figure that out just now.
So will re-spin it.
>
> > + # With multicast-to-unicast enabled kernel crashes
> > + # on the first wireless client connection in
> > + # br_multicast_add_group() -> br_port_group_equal() ->
> > + # ether_addr_equal() due to misaligned read.
> > + # For some reason "src" being "eth_hdr(skb)->h_source"
> > + # is not 16-bit aligned as it is supposed to be.
> > + uci set network.lan.multicast_to_unicast='0'
>
> And this doesn't belong here at all, this is a complete separate issue
> and should be fixed where it occurs, not worked around (sounds like an
> issue in the ath9k-htc driver). Does ARC not provide emulation of
> unaligned accesses like mips does?
Well in ARCv1 we can only handle unaligned access in software.
Here I mean handle unaligned exception in Linux kernel and copying
data back to caller. But this essentially comes with performance penalty.
On ARCv2 we may have that feature right in hardware though still not
necessary - remember ARC is highly configurable architecture and real
users (I mean vendors of ASICs) may use or not use each particular feature.
But I'd say unaligned access highlights a problem here (and I'm not yet
to blame yet anybody for now). Because what happens compiler attempts
to use half-word (two-bytes) read () on a byte-aligned address
(something like 0x4000_0001). And that happens in ether_addr_equal()
comment for which clearly states:
https://github.com/torvalds/linux/blob/master/include/linux/etherdevice.h#L308
---------------->8-----------------
Please note: addr1 & addr2 must both be aligned to u16.
---------------->8-----------------
So what we seeing here "src = eth_hdr(skb)->h_source" is not 2-bytes
aligned (=0x9e3c766b) which I believe should not be the case , right?
I mean even if unaligned accesses could be supported something doesn't
match expectations of ether_addr_equal().
Any thoughts?
-Alexey
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list