Hello!
The current wireless-testing appears to have some non-wireless bits from
the upcoming Linux 2.6.34. As a result, libpcap and all capture
programs that use it are broken.
This patch to libpcap helps:
--- a/pcap-linux.c
+++ b/pcap-linux.c
@@ -1563,6 +1563,7 @@ live_open_new(pcap_t *handle, const char
memset(&mr, 0, sizeof(mr));
mr.mr_ifindex = handle->md.ifindex;
mr.mr_type = PACKET_MR_PROMISC;
+ mr.mr_alen = 6;
if (setsockopt(sock_fd, SOL_PACKET,
PACKET_ADD_MEMBERSHIP, &mr, sizeof(mr)) == -1)
{
libpcap git doesn't have the fix yet.
The breakage must be coming from the commit 914c8ad2 by Jiri Pirko to
net/packet/af_packet.c
I think it's very unhelpful to introduce patches that break significant
userspace functionality without giving the affected programs an advance
warning.
Also, pulling bleeding edge stuff into wireless-testing before rc1
appears to be either a mistake or a bad decision.
Sorry for cross-post, but it's an urgent issue. Repliers are encouraged
to trim the recipient list as necessary.
--
Regards,
Pavel Roskin
From: Jiri Pirko <[email protected]>
Date: Wed, 3 Mar 2010 07:40:01 +0100
> Subject: [net-2.6 PATCH] af_packet: move strict addr_len check right before dev_[mc/unicast]_[add/del]
>
> My previous patch 914c8ad2d18b62ad1420f518c0cab0b0b90ab308 incorrectly changed
> the length check in packet_mc_add to be more strict. The problem is that
> userspace is not filling this field (and it stays zeroed) in case of setting
> PACKET_MR_PROMISC or PACKET_MR_ALLMULTI. So move the strict check to the point
> in path where the addr_len must be set correctly.
>
> Signed-off-by: Jiri Pirko <[email protected]>
Applied.
From: Jiri Pirko <[email protected]>
Date: Wed, 3 Mar 2010 10:05:13 +0100
> Wed, Mar 03, 2010 at 07:40:01AM CET, [email protected] wrote:
>>Subject: [net-2.6 PATCH] af_packet: move strict addr_len check right before dev_[mc/unicast]_[add/del]
>
> Dave please apply this against net-next-2.6. I see that 914c8ad2d18b is still not in
> net-2.6.
Would you relax?
I just rebased net-2.6 and net-next-2.6 after Linus took in my
changes and I just applied your regression fix to my tree and
was about to let you know I applied it.
Sat, Mar 06, 2010 at 10:23:12PM CET, [email protected] wrote:
>
>On Mar 2, 2010, at 5:00 PM, Pavel Roskin wrote:
>
>> This patch to libpcap helps:
>>
>> --- a/pcap-linux.c
>> +++ b/pcap-linux.c
>> @@ -1563,6 +1563,7 @@ live_open_new(pcap_t *handle, const char
>> memset(&mr, 0, sizeof(mr));
>> mr.mr_ifindex = handle->md.ifindex;
>> mr.mr_type = PACKET_MR_PROMISC;
>> + mr.mr_alen = 6;
>
>If there are any network types that support promiscuous mode and have link-layer addresses that aren't 6 octets long, that would still fail.
>
>It sounds as if the fix is not to care about the address length if the address isn't used, so you don't need to get the length right for PACKET_MR_PROMISC or PACKET_MR_ALLMULTI, so libpcap, and other clients setting promiscuous or "show me all multicast packets" mode, don't need to change. Is that the case?
This should be fixed in kernel (net-2.6
1162563f82b434e3099c9e6c1bbdba846d792f0d)
Jirka
Le mercredi 03 mars 2010 à 07:40 +0100, Jiri Pirko a écrit :
> Subject: [net-2.6 PATCH] af_packet: move strict addr_len check right before dev_[mc/unicast]_[add/del]
>
> My previous patch 914c8ad2d18b62ad1420f518c0cab0b0b90ab308 incorrectly changed
> the length check in packet_mc_add to be more strict. The problem is that
> userspace is not filling this field (and it stays zeroed) in case of setting
> PACKET_MR_PROMISC or PACKET_MR_ALLMULTI. So move the strict check to the point
> in path where the addr_len must be set correctly.
>
> Signed-off-by: Jiri Pirko <[email protected]>
>
I am not sure it solves Pavel Roskin concern, but some credit should be
given to him :)
Reported-by: Pavel Roskin <[email protected]>
Thanks
Wed, Mar 03, 2010 at 04:31:07PM CET, [email protected] wrote:
>
>Would this be preventing pcap_inject() from working say in kernel 2.6.31
>(stock FC12 kernel)?
Nope. The patch went in just recently.
>
>Thanks,
>FM
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:tcpdump-workers-
>> [email protected]] On Behalf Of Pavel Roskin
>> Sent: Tuesday, March 02, 2010 6:01 PM
>> To: [email protected]; [email protected]; tcpdump-
>> [email protected]
>> Cc: Jiri Pirko
>> Subject: [tcpdump-workers] Current wireless-testing breaks libpcap:
>> mr_alen should be set
>>
>> Hello!
>>
>> The current wireless-testing appears to have some non-wireless bits from
>> the upcoming Linux 2.6.34. As a result, libpcap and all capture
>> programs that use it are broken.
>>
>> This patch to libpcap helps:
>>
>> --- a/pcap-linux.c
>> +++ b/pcap-linux.c
>> @@ -1563,6 +1563,7 @@ live_open_new(pcap_t *handle, const char
>> memset(&mr, 0, sizeof(mr));
>> mr.mr_ifindex = handle->md.ifindex;
>> mr.mr_type = PACKET_MR_PROMISC;
>> + mr.mr_alen = 6;
>> if (setsockopt(sock_fd, SOL_PACKET,
>> PACKET_ADD_MEMBERSHIP, &mr, sizeof(mr)) ==
>-1)
>> {
>>
>> libpcap git doesn't have the fix yet.
>>
>> The breakage must be coming from the commit 914c8ad2 by Jiri Pirko to
>> net/packet/af_packet.c
>>
>> I think it's very unhelpful to introduce patches that break significant
>> userspace functionality without giving the affected programs an advance
>> warning.
>>
>> Also, pulling bleeding edge stuff into wireless-testing before rc1
>> appears to be either a mistake or a bad decision.
>>
>> Sorry for cross-post, but it's an urgent issue. Repliers are encouraged
>> to trim the recipient list as necessary.
>>
>> --
>> Regards,
>> Pavel Roskin
>> -
>> This is the tcpdump-workers list.
>> Visit https://cod.sandelman.ca/ to unsubscribe.
>
Would this be preventing pcap_inject() from working say in kernel 2.6.31
(stock FC12 kernel)?
Thanks,
FM
> -----Original Message-----
> From: [email protected] [mailto:tcpdump-workers-
> [email protected]] On Behalf Of Pavel Roskin
> Sent: Tuesday, March 02, 2010 6:01 PM
> To: [email protected]; [email protected]; tcpdump-
> [email protected]
> Cc: Jiri Pirko
> Subject: [tcpdump-workers] Current wireless-testing breaks libpcap:
> mr_alen should be set
>
> Hello!
>
> The current wireless-testing appears to have some non-wireless bits from
> the upcoming Linux 2.6.34. As a result, libpcap and all capture
> programs that use it are broken.
>
> This patch to libpcap helps:
>
> --- a/pcap-linux.c
> +++ b/pcap-linux.c
> @@ -1563,6 +1563,7 @@ live_open_new(pcap_t *handle, const char
> memset(&mr, 0, sizeof(mr));
> mr.mr_ifindex = handle->md.ifindex;
> mr.mr_type = PACKET_MR_PROMISC;
> + mr.mr_alen = 6;
> if (setsockopt(sock_fd, SOL_PACKET,
> PACKET_ADD_MEMBERSHIP, &mr, sizeof(mr)) ==
-1)
> {
>
> libpcap git doesn't have the fix yet.
>
> The breakage must be coming from the commit 914c8ad2 by Jiri Pirko to
> net/packet/af_packet.c
>
> I think it's very unhelpful to introduce patches that break significant
> userspace functionality without giving the affected programs an advance
> warning.
>
> Also, pulling bleeding edge stuff into wireless-testing before rc1
> appears to be either a mistake or a bad decision.
>
> Sorry for cross-post, but it's an urgent issue. Repliers are encouraged
> to trim the recipient list as necessary.
>
> --
> Regards,
> Pavel Roskin
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
On Mar 2, 2010, at 5:00 PM, Pavel Roskin wrote:
> This patch to libpcap helps:
>
> --- a/pcap-linux.c
> +++ b/pcap-linux.c
> @@ -1563,6 +1563,7 @@ live_open_new(pcap_t *handle, const char
> memset(&mr, 0, sizeof(mr));
> mr.mr_ifindex = handle->md.ifindex;
> mr.mr_type = PACKET_MR_PROMISC;
> + mr.mr_alen = 6;
If there are any network types that support promiscuous mode and have link-layer addresses that aren't 6 octets long, that would still fail.
It sounds as if the fix is not to care about the address length if the address isn't used, so you don't need to get the length right for PACKET_MR_PROMISC or PACKET_MR_ALLMULTI, so libpcap, and other clients setting promiscuous or "show me all multicast packets" mode, don't need to change. Is that the case?
Subject: [net-2.6 PATCH] af_packet: move strict addr_len check right before dev_[mc/unicast]_[add/del]
My previous patch 914c8ad2d18b62ad1420f518c0cab0b0b90ab308 incorrectly changed
the length check in packet_mc_add to be more strict. The problem is that
userspace is not filling this field (and it stays zeroed) in case of setting
PACKET_MR_PROMISC or PACKET_MR_ALLMULTI. So move the strict check to the point
in path where the addr_len must be set correctly.
Signed-off-by: Jiri Pirko <[email protected]>
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 031a5e6..1612d41 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1688,6 +1688,8 @@ static int packet_dev_mc(struct net_device *dev, struct packet_mclist *i,
{
switch (i->type) {
case PACKET_MR_MULTICAST:
+ if (i->alen != dev->addr_len)
+ return -EINVAL;
if (what > 0)
return dev_mc_add(dev, i->addr, i->alen, 0);
else
@@ -1700,6 +1702,8 @@ static int packet_dev_mc(struct net_device *dev, struct packet_mclist *i,
return dev_set_allmulti(dev, what);
break;
case PACKET_MR_UNICAST:
+ if (i->alen != dev->addr_len)
+ return -EINVAL;
if (what > 0)
return dev_unicast_add(dev, i->addr);
else
@@ -1734,7 +1738,7 @@ static int packet_mc_add(struct sock *sk, struct packet_mreq_max *mreq)
goto done;
err = -EINVAL;
- if (mreq->mr_alen != dev->addr_len)
+ if (mreq->mr_alen > dev->addr_len)
goto done;
err = -ENOBUFS;
Wed, Mar 03, 2010 at 07:40:01AM CET, [email protected] wrote:
>Subject: [net-2.6 PATCH] af_packet: move strict addr_len check right before dev_[mc/unicast]_[add/del]
Dave please apply this against net-next-2.6. I see that 914c8ad2d18b is still not in
net-2.6.
Thanks a lot
Jirka
>
>My previous patch 914c8ad2d18b62ad1420f518c0cab0b0b90ab308 incorrectly changed
>the length check in packet_mc_add to be more strict. The problem is that
>userspace is not filling this field (and it stays zeroed) in case of setting
>PACKET_MR_PROMISC or PACKET_MR_ALLMULTI. So move the strict check to the point
>in path where the addr_len must be set correctly.
>
>Signed-off-by: Jiri Pirko <[email protected]>
>
>diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
>index 031a5e6..1612d41 100644
>--- a/net/packet/af_packet.c
>+++ b/net/packet/af_packet.c
>@@ -1688,6 +1688,8 @@ static int packet_dev_mc(struct net_device *dev, struct packet_mclist *i,
> {
> switch (i->type) {
> case PACKET_MR_MULTICAST:
>+ if (i->alen != dev->addr_len)
>+ return -EINVAL;
> if (what > 0)
> return dev_mc_add(dev, i->addr, i->alen, 0);
> else
>@@ -1700,6 +1702,8 @@ static int packet_dev_mc(struct net_device *dev, struct packet_mclist *i,
> return dev_set_allmulti(dev, what);
> break;
> case PACKET_MR_UNICAST:
>+ if (i->alen != dev->addr_len)
>+ return -EINVAL;
> if (what > 0)
> return dev_unicast_add(dev, i->addr);
> else
>@@ -1734,7 +1738,7 @@ static int packet_mc_add(struct sock *sk, struct packet_mreq_max *mreq)
> goto done;
>
> err = -EINVAL;
>- if (mreq->mr_alen != dev->addr_len)
>+ if (mreq->mr_alen > dev->addr_len)
> goto done;
>
> err = -ENOBUFS;
Wed, Mar 03, 2010 at 02:00:48AM CET, [email protected] wrote:
>Hello!
>
>The current wireless-testing appears to have some non-wireless bits from
>the upcoming Linux 2.6.34. As a result, libpcap and all capture
>programs that use it are broken.
>
>This patch to libpcap helps:
>
>--- a/pcap-linux.c
>+++ b/pcap-linux.c
>@@ -1563,6 +1563,7 @@ live_open_new(pcap_t *handle, const char
> memset(&mr, 0, sizeof(mr));
> mr.mr_ifindex = handle->md.ifindex;
> mr.mr_type = PACKET_MR_PROMISC;
>+ mr.mr_alen = 6;
> if (setsockopt(sock_fd, SOL_PACKET,
> PACKET_ADD_MEMBERSHIP, &mr, sizeof(mr)) == -1)
> {
>
>libpcap git doesn't have the fix yet.
>
>The breakage must be coming from the commit 914c8ad2 by Jiri Pirko to
>net/packet/af_packet.c
>
>I think it's very unhelpful to introduce patches that break significant
>userspace functionality without giving the affected programs an advance
>warning.
>
>Also, pulling bleeding edge stuff into wireless-testing before rc1
>appears to be either a mistake or a bad decision.
>
>Sorry for cross-post, but it's an urgent issue. Repliers are encouraged
>to trim the recipient list as necessary.
Sorry about this. Corrected patch will follow.
Jirka
>
>--
>Regards,
>Pavel Roskin
On Tue, Mar 02, 2010 at 08:00:48PM -0500, Pavel Roskin wrote:
> Also, pulling bleeding edge stuff into wireless-testing before rc1
> appears to be either a mistake or a bad decision.
Feel free to use an earlier commit...
--
John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
[email protected] ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.