* 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.