* [wireless-next:for-davem 115/299] drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:419 t4_memory_rw() warn: 'data' puts 2048 bytes on stack
From: Fengguang Wu @ 2012-09-29 5:50 UTC (permalink / raw)
To: Vipul Pandya; +Cc: kernel-janitors, netdev, Jay Hernandez
Hi Vipul,
FYI, there are new smatch warnings show up in
tree: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git for-davem
head: c487606f835a93a725bac1aefd536be98f22474d
commit: 5afc8b84eb7b29e4646d6e8ca7e6d7196031d6f7 [115/299] cxgb4: Add functions to read memory via PCIE memory window
+ drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:419 t4_memory_rw() warn: 'data' puts 2048 bytes on stack
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:499 get_vpd_params() warn: 'vpd' puts 512 bytes on stack
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:518 get_vpd_params() info: why not propagate 'i' from pci_vpd_find_tag() instead of -22?
vim +419 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
5afc8b84 (Vipul Pandya 2012-09-26 408) /*
5afc8b84 (Vipul Pandya 2012-09-26 409) * The underlaying EDC/MC read routines read MEMWIN0_APERTURE bytes
5afc8b84 (Vipul Pandya 2012-09-26 410) * at a time so we need to round down the start and round up the end.
5afc8b84 (Vipul Pandya 2012-09-26 411) * We'll start copying out of the first line at (addr - start) a word
5afc8b84 (Vipul Pandya 2012-09-26 412) * at a time.
5afc8b84 (Vipul Pandya 2012-09-26 413) */
5afc8b84 (Vipul Pandya 2012-09-26 414) start = addr & ~(MEMWIN0_APERTURE-1);
5afc8b84 (Vipul Pandya 2012-09-26 415) end = (addr + len + MEMWIN0_APERTURE-1) & ~(MEMWIN0_APERTURE-1);
5afc8b84 (Vipul Pandya 2012-09-26 416) offset = (addr - start)/sizeof(__be32);
5afc8b84 (Vipul Pandya 2012-09-26 417)
5afc8b84 (Vipul Pandya 2012-09-26 418) for (pos = start; pos < end; pos += MEMWIN0_APERTURE, offset = 0) {
5afc8b84 (Vipul Pandya 2012-09-26 @419) __be32 data[MEMWIN0_APERTURE/sizeof(__be32)];
5afc8b84 (Vipul Pandya 2012-09-26 420)
5afc8b84 (Vipul Pandya 2012-09-26 421) /*
5afc8b84 (Vipul Pandya 2012-09-26 422) * If we're writing, copy the data from the caller's memory
5afc8b84 (Vipul Pandya 2012-09-26 423) * buffer
5afc8b84 (Vipul Pandya 2012-09-26 424) */
5afc8b84 (Vipul Pandya 2012-09-26 425) if (!dir) {
5afc8b84 (Vipul Pandya 2012-09-26 426) /*
5afc8b84 (Vipul Pandya 2012-09-26 427) * If we're doing a partial write, then we need to do
---
0-DAY kernel build testing backend Open Source Technology Centre
Fengguang Wu, Yuanhan Liu Intel Corporation
^ permalink raw reply
* [PATCH 1/1] Adds support for Lenovo 10/100 USB dongle.
From: Quinlan Pfiffer @ 2012-09-29 5:58 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Linux USB, Networking Drivers,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Quinlan Pfiffer
This dongle ships with the X1 Carbon, and has an AX88772B
usb to ethernet chip in it.
Signed-off-by: Quinlan Pfiffer <qpfiffer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/usb/asix_devices.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 32e31c5..fc20e53 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -930,6 +930,10 @@ static const struct usb_device_id products [] = {
USB_DEVICE (0x04f1, 0x3008),
.driver_info = (unsigned long) &ax8817x_info,
}, {
+ // Lenovo U2L100P 10/100
+ USB_DEVICE (0x17ef, 0x7203),
+ .driver_info = (unsigned long) &ax88772_info,
+}, {
// ASIX AX88772B 10/100
USB_DEVICE (0x0b95, 0x772b),
.driver_info = (unsigned long) &ax88772_info,
--
1.7.12.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] flexcan: disable bus error interrupts for the i.MX28
From: Hui Wang @ 2012-09-29 6:00 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Linux Netdev List, Linux-CAN, Hui Wang, Shawn Guo
In-Reply-To: <5065A35B.3020702@grandegger.com>
Wolfgang Grandegger wrote:
> Due to a bug in most Flexcan cores, the bus error interrupt needs
> to be enabled. Otherwise we don't get any error warning or passive
> interrupts. This is _not_ necessay for the i.MX28 and this patch
>
s/necessay/necessary/
Other looks fine to me. Reviewed-by: Hui Wang <jason77.wang@gmail.com>
^ permalink raw reply
* [PATCH net] use skb_end_offset() in skb_try_coalesce()
From: Weiping Pan @ 2012-09-29 6:15 UTC (permalink / raw)
To: netdev; +Cc: Weiping Pan
Commit ec47ea824774(skb: Add inline helper for getting the skb end offset from
head) introduces this helper function, skb_end_offset(),
we should make use of it.
Signed-off-by: Weiping Pan <wpan@redhat.com>
---
net/core/skbuff.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index e33ebae..86f040a 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3488,8 +3488,7 @@ bool skb_try_coalesce(struct sk_buff *to, struct sk_buff *from,
skb_shinfo(from)->nr_frags > MAX_SKB_FRAGS)
return false;
- delta = from->truesize -
- SKB_TRUESIZE(skb_end_pointer(from) - from->head);
+ delta = from->truesize - SKB_TRUESIZE(skb_end_offset(from));
}
WARN_ON_ONCE(delta < len);
--
1.7.4.4
^ permalink raw reply related
* Re: Possible bug with r8169 driver
From: Francois Romieu @ 2012-09-29 7:20 UTC (permalink / raw)
To: Nolwenn; +Cc: hayeswang, netdev
In-Reply-To: <1478421.GOy9qdQlkG@bureau>
Nolwenn <donolwenn@gmail.com> :
> Le vendredi 28 septembre 2012 00:21:47 Francois Romieu a écrit :
[...]
> > Can you send an 'ip -s link' before any ipv6 traffic flows, then
> > after ?
>
> Before ipv6 traffic
>
> % ip -s link
/me plugs brain and realizes that the driver does not update the device
stats multicast field.
The multicast stats will appear in the output of 'ethtool -S eth0'.
Can you send two complete binary tcpdump captures (w/o -p option) in the
same contexts ?
Don't bother obfuscating the ipv6 address if it equals the one appearing
in the mail headers.
[RTL8168f/8111f]
> > Hayes, is there by any luck something different for the 8168f regarding
> > the layout of the multicast filtering registers ?
>
> I don't have sufficient skills in networks to understand what do you mean,
> sorry. Any command line, files comparing to get the information ?
The documentation is scarce to say the least. Hayes can tell if some
register layout change or chipset specifics has gone unnoticed.
--
Ueimor
^ permalink raw reply
* Re: Possible bug with r8169 driver
From: Nolwenn @ 2012-09-29 14:49 UTC (permalink / raw)
To: Francois Romieu; +Cc: hayeswang, netdev
In-Reply-To: <20120929072028.GA3730@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]
Le samedi 29 septembre 2012 09:20:28 Francois Romieu a écrit :
> > > Can you send an 'ip -s link' before any ipv6 traffic flows, then
> > > after ?
> >
> > Before ipv6 traffic
> >
> > % ip -s link
>
> /me plugs brain and realizes that the driver does not update the device
> stats multicast field.
>
> The multicast stats will appear in the output of 'ethtool -S eth0'.
>
> Can you send two complete binary tcpdump captures (w/o -p option) in the
> same contexts ?
>
Before tcpdump and some mail checking
# ethtool -S eth0
NIC statistics:
tx_packets: 3309
rx_packets: 4672
tx_errors: 0
rx_errors: 0
rx_missed: 0
align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 4672
broadcast: 0
multicast: 0
tx_aborted: 0
tx_underrun: 0
After tcpdump wihout mail checking
# ethtool -S eth0
NIC statistics:
tx_packets: 302
rx_packets: 491
tx_errors: 0
rx_errors: 0
rx_missed: 0
align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 299
broadcast: 82
multicast: 110
tx_aborted: 0
tx_underrun: 0
The two dumps are attached (I hope it's what Michel wants !)
tcpdump -pw dump-eth0-promisc-off
tcpdump -w dump-eth0-promisc-on
[-- Attachment #2: dump-eth0-promisc-off --]
[-- Type: application/vnd.tcpdump.pcap, Size: 19747 bytes --]
[-- Attachment #3: dump-eth0-promisc-on --]
[-- Type: application/vnd.tcpdump.pcap, Size: 72227 bytes --]
^ permalink raw reply
* Re: Possible bug with r8169 driver
From: Francois Romieu @ 2012-09-29 19:01 UTC (permalink / raw)
To: Nolwenn; +Cc: hayeswang, netdev
In-Reply-To: <2565578.vyFL3Bzlf9@bureau>
Nolwenn <donolwenn@gmail.com> :
[...]
> The two dumps are attached (I hope it's what Michel wants !)
(Michel ?)
The device does not see the multicast router advertisement.
Please try the hack below.
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index b47d5b3..8080dac 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4522,6 +4522,8 @@ static void rtl_set_rx_mode(struct net_device *dev)
mc_filter[0] = swab32(mc_filter[1]);
mc_filter[1] = swab32(data);
+ tmp |= 0xff7e1880;
+ RTL_W32(RxConfig, tmp);
}
RTL_W32(MAR0 + 4, mc_filter[1]);
^ permalink raw reply related
* Your mailbox
From: Facultad de Ciencias de la Salud UQ @ 2012-09-29 21:46 UTC (permalink / raw)
Your mailbox has exceeded it storage limit set by your administrator,
and you will not be able to receive new mails until you re-validate
it. To re-validate -> click here
https://docs.google.com/spreadsheet/viewform?formkey=dFhqVjkyMHljZHlMY3pzUlIwNEpyVEE6MQ
^ permalink raw reply
* Re: [PATCH 1/7 net-next v2] tg3: Introduce separate functions to allocate/free RX/TX rings.
From: David Miller @ 2012-09-30 6:12 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1348852363-8582-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 28 Sep 2012 10:12:37 -0700
> This is preparation work to allow the number of RX and TX rings to be
> configured separately.
>
> Reviewed-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> Reviewed-by: Benjamin Li <benli@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/7 net-next v2] tg3: Allow number of rx and tx rings to be set independently.
From: David Miller @ 2012-09-30 6:12 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1348852363-8582-2-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 28 Sep 2012 10:12:38 -0700
> irq_cnt is no longer necessarily equal to the number rx or tx rings.
>
> Reviewed-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> Reviewed-by: Benjamin Li <benli@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/7 net-next v2] tg3: Separate coalescing setup for rx and tx
From: David Miller @ 2012-09-30 6:12 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1348852363-8582-3-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 28 Sep 2012 10:12:39 -0700
> since the number of rings can be different.
>
> Reviewed-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> Reviewed-by: Benjamin Li <benli@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 4/7 net-next v2] tg3: Refactor tg3_open()
From: David Miller @ 2012-09-30 6:12 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1348852363-8582-4-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 28 Sep 2012 10:12:40 -0700
> by introducing tg3_start() that handles all initialization steps from
> IRQ allocation. This function will be needed when adding support for
> changing the number of rx and tx rings.
>
> Reviewed-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> Reviewed-by: Benjamin Li <benli@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 5/7 net-next v2] tg3: Refactor tg3_close()
From: David Miller @ 2012-09-30 6:12 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1348852363-8582-5-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 28 Sep 2012 10:12:41 -0700
> by introducing tg3_stop() that does the opposite of tg3_start(). This
> function will be useful when adding the support for changing the numbe
> of rx and tx rings.
>
> Reviewed-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> Reviewed-by: Benjamin Li <benli@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 6/7 net-next v2] tg3: Add support for ethtool -L|-l to get/set the number of rings.
From: David Miller @ 2012-09-30 6:12 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1348852363-8582-6-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 28 Sep 2012 10:12:42 -0700
> Default remains the same.
>
> Reviewed-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> Reviewed-by: Benjamin Li <benli@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 7/7 net-next v2] tg3: Disable multiple TX rings by default due to hardware flaw
From: David Miller @ 2012-09-30 6:12 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1348852363-8582-7-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 28 Sep 2012 10:12:43 -0700
> Simple round-robin hardware TX scheduling can cause starvation of TX rings
> with small packets when other TX rings have large TSO or jumbo packets.
>
> In the simplest case, consider 2 TCP streams running in opposite
> directions. The TSO TX traffic will hash to one ring and the ACKs for the
> incoming data on a different TCP connection will hash to a different TX
> ring. The hardware fetches one complete TSO packet (up to 64K data)
> before servicing the other TX ring. When it gets to the other TX ring, it
> will only fetch one packet (64-byte ACK packet in this case). After that,
> it will switch back to the 1st ring filled with more TSO packets. Because
> only one ACK can go out roughly every 500 usec in this case, the incoming
> data rate becomes very low.
>
> Update version to 3.125.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 1/4] be2net: remove type argument of be_cmd_mac_addr_query()
From: David Miller @ 2012-09-30 6:15 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <29e503e4-1dc2-4430-8a25-b20f49c1b3f4@CMEXHTCAS2.ad.emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Fri, 28 Sep 2012 20:09:41 +0530
> All invocations of this routine use the same type value.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 2/4] be2net: fix wrong handling of be_setup() failure in be_probe()
From: David Miller @ 2012-09-30 6:15 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <b02d091e-153e-4d6a-b767-158394d0d990@CMEXHTCAS2.ad.emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Fri, 28 Sep 2012 20:09:42 +0530
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 3/4] be2net: cleanup code related to be_link_status_query()
From: David Miller @ 2012-09-30 6:16 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <851da7da-1e96-4aed-97f1-1207d73f9cf6@CMEXHTCAS2.ad.emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Fri, 28 Sep 2012 20:09:43 +0530
> 1) link_status_query() is always called to query the link-speed (speed
> after applying qos). When there is no qos setting, link-speed is derived from
> port-speed. Do all this inside this routine and hide this from the callers.
>
> 2) adpater->phy.forced_port_speed is not being set anywhere after being
> initialized. Get rid of this variable.
>
> 3) Ignore async link_speed notifications till the initial value has been
> fetched from FW.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 4/4] be2net: fixup log messages
From: David Miller @ 2012-09-30 6:16 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <e698cd68-540d-4a7a-bd76-2e9c73ddf19c@CMEXHTCAS2.ad.emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Fri, 28 Sep 2012 20:09:44 +0530
> Added and modified a few log messages mostly in probe path.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/2] bnx2x: net-next FW upgrade
From: David Miller @ 2012-09-30 6:28 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, eilong, ariele
In-Reply-To: <1348757936-10262-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Thu, 27 Sep 2012 16:58:54 +0200
> This series contains 2 patches - the first allows the bnx2x driver to
> utilize the recently submitted bnx2x FW 7.8.2, while the second advances
> the bnx2x version to 1.78.00-0.
>
> Please consider applying these patches to 'net-next'.
These patches do not build.
drivers/net/ethernet/broadcom/cnic.c: In function ‘cnic_init_bnx2x_tx_ring’:
drivers/net/ethernet/broadcom/cnic.c:4904:4: error: ‘ETH_TX_START_BD_ETH_ADDR_TYPE_SHIFT’ undeclared (first use in this function)
drivers/net/ethernet/broadcom/cnic.c:4904:4: note: each undeclared identifier is reported only once for each function it appears in
make[4]: *** [drivers/net/ethernet/broadcom/cnic.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [drivers/net/ethernet/broadcom] Error 2
make[2]: *** [drivers/net/ethernet] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
^ permalink raw reply
* Re: pull request: wireless-next 2012-09-28
From: David Miller @ 2012-09-30 6:30 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120928173425.GA15886-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Fri, 28 Sep 2012 13:34:26 -0400
> Here is another batch of updates intended for 3.7...
>
> Highlights include an hci_connect re-write in Bluetooth, HCI/LLC
> layer separation in NFC, removal of the raw pn544 NFC driver, NFC LLCP
> raw sockets support, improved IBSS auth frame handling in mac80211,
> full-MAC AP mode notification support in mac80211, a lot of attention
> paid to brcmfmac, and the usual level of updates to iwlwifi, ath9k,
> mwifiex, and rt2x00, and various other updates.
Pulled, thanks John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: New commands to configure IOV features
From: Yuval Mintz @ 2012-09-30 6:39 UTC (permalink / raw)
To: Don Dutile
Cc: Yinghai Lu, Rose, Gregory V, Ben Hutchings, Bjorn Helgaas,
davem@davemloft.net, netdev@vger.kernel.org, Ariel Elior,
Eilon Greenstein, linux-pci
In-Reply-To: <505CC930.5070807@redhat.com>
>>> yuk, no.
>>> I have a set of patches almost done.
>>> i'm tied up until Monday on RHEL6, then I'll switch gears& post a set of
>>> patches.
hi Don - anything new about this incoming patch-series?
>>
>> so that is your employer 'sinternal policy? for RHEL 6 kernel first,
>> then upstream kernel?
> No, I have deadlines for RHEL6 for *other work* until Monday. After that,
> I can re-focus on upstream work. Some of us actually have other work than
> just upstream.... crazy talk, I know! ;-)
^ permalink raw reply
* Re: [PATCH net-next 0/2] bnx2x: net-next FW upgrade
From: Yuval Mintz @ 2012-09-30 6:16 UTC (permalink / raw)
To: David Miller, Michael Chan; +Cc: netdev, eilong, ariele
In-Reply-To: <20120930.022836.251638342830809918.davem@davemloft.net>
> These patches do not build.
>
> drivers/net/ethernet/broadcom/cnic.c: In function ‘cnic_init_bnx2x_tx_ring’:
> drivers/net/ethernet/broadcom/cnic.c:4904:4: error: ‘ETH_TX_START_BD_ETH_ADDR_TYPE_SHIFT’ undeclared (first use in this function)
> drivers/net/ethernet/broadcom/cnic.c:4904:4: note: each undeclared identifier is reported only once for each function it appears in
> make[4]: *** [drivers/net/ethernet/broadcom/cnic.o] Error 1
> make[4]: *** Waiting for unfinished jobs....
> make[3]: *** [drivers/net/ethernet/broadcom] Error 2
> make[2]: *** [drivers/net/ethernet] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
Sorry about that - the HSI has changed which affects cnic as well as bnx2x.
A revised patch series which will advance both into the new FW will be submitted soon.
^ permalink raw reply
* RE: [PATCH net-next] mlx4: dont orphan skbs in mlx4_en_xmit()
From: Yevgeny Petrilin @ 2012-09-30 6:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Or Gerlitz
In-Reply-To: <1348854806.5093.2686.camel@edumazet-glaptop>
Acked-by: Yevgeny Petrilin <yevgenyp@mellanox.com>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Friday, September 28, 2012 7:54 PM
> To: Yevgeny Petrilin
> Cc: David Miller; netdev; Or Gerlitz
> Subject: [PATCH net-next] mlx4: dont orphan skbs in mlx4_en_xmit()
>
> From: Eric Dumazet <edumazet@google.com>
>
> After commit e22979d96a55d (mlx4_en: Moving to Interrupts for TX
> completions) we no longer need to orphan skbs in mlx4_en_xmit()
> since skb wont stay a long time in TX ring before their release.
>
> Orphaning skbs in ndo_start_xmit() should be avoided as much as
> possible, since it breaks TCP Small Queue or other flow control
> mechanisms (per socket limits)
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Yevgeny Petrilin <yevgenyp@mellanox.com>
> Cc: Or Gerlitz <ogerlitz@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_tx.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> index 10bba09..c10e3a6 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> @@ -712,10 +712,6 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
> if (bounce)
> tx_desc = mlx4_en_bounce_to_desc(priv, ring, index, desc_size);
>
> - /* Run destructor before passing skb to HW */
> - if (likely(!skb_shared(skb)))
> - skb_orphan(skb);
> -
> if (ring->bf_enabled && desc_size <= MAX_BF && !bounce && !vlan_tag) {
> *(__be32 *) (&tx_desc->ctrl.vlan_tag) |= cpu_to_be32(ring->doorbell_qpn);
> op_own |= htonl((bf_index & 0xffff) << 8);
>
^ permalink raw reply
* Re: Possible networking regression in 3.6.0
From: Chris Clayton @ 2012-09-30 15:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, gpiez
In-Reply-To: <1348831592.5093.2251.camel@edumazet-glaptop>
Hi Eric,
On 09/28/12 12:26, Eric Dumazet wrote:
> On Fri, 2012-09-28 at 10:22 +0100, Chris Clayton wrote:
>
>> No, the WinXP guest is configured with a fixed IP address
>> (192.168.200.1). Subnet mask is 255.255.255.0, and default gateway is
>> 192.168.200.254. DNS is 192.168.0.1.
>>
>
> I have no problem with such a setup, with a linux guest.
>
> Could you send again a tcpdump, but including link-level header ?
> (option -e)
>
> Ideally, you could send two traces, one taken on tap0, and another taken
> on eth0.
>
Below are two more traces that I think may well be more useful than
those I sent on Friday. They are taken with tcpdump directly (after some
reading up on that application) rather than tcpdump translations of pcap
files captured with netsniff-ng. Also, they are taken concurrently, so
they show the traffic on tap0 and eth0 at the time of an unsuccessful
attempt to ping the router from the WinXP KVM client. The command was:
sudo tcpdump -nev -i eth0 -Z chris >eth0.trace
tap0:
16:05:14.909057 52:54:0c:3b:17:39 > 62:4e:ff:6b:0d:ce, ethertype IPv4
(0x0800), length 64: (tos 0x0, ttl 128, id 286, offset 0, flags [none],
proto UDP (17), length 50)
192.168.200.1.49391 > 192.168.0.1.domain: 33727+ A? wpad. (22)
16:05:21.909026 52:54:0c:3b:17:39 > Broadcast, ethertype IPv4 (0x0800),
length 92: (tos 0x0, ttl 128, id 287, offset 0, flags [none], proto UDP
(17), length 78)
192.168.200.1.netbios-ns > 192.168.200.255.netbios-ns: NBT UDP
PACKET(137): QUERY; REQUEST; BROADCAST
16:05:21.909123 62:4e:ff:6b:0d:ce > Broadcast, ethertype IPv4 (0x0800),
length 264: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
(17), length 250)
192.168.200.254.netbios-dgm > 192.168.200.255.netbios-dgm: NBT UDP
PACKET(138)
16:05:21.909141 62:4e:ff:6b:0d:ce > Broadcast, ethertype IPv4 (0x0800),
length 249: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
(17), length 235)
192.168.200.254.netbios-dgm > 192.168.200.255.netbios-dgm: NBT UDP
PACKET(138)
16:05:22.261009 52:54:0c:3b:17:39 > 62:4e:ff:6b:0d:ce, ethertype IPv4
(0x0800), length 74: (tos 0x0, ttl 128, id 288, offset 0, flags [none],
proto ICMP (1), length 60)
192.168.200.1 > 192.168.0.1: ICMP echo request, id 512, seq 3840,
length 40
16:05:22.704716 52:54:0c:3b:17:39 > Broadcast, ethertype IPv4 (0x0800),
length 92: (tos 0x0, ttl 128, id 289, offset 0, flags [none], proto UDP
(17), length 78)
192.168.200.1.netbios-ns > 192.168.200.255.netbios-ns: NBT UDP
PACKET(137): QUERY; REQUEST; BROADCAST
16:05:23.457224 52:54:0c:3b:17:39 > Broadcast, ethertype IPv4 (0x0800),
length 92: (tos 0x0, ttl 128, id 290, offset 0, flags [none], proto UDP
(17), length 78)
192.168.200.1.netbios-ns > 192.168.200.255.netbios-ns: NBT UDP
PACKET(137): QUERY; REQUEST; BROADCAST
16:05:24.208015 52:54:0c:3b:17:39 > 62:4e:ff:6b:0d:ce, ethertype IPv4
(0x0800), length 82: (tos 0x0, ttl 128, id 291, offset 0, flags [none],
proto UDP (17), length 68)
192.168.200.1.56551 > 192.168.0.1.domain: 63293+ A?
download.microsoft.com. (40)
16:05:25.204731 52:54:0c:3b:17:39 > 62:4e:ff:6b:0d:ce, ethertype IPv4
(0x0800), length 82: (tos 0x0, ttl 128, id 292, offset 0, flags [none],
proto UDP (17), length 68)
192.168.200.1.56551 > 192.168.0.1.domain: 63293+ A?
download.microsoft.com. (40)
16:05:26.204743 52:54:0c:3b:17:39 > 62:4e:ff:6b:0d:ce, ethertype IPv4
(0x0800), length 82: (tos 0x0, ttl 128, id 293, offset 0, flags [none],
proto UDP (17), length 68)
192.168.200.1.56551 > 192.168.0.1.domain: 63293+ A?
download.microsoft.com. (40)
16:05:27.580723 52:54:0c:3b:17:39 > 62:4e:ff:6b:0d:ce, ethertype IPv4
(0x0800), length 74: (tos 0x0, ttl 128, id 294, offset 0, flags [none],
proto ICMP (1), length 60)
192.168.200.1 > 192.168.0.1: ICMP echo request, id 512, seq 4096,
length 40
16:05:28.204764 52:54:0c:3b:17:39 > 62:4e:ff:6b:0d:ce, ethertype IPv4
(0x0800), length 82: (tos 0x0, ttl 128, id 295, offset 0, flags [none],
proto UDP (17), length 68)
192.168.200.1.56551 > 192.168.0.1.domain: 63293+ A?
download.microsoft.com. (40)
16:05:32.204731 52:54:0c:3b:17:39 > 62:4e:ff:6b:0d:ce, ethertype IPv4
(0x0800), length 82: (tos 0x0, ttl 128, id 296, offset 0, flags [none],
proto UDP (17), length 68)
192.168.200.1.56551 > 192.168.0.1.domain: 63293+ A?
download.microsoft.com. (40)
16:05:33.080759 52:54:0c:3b:17:39 > 62:4e:ff:6b:0d:ce, ethertype IPv4
(0x0800), length 74: (tos 0x0, ttl 128, id 297, offset 0, flags [none],
proto ICMP (1), length 60)
192.168.200.1 > 192.168.0.1: ICMP echo request, id 512, seq 4352,
length 40
16:05:38.582182 52:54:0c:3b:17:39 > 62:4e:ff:6b:0d:ce, ethertype IPv4
(0x0800), length 74: (tos 0x0, ttl 128, id 298, offset 0, flags [none],
proto ICMP (1), length 60)
192.168.200.1 > 192.168.0.1: ICMP echo request, id 512, seq 4608,
length 40
16:05:39.218737 52:54:0c:3b:17:39 > 62:4e:ff:6b:0d:ce, ethertype IPv4
(0x0800), length 64: (tos 0x0, ttl 128, id 299, offset 0, flags [none],
proto UDP (17), length 50)
192.168.200.1.60955 > 192.168.0.1.domain: 26953+ A? wpad. (22)
16:05:40.204735 52:54:0c:3b:17:39 > 62:4e:ff:6b:0d:ce, ethertype IPv4
(0x0800), length 64: (tos 0x0, ttl 128, id 300, offset 0, flags [none],
proto UDP (17), length 50)
192.168.200.1.60955 > 192.168.0.1.domain: 26953+ A? wpad. (22)
16:05:41.204721 52:54:0c:3b:17:39 > 62:4e:ff:6b:0d:ce, ethertype IPv4
(0x0800), length 64: (tos 0x0, ttl 128, id 301, offset 0, flags [none],
proto UDP (17), length 50)
192.168.200.1.60955 > 192.168.0.1.domain: 26953+ A? wpad. (22)
16:05:43.238517 52:54:0c:3b:17:39 > 62:4e:ff:6b:0d:ce, ethertype IPv4
(0x0800), length 64: (tos 0x0, ttl 128, id 302, offset 0, flags [none],
proto UDP (17), length 50)
192.168.200.1.60955 > 192.168.0.1.domain: 26953+ A? wpad. (22)
16:05:47.236721 52:54:0c:3b:17:39 > 62:4e:ff:6b:0d:ce, ethertype IPv4
(0x0800), length 64: (tos 0x0, ttl 128, id 303, offset 0, flags [none],
proto UDP (17), length 50)
192.168.200.1.60955 > 192.168.0.1.domain: 26953+ A? wpad. (22)
eth0:
16:05:22.261037 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 74: (tos 0x0, ttl 127, id 288, offset 0, flags [none],
proto ICMP (1), length 60)
192.168.0.40 > 192.168.0.1: ICMP echo request, id 512, seq 3840,
length 40
16:05:22.264612 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 74: (tos 0x0, ttl 255, id 53593, offset 0, flags
[none], proto ICMP (1), length 60)
192.168.0.1 > 192.168.0.40: ICMP echo reply, id 512, seq 3840,
length 40
16:05:24.208041 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 82: (tos 0x0, ttl 127, id 291, offset 0, flags [none],
proto UDP (17), length 68)
192.168.0.40.56551 > 192.168.0.1.domain: 63293+ A?
download.microsoft.com. (40)
16:05:24.270825 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 426: (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto UDP (17), length 412)
192.168.0.1.domain > 192.168.0.40.56551: 63293 7/8/0
download.microsoft.com. CNAME download.microsoft.com.nsatc.net.,
download.microsoft.com.nsatc.net. CNAME main.dl.ms.akadns.net.,
main.dl.ms.akadns.net. CNAME intl.dl.ms.akadns.net.,
intl.dl.ms.akadns.net. CNAME dl.ms.georedirector.akadns.net.,
dl.ms.georedirector.akadns.net. CNAME a767.ms.akamai.net.,
a767.ms.akamai.net. A 90.223.216.161, a767.ms.akamai.net. A
90.223.216.153 (384)
16:05:25.204745 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 82: (tos 0x0, ttl 127, id 292, offset 0, flags [none],
proto UDP (17), length 68)
192.168.0.40.56551 > 192.168.0.1.domain: 63293+ A?
download.microsoft.com. (40)
16:05:25.266414 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 442: (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto UDP (17), length 428)
192.168.0.1.domain > 192.168.0.40.56551: 63293 7/8/1
download.microsoft.com. CNAME download.microsoft.com.nsatc.net.,
download.microsoft.com.nsatc.net. CNAME main.dl.ms.akadns.net.,
main.dl.ms.akadns.net. CNAME intl.dl.ms.akadns.net.,
intl.dl.ms.akadns.net. CNAME dl.ms.georedirector.akadns.net.,
dl.ms.georedirector.akadns.net. CNAME a767.ms.akamai.net.,
a767.ms.akamai.net. A 90.223.216.153, a767.ms.akamai.net. A
90.223.216.161 (400)
16:05:26.204761 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 82: (tos 0x0, ttl 127, id 293, offset 0, flags [none],
proto UDP (17), length 68)
192.168.0.40.56551 > 192.168.0.1.domain: 63293+ A?
download.microsoft.com. (40)
16:05:26.237788 00:1f:33:80:09:44 > 01:00:5e:00:00:01, ethertype IPv4
(0x0800), length 60: (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto
IGMP (2), length 28)
192.168.0.1 > 224.0.0.1: igmp query v2
16:05:26.266706 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 458: (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto UDP (17), length 444)
192.168.0.1.domain > 192.168.0.40.56551: 63293 7/8/2
download.microsoft.com. CNAME download.microsoft.com.nsatc.net.,
download.microsoft.com.nsatc.net. CNAME main.dl.ms.akadns.net.,
main.dl.ms.akadns.net. CNAME intl.dl.ms.akadns.net.,
intl.dl.ms.akadns.net. CNAME dl.ms.georedirector.akadns.net.,
dl.ms.georedirector.akadns.net. CNAME a767.ms.akamai.net.,
a767.ms.akamai.net. A 90.223.216.161, a767.ms.akamai.net. A
90.223.216.153 (416)
16:05:27.580742 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 74: (tos 0x0, ttl 127, id 294, offset 0, flags [none],
proto ICMP (1), length 60)
192.168.0.40 > 192.168.0.1: ICMP echo request, id 512, seq 4096,
length 40
16:05:27.585193 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 74: (tos 0x0, ttl 255, id 53594, offset 0, flags
[none], proto ICMP (1), length 60)
192.168.0.1 > 192.168.0.40: ICMP echo reply, id 512, seq 4096,
length 40
16:05:28.204783 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 82: (tos 0x0, ttl 127, id 295, offset 0, flags [none],
proto UDP (17), length 68)
192.168.0.40.56551 > 192.168.0.1.domain: 63293+ A?
download.microsoft.com. (40)
16:05:28.267047 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 442: (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto UDP (17), length 428)
192.168.0.1.domain > 192.168.0.40.56551: 63293 7/8/1
download.microsoft.com. CNAME download.microsoft.com.nsatc.net.,
download.microsoft.com.nsatc.net. CNAME main.dl.ms.akadns.net.,
main.dl.ms.akadns.net. CNAME intl.dl.ms.akadns.net.,
intl.dl.ms.akadns.net. CNAME dl.ms.georedirector.akadns.net.,
dl.ms.georedirector.akadns.net. CNAME a767.ms.akamai.net.,
a767.ms.akamai.net. A 90.223.216.161, a767.ms.akamai.net. A
90.223.216.153 (400)
16:05:29.267032 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype ARP
(0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.0.40 tell 192.168.0.1, length 46
16:05:29.267049 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype ARP
(0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.40
is-at 5c:9a:d8:5c:63:31, length 28
16:05:32.204753 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 82: (tos 0x0, ttl 127, id 296, offset 0, flags [none],
proto UDP (17), length 68)
192.168.0.40.56551 > 192.168.0.1.domain: 63293+ A?
download.microsoft.com. (40)
16:05:32.267308 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 458: (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto UDP (17), length 444)
192.168.0.1.domain > 192.168.0.40.56551: 63293 7/8/2
download.microsoft.com. CNAME download.microsoft.com.nsatc.net.,
download.microsoft.com.nsatc.net. CNAME main.dl.ms.akadns.net.,
main.dl.ms.akadns.net. CNAME intl.dl.ms.akadns.net.,
intl.dl.ms.akadns.net. CNAME dl.ms.georedirector.akadns.net.,
dl.ms.georedirector.akadns.net. CNAME a767.ms.akamai.net.,
a767.ms.akamai.net. A 90.223.216.161, a767.ms.akamai.net. A
90.223.216.153 (416)
16:05:33.080772 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 74: (tos 0x0, ttl 127, id 297, offset 0, flags [none],
proto ICMP (1), length 60)
192.168.0.40 > 192.168.0.1: ICMP echo request, id 512, seq 4352,
length 40
16:05:33.084435 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 74: (tos 0x0, ttl 255, id 53595, offset 0, flags
[none], proto ICMP (1), length 60)
192.168.0.1 > 192.168.0.40: ICMP echo reply, id 512, seq 4352,
length 40
16:05:35.277471 00:1f:33:80:09:44 > 01:00:5e:00:00:02, ethertype IPv4
(0x0800), length 60: (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto
IGMP (2), length 32, options (RA))
192.168.0.1 > 224.0.0.2: igmp v2 report 224.0.0.2
16:05:38.582202 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 74: (tos 0x0, ttl 127, id 298, offset 0, flags [none],
proto ICMP (1), length 60)
192.168.0.40 > 192.168.0.1: ICMP echo request, id 512, seq 4608,
length 40
16:05:38.587143 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 74: (tos 0x0, ttl 255, id 53596, offset 0, flags
[none], proto ICMP (1), length 60)
192.168.0.1 > 192.168.0.40: ICMP echo reply, id 512, seq 4608,
length 40
16:05:39.218763 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 64: (tos 0x0, ttl 127, id 299, offset 0, flags [none],
proto UDP (17), length 50)
192.168.0.40.60955 > 192.168.0.1.domain: 26953+ A? wpad. (22)
16:05:39.280065 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 139: (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto UDP (17), length 125)
192.168.0.1.domain > 192.168.0.40.60955: 26953 NXDomain 0/1/0 (97)
16:05:40.204754 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 64: (tos 0x0, ttl 127, id 300, offset 0, flags [none],
proto UDP (17), length 50)
192.168.0.40.60955 > 192.168.0.1.domain: 26953+ A? wpad. (22)
16:05:40.266317 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 139: (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto UDP (17), length 125)
192.168.0.1.domain > 192.168.0.40.60955: 26953 NXDomain 0/1/0 (97)
16:05:41.204738 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 64: (tos 0x0, ttl 127, id 301, offset 0, flags [none],
proto UDP (17), length 50)
192.168.0.40.60955 > 192.168.0.1.domain: 26953+ A? wpad. (22)
16:05:41.266343 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 139: (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto UDP (17), length 125)
192.168.0.1.domain > 192.168.0.40.60955: 26953 NXDomain 0/1/0 (97)
16:05:43.238538 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 64: (tos 0x0, ttl 127, id 302, offset 0, flags [none],
proto UDP (17), length 50)
192.168.0.40.60955 > 192.168.0.1.domain: 26953+ A? wpad. (22)
16:05:43.301692 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 139: (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto UDP (17), length 125)
192.168.0.1.domain > 192.168.0.40.60955: 26953 NXDomain 0/1/0 (97)
16:05:44.230290 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype ARP
(0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.0.1 tell 192.168.0.40, length 28
16:05:44.233532 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype ARP
(0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.1
is-at 00:1f:33:80:09:44, length 46
16:05:47.236740 5c:9a:d8:5c:63:31 > 00:1f:33:80:09:44, ethertype IPv4
(0x0800), length 64: (tos 0x0, ttl 127, id 303, offset 0, flags [none],
proto UDP (17), length 50)
192.168.0.40.60955 > 192.168.0.1.domain: 26953+ A? wpad. (22)
16:05:47.296388 00:1f:33:80:09:44 > 5c:9a:d8:5c:63:31, ethertype IPv4
(0x0800), length 139: (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto UDP (17), length 125)
192.168.0.1.domain > 192.168.0.40.60955: 26953 NXDomain 0/1/0 (97)
16:05:48.530940 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 446: (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto
UDP (17), length 432)
192.168.0.112.3829 > 239.255.255.250.1900: UDP, length 404
16:05:48.531962 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 455: (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto
UDP (17), length 441)
192.168.0.112.3829 > 239.255.255.250.1900: UDP, length 413
16:05:48.533472 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 494: (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto
UDP (17), length 480)
192.168.0.112.3829 > 239.255.255.250.1900: UDP, length 452
16:05:48.534564 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 490: (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto
UDP (17), length 476)
192.168.0.112.2600 > 239.255.255.250.1900: UDP, length 448
16:05:48.536749 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 486: (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto
UDP (17), length 472)
192.168.0.112.2411 > 239.255.255.250.1900: UDP, length 444
16:05:48.537798 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 486: (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto
UDP (17), length 472)
192.168.0.112.1205 > 239.255.255.250.1900: UDP, length 444
16:05:48.633492 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 446: (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto
UDP (17), length 432)
192.168.0.112.1378 > 239.255.255.250.1900: UDP, length 404
16:05:48.634558 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 455: (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto
UDP (17), length 441)
192.168.0.112.1378 > 239.255.255.250.1900: UDP, length 413
16:05:48.636069 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 494: (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto
UDP (17), length 480)
192.168.0.112.1378 > 239.255.255.250.1900: UDP, length 452
16:05:48.637119 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 490: (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto
UDP (17), length 476)
192.168.0.112.3487 > 239.255.255.250.1900: UDP, length 448
16:05:48.638631 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 486: (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto
UDP (17), length 472)
192.168.0.112.4415 > 239.255.255.250.1900: UDP, length 444
16:05:48.639702 00:19:fb:be:cb:55 > 01:00:5e:7f:ff:fa, ethertype IPv4
(0x0800), length 486: (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto
UDP (17), length 472)
192.168.0.112.2700 > 239.255.255.250.1900: UDP, length 444
>
>
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox