[kwlug-disc] OpenWRT: DHCP/VLAN problems
unsolicited
unsolicited at swiz.ca
Sat Aug 13 20:46:28 EDT 2011
No responses, yet? Hmmm.
I don't have the answers, but I have some thoughts. Perhaps the
thoughts are wrong and someone will chime in to dispute them, and
we'll all learn.
Bridging:
- as I understand OpenWRT, it's capabilities depends upon the
capabilities of the chip in the router. No all chips have the same
capabilities, so not all routers can do everything OpenWRT offers. On
the switch, OpenWRT hands off everything to it to process, and largely
keeps its fingers out.
- i.e. As I understand it, most OpenWRT commands actually send config
changes to the chip. Not, and when I get traffic from the chip I'll do
'this' with it. No packet inspection, for example.
- The only time OpenWRT sticks its fingers in traffic is when traffic
crosses the WAN and LAN (switch). Since it hands off traffic above, it
can't do so when crossing chips, and it's at that point that
horsepower matters. In your case, if you have a lot of traffic on your
VLAN between WAN and LAN, you may notice a speed difference from what
you expect.
- Hopefully Cedric or Lori will chime in and tell me I'm all wrong. I
know Cedric has VLANed OpenWRT.
- Upshot on the chips is, to the extent possible, keep all VLANs on
the switch. (So you don't cross WAN/LAN and consume horsepower.)
VLAN:
- for the moment, you might want to just ignore that aspect, just
until you get everything else working. VLAN implementation (in theory)
is just flip the switch - all the other stuff you're doing involves
more complexity to sort out, so keep VLAN out of it for the moment.
- to that end, make everything part of the default VLAN, and come back
to VLAN later. Having everything on a VLAN at all in the first place
is the first step to VLAN implementation. Set it (default VLAN),
forget it, come back later. Perhaps this is better said - make
everything explicitly part of the default VLAN, not implicitly by
having no VLAN specification at all. [Easy to play with VLAN
membership later, when you know everything else is right. At this
later point, testing gets easy - put it on a VLAN, see traffic?, got
it right. No traffic, check what you just did.]
- don't forget there are different types of VLANs. e.g. Port vlan
(anything connected to the port is on that VLAN). When you get that
far, play with that first. Other types require setting each NIC for
which VLAN(s) to listen to. Build to what you really want in stages.
e.g. Having accomplished the latter, you can change from port VLAN.
- you can achieve virtually the same effect by dual-homing NICs.
LANs/masks won't cross each other unless something routes them. If you
having nothing routing them, you have most of what VLANs offer. Not to
say things aren't more 'hackable' but you're just trying to get going
here, and wrap your head around a bunch of stuff.
- a multi-homed NIC, for example, upon which your DHCP server resides,
will let you use one DHCP server to serve all nets. Not to say that's
not true with VLAN, merely that that's an extra level of complexity at
the moment. [You may even have to have multi-home NICs to serve DHCP,
even under a VLAN. I forget.]
- Alternately, keep everything on every VLAN for the moment, take
VLANs away, later. (Just thinking of ease of testing here. Get
everything working, then start restricting traffic, not the other way
around.)
- the device only needs 2 addresses, one each for LAN/WAN. Not 1 per
VLAN. You're managing the switch fabric, not each VLAN. VLAN traffic
just passes through. You manage the VLANs through the 1 address.
- not to say you can't have a VLAN address for each, but it's not
necessary. (Adding complexity, early, I suspect.) By not having an
address, you eliminate your DHCP issues there.
- multi-home one port (listen to all VLANs), when you get that far,
and focus all DHCP issues there.
- for gateways, they can be on the other side of a physical hop, even
if the pundits frown upon it. i.e. routing 0.0.0.0 on 1.2.3.4 can be
something on the other side of the OpenWRT device. (At this level,
it's all Layer 2 hardware routing.)
- set static IPs for addresses. Best practices (IMHO) on any routing
device, anyways. Switches, too, even. You don't want to try to be
solving network issues, only to discover much later that your DHCP
server isn't working, so your statically defined IP routes have also
fallen over.
- IIRC, the wireless and switch are on the same chip.
- routers manage traffic between nets. Full stop.
- firewalls do packet inspection and make judgement calls to pass / no
pass. Mostly layer 3. (Switches are themselves layer 2.)
- nothing says multiple networks can't pass through the same switch
port, they will still never talk to each other (the networks), unless
something somewhere is routing between the networks.
- for what you're developing, why use OpenWRT at this time? Take a
clunker, etc. I'm just thinking of a richer tool environment as you
get your head straight on this / what you want to do. Having
accomplished that, then move to OpenWRT?
- not suggesting you aren't certain of what you're about, merely that
from my own experience, knowing what I want to do, and being able to
tweak the config files that way, ain't the same thing.
Sorry, I've been away from OpenWRT too long, and never had the time to
get that deep into it, to give you specific config lines.
Don't forget - openwrt is on freenode ... take advantage of irc to
help work through the problems when you're in the middle of them.
Paul Nijjar wrote, On 08/13/2011 5:28 AM:
> I have a Linksys WRT54GL running OpenWRT backfire.
>
> Here is what I want:
>
> 0. A trunk with two VLANs (tagged 2 and 3) going in on the "wan" port
> (port 4 on the device). I think that is not yet relevant to
> the problem, but setting up VLANs may be messing other things up.
>
> 1. Two different networks handled by the device:
> - The "WR" network consists of two of the LAN ports (0 and 1)
> - The "66APT" network consists of the other two LAN ports (2 and 3)
> and the wireless device.
>
> 2. No DHCP server running on the device. Both of the networks
> interfaces should have addresses, but they will get those addresses
> from someplace else (say coming in on the LAN ports). Assume that each
> of the WR and 66APT networks has exactly one wired connection which
> answers DHCP requests.
>
> 3. No firewalling or NAT.
>
> So basically I am looking for this device to be a smart switch that
> can offer wireless and handle VLANs, as opposed to a firewall or a
> router.
>
> I have been twiddling with configuration files, but I can't get the
> setup to work right. Even ignoring the trunking, I cannot get the LAN
> ports to accept DHCP requests. In the configuration below, the
> wireless (!) accepted DHCP requests and assigned the "66APT" interface
> an address accordingly, but neither the WR nor the 66APT LAN ports
> will accept DHCP, and I don't know why.
>
> HOWEVER, the LAN ports allow DHCP packets through just fine. If I hook
> up a laptop to one port and a cable from my DHCP server to the other
> LAN port in a group, then the laptop gets a DHCP address just fine.
> But the WRT54GL does not accept DHCP requests itself, and I am not
> sure why. I suspect I do not understand Linux bridging well at all.
>
>
> Here are some ways I twiddled the files:
> - Clearing the firewall file entirely
> - Twiddling with making port 5 (the internal port connected to the
> CPU) tagged or untagged
> - Twiddling with commenting out all references to VLAN tagging
>
> In the worst case I have to set static IP addresses and move on to the
> VLAN configuration (which is the point of this exercise) but I am
> getting frustrated that I don't even know why OpenWRT is behaving the
> way it is. Any thoughts?
>
>
> Here is my /etc/config/network file:
>
> =======================
> config 'switch' 'eth0'
> option 'enable' '1'
>
> config 'switch_vlan' 'eth0_0'
> option 'device' 'eth0'
> option 'vlan' '2'
> option 'ports' '0 1 4t 5t'
>
> config 'switch_vlan' 'eth0_1'
> option 'device' 'eth0'
> option 'vlan' '3'
> option 'ports' '2 3 4t 5t'
>
> config 'interface' 'loopback'
> option 'ifname' 'lo'
> option 'proto' 'static'
> option 'ipaddr' '127.0.0.1'
> option 'netmask' '255.0.0.0'
>
> config 'interface' '66APT'
> option 'type' 'bridge'
> option 'ifname' 'eth0.0'
> option 'proto' 'dhcp'
> #option 'proto' 'static'
> #option 'netmask' '255.255.255.0'
> #option 'ipaddr' '172.26.98.2'
>
> config 'interface' 'WR'
> option 'ifname' 'eth0.1'
> option 'proto' 'dhcp'
>
>
> =======================
>
> Here is my /etc/config/wireless
>
> =======================
>
>
> config 'wifi-device' 'wl0'
> option 'type' 'broadcom'
> option 'disabled' '0'
> option 'channel' '11'
>
> config 'wifi-iface'
> option 'device' 'wl0'
> option 'network' '66APT'
> option 'mode' 'ap'
> option 'ssid' 'mynetwork'
> option 'encryption' 'psk'
> option 'key' 'topsecret'
> #option 'isolate' '1'
>
>
> =======================
>
> Here is my /etc/config/dhcp file:
>
> =======================
> config dnsmasq
> option domainneeded 1
> option boguspriv 1
> option filterwin2k '0' #enable for dial on demand
> option localise_queries 1
> option local '/lan/'
> option domain 'lan'
> option expandhosts 1
> option nonegcache 0
> option authoritative 1
> option readethers 1
> option leasefile '/tmp/dhcp.leases'
> option resolvfile '/tmp/resolv.conf.auto'
> #list server '/mycompany.local/1.2.3.4'
> #option nonwildcard 1
> #list interface br-66APT
> #list notinterface lo
>
> config dhcp 66APT
> option interface 66APT
> option ignore 1
> #option start 100
> #option limit 150
> #option leasetime 12h
>
> config dhcp WR
> option interface WR
> option ignore 1
>
> =======================
>
> Here is my /etc/config/firewall file (which I suspect might be useless
> since I did not rename interfaces in this file:
>
> =======================
> config option 'syn_flood' '1'
> option 'input' 'ACCEPT'
> option 'output' 'ACCEPT'
> option 'forward' 'REJECT'
>
> config 'zone'
> option 'name' 'lan'
> option 'input' 'ACCEPT'
> option 'output' 'ACCEPT'
> option 'forward' 'REJECT'
>
> config 'zone'
> option 'name' 'wan'
> option 'input' 'REJECT'
> option 'output' 'ACCEPT'
> option 'forward' 'REJECT'
> option 'masq' '1'
> option 'mtu_fix' '1'
>
> config 'forwarding'
> option 'src' 'lan'
> option 'dest' 'wan'
> option 'mtu_fix' '0'
>
> config 'rule'
> option 'src' 'wan'
> option 'proto' 'udp'
> option 'dest_port' '68'
> option 'target' 'ACCEPT'
>
> config 'rule'
> option 'src' 'wan'
> option 'proto' 'icmp'
> option 'icmp_type' 'echo-request'
> option 'target' 'ACCEPT'
>
> config 'include'
> option 'path' '/etc/firewall.user'
>
> ======================
>
> - Paul
>
More information about the kwlug-disc
mailing list