Re: Changes to VLAN and promiscuous mode in 6.6
Hey,
This should be fixed in current as of r1.199 of src/sys/net/if_vlan.c
Sorry for the inconvenience.
Cheers,
dlg
> On 29 Oct 2019, at 19:49, Zé Loff wrote:
>
>
> Hi all
>
> Some changes in VLAN-related code went into 6.6 and I think some of them
> changed the way the parent interface gets into promiscuous mode. Let me
> try to explain...
>
> Our ISP provides internet and VoIP over two separate VLANs (100 and 101,
> respectively). Our external firewall has two physical interfaces re0,
> and re1, and also does the filtering and NATing for internet, but VoIP
> traffic is transparently forwarded to the VoIP phone. So it's something
> like this:
>
> GPON -> re0 -+--> vlan100 -> (PF/NAT) -> vlan90 -+-> re1 -> A switch
> \-> vlan1010 -> bridge1 -> vlan1011 -/
>
> The VoIP phone connected to the switch, which does all the appropriate
> tagging and untagging. re0 and re1 have no IP addresses, neither do the
> vlan1010, vlan1011 and bridge1 virtual interfaces. The VoIP phone gets
> configured by DHCP, and gets its address (and etc) from the ISP. All
> interfaces are up, and correctly configured (ifconfigs below). This
> worked fine up until the 6.6 upgrade.
>
> Now, if things are left alone, the phone fails to get DHCP replies.
> This can be checked by running "tcpdump -i re1 vlan 101", which clearly
> shows the DHCP requests coming from the phone, but getting no replies.
> Exactly the same is seen on vlan1011 and vlan1010 (i.e. on both sides of
> the bridge1): DHCP requests but no replies. If tcpdump is run on re0
> ("tcpdump -i re0 vlan 101") then the interface goes into promiscuous
> mode and the DHCP replies start flowing from the ISP and the phone
> finally gets configured. Crucially, if the "-p" flag is added to
> tcpdump (i.e. not putting the if in promiscuous mode), DHCP fails.
>
> Is this behaviour intended and, if so, can re0 be configured to stay in
> promiscuous mode without having to do something silly as tcpdump'ing
> into /dev/null?
>
> Thanks in advance
> Zé
>
> --
>
> # ifconfig -A
> lo0: flags=8049 mtu 32768
>index 5 priority 0 llprio 3
>groups: lo
>inet6 ::1 prefixlen 128
>inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
>inet 127.0.0.1 netmask 0xff00
> re0: flags=8b43 mtu
> 1500
>lladdr 00:0d:b9:3c:b0:e8
>index 1 priority 0 llprio 3
>media: Ethernet autoselect (1000baseT full-duplex,master)
>status: active
> re1: flags=8843 mtu 9100
>lladdr 00:0d:b9:3c:b0:e9
>index 2 priority 0 llprio 3
>media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
>status: active
> re2: flags=8802 mtu 1500
>lladdr 00:0d:b9:3c:b0:ea
>index 3 priority 0 llprio 3
>media: Ethernet autoselect (10baseT half-duplex)
>status: no carrier
> enc0: flags=0<>
>index 4 priority 0 llprio 3
>groups: enc
>status: active
> bridge1: flags=41
>index 6 llprio 3
>groups: bridge
>priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
>vlan1011 flags=3
>port 11 ifpriority 0 ifcost 0
>vlan1010 flags=3
>port 10 ifpriority 0 ifcost 0
>Addresses (max cache: 100, timeout: 240):
>00:00:5e:00:01:c9 vlan1010 1 flags=0<>
>80:5e:c0:12:3f:80 vlan1011 1 flags=0<>
> vlan100: flags=808843 mtu
> 1500
>lladdr 00:0d:b9:3c:b0:e8
>description: WAN
>index 9 priority 0 llprio 3
>encap: vnetid 100 parent re0 txprio packet rxprio outer
>groups: vlan egress
>media: Ethernet autoselect (1000baseT full-duplex,master)
>status: active
>inet 148.69.164.57 netmask 0xfc00 broadcast 148.69.167.255
>inet 148.69.143.1 netmask 0xfffc broadcast 148.69.143.3
> vlan1010: flags=8943 mtu 1500
>lladdr 00:0d:b9:3c:b0:e8
>description: VoIP WAN
>index 10 priority 0 llprio 3
>encap: vnetid 101 parent re0 txprio packet rxprio outer
>groups: vlan
>media: Ethernet autoselect (1000baseT full-duplex,master)
>status: active
> vlan1011: flags=8943 mtu 1500
>lladdr 00:0d:b9:3c:b0:e9
>description: VoIP DMZ
>index 11 priority 0 llprio 3
>encap: vnetid 101 parent re1 txprio packet rxprio outer
>groups: vlan
>media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
>status: active
> vlan90: flags=8843 mtu 9000
>lladdr 00:0d:b9:3c:b0:e9
>
Changes to VLAN and promiscuous mode in 6.6
Hi all
Some changes in VLAN-related code went into 6.6 and I think some of them
changed the way the parent interface gets into promiscuous mode. Let me
try to explain...
Our ISP provides internet and VoIP over two separate VLANs (100 and 101,
respectively). Our external firewall has two physical interfaces re0,
and re1, and also does the filtering and NATing for internet, but VoIP
traffic is transparently forwarded to the VoIP phone. So it's something
like this:
GPON -> re0 -+--> vlan100 -> (PF/NAT) -> vlan90 -+-> re1 -> A switch
\-> vlan1010 -> bridge1 -> vlan1011 -/
The VoIP phone connected to the switch, which does all the appropriate
tagging and untagging. re0 and re1 have no IP addresses, neither do the
vlan1010, vlan1011 and bridge1 virtual interfaces. The VoIP phone gets
configured by DHCP, and gets its address (and etc) from the ISP. All
interfaces are up, and correctly configured (ifconfigs below). This
worked fine up until the 6.6 upgrade.
Now, if things are left alone, the phone fails to get DHCP replies.
This can be checked by running "tcpdump -i re1 vlan 101", which clearly
shows the DHCP requests coming from the phone, but getting no replies.
Exactly the same is seen on vlan1011 and vlan1010 (i.e. on both sides of
the bridge1): DHCP requests but no replies. If tcpdump is run on re0
("tcpdump -i re0 vlan 101") then the interface goes into promiscuous
mode and the DHCP replies start flowing from the ISP and the phone
finally gets configured. Crucially, if the "-p" flag is added to
tcpdump (i.e. not putting the if in promiscuous mode), DHCP fails.
Is this behaviour intended and, if so, can re0 be configured to stay in
promiscuous mode without having to do something silly as tcpdump'ing
into /dev/null?
Thanks in advance
Zé
--
# ifconfig -A
lo0: flags=8049 mtu 32768
index 5 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet 127.0.0.1 netmask 0xff00
re0: flags=8b43 mtu
1500
lladdr 00:0d:b9:3c:b0:e8
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
re1: flags=8843 mtu 9100
lladdr 00:0d:b9:3c:b0:e9
index 2 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
re2: flags=8802 mtu 1500
lladdr 00:0d:b9:3c:b0:ea
index 3 priority 0 llprio 3
media: Ethernet autoselect (10baseT half-duplex)
status: no carrier
enc0: flags=0<>
index 4 priority 0 llprio 3
groups: enc
status: active
bridge1: flags=41
index 6 llprio 3
groups: bridge
priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
vlan1011 flags=3
port 11 ifpriority 0 ifcost 0
vlan1010 flags=3
port 10 ifpriority 0 ifcost 0
Addresses (max cache: 100, timeout: 240):
00:00:5e:00:01:c9 vlan1010 1 flags=0<>
80:5e:c0:12:3f:80 vlan1011 1 flags=0<>
vlan100: flags=808843 mtu 1500
lladdr 00:0d:b9:3c:b0:e8
description: WAN
index 9 priority 0 llprio 3
encap: vnetid 100 parent re0 txprio packet rxprio outer
groups: vlan egress
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
inet 148.69.164.57 netmask 0xfc00 broadcast 148.69.167.255
inet 148.69.143.1 netmask 0xfffc broadcast 148.69.143.3
vlan1010: flags=8943 mtu 1500
lladdr 00:0d:b9:3c:b0:e8
description: VoIP WAN
index 10 priority 0 llprio 3
encap: vnetid 101 parent re0 txprio packet rxprio outer
groups: vlan
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
vlan1011: flags=8943 mtu 1500
lladdr 00:0d:b9:3c:b0:e9
description: VoIP DMZ
index 11 priority 0 llprio 3
encap: vnetid 101 parent re1 txprio packet rxprio outer
groups: vlan
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
vlan90: flags=8843 mtu 9000
lladdr 00:0d:b9:3c:b0:e9
description: DMZ
index 14 priority 0 llprio 3
encap: vnetid 90 parent re1 txprio packet rxprio outer
groups: vlan
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet 10.17.16.1 netmask 0xfe00 broadcast 10.17.17.255
pflog0: flags=141 mtu 33136
index 15 priority 0 llprio 3
groups: pflogDear sirs
# dmesg
OpenBSD 6.6 (GENERIC.MP) #372: Sat Oct 12 10:56:27 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2098511872 (2001MB)
avail mem = 2022256640 (1928MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at roo
Re: em interface fails to enter promiscuous mode when bridging on vlan interfaces
‐‐‐ Original Message ‐‐‐ On Thursday, February 21, 2019 12:55 AM, Jordan Geoghegan wrote: > I'm not sure if this has already been reported, or if it is indeed a > bug, but the title pretty much sums it up. Hi Jordan, I have also reported this a while ago on this very same list and ended up assigning an IP address on that interface as a workaround. It would be great if a nicer fix for that could be found. Also I would be interested to know if you also are loosing connection from time to time on your VMs? I have posted this a three weeks ago: https://marc.info/?l=openbsd-misc=154904432526324=2 Cheers, Mabi
Re: em interface fails to enter promiscuous mode when bridging on vlan interfaces
On 2019-02-20, Jordan Geoghegan wrote: > Hello, > > I'm not sure if this has already been reported, or if it is indeed a > bug, but the title pretty much sums it up. > > I wanted to isolate some vmm virtual machines onto a separate vlan so I > created a vlan interface on the host machine, and created a bridge on > it. I used option 4 from the link below for guidance: > > https://www.openbsd.org/faq/faq16.html#VMMnet > > Everything works great, but the problem is that the host interface needs > to be put into promiscuous mode for the bridged vlan interface to pass > packets to the virtual machine. No packets can be passed to or from the > virtual machine unless I manually put the host's vlan parent interface > into promiscuous mode by (for example) running tcpdump on the em interface. > > If folks think it's warranted, I'd be happy to do up a proper bug > report. Below please find a dmesg from my machine. Others have reported this too and it's clearly not working as expected, but I've been unable to replicate it here. If you're able to figure out a set of commands or file changes to trigger it then a proper report on bugs@ would definitely be a good idea.
em interface fails to enter promiscuous mode when bridging on vlan interfaces
Hello, I'm not sure if this has already been reported, or if it is indeed a bug, but the title pretty much sums it up. I wanted to isolate some vmm virtual machines onto a separate vlan so I created a vlan interface on the host machine, and created a bridge on it. I used option 4 from the link below for guidance: https://www.openbsd.org/faq/faq16.html#VMMnet Everything works great, but the problem is that the host interface needs to be put into promiscuous mode for the bridged vlan interface to pass packets to the virtual machine. No packets can be passed to or from the virtual machine unless I manually put the host's vlan parent interface into promiscuous mode by (for example) running tcpdump on the em interface. If folks think it's warranted, I'd be happy to do up a proper bug report. Below please find a dmesg from my machine. Regards, Jordan OpenBSD 6.4 (GENERIC.MP) #6: Sat Jan 26 20:37:44 CET 2019 r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 68664565760 (65483MB) avail mem = 66574290944 (63490MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec0d0 (43 entries) bios0: vendor American Megatrends Inc. version "P1.80" date 12/09/2013 bios0: ASRock EP2C602 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG AAFT SRAT SLIT HPET PRAD SPMI SSDT SPCR EINJ ERST HEST BERT acpi0: wakeup devices UR11(S4) UR12(S4) P0P9(S1) EUSB(S4) USBE(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4) GBE_(S4) NPE1(S4) NPE2(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.27 MHz, 06-2d-07 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.01 MHz, 06-2d-07 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.01 MHz, 06-2d-07 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.01 MHz, 06-2d-07 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 8 (application processor) cpu4: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.01 MHz, 06-2d-07 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 4, package 0 cpu5 at mainbus0: apid 10 (application processor) cpu5: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.01 MHz, 06-2d-07 cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,S
promiscuous mode
Hello all, I've looked over the ifconfig man page and can't find a way to set a specific interface to PROMISC mode on 4.4, for example: vr0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 Here's another example of that this possible: sis0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 Is there a way to set the flags to PROMISC for an interface? A good reference would work. Ciao for now,
Re: promiscuous mode
On Tue, May 19, 2009 at 2:51 PM, Fortunato fortunato.montre...@earthlink.net wrote: Hello all, I've looked over the ifconfig man page and can't find a way to set a specific interface to PROMISC mode on 4.4, for example: ifconfig can't be used to set an interface to promiscuous. You can use something like tcpdump.
Re: promiscuous mode
On Tue, May 19, 2009 at 11:51 AM, Fortunato fortunato.montre...@earthlink.net wrote: ... Is there a way to set the flags to PROMISC for an interface? What problem are you trying to solve? Philip Guenther
Re: promiscuous mode
Thanks, tcpdump does it alright, but I'd like to have promiscuous mode on without running tcpdump in the background if possible. (I'll take this as a learning moment otherwise.) I'm trying to use the first vr[0-3] interfaces like an L2 switch in this case. -Original Message- From: Ted Unangst ted.unan...@gmail.com Sent: May 19, 2009 3:18 PM To: Fortunato fortunato.montre...@earthlink.net Cc: misc@openbsd.org Subject: Re: promiscuous mode On Tue, May 19, 2009 at 2:51 PM, Fortunato fortunato.montre...@earthlink.net wrote: Hello all, I've looked over the ifconfig man page and can't find a way to set a specific interface to PROMISC mode on 4.4, for example: ifconfig can't be used to set an interface to promiscuous. You can use something like tcpdump.
Re: promiscuous mode
On Tue, May 19, 2009 at 1:03 PM, Fortunato fortunato.montre...@earthlink.net wrote: Thanks, tcpdump does it alright, but I'd like to have promiscuous mode on without running tcpdump in the background if possible. The interfaces are put into promiscuous mode automatically when there's something that needs them to be. Otherwise, it's a waste of CPU time to receive packets that the network stack is simply going to otherwise discard. I'm trying to use the first vr[0-3] interfaces like an L2 switch in this case. It sounds like you want to setup a bridge(4). Check the bridgename.if and brconfig man pages.
Re: promiscuous mode
On Tue, May 19, 2009 at 2:03 PM, Fortunato fortunato.montre...@earthlink.net wrote: Thanks, tcpdump does it alright, but I'd like to have promiscuous mode on without running tcpdump in the background if possible. (I'll take this as a learning moment otherwise.) I'm trying to use the first vr[0-3] interfaces like an L2 switch in this case. man brconfig -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: promiscuous mode
Grazie, For some reason when I put all the vr interfaces in the bridge at first, there was no forwarding. (I did not verify nor know about the PROMISC settings at the time.) After much tinkering, it works and brconfig does set the interfaces on PROMISC. Thanks to all, -Original Message- From: Matthew Dempsky matt...@dempsky.org Sent: May 19, 2009 4:21 PM To: Fortunato fortunato.montre...@earthlink.net Cc: misc@openbsd.org Subject: Re: promiscuous mode On Tue, May 19, 2009 at 1:03 PM, Fortunato fortunato.montre...@earthlink.net wrote: Thanks, tcpdump does it alright, but I'd like to have promiscuous mode on without running tcpdump in the background if possible. The interfaces are put into promiscuous mode automatically when there's something that needs them to be. Otherwise, it's a waste of CPU time to receive packets that the network stack is simply going to otherwise discard. I'm trying to use the first vr[0-3] interfaces like an L2 switch in this case. It sounds like you want to setup a bridge(4). Check the bridgename.if and brconfig man pages.
Re: promiscuous mode
On Tue, May 19, 2009 at 01:03:40PM -0700, Philip Guenther wrote:
On Tue, May 19, 2009 at 11:51 AM, Fortunato
fortunato.montre...@earthlink.net wrote:
...
Is there a way to set the flags to PROMISC for an interface?
What problem are you trying to solve?
Although not the original poster, and this is not his problem, I had a
need to set an interface to PROMISC and I used tcpdump fxp0 host 1.1.1.1
to accomplish it which seemed a kludge.
I was testing some point to mulit-point wireless bridges. We ended up
being able to load test 7 clients from one laptop, and could scale it
further but ran out of places to mount the client equipment.
Setup is like this:
Iperf endpoint DHCP server
Switch
AP
Wireless Links
Multiple Clients
Switch (with vlans)
OpenBSD Laptop to Trunk port on switch
So, I did something like this to create vlans for the number of clients I
want to test:
local _count=3
local _start=1
for _v in `jot $_count $(( $_start + 100 ))`; do
echo Start vlan$_v
_lladdr=lladdr 00:11:22`echo $_v | sed -e 's/\(.\)/:0\1/g'`
ifconfig vlan$_v vlandev $_vlandev $_lladdr
dhclient vlan$_v
done
The lladdr change is because the DHCP server will not hand out multiple
addresses if the vlans have the same MAC.
The switch with vlans is configured as such:
interface FastEthernet0/1
switchport access vlan 101
!
interface FastEthernet0/2
switchport access vlan 102
!
...
!
interface GigabitEthernet0/1
switchport mode trunk
!
The laptop is plugged into the gigabit port on the switch, the different
pieces of client equipment are plugged into the different FastEthernet
ports.
Then I run iperf simultaneously, bound to each vlan with an IP.
#!/bin/sh
local _host=iperf.server
for _int in `ifconfig vlan 2/dev/null |
awk '/^vlan/ { sub(:,,$1); print $1 }' |
sort`; do
local _ip=`ifconfig $_int | awk '/inet / { print $2 }'`
local _last=`echo $_int | sed -e 's/^.*\(..\)$/\1/'`
local _port=$(( $_last + 5000 ))
if [ ! -z $_ip ]; then
iperf -B $_ip -p $_port -c $_host $@ | {
local _line
while read _line; do
echo $_int: $_line
done
}
fi
done
wait
l8rZ,
--
andrew - ICQ# 253198 - Jabber: and...@rraz.net
BOFH excuse of the day: A plumber is needed, the network drain is
clogged
Re: Problem with interface in promiscuous mode
On 2009/03/19 23:58, Mail Lists wrote: Did you see what sort of packets they are? Broadcast or multicast or something? I'm wondering why they would even hit your machine otherwise. They are multicast packets that are going to 224.0.1.24 which according to this: http://www.iana.org/assignments/multicast-addresses/ is for microsoft-ds. Is there perhaps something in this that lets me tell the administrator of the offending box what's going on since the network admin seems unwilling or unable to to so? Maybe they can try turning off WINS. Or maybe the network admin can filter out the multicast destination MAC, if my working-out is right this should be 01:00:5e:00:01:18, but you can check with tcpdump -e. If they happen to use HP switches Henning wrote an article which has a config example: http://bulabula.org/carp-and-stp-meet-switch-security.html Anyways -this isn't really openbsd related any longer. Apologies if this is turning into noise. dragging this back on topic, the above article is also useful if you want to prevent carp traffic on certain switch-ports. :-)
Re: Problem with interface in promiscuous mode
On 3/20/2009 12:59 PM, (private) HKS wrote: On Wed, Mar 18, 2009 at 8:49 PM, Mail Listsmail-li...@peachnet.com wrote: On Wed, Mar 18, 2009 at 12:33 PM, (private) HKShks.priv...@gmail.com wrote: On Wed, Mar 18, 2009 at 12:12 PM, Mail Listsmail-li...@peachnet.com wrote: Hello all, I'm have some issues setting up a bridge. We recently co-located a router in a data canter. The machine is a a soekris 5501 running openbsd4.4. The interfaces use the vr drivers. A machine belonging to someone in our cabinet is sending out about 10 packets/second of udp traffic on port 42. When I try to put my primary interface into bridge mode my machine locks up. I'm assuming this is because it can't handle the amount of packets flowing past the interface. Could anyone indicate whether or not this could indeed be the problem or if I'm completely off base here. The admin at the data center seems to think my box should be able to handle that amount of traffic just fine. The problem is not as pronounced when PF is disabled. The machine still crawls to a virtual standstill but I can at least do a ctrl-c on a tcpdump to stop it. The only way to get back at the command line when PF is enabled is to unplug the ethernet cable. When I DO a tcpdump I get millions of the following: 23:25:10.082217 00:0b:db:93:fb:70 01:00:5e:00:01:18 0800 60: 74.255.56.30.42 224.0.1.24.42: udp 16 Cancelling the dump it reports for instance 20 packets received by filter 198000 packets dropped by kernel I can provide more details on the box if needed but I would just like some advice on what I can do about this. Is there a way to ignore all packets coming from a certain MAC address on layer 2? Is there anyway possible that this is 'legitimate' traffic? Is there any other way to create a filtering bridge without putting interfaces into promiscuous mode? Thanks for any advice, would really appreciate it. Steve This PR may be related: http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yesnumbers=6072 Try setting up a blackhole route for multicast addresses, see if that settles things down a bit. On another note, I'd be blown away to see a Soekris 5501 handle 100k packets/second without eating shit. Their NICs are Terrible (capital T), and the low-powered CPU is quickly overwhelmed by interrupts. -HKS Thanks, I will try this when I'm next able to drive down there as I've effectively cut myself off doing exactly what I shouldn't have. I'm not sure I get why routing these packets to a blackhole would be any easier on the CPU though. Would something like this work? route add IPOFOFFENDINGMACHINE 127.0.0.1 -blackhole Thanks for the advice! Oh, I missed the question you asked about why it would be easier. The PR explains some of that, but I've observed that when multicast traffic enters an interface in promiscuous mode, if net.inet.ip.forwarding=1, the host will attempt to route those packets. This can create a loop where traffic is repeatedly replicated until the box is paralyzed. I knocked down a couple 5501s in discovering this problem. I don't know that this is what you're seeing, but 100k multicast packets/sec from a single host sounds an awful lot like a traffic replication loop. -HKS OK, I understand. If that were the case I should be able to turn off forwarding and the bulk of the problem would disappear? I tried this and this wasn't the case. I tried the blackhole too - route add IP 127.0.0.1 -blackhole and it didn't make any apparent difference. I guess that leads me to believe that these packets are all original packets coming from this IP? What exactly does the OS do when it receives a multicast packet? Does the packet get passed all the way down the network stack and back out? (when in promiscuous mode I suppose). If so why can't you simply tell the stack not to do this for specific packets? I'm sure there's a real reason why this isn't possible I'm just trying to get a grasp on what's hapenning. Anyways, thanks for all the help, really appreciate it. I think I've pretty much given up on this situation and am going to approach this on a physical level (move to a different cabinet probably). I'm mostly pursuing this for my own edification I suppose. Thanks, Steve
Re: Problem with interface in promiscuous mode
On Thu, Mar 19, 2009 at 4:45 AM, Stuart Henderson s...@spacehopper.org wrote: On 2009/03/18 20:45, Mail Lists wrote: Is there anyway possible that this is 'legitimate' traffic? damned unlikely. I think I'd be looking at a layer-1 solution if the box can't be made to behave... Sorry, I don't quite know what you mean by a layer one solution short of moving the box to a different network. B I'm a little new to this sort of stuff. layer 1 = physical - pulling the cable :-) Thanks for the help - I'll probably end up insisting he move us to a different cabinet or a different VLAN if he can't contact the owner of the server sending the traffic. The funny thing is that they have VLAN's set up for separate cabinets but don't seem to be able to setup individual customers with their own vlan. They might not want to segregate customers as a matter of course, it's a fair bit of work to setup in the first place (and extra IP address use unless you use filtering bridges), and if they're a very large operation, the maximum of 4096 VLANs might make things excessively complicated if they do this for everyone. But I don't think you should accept being DOS'd by someone in the same rack.. Did you see what sort of packets they are? Broadcast or multicast or something? I'm wondering why they would even hit your machine otherwise. They are multicast packets that are going to 224.0.1.24 which according to this: http://www.iana.org/assignments/multicast-addresses/ is for microsoft-ds. A snippet of the UDP stream looks like this: 8.J.8.J.8.J.8.J.8 .J.8.J.8.J.8.J.8.J.8. J.8.J.8.J I have not a clue that that means. Is there perhaps something in this that lets me tell the administrator of the offending box what's going on since the network admin seems unwilling or unable to to so? Anyways -this isn't really openbsd related any longer. Apologies if this is turning into noise. Thanks for all the help!
Problem with interface in promiscuous mode
Hello all, I'm have some issues setting up a bridge. We recently co-located a router in a data canter. The machine is a a soekris 5501 running openbsd4.4. The interfaces use the vr drivers. A machine belonging to someone in our cabinet is sending out about 10 packets/second of udp traffic on port 42. When I try to put my primary interface into bridge mode my machine locks up. I'm assuming this is because it can't handle the amount of packets flowing past the interface. Could anyone indicate whether or not this could indeed be the problem or if I'm completely off base here. The admin at the data center seems to think my box should be able to handle that amount of traffic just fine. The problem is not as pronounced when PF is disabled. The machine still crawls to a virtual standstill but I can at least do a ctrl-c on a tcpdump to stop it. The only way to get back at the command line when PF is enabled is to unplug the ethernet cable. When I DO a tcpdump I get millions of the following: 23:25:10.082217 00:0b:db:93:fb:70 01:00:5e:00:01:18 0800 60: 74.255.56.30.42 224.0.1.24.42: udp 16 Cancelling the dump it reports for instance 20 packets received by filter 198000 packets dropped by kernel I can provide more details on the box if needed but I would just like some advice on what I can do about this. Is there a way to ignore all packets coming from a certain MAC address on layer 2? Is there anyway possible that this is 'legitimate' traffic? Is there any other way to create a filtering bridge without putting interfaces into promiscuous mode? Thanks for any advice, would really appreciate it. Steve
Re: Problem with interface in promiscuous mode
On 2009-03-18, Mail Lists mail-li...@peachnet.com wrote: I'm have some issues setting up a bridge. We recently co-located a router in a data canter. The machine is a a soekris 5501 running openbsd4.4. The interfaces use the vr drivers. A machine belonging to someone in our cabinet is sending out about 10 packets/second of udp traffic on port 42. When I try to put my primary interface into bridge mode my machine locks up. I'm assuming this is because it can't handle the amount of packets flowing past the interface. Could anyone indicate whether or not this could indeed be the problem or if I'm completely off base here. The admin at the data center seems to think my box should be able to handle that amount of traffic just fine. it's pretty much sure to be the problem, the Geode CPU and vr(4) is not a winning combination for handling high packet-per-second. ping -f to my alix results in about 100% cpu use at 15K PPS. Is there a way to ignore all packets coming from a certain MAC address on layer 2? maybe this can be done at the switch. Is there anyway possible that this is 'legitimate' traffic? damned unlikely. I think I'd be looking at a layer-1 solution if the box can't be made to behave... Is there any other way to create a filtering bridge without putting interfaces into promiscuous mode? you need promiscuous mode to act as a bridge.
ifconfig promiscuous mode
Hi, How to enable and disable the promiscuous mode with OpenBSD 4.3. I didn't find the -promisc argument in ifconfig. Thanks M
Re: ifconfig promiscuous mode
On 03:43:49 Nov 18, Man Lam wrote: Hi, How to enable and disable the promiscuous mode with OpenBSD 4.3. I didn't find the -promisc argument in ifconfig. man pcap -Girish
Re: ifconfig promiscuous mode
On Tue, Nov 18, 2008 at 12:43 AM, Man Lam [EMAIL PROTECTED] wrote: How to enable and disable the promiscuous mode with OpenBSD 4.3. I didn't find the -promisc argument in ifconfig. Why would you want to do that manually? Software that needs promiscuous mode should turn it on automatically. Philip Guenther
Is there an ifconfig flag to put an interface in promiscuous mode?
I'm trying to set up bridging over gif between multiple locations, the ultimate goal of which is to support Windows machines sharing disks. Now, I don't know *^% about windows, and I got this working perfectly as far as I can tell (I can get dhcp addresses from either end of the bridge for instance). But when I set it up at the customer location, the Windows machines could not see the file shares in Network Neighborhood. I started poking around with wireshark, and almost instantly they could see each other. Now, I'm thinking this might be the result of wireshark punting the interfaces in promiscuous mode. Does this make any sense? If so, is there an ifconfig flag I can use to accomplish this? Or should I be looking at some other knob to tweak here? -- Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
snort / promiscuous mode
Hey all: OBSD3.7 SNORT2.3.3 I have a machine with 4 nics running 4 instances of snort: /usr/local/bin/snort -u sguil -g sguil -l /nsm/em0 -c /etc/snort/em0.snort.conf -U -A none -m 122 -i em0 -D /usr/local/bin/snort -u sguil -g sguil -l /nsm/em1 -c /etc/snort/em1.snort.conf -U -A none -m 122 -i em1 -D /usr/local/bin/snort -u sguil -g sguil -l /nsm/em2 -c /etc/snort/em2.snort.conf -U -A none -m 122 -i em2 -D /usr/local/bin/snort -u sguil -g sguil -l /nsm/em3 -c /etc/snort/em3.snort.conf -U -A none -m 122 -i em3 -D One of the 4 nics has an ip address, the others do not. When I start up the 4 instances of snort, the nic (em0) with the ip address shows up in promiscuous mode, the others do not. # ifconfig -a lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33224 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 address: 00:04:23:bd:ab:d6 media: Ethernet autoselect (1000baseT full-duplex) status: active inet 10.1.1.3 netmask 0xff00 broadcast 10.1.1.255 inet6 fe80::204:23ff:febd:abd6%em0 prefixlen 64 scopeid 0x1 em1: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 address: 00:04:23:bd:ab:d7 media: Ethernet autoselect (1000baseT full-duplex) status: active em2: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 address: 00:14:22:0f:84:2b media: Ethernet autoselect (1000baseT full-duplex) status: active em3: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 address: 00:14:22:0f:84:2c media: Ethernet autoselect (100baseTX full-duplex) status: active pflog0: flags=0 mtu 33224 pfsync0: flags=0 mtu 2020 enc0: flags=0 mtu 1536 # How do I get the other 3 ip-less nics to run in promiscuous mode in OBSD? Any help would be appreciated. Sean
