Before this patch, a sniffer attached to a VRF used as the receiving
interface of L3 tunneled packets detects them as malformed packets and
it complains about that (i.e.: tcpdump shows bogus packets).
The reason is that a tunneled L3 packet does not carry any L2
information and when the VRF is
Before this patch, a sniffer attached to a VRF used as the receiving
interface of L3 tunneled packets detects them as malformed packets and
it complains about that (i.e.: tcpdump shows bogus packets).
The reason is that a tunneled L3 packet does not carry any L2
information and when the VRF is
Hi Jakub,
On Tue, 10 Nov 2020 14:50:45 -0800
Jakub Kicinski wrote:
> On Sat, 7 Nov 2020 16:31:35 +0100 Andrea Mayer wrote:
> > Before this patch, a sniffer attached to a VRF used as the receiving
> > interface of L3 tunneled packets detects them as malformed packets and
> &g
On Sat, 7 Nov 2020 16:31:35 +0100 Andrea Mayer wrote:
> Before this patch, a sniffer attached to a VRF used as the receiving
> interface of L3 tunneled packets detects them as malformed packets and
> it complains about that (i.e.: tcpdump shows bogus packets).
>
> The reason is
Before this patch, a sniffer attached to a VRF used as the receiving
interface of L3 tunneled packets detects them as malformed packets and
it complains about that (i.e.: tcpdump shows bogus packets).
The reason is that a tunneled L3 packet does not carry any L2
information and when the VRF is
On 11/3/20 5:52 AM, Andrea Mayer wrote:
> Before this patch, a sniffer attached to a VRF used as the receiving
> interface of L3 tunneled packets detects them as malformed packets and
> it complains about that (i.e.: tcpdump shows bogus packets).
>
> The reason is that a tunneled
Before this patch, a sniffer attached to a VRF used as the receiving
interface of L3 tunneled packets detects them as malformed packets and
it complains about that (i.e.: tcpdump shows bogus packets).
The reason is that a tunneled L3 packet does not carry any L2
information and when the VRF is
Before this patch, a sniffer attached to a VRF used as the receiving
interface of L3 tunneled packets detects them as malformed packets and
it complains about that (i.e.: tcpdump shows bogus packets).
The reason is that a tunneled L3 packet does not carry any L2
information and when the VRF is
userspace to delete all the IPs on the interface. But qeth is expected
to also tolerate a configuration where that is not the case, by skipping
the IP registration when in sniffer mode.
Since commit 5f78e29ceebf ("qeth: optimize IP handling in rx_mode callback")
reworked the IP registration lo
userspace to delete all the IPs on the interface. But qeth is expected
to also tolerate a configuration where that is not the case, by skipping
the IP registration when in sniffer mode.
Since commit 5f78e29ceebf ("qeth: optimize IP handling in rx_mode callback")
reworked the IP registration lo
userspace to delete all the IPs on the interface. But qeth is expected
to also tolerate a configuration where that is not the case, by skipping
the IP registration when in sniffer mode.
Since commit 5f78e29ceebf ("qeth: optimize IP handling in rx_mode callback")
reworked the IP registration lo
tolerate a configuration where that is not the case, by skipping
the IP registration when in sniffer mode.
Since commit 5f78e29ceebf ("qeth: optimize IP handling in rx_mode callback")
reworked the IP registration logic in the L3 subdriver, this no longer
works. When the qeth device is
tolerate a configuration where that is not the case, by skipping
the IP registration when in sniffer mode.
Since commit 5f78e29ceebf ("qeth: optimize IP handling in rx_mode callback")
reworked the IP registration logic in the L3 subdriver, this no longer
works. When the qeth device is
tolerate a configuration where that is not the case, by skipping
the IP registration when in sniffer mode.
Since commit 5f78e29ceebf ("qeth: optimize IP handling in rx_mode callback")
reworked the IP registration logic in the L3 subdriver, this no longer
works. When the qeth device is
tolerate a configuration where that is not the case, by skipping
the IP registration when in sniffer mode.
Since commit 5f78e29ceebf ("qeth: optimize IP handling in rx_mode callback")
reworked the IP registration logic in the L3 subdriver, this no longer
works. When the qeth device is
On Wed, Mar 11, 2015 at 11:20:59AM +, Stathis Voukelatos wrote:
> Our feeling is that we will have to test and verify that a move to gPTP
> will fit with the use cases that we have to support and that will
> require a fair amount of effort and rewrite of application software.
> If the driver is
Hi Richard,
On 06/03/15 15:22, Richard Cochran wrote:
I don't really know what the problem here is. Yes, there is some
networking configuration that you need to do when administering a
network using PTP protocols. But these protocols (1588 aka PTP, and
802.1AS aka gPTP) do offer means for deal
BTW I am getting doubles of your messages, both addressed to the
mailings lists, but only one also addressed to me. You should just
send one copy, with everyone on CC.
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@
On Fri, Mar 06, 2015 at 10:50:08AM +, Stathis Voukelatos wrote:
> Although the PTP way appears to be the best from an architectural point
> of view, we have some questions as whether it is suitable for the audio
> use cases that this module is mainly intended for.
> To use the PTP terminology i
Hi Richard,
On 27/02/15 18:14, Richard Cochran wrote:
>> The H/W does have the capability to do that. However, in order to
>> implement it there will be some architectural changes needed
>> in the kernel. This module cannot really pretend to be a PHY.
>> In the real world it sits between the MAC
On Fri, Feb 27, 2015 at 05:09:24PM +, Stathis Voukelatos wrote:
> To summarize (and confirm my understanding) your suggestion is for the
> sniffer to be configured to match PTP packets and (similarly to the
> dp83640) return the Message Type and Sequence Id fields that will allow
>
code in the world. Please feel free to ask if you have any questions.
To summarize (and confirm my understanding) your suggestion is for the
sniffer to be configured to match PTP packets and (similarly to the
dp83640) return the Message Type and Sequence Id fields that will allow
them to be
On Wed, Feb 25, 2015 at 05:12:08PM +, Stathis Voukelatos wrote:
> Regarding this last point, the actual counter that generates the
> timestamps is not part of the sniffer H/W module. Timestamps are
> provided to the sniffer externally in H/W by a different module.
> Apart of that
d use case is synchronization for AVB
applications using gPTP.
Also, forgot to say, expose your clock as a PTP Hardware Clock (PHC).
Regarding this last point, the actual counter that generates the
timestamps is not part of the sniffer H/W module. Timestamps are
provided to the sniffer exter
On Wed, Feb 25, 2015 at 04:19:45PM +0100, Richard Cochran wrote:
> Let me suggest another approach that stays in line with the existing
> frame work. Based on the device's limitations and your own example,
> it seems clear that the intended use case is synchronization for AVB
> applications using
On Tue, Feb 24, 2015 at 04:48:08PM +, Stathis Voukelatos wrote:
> This patch adds support for the Ethernet Packet Sniffer H/W module
> developed by Linn Products Ltd and found in the IMG Pistachio SoC.
> The module allows Ethernet packets to be parsed, matched against
> a user-def
On Wed, Feb 25, 2015 at 10:53:11AM +, Stathis Voukelatos wrote:
> On 25/02/15 09:50, Richard Cochran wrote:
> >
> >The Linux kernel already fully supports this kind of application via
> >the SIOCSHWTSTAMP, SO_TIMESTAMPING, and PHC mechanisms. We certainly
> >don't need another another interfac
Hi Richard,
On 25/02/15 09:50, Richard Cochran wrote:
The Linux kernel already fully supports this kind of application via
the SIOCSHWTSTAMP, SO_TIMESTAMPING, and PHC mechanisms. We certainly
don't need another another interface just for someone's warped
hardware design.
I suggest that you fi
On Mon, Feb 23, 2015 at 09:37:24AM +, Stathis Voukelatos wrote:
> Hi Richard,
>
> On 18/02/15 21:08, Richard Cochran wrote:
> >On Tue, Feb 17, 2015 at 02:03:30PM +, Stathis Voukelatos wrote:
> >>The command string for packet matching is stored in module RAM
> >>and consists of a sequence o
+1,39 @@
+* Linn Products Ethernet Packet Sniffer
+The module allows Ethernet packets to be parsed, matched against
+a user-defined pattern and timestamped. It sits between a 100M
+Ethernet MAC and PHY and is completely passive with respect to
+Ethernet frames.
+Matched packet bytes and timestamp
The framework registers each backend sniffer channel as a netdev,
which can be accessed from user space through a raw packet socket.
Packets received from user space are treated as a command string
configuration. Each match event from the backend driver will
generate a packet with the matching
Driver for the Ethernet Mii packet sniffer H/W module found in
the IMG Pistachio SoC.
Signed-off-by: Stathis Voukelatos
---
drivers/net/ethernet/linn/Kconfig | 11 +
drivers/net/ethernet/linn/Makefile | 1 +
.../linn/pkt-sniffer/backends/ether/Makefile
This patch adds support for the Ethernet Packet Sniffer H/W module
developed by Linn Products Ltd and found in the IMG Pistachio SoC.
The module allows Ethernet packets to be parsed, matched against
a user-defined pattern and timestamped. It sits between a 100M
Ethernet MAC and PHY and is
On 23/02/15 21:38, David Miller wrote:
From: Stathis Voukelatos
Date: Mon, 23 Feb 2015 14:26:22 +
Driver for the Ethernet Mii packet sniffer H/W module found in
the IMG Pistachio SoC.
Signed-off-by: Stathis Voukelatos
You really have to explain what this thing does, how it is used
On 23/02/15 21:37, David Miller wrote:
From: Stathis Voukelatos
Date: Mon, 23 Feb 2015 14:26:21 +
+ spin_lock_irqsave(&priv->lock, flags);
+ /* Stop the hardware */
+ sch->stop(sch);
+ /* Set the new command pattern */
+ ret = sch->set_pattern(sch, skb->data
From: Stathis Voukelatos
Date: Mon, 23 Feb 2015 14:26:22 +
> Driver for the Ethernet Mii packet sniffer H/W module found in
> the IMG Pistachio SoC.
>
> Signed-off-by: Stathis Voukelatos
You really have to explain what this thing does, how it is used,
what APIs are ma
From: Stathis Voukelatos
Date: Mon, 23 Feb 2015 14:26:21 +
> + spin_lock_irqsave(&priv->lock, flags);
> + /* Stop the hardware */
> + sch->stop(sch);
> + /* Set the new command pattern */
> + ret = sch->set_pattern(sch, skb->data, skb->len / 2);
> + /* Restart the hard
The framework registers each backend sniffer channel as a netdev,
which can be accessed from user space through a raw packet socket.
Packets received from user space are treated as a command string
configuration. Each match event from the backend driver will
generate a packet with the matching
Driver for the Ethernet Mii packet sniffer H/W module found in
the IMG Pistachio SoC.
Signed-off-by: Stathis Voukelatos
---
drivers/net/ethernet/linn/Kconfig | 11 +
drivers/net/ethernet/linn/Makefile | 1 +
.../linn/pkt-sniffer/backends/ether/Makefile
This patch adds support the Ethernet Packet Sniffer H/W module
developed by Linn Products Ltd and found in the IMG Pistachio SoC.
The module allows Ethernet packets to be parsed, matched against
a user-defined pattern and timestamped. It sits between a 100M
Ethernet MAC and PHY and is completely
+1,39 @@
+* Linn Products Ethernet Packet Sniffer
+The module allows Ethernet packets to be parsed, matched against
+a user-defined pattern and timestamped. It sits between a 100M
+Ethernet MAC and PHY and is completely passive with respect to
+Ethernet frames.
+Matched packet bytes and timestamp
Hi Richard,
On 18/02/15 21:08, Richard Cochran wrote:
On Tue, Feb 17, 2015 at 02:03:30PM +, Stathis Voukelatos wrote:
The command string for packet matching is stored in module RAM
and consists of a sequence of 16-bit entries. Each entry includes
an 8-bit command code and and 8-bit data val
On Tue, Feb 17, 2015 at 02:03:30PM +, Stathis Voukelatos wrote:
> The command string for packet matching is stored in module RAM
> and consists of a sequence of 16-bit entries. Each entry includes
> an 8-bit command code and and 8-bit data value. Valid command
> codes are:
> 0 - Don't care
> 1
Hi Daniel,
On 18/02/15 15:42, Daniel Borkmann wrote:
This whole framework really looks like only tailored to your specific
driver, I have no idea who else should reuse that?! So, I don't think
putting this under drivers/net/pkt-sniffer/ is a good idea.
Yes, it is not necessarilly exp
On 02/17/2015 03:03 PM, Stathis Voukelatos wrote:
The framework registers each backend sniffer channel as a netdev,
which can be accessed from user space through a raw packet socket.
Packets received from user space are treated as a command string
configuration. Each match event from the backend
Hi Mark,
On 18/02/15 12:11, Mark Rutland wrote:
Counters can often have a divider applied to their input clock and
therefore run at a scaled down frequency. This is not the case in the
first SoC where the sniffer is used, so for simplicity I can modify as
you suggest and remove that field
On Wed, Feb 18, 2015 at 09:40:22AM +, Stathis Voukelatos wrote:
>
>
> On 17/02/15 17:30, Mark Rutland wrote:
>
> >> It is the frequency of the timestamp values supplied to the sniffer
> >> module. It is used by the driver to convert to nanoseconds.
> >&
On 17/02/15 17:30, Mark Rutland wrote:
It is the frequency of the timestamp values supplied to the sniffer
module. It is used by the driver to convert to nanoseconds.
I was trying to be somewhat generic here and not assume that it
is necessarily the same as the 'tstamp' clock below
at it
> > should be programmed to in order to be used?
> >
> > The former can be queried from the common clock framework, and if you
> > intended the latter the wording shuold be a little more explicit about
> > that being the case.
> >
>
> It is the f
intended the latter the wording shuold be a little more explicit about
that being the case.
It is the frequency of the timestamp values supplied to the sniffer
module. It is used by the driver to convert to nanoseconds.
I was trying to be somewhat generic here and not assume that it
is necessarily the
y
> >> +generated Gray-encoded counter.
> >
> > Does this counter unit need to be enabled (or have any input clocks
> > enabled)?
> >
>
> Yes it does, that is the purpose of the 'tstamp' entry in the
> 'clock-names' property below.
)?
Yes it does, that is the purpose of the 'tstamp' entry in the
'clock-names' property below.
+
+Required properties:
+- compatible : must be "linn,eth-sniffer"
Is there not a more precise name for this IP block?
It is generally called 'ethernet packet snif
le mode 100644
> index 000..74bac5e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt
> @@ -0,0 +1,42 @@
> +* Linn Products Ethernet Packet Sniffer
> +The module allows Ethernet packets to be parsed, matched against
> +a user-defined
Hello.
On 02/17/2015 05:03 PM, Stathis Voukelatos wrote:
Signed-off-by: Stathis Voukelatos
[...]
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d443279..891c224 100644
--- a/Documentation/devicetree/bindings
The framework registers each backend sniffer channel as a netdev,
which can be accessed from user space through a raw packet socket.
Packets received from user space are treated as a command string
configuration. Each match event from the backend driver will
generate a packet with the matching
Driver for the Ethernet Mii packet sniffer H/W module found in
the IMG Pistachio SoC.
Signed-off-by: Stathis Voukelatos
---
drivers/net/pkt-sniffer/Kconfig | 11 +
drivers/net/pkt-sniffer/Makefile | 4 +
drivers/net/pkt-sniffer/backends/ether/channel.c
+1,42 @@
+* Linn Products Ethernet Packet Sniffer
+The module allows Ethernet packets to be parsed, matched against
+a user-defined pattern and timestamped. It sits between a 100M
+Ethernet MAC and PHY and is completely passive with respect to
+Ethernet frames.
+Matched packet bytes and timestamp
This patch adds support the Ethernet Packet Sniffer H/W module
developed by Linn Products Ltd and found in the IMG Pistachio SoC.
The module allows Ethernet packets to be parsed, matched against
a user-defined pattern and timestamped. It sits between a 100M
Ethernet MAC and PHY and is completely
This is experienced with l3.large, t2.micro with Ubuntu 14. I believe
we don't have any special settings over system defaults.
We send a large datagram from remote host, e.g. with such trivial app in python:
import socket
UDP_IP = "123.123.123.123" # remote host IP
UDP_PORT = 3
MESSAGE = """
.
oming data packets. Timestamp values are provided by an
external implementation-dependent clock or timer that is of suitable
quality for the application.
Example: multiple audio receivers synchronizing their clocks to a
single transmitter, for synchronized playback.
The TX and RX blocks of the snif
dn't parse that from your
commit message.
- Would the control interface for the sniffer in that case need to be
through private socket ioctls (ie SIOCDEVPRIVATE + x ioctl ids)?
Nope, please have a look at Documentation/networking/packet_mmap.txt.
--
To unsubscribe from this list: send the lin
ances.
One for sniffing Ethernet TX packets and one for RX.
- Would the control interface for the sniffer in that case need to be
through private socket ioctls (ie SIOCDEVPRIVATE + x ioctl ids)?
- For each ethernet packet that matches the command string the sniffer
returns some data bytes and op
-sniffer.txt
> > new file mode 100644
> > index 000..6b6e105
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt
> > @@ -0,0 +1,27 @@
> > +* Linn Products Ethernet Packet Sniffer
> > +
> > +Required pr
Hi Florian,
On 26/01/15 22:30, Florian Fainelli wrote:
On 23/01/15 02:07, Stathis Voukelatos wrote:
This patch adds support the Ethernet Packet Sniffer H/W module
developed by Linn Products Ltd and found in the IMG Pistachio SoC.
The module allows Ethernet packets to be parsed, matched against
On 26/01/15 19:39, Joe Perches wrote:
This header file is the public API for the driver.
Should it not live under the 'include' directory?
Several other drivers seem to follow that convention.
It depends on how public is public.
If it's _really_ public, it should be in uapi.
If it's kinda publi
On 23/01/15 02:07, Stathis Voukelatos wrote:
> This patch adds support the Ethernet Packet Sniffer H/W module
> developed by Linn Products Ltd and found in the IMG Pistachio SoC.
> The module allows Ethernet packets to be parsed, matched against
> a user-defined pattern and timestam
On Mon, 2015-01-26 at 11:11 +, Stathis Voukelatos wrote:
> On 24/01/15 21:37, Joe Perches wrote:
> > On Fri, 2015-01-23 at 10:07 +, Stathis Voukelatos wrote:
> >> This patch adds support the Ethernet Packet Sniffer H/W module
> >> developed by Linn Produc
On 23/01/15 10:21, Arnd Bergmann wrote:
On Friday 23 January 2015 10:07:01 Stathis Voukelatos wrote:
+- interrupts : sniffer interrupt specifier
+- clocks : specify the system clock for the peripheral
+- clock-names : must contain the "sys" entry
+- fifo-block-words : number of wo
On 24/01/15 21:37, Joe Perches wrote:
On Fri, 2015-01-23 at 10:07 +, Stathis Voukelatos wrote:
This patch adds support the Ethernet Packet Sniffer H/W module
developed by Linn Products Ltd and found in the IMG Pistachio SoC.
The module allows Ethernet packets to be parsed, matched against
On 23/01/15 18:12, James Hogan wrote:
diff --git a/drivers/net/pkt-sniffer/Kconfig
b/drivers/net/pkt-sniffer/Kconfig
new file mode 100644
index 000..26b4f98
--- /dev/null
+++ b/drivers/net/pkt-sniffer/Kconfig
@@ -0,0 +1,23 @@
+menuconfig PKT_SNIFFER
+tristate "Linn packet sn
/linn-ether-packet-sniffer.txt
@@ -0,0 +1,27 @@
+* Linn Products Ethernet Packet Sniffer
+
+Required properties:
+- compatible : must be "linn,eth-sniffer"
+- reg : physical addresses and sizes of registers. Must contain 3 entries:
+ first entry: registers memory space
+
Hi Stathis,
On 01/26/2015 10:49 AM, Stathis Voukelatos wrote:
On 23/01/15 11:20, Daniel Borkmann wrote:
On 01/23/2015 11:07 AM, Stathis Voukelatos wrote:
This patch adds support the Ethernet Packet Sniffer H/W module
developed by Linn Products Ltd and found in the IMG Pistachio SoC.
The
On 23/01/15 11:20, Daniel Borkmann wrote:
On 01/23/2015 11:07 AM, Stathis Voukelatos wrote:
This patch adds support the Ethernet Packet Sniffer H/W module
developed by Linn Products Ltd and found in the IMG Pistachio SoC.
The module allows Ethernet packets to be parsed, matched against
a user
On Fri, 2015-01-23 at 10:07 +, Stathis Voukelatos wrote:
> This patch adds support the Ethernet Packet Sniffer H/W module
> developed by Linn Products Ltd and found in the IMG Pistachio SoC.
> The module allows Ethernet packets to be parsed, matched against
> a user-defined
t| 1 +
> MAINTAINERS| 7 +
> drivers/net/Kconfig| 2 +
> drivers/net/Makefile | 1 +
> drivers/net/pkt-sniffer/Kconfig| 23 ++
> dri
On 01/23/2015 11:07 AM, Stathis Voukelatos wrote:
This patch adds support the Ethernet Packet Sniffer H/W module
developed by Linn Products Ltd and found in the IMG Pistachio SoC.
The module allows Ethernet packets to be parsed, matched against
a user-defined pattern and timestamped. It sits
On Fri, Jan 23, 2015 at 10:07:01AM +, Stathis Voukelatos wrote:
> This patch adds support the Ethernet Packet Sniffer H/W module
> developed by Linn Products Ltd and found in the IMG Pistachio SoC.
> The module allows Ethernet packets to be parsed, matched against
> a user-defined
On Friday 23 January 2015 10:07:01 Stathis Voukelatos wrote:
> +- interrupts : sniffer interrupt specifier
> +- clocks : specify the system clock for the peripheral
> +- clock-names : must contain the "sys" entry
> +- fifo-block-words : number of words in one data FIF
This patch adds support the Ethernet Packet Sniffer H/W module
developed by Linn Products Ltd and found in the IMG Pistachio SoC.
The module allows Ethernet packets to be parsed, matched against
a user-defined pattern and timestamped. It sits between a 100M
Ethernet MAC and PHY and is completely
Dear all,
Do you know that why tcpdump will loss some packet passing in the subnet?
Sorry, I mean that if there are 99Mbps packet in the ethernet,
but tcpdump just find out 80Mbps packet. Why?
What thing affect packet loss?
Thanks
Tom
-
To unsubscribe from this list: send the line "unsubscrib
well..
Dave.
On Thu, 29 Mar 2001, Dave Airlie wrote:
>
> when boot Linux 2.2.19 with a Digianswer Bluetooth Sniffer plugged into
> the USB I get the following oops ... I know the device isn't supported but
> I'd like to be able to leave it plugged in without oopsen between
&g
when boot Linux 2.2.19 with a Digianswer Bluetooth Sniffer plugged into
the USB I get the following oops ... I know the device isn't supported but
I'd like to be able to leave it plugged in without oopsen between
Linux/Windows..
Regards,
Dave.
ksymoops 0.7c on i686 2.2.19
82 matches
Mail list logo
