this implements 3 new features for uml_switch
1) learning bridge, so you can bridge over uml_switch:
host <-> uml1(bridging) <- uml_switch -> uml2/3/4
The static MAC addresses wont be overwritten, so this combined with
static arp entries should give some protection against arp spoofing and
switch port stealing (MAC src spoofing).
2) tun switch port support:
Sorry for the multiple work, I saw the release of the program to connect
an uml_switch port to a tun interface. This should help if you only want
to have a single tun port on the switch.
3) monitor port:
All traffic will be seen on the tun interface. This will only be disabled
if hub mode is enabled. It should be easy to add a control message to
enable a given port as a monitor port. This would be useful to avoid
overloading of the tun interface when you are not interested in
monitoring (and a possible securty risk).
I was catching up with my email and realized I should have released this
before. I updated it to the latest version and linted it a bit. There are
some XXX's left, but it works for my needs ;-) (protocol debugging with
too much NAT around, so I wanted to have a copy of the wire data, without
having to a) think about netfilter <-> libpcap interactions b) waiting for
my kernel breakpoint tracing to end.)
Just jack in your favorite packet analyzer on the tun interface.
It could be usefull (and easy) to add command lines to:
- enable/disable monitor port
- name the tun interface (umls0, moni0, whatever34)
Send SIGUSR1 to get a dump of the mac table. Static MAC to port
mappings don't time out ;-) .
Another usage example would be to have hogwash running on the
host, repeating between tapX and ethX and thus IDS'ing and FW'ing your uml