* ULOG and vlans
@ 2011-07-27 18:59 Stig
2011-07-28 11:15 ` Patrick McHardy
0 siblings, 1 reply; 5+ messages in thread
From: Stig @ 2011-07-27 18:59 UTC (permalink / raw)
To: netfilter-devel
I'm using ULOG iptables target to capture packets for pmacct (a
netflow exporter). I noticed when ulog gets a packet from a vlan
interface that the ulog header shows a mac_len of 18 bytes, but it
appears that the vlan tag has already been stripped from the packet
header:
(gdb) p/x *ulog_pkt
$7 = {
mark = 0x0,
timestamp_sec = 0x4e2f6077,
timestamp_usec = 0x222f3,
hook = 0x0,
indev_name = {0x65, 0x74, 0x68, 0x31, 0x2e, 0x31, 0x30, 0x30, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0},
outdev_name = {0x0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5, 0xf, 0x0,
0x0, 0x5, 0xf, 0x0, 0x0},
data_len = 0x40,
prefix = {0x0, 0x0, 0x2, 0x0, 0x72, 0x60, 0x2f, 0x4e, 0xed, 0x6, 0x0, 0x0,
0xa, 0x40, 0x80, 0xfd, 0x2, 0x0, 0x0, 0x0, 0x14, 0x0, 0x1, 0x0, 0xfe,
0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
mac_len = 0x12,
mac = {0x0, 0xd, 0xb9, 0x15, 0x6d, 0x1, 0x0, 0xf, 0x30, 0x4, 0x35, 0x4f,
0x8, 0x0, 0x45, 0x0, 0x0, 0x54, 0xff, 0x21, 0x12, 0x0, 0x0, 0x21, 0x12,
0x0, 0x0, 0x40, 0x0, 0x0, 0x0, 0x14, 0x0, 0x2, 0x0, 0x72, 0x60, 0x2f,
0x4e, 0xed, 0x6, 0x0, 0x0, 0xa, 0x40, 0x80, 0xfd, 0x3, 0x0, 0x0, 0x0,
0x14, 0x0, 0x1, 0x0, 0xfe, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0xd,
0xb9, 0xff, 0xfe, 0x15, 0x6d, 0x1, 0x14, 0x0, 0x6, 0x0, 0xff, 0xff, 0xff,
0xff, 0xff},
payload = 0x941cc35
}
If the vlan has been remove, shouldn't the mac_len be reduced to 14?
This causes parsing problems of the ip header for pmacct because it
does the following:
if (ulog_pkt->mac_len) {
memcpy(jumbo_container, ulog_pkt->mac, ulog_pkt->mac_len);
memcpy(jumbo_container+ulog_pkt->mac_len, ulog_pkt->payload, hdr.caplen);
hdr.caplen += ulog_pkt->mac_len;
hdr.len += ulog_pkt->mac_len;
Obviously I can work around it, but I'm wondering if this is the
expected behavior for ulog with vlans?
stig
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: ULOG and vlans 2011-07-27 18:59 ULOG and vlans Stig @ 2011-07-28 11:15 ` Patrick McHardy 2011-07-28 17:00 ` Stig 0 siblings, 1 reply; 5+ messages in thread From: Patrick McHardy @ 2011-07-28 11:15 UTC (permalink / raw) To: Stig; +Cc: netfilter-devel On 27.07.2011 20:59, Stig wrote: > I'm using ULOG iptables target to capture packets for pmacct (a > netflow exporter). I noticed when ulog gets a packet from a vlan > interface that the ulog header shows a mac_len of 18 bytes, but it > appears that the vlan tag has already been stripped from the packet > header: > > (gdb) p/x *ulog_pkt > $7 = { > mark = 0x0, > timestamp_sec = 0x4e2f6077, > timestamp_usec = 0x222f3, > hook = 0x0, > indev_name = {0x65, 0x74, 0x68, 0x31, 0x2e, 0x31, 0x30, 0x30, 0x0, 0x0, 0x0, > 0x0, 0x0, 0x0, 0x0, 0x0}, > outdev_name = {0x0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5, 0xf, 0x0, > 0x0, 0x5, 0xf, 0x0, 0x0}, > data_len = 0x40, > prefix = {0x0, 0x0, 0x2, 0x0, 0x72, 0x60, 0x2f, 0x4e, 0xed, 0x6, 0x0, 0x0, > 0xa, 0x40, 0x80, 0xfd, 0x2, 0x0, 0x0, 0x0, 0x14, 0x0, 0x1, 0x0, 0xfe, > 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, > mac_len = 0x12, > mac = {0x0, 0xd, 0xb9, 0x15, 0x6d, 0x1, 0x0, 0xf, 0x30, 0x4, 0x35, 0x4f, > 0x8, 0x0, 0x45, 0x0, 0x0, 0x54, 0xff, 0x21, 0x12, 0x0, 0x0, 0x21, 0x12, > 0x0, 0x0, 0x40, 0x0, 0x0, 0x0, 0x14, 0x0, 0x2, 0x0, 0x72, 0x60, 0x2f, > 0x4e, 0xed, 0x6, 0x0, 0x0, 0xa, 0x40, 0x80, 0xfd, 0x3, 0x0, 0x0, 0x0, > 0x14, 0x0, 0x1, 0x0, 0xfe, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0xd, > 0xb9, 0xff, 0xfe, 0x15, 0x6d, 0x1, 0x14, 0x0, 0x6, 0x0, 0xff, 0xff, 0xff, > 0xff, 0xff}, > payload = 0x941cc35 > } > > > If the vlan has been remove, shouldn't the mac_len be reduced to 14? Yes. How is your vlan device configured (ip -s link show vlanX)? > > This causes parsing problems of the ip header for pmacct because it > does the following: > > if (ulog_pkt->mac_len) { > memcpy(jumbo_container, ulog_pkt->mac, ulog_pkt->mac_len); > memcpy(jumbo_container+ulog_pkt->mac_len, ulog_pkt->payload, hdr.caplen); > hdr.caplen += ulog_pkt->mac_len; > hdr.len += ulog_pkt->mac_len; > > > Obviously I can work around it, but I'm wondering if this is the > expected behavior for ulog with vlans? No, if the tag is stripped, the length should reflect that. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ULOG and vlans 2011-07-28 11:15 ` Patrick McHardy @ 2011-07-28 17:00 ` Stig 2011-07-29 14:23 ` Patrick McHardy 0 siblings, 1 reply; 5+ messages in thread From: Stig @ 2011-07-28 17:00 UTC (permalink / raw) To: Patrick McHardy; +Cc: netfilter-devel On Thu, Jul 28, 2011 at 4:15 AM, Patrick McHardy <kaber@trash.net> wrote: > On 27.07.2011 20:59, Stig wrote: >> I'm using ULOG iptables target to capture packets for pmacct (a >> netflow exporter). I noticed when ulog gets a packet from a vlan >> interface that the ulog header shows a mac_len of 18 bytes, but it >> appears that the vlan tag has already been stripped from the packet >> header: >> >> (gdb) p/x *ulog_pkt >> $7 = { >> mark = 0x0, >> timestamp_sec = 0x4e2f6077, >> timestamp_usec = 0x222f3, >> hook = 0x0, >> indev_name = {0x65, 0x74, 0x68, 0x31, 0x2e, 0x31, 0x30, 0x30, 0x0, 0x0, 0x0, >> 0x0, 0x0, 0x0, 0x0, 0x0}, >> outdev_name = {0x0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5, 0xf, 0x0, >> 0x0, 0x5, 0xf, 0x0, 0x0}, >> data_len = 0x40, >> prefix = {0x0, 0x0, 0x2, 0x0, 0x72, 0x60, 0x2f, 0x4e, 0xed, 0x6, 0x0, 0x0, >> 0xa, 0x40, 0x80, 0xfd, 0x2, 0x0, 0x0, 0x0, 0x14, 0x0, 0x1, 0x0, 0xfe, >> 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, >> mac_len = 0x12, >> mac = {0x0, 0xd, 0xb9, 0x15, 0x6d, 0x1, 0x0, 0xf, 0x30, 0x4, 0x35, 0x4f, >> 0x8, 0x0, 0x45, 0x0, 0x0, 0x54, 0xff, 0x21, 0x12, 0x0, 0x0, 0x21, 0x12, >> 0x0, 0x0, 0x40, 0x0, 0x0, 0x0, 0x14, 0x0, 0x2, 0x0, 0x72, 0x60, 0x2f, >> 0x4e, 0xed, 0x6, 0x0, 0x0, 0xa, 0x40, 0x80, 0xfd, 0x3, 0x0, 0x0, 0x0, >> 0x14, 0x0, 0x1, 0x0, 0xfe, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0xd, >> 0xb9, 0xff, 0xfe, 0x15, 0x6d, 0x1, 0x14, 0x0, 0x6, 0x0, 0xff, 0xff, 0xff, >> 0xff, 0xff}, >> payload = 0x941cc35 >> } >> >> >> If the vlan has been remove, shouldn't the mac_len be reduced to 14? > > Yes. How is your vlan device configured (ip -s link show vlanX)? vyatta@vyatta:~$ ip -s link show eth1.100 4: eth1.100@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue stat link/ether 00:0d:b9:15:6d:01 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 296652 3372 0 0 0 0 TX: bytes packets errors dropped carrier collsns 344216 3376 0 0 0 0 vyatta@vyatta:~$ iptables -V iptables v1.4.10 vyatta@vyatta:~$ uname -a Linux alix-vyatta 2.6.37-1-586-vyatta #1 SMP Mon Jun 13 14:41:41 PDT 2011 i586 x stig -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ULOG and vlans 2011-07-28 17:00 ` Stig @ 2011-07-29 14:23 ` Patrick McHardy 2011-07-29 18:59 ` Stig 0 siblings, 1 reply; 5+ messages in thread From: Patrick McHardy @ 2011-07-29 14:23 UTC (permalink / raw) To: Stig; +Cc: netfilter-devel On 28.07.2011 19:00, Stig wrote: > On Thu, Jul 28, 2011 at 4:15 AM, Patrick McHardy <kaber@trash.net> wrote: >> On 27.07.2011 20:59, Stig wrote: >>> I'm using ULOG iptables target to capture packets for pmacct (a >>> netflow exporter). I noticed when ulog gets a packet from a vlan >>> interface that the ulog header shows a mac_len of 18 bytes, but it >>> appears that the vlan tag has already been stripped from the packet >>> header: >>> >>> (gdb) p/x *ulog_pkt >>> $7 = { >>> mark = 0x0, >>> timestamp_sec = 0x4e2f6077, >>> timestamp_usec = 0x222f3, >>> hook = 0x0, >>> indev_name = {0x65, 0x74, 0x68, 0x31, 0x2e, 0x31, 0x30, 0x30, 0x0, 0x0, 0x0, >>> 0x0, 0x0, 0x0, 0x0, 0x0}, >>> outdev_name = {0x0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5, 0xf, 0x0, >>> 0x0, 0x5, 0xf, 0x0, 0x0}, >>> data_len = 0x40, >>> prefix = {0x0, 0x0, 0x2, 0x0, 0x72, 0x60, 0x2f, 0x4e, 0xed, 0x6, 0x0, 0x0, >>> 0xa, 0x40, 0x80, 0xfd, 0x2, 0x0, 0x0, 0x0, 0x14, 0x0, 0x1, 0x0, 0xfe, >>> 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, >>> mac_len = 0x12, >>> mac = {0x0, 0xd, 0xb9, 0x15, 0x6d, 0x1, 0x0, 0xf, 0x30, 0x4, 0x35, 0x4f, >>> 0x8, 0x0, 0x45, 0x0, 0x0, 0x54, 0xff, 0x21, 0x12, 0x0, 0x0, 0x21, 0x12, >>> 0x0, 0x0, 0x40, 0x0, 0x0, 0x0, 0x14, 0x0, 0x2, 0x0, 0x72, 0x60, 0x2f, >>> 0x4e, 0xed, 0x6, 0x0, 0x0, 0xa, 0x40, 0x80, 0xfd, 0x3, 0x0, 0x0, 0x0, >>> 0x14, 0x0, 0x1, 0x0, 0xfe, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0xd, >>> 0xb9, 0xff, 0xfe, 0x15, 0x6d, 0x1, 0x14, 0x0, 0x6, 0x0, 0xff, 0xff, 0xff, >>> 0xff, 0xff}, >>> payload = 0x941cc35 >>> } >>> >>> >>> If the vlan has been remove, shouldn't the mac_len be reduced to 14? >> >> Yes. How is your vlan device configured (ip -s link show vlanX)? > > vyatta@vyatta:~$ ip -s link show eth1.100 > 4: eth1.100@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue stat > link/ether 00:0d:b9:15:6d:01 brd ff:ff:ff:ff:ff:ff > RX: bytes packets errors dropped overrun mcast > 296652 3372 0 0 0 0 > TX: bytes packets errors dropped carrier collsns > 344216 3376 0 0 0 0 Sorry, I actually meant ip -d link show vlanX. Also, what driver are you using? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ULOG and vlans 2011-07-29 14:23 ` Patrick McHardy @ 2011-07-29 18:59 ` Stig 0 siblings, 0 replies; 5+ messages in thread From: Stig @ 2011-07-29 18:59 UTC (permalink / raw) To: Patrick McHardy; +Cc: netfilter-devel On Fri, Jul 29, 2011 at 7:23 AM, Patrick McHardy <kaber@trash.net> wrote: > On 28.07.2011 19:00, Stig wrote: >> On Thu, Jul 28, 2011 at 4:15 AM, Patrick McHardy <kaber@trash.net> wrote: >>> On 27.07.2011 20:59, Stig wrote: >>>> I'm using ULOG iptables target to capture packets for pmacct (a >>>> netflow exporter). I noticed when ulog gets a packet from a vlan >>>> interface that the ulog header shows a mac_len of 18 bytes, but it >>>> appears that the vlan tag has already been stripped from the packet >>>> header: >>>> >>>> (gdb) p/x *ulog_pkt >>>> $7 = { >>>> mark = 0x0, >>>> timestamp_sec = 0x4e2f6077, >>>> timestamp_usec = 0x222f3, >>>> hook = 0x0, >>>> indev_name = {0x65, 0x74, 0x68, 0x31, 0x2e, 0x31, 0x30, 0x30, 0x0, 0x0, 0x0, >>>> 0x0, 0x0, 0x0, 0x0, 0x0}, >>>> outdev_name = {0x0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5, 0xf, 0x0, >>>> 0x0, 0x5, 0xf, 0x0, 0x0}, >>>> data_len = 0x40, >>>> prefix = {0x0, 0x0, 0x2, 0x0, 0x72, 0x60, 0x2f, 0x4e, 0xed, 0x6, 0x0, 0x0, >>>> 0xa, 0x40, 0x80, 0xfd, 0x2, 0x0, 0x0, 0x0, 0x14, 0x0, 0x1, 0x0, 0xfe, >>>> 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, >>>> mac_len = 0x12, >>>> mac = {0x0, 0xd, 0xb9, 0x15, 0x6d, 0x1, 0x0, 0xf, 0x30, 0x4, 0x35, 0x4f, >>>> 0x8, 0x0, 0x45, 0x0, 0x0, 0x54, 0xff, 0x21, 0x12, 0x0, 0x0, 0x21, 0x12, >>>> 0x0, 0x0, 0x40, 0x0, 0x0, 0x0, 0x14, 0x0, 0x2, 0x0, 0x72, 0x60, 0x2f, >>>> 0x4e, 0xed, 0x6, 0x0, 0x0, 0xa, 0x40, 0x80, 0xfd, 0x3, 0x0, 0x0, 0x0, >>>> 0x14, 0x0, 0x1, 0x0, 0xfe, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0xd, >>>> 0xb9, 0xff, 0xfe, 0x15, 0x6d, 0x1, 0x14, 0x0, 0x6, 0x0, 0xff, 0xff, 0xff, >>>> 0xff, 0xff}, >>>> payload = 0x941cc35 >>>> } >>>> >>>> >>>> If the vlan has been remove, shouldn't the mac_len be reduced to 14? >>> >>> Yes. How is your vlan device configured (ip -s link show vlanX)? >> >> vyatta@vyatta:~$ ip -s link show eth1.100 >> 4: eth1.100@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue stat >> link/ether 00:0d:b9:15:6d:01 brd ff:ff:ff:ff:ff:ff >> RX: bytes packets errors dropped overrun mcast >> 296652 3372 0 0 0 0 >> TX: bytes packets errors dropped carrier collsns >> 344216 3376 0 0 0 0 > > Sorry, I actually meant ip -d link show vlanX. Also, what driver are > you using? vyatta@vyatta:~# ip -d link sh eth1.100 4: eth1.100@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue stat link/ether 00:0d:b9:15:6d:01 brd ff:ff:ff:ff:ff:ff vlan id 100 <REORDER_HDR> vyatta@vyatta:~# ethtool -i eth1.100 driver: 802.1Q VLAN Support version: 1.8 firmware-version: N/A bus-info: vyatta@vyatta:~# ethtool -i eth1 driver: via-rhine version: 1.4.3 firmware-version: bus-info: 0000:00:0a.0 I've also see the same issue under kvm with: root@dut2:/home/vyatta# ip -d link show eth1.123 12: eth1.123@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 52:54:00:e7:68:9e brd ff:ff:ff:ff:ff:ff vlan id 123 <REORDER_HDR> root@dut2:/home/vyatta# ethtool -i eth1 driver: pcnet32 version: 1.35 firmware-version: bus-info: 0000:00:06.0 stig -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-07-29 18:59 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-07-27 18:59 ULOG and vlans Stig 2011-07-28 11:15 ` Patrick McHardy 2011-07-28 17:00 ` Stig 2011-07-29 14:23 ` Patrick McHardy 2011-07-29 18:59 ` Stig
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.