From: Dave Taht <dave.taht@gmail.com>
To: bloat-devel <bloat-devel@lists.bufferbloat.net>,
openwrt-devel@lists.openwrt.org
Subject: pure routing.... generating a sane mac addr on the wndr3700 in cerowrt?
Date: Sun, 19 Jun 2011 09:14:08 -0600 [thread overview]
Message-ID: <BANLkTimi1NoNaBrZSWkgsij2OjCWvVTEjA@mail.gmail.com> (raw)
I really want to stop bridging on cerowrt[1], entirely, at least for now.
Coping with multicast, doing saner traffic shaping, trying to come up
with an qdisc estimator that handles multicast right in the presence
of multicast's monsterous effects, and especially - *only seeing
traffic generated from the wireless network while looking at the
problems therein*, is what's driving me.
I don't care about the performance impact of routing vs bridging right
now. In fact I think the performance impact of bridging a GigE wired
network to a 54Mbit wireless impact is rather easily demonstrated
with things like IPTv or any even modest level of multicast traffic,
but the latter is hard to prove without testing.
1) What's stopping me is figuring out the depths of the openwrt code
to generate a valid, usable mac address for the undefined wndr wired
card on first boot. I figure it should come from the second wireless
interface, get the local bit defined, and go to the top of the
allowable range that the wireless interface pulls from to generate
it's SSIDs, then slam the generated address into
/etc/config/network....
2) I generate a non-bridged network on the nano-m5s (which has valid
mac addrs for all interfaces, I think) and babel loses the ability to
send mc packets to any interface. Other normal network behavior (eg,
the interfaces work for normal connects) ensues, however.
I've managed to get similar behavior on the wndr when I assign an
arbitrary mac addr to the ethernet interface and unbridge them. With
the vlan enabled, wired networking stops working entirely, with the
vlan disabled, networking worked, but babel stopped. So my assumption
is that there is code buried in the bridging and/or firewall code that
enables some kernel feature or another.
(I'd run into similar problems a year back:
http://answerpot.com/showthread.php?1484403-IFF_RUNNING%20and%20hostapd
which I thought were solved
)
Just to add to my test set, I've got a kvm and dreamplug build popping out soon.
--
Dave Täht
http://www.bufferbloat.net
1: http://www.bufferbloat.net/projects/uberwrt
next reply other threads:[~2011-06-19 14:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-19 15:14 Dave Taht [this message]
2011-06-23 22:58 ` Juliusz Chroboczek
2011-06-23 23:28 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BANLkTimi1NoNaBrZSWkgsij2OjCWvVTEjA@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=bloat-devel@lists.bufferbloat.net \
--cc=openwrt-devel@lists.openwrt.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox