When does Linux drop UDP packets?

When does Linux drop UDP packets?

[Philipp Reh]

Dear list,

I have the following setting in which a client that resides on the same
physical network as a server wants to receive any UDP packet that
arrives on any of its interfaces sent by that server.

The code sets the broadcast flag, calls bind to INADDR_ANY and
uses recvfrom from there on.

Let's say the server resides in the subnet 192.168.6.255 and the
client in 192.168.3.255. The server uses its real IP as the packet's
sender ip (192.168.6.5).

Now the first problem I've encountered is the following:
If the client removes its default route and doesn't have any route
pointing into the subnet the server is in, the packets get discarded
(still tcpdump sees them).

The second problem is that if the server uses the broadcast address as
its sender address (255.255.255.255), the packets get always discarded
(again, tcpdump sees them).

Now if the server fakes its sender address to be in the client's subnet,
every packet arrives again.

So my real question is:
When does Linux discard packets and how can I prevent it from doing
that?

As I'm not yet subscribed to the list, please CC me directly.

Cheers,
Philipp

Re: When does Linux drop UDP packets?

[Steven Rostedt]

On Thu, Jun 04, 2009 at 04:53:47PM +0200, Philipp Reh wrote:
> Dear list,
> 
> I have the following setting in which a client that resides on the same
> physical network as a server wants to receive any UDP packet that
> arrives on any of its interfaces sent by that server.
> 
> The code sets the broadcast flag, calls bind to INADDR_ANY and
> uses recvfrom from there on.
> 
> Let's say the server resides in the subnet 192.168.6.255 and the
> client in 192.168.3.255. The server uses its real IP as the packet's
> sender ip (192.168.6.5).

You don't say what the client IP is. Let's assume that it is 192.168.3.1
for simplicity.

> 
> Now the first problem I've encountered is the following:
> If the client removes its default route and doesn't have any route
> pointing into the subnet the server is in, the packets get discarded
> (still tcpdump sees them).
> 

Are you saying that the server sent to 192.168.3.1 with source ip of
192.168.6.5 and the client did not see it?

> The second problem is that if the server uses the broadcast address as
> its sender address (255.255.255.255), the packets get always discarded
> (again, tcpdump sees them).

Again, what was the destination IP address?

> Now if the server fakes its sender address to be in the client's subnet,
> every packet arrives again.

So the only thing you change is the sender address?

What tools are you using to read the packets, and how do you know it is
dropped?

-- Steve

> 
> So my real question is:
> When does Linux discard packets and how can I prevent it from doing
> that?

Re: When does Linux drop UDP packets?

[Steven Rostedt]

Oh, btw, you don't need to strip LKML from replys (or any Cc), unless it 
is off topic.  LKML is a public forum, and as long as things are on topic, 
it is nice to show others the solutions that are found.

> 
> On Thu, 4 Jun 2009, Philipp Reh wrote:
> 
> > I'm not really sure it is dropped but tcpdump sees the packet and
> > recvfrom doesn't see it, so I think that the kernel might drop it
> > somewhere when processing the IP stack logic.
> 
> Looking at the udp stack, selinux plays a role, and looks like it will 
> drop a packet if it is not in the routing table.
> 
> Try:
> 
> # setenforce 0
> 
> and see if you start seeing packets.

BTW, I used ftrace to look into this:

Enable:

	CONFIG_FTRACE
	CONFIG_FUNCTION_TRACER
	CONFIG_FUNCITON_GRAPH_TRACER
	CONFIG_DYNAMIC_FTRACE

Compile and boot:

# mount -t debugfs nodev /sys/kernel/debug
# cd /sys/kernel/debug
# echo udp_rcv > set_graph_function
# echo function_graph > current_tracer
# cat trace

and this is what I see:

# tracer: function_graph
#
# CPU  DURATION                  FUNCTION CALLS
# |     |   |                     |   |   |   |
 1)               |  udp_rcv() {
 1)               |    __udp4_lib_rcv() {
 1)               |      __udp4_lib_lookup() {
 1)   0.584 us    |        T.757();
 1)   2.905 us    |      }
 1)               |      udp_queue_rcv_skb() {
 1)   0.584 us    |        nf_reset();
 1)   0.996 us    |        _spin_lock();
 1)               |        __udp_queue_rcv_skb() {
 1)               |          sock_queue_rcv_skb() {
 1)               |            sk_filter() {
 1)               |              security_sock_rcv_skb() {
 1)               |                selinux_socket_sock_rcv_skb() {
 1)               |                  selinux_parse_skb() {
 1)   0.584 us    |                    skb_header_pointer();
 1)   0.569 us    |                    skb_header_pointer();
 1)   3.074 us    |                  }
 1)               |                  selinux_netlbl_sock_rcv_skb() {
 1)   0.561 us    |                    netlbl_enabled();
 1)   1.748 us    |                  }
 1)   6.792 us    |                }
 1)   8.095 us    |              }
 1)               |              local_bh_disable() {
 1)   0.599 us    |                __local_bh_disable();
 1)   1.790 us    |              }
 1)               |              local_bh_enable() {
 1)               |                _local_bh_enable_ip() {
 1)   0.566 us    |                  T.445();
 1)   1.906 us    |                }
 1)   3.149 us    |              }
 1) + 15.722 us   |            }
 1)               |            skb_queue_tail() {
 1)   1.059 us    |              _spin_lock_irqsave();
 1)               |              _spin_unlock_irqrestore() {
 1)   0.596 us    |                T.263();
 1)   1.913 us    |              }
 1)   4.718 us    |            }
 1)   0.565 us    |            sock_flag();
 1)               |            sock_def_readable() {
 1)   0.981 us    |              _read_lock();
 1)               |              __wake_up_sync_key() {
 1)   0.887 us    |                _spin_lock_irqsave();
 1)               |                __wake_up_common() {
 1)               |                  pollwake() {
 1)               |                    default_wake_function() {
 1)               |                      try_to_wake_up() {
 1)               |                        task_rq_lock() {
 1)   0.951 us    |                          _spin_lock();
 1)   2.030 us    |                        }
 1)   0.768 us    |                        update_rq_clock();
 1)               |                        select_task_rq_fair() {
 1)   0.501 us    |                          effective_load();
 1)   0.494 us    |                          effective_load();

-- Steve

Re: When does Linux drop UDP packets?

[Steven Rostedt]

On Thu, 4 Jun 2009, Steven Rostedt wrote:

> 
> Oh, btw, you don't need to strip LKML from replys (or any Cc), unless it 
> is off topic.  LKML is a public forum, and as long as things are on topic, 
> it is nice to show others the solutions that are found.
> 
> > 
> > On Thu, 4 Jun 2009, Philipp Reh wrote:
> > 
> > > I'm not really sure it is dropped but tcpdump sees the packet and
> > > recvfrom doesn't see it, so I think that the kernel might drop it
> > > somewhere when processing the IP stack logic.
> > 
> > Looking at the udp stack, selinux plays a role, and looks like it will 
> > drop a packet if it is not in the routing table.
> > 
> > Try:
> > 
> > # setenforce 0
> > 
> > and see if you start seeing packets.
> 
> BTW, I used ftrace to look into this:
> 
> Enable:
> 
> 	CONFIG_FTRACE
> 	CONFIG_FUNCTION_TRACER
> 	CONFIG_FUNCITON_GRAPH_TRACER
> 	CONFIG_DYNAMIC_FTRACE
> 
> Compile and boot:
> 
> # mount -t debugfs nodev /sys/kernel/debug
> # cd /sys/kernel/debug
> # echo udp_rcv > set_graph_function
> # echo function_graph > current_tracer
> # cat trace
> 

Could you do the above and send me (off list) the output of the trace?

-- Steve

Re: When does Linux drop UDP packets?

[Jaswinder Singh Rajput]

On Thu, 2009-06-04 at 12:34 -0400, Steven Rostedt wrote:

> BTW, I used ftrace to look into this:
> 
> Enable:
> 
> 	CONFIG_FTRACE
> 	CONFIG_FUNCTION_TRACER
> 	CONFIG_FUNCITON_GRAPH_TRACER
> 	CONFIG_DYNAMIC_FTRACE
> 
> Compile and boot:
> 
> # mount -t debugfs nodev /sys/kernel/debug

Very glad to see you following standards ;-)

> # cd /sys/kernel/debug

hmm you mean # cd /sys/kernel/debug/tracing

> # echo udp_rcv > set_graph_function
> # echo function_graph > current_tracer
> # cat trace
> 

Anyway you can also see UDP packet drops when you increase network and
CPU load.

--
JSR

Re: When does Linux drop UDP packets?

[Steven Rostedt]

On Thu, 4 Jun 2009, Jaswinder Singh Rajput wrote:

> On Thu, 2009-06-04 at 12:34 -0400, Steven Rostedt wrote:
> 
> > BTW, I used ftrace to look into this:
> > 
> > Enable:
> > 
> > 	CONFIG_FTRACE
> > 	CONFIG_FUNCTION_TRACER
> > 	CONFIG_FUNCITON_GRAPH_TRACER
> > 	CONFIG_DYNAMIC_FTRACE
> > 
> > Compile and boot:
> > 
> > # mount -t debugfs nodev /sys/kernel/debug
> 
> Very glad to see you following standards ;-)

I only did that to not hear the debugfs nazis squack.

> 
> > # cd /sys/kernel/debug
> 
> hmm you mean # cd /sys/kernel/debug/tracing

A mistake I would not have made if I just did /debug

> 
> > # echo udp_rcv > set_graph_function
> > # echo function_graph > current_tracer
> > # cat trace
> > 
> 
> Anyway you can also see UDP packet drops when you increase network and
> CPU load.

That's not the issue here.

-- Steve

Re: When does Linux drop UDP packets?

[david]

On Thu, 4 Jun 2009, Steven Rostedt wrote:

> On Thu, Jun 04, 2009 at 04:53:47PM +0200, Philipp Reh wrote:
>> Dear list,
>>
>> I have the following setting in which a client that resides on the same
>> physical network as a server wants to receive any UDP packet that
>> arrives on any of its interfaces sent by that server.
>>
>> The code sets the broadcast flag, calls bind to INADDR_ANY and
>> uses recvfrom from there on.
>>
>> Let's say the server resides in the subnet 192.168.6.255 and the
>> client in 192.168.3.255. The server uses its real IP as the packet's
>> sender ip (192.168.6.5).
>
> You don't say what the client IP is. Let's assume that it is 192.168.3.1
> for simplicity.
>
>>
>> Now the first problem I've encountered is the following:
>> If the client removes its default route and doesn't have any route
>> pointing into the subnet the server is in, the packets get discarded
>> (still tcpdump sees them).
>>
>
> Are you saying that the server sent to 192.168.3.1 with source ip of
> 192.168.6.5 and the client did not see it?
>
>> The second problem is that if the server uses the broadcast address as
>> its sender address (255.255.255.255), the packets get always discarded
>> (again, tcpdump sees them).
>
> Again, what was the destination IP address?
>
>> Now if the server fakes its sender address to be in the client's subnet,
>> every packet arrives again.
>
> So the only thing you change is the sender address?
>
> What tools are you using to read the packets, and how do you know it is
> dropped?


I have seen the same thing. I have syslog servers on one subnet without a 
default route. If I configure a server on another subnet to send it logs I 
can see the packets with tcpdump, but syslogd will not record them.

If I configure a route on the recieving box that makes it think that it 
can get to the sender (note that the route can be completely bogus, 
pointing at a wrong or non-existing gateway) the kernel is happy and the 
packets show up to syslogd

the systems I am running do _not_ have selinux on them.

I have seen this as far back as 2.6.12 so it's not a recent change.

if you need examples with IP addresses

box 1
IP 10.1.1.2

router
IP 10.1.1.1
IP 192.168.1.1

box 2
IP 192.168.1.2

If I configure box 2 to have a route to box1, but do not configure box 1 
to have any route (including not having a default route) that would get it 
to a 192.168.1.x subnet tcpdump on box 1 will show the syslog packets, but 
syslog (and any non-pcap tool) will not see the packets)

if I configure a route on box 1 to have a default route of 10.1.1.3 (which 
does not exist, so cannot possibly route packets anywhere) then everything 
works.

>> So my real question is:
>> When does Linux discard packets and how can I prevent it from doing
>> that?

for this problem, set a default route that points at a non-existing 
gateway and I believe that your problem will go away.

David Lang

Re: When does Linux drop UDP packets?

[Eric Dumazet]

david@lang.hm a écrit :
> On Thu, 4 Jun 2009, Steven Rostedt wrote:
> 
>> On Thu, Jun 04, 2009 at 04:53:47PM +0200, Philipp Reh wrote:
>>> Dear list,
>>>
>>> I have the following setting in which a client that resides on the same
>>> physical network as a server wants to receive any UDP packet that
>>> arrives on any of its interfaces sent by that server.
>>>
>>> The code sets the broadcast flag, calls bind to INADDR_ANY and
>>> uses recvfrom from there on.
>>>
>>> Let's say the server resides in the subnet 192.168.6.255 and the
>>> client in 192.168.3.255. The server uses its real IP as the packet's
>>> sender ip (192.168.6.5).
>>
>> You don't say what the client IP is. Let's assume that it is 192.168.3.1
>> for simplicity.
>>
>>>
>>> Now the first problem I've encountered is the following:
>>> If the client removes its default route and doesn't have any route
>>> pointing into the subnet the server is in, the packets get discarded
>>> (still tcpdump sees them).
>>>
>>
>> Are you saying that the server sent to 192.168.3.1 with source ip of
>> 192.168.6.5 and the client did not see it?
>>
>>> The second problem is that if the server uses the broadcast address as
>>> its sender address (255.255.255.255), the packets get always discarded
>>> (again, tcpdump sees them).
>>
>> Again, what was the destination IP address?
>>
>>> Now if the server fakes its sender address to be in the client's subnet,
>>> every packet arrives again.
>>
>> So the only thing you change is the sender address?
>>
>> What tools are you using to read the packets, and how do you know it is
>> dropped?
> 
> 
> I have seen the same thing. I have syslog servers on one subnet without
> a default route. If I configure a server on another subnet to send it
> logs I can see the packets with tcpdump, but syslogd will not record them.
> 
> If I configure a route on the recieving box that makes it think that it
> can get to the sender (note that the route can be completely bogus,
> pointing at a wrong or non-existing gateway) the kernel is happy and the
> packets show up to syslogd
> 
> the systems I am running do _not_ have selinux on them.
> 
> I have seen this as far back as 2.6.12 so it's not a recent change.
> 
> if you need examples with IP addresses
> 
> box 1
> IP 10.1.1.2
> 
> router
> IP 10.1.1.1
> IP 192.168.1.1
> 
> box 2
> IP 192.168.1.2
> 
> If I configure box 2 to have a route to box1, but do not configure box 1
> to have any route (including not having a default route) that would get
> it to a 192.168.1.x subnet tcpdump on box 1 will show the syslog
> packets, but syslog (and any non-pcap tool) will not see the packets)
> 
> if I configure a route on box 1 to have a default route of 10.1.1.3
> (which does not exist, so cannot possibly route packets anywhere) then
> everything works.

I guess you need to change rp_filter settings

Documentation/networking/ip-sysctl.txt

rp_filter - INTEGER

        0 - No source validation.
        1 - Strict mode as defined in RFC3704 Strict Reverse Path
            Each incoming packet is tested against the FIB and if the interface
            is not the best reverse path the packet check will fail.
            By default failed packets are discarded.
        2 - Loose mode as defined in RFC3704 Loose Reverse Path
            Each incoming packet's source address is also tested against the FIB
            and if the source address is not reachable via any interface
            the packet check will fail.

        Current recommended practice in RFC3704 is to enable strict mode
        to prevent IP spoofing from DDos attacks. If using asymmetric routing
        or other complicated routing, then loose mode is recommended.

        conf/all/rp_filter must also be set to non-zero to do source validation
        on the interface

        Default value is 0. Note that some distributions enable it
        in startup scripts.


> 
>>> So my real question is:
>>> When does Linux discard packets and how can I prevent it from doing
>>> that?
> 
> for this problem, set a default route that points at a non-existing
> gateway and I believe that your problem will go away.

Re: When does Linux drop UDP packets?

[david]

On Thu, 4 Jun 2009, Eric Dumazet wrote:

> david@lang.hm a ?crit :
>> On Thu, 4 Jun 2009, Steven Rostedt wrote:
>>
>>> On Thu, Jun 04, 2009 at 04:53:47PM +0200, Philipp Reh wrote:
>>>> Dear list,
>>>>
>>>> I have the following setting in which a client that resides on the same
>>>> physical network as a server wants to receive any UDP packet that
>>>> arrives on any of its interfaces sent by that server.
>>>>
>>>> The code sets the broadcast flag, calls bind to INADDR_ANY and
>>>> uses recvfrom from there on.
>>>>
>>>> Let's say the server resides in the subnet 192.168.6.255 and the
>>>> client in 192.168.3.255. The server uses its real IP as the packet's
>>>> sender ip (192.168.6.5).
>>>
>>> You don't say what the client IP is. Let's assume that it is 192.168.3.1
>>> for simplicity.
>>>
>>>>
>>>> Now the first problem I've encountered is the following:
>>>> If the client removes its default route and doesn't have any route
>>>> pointing into the subnet the server is in, the packets get discarded
>>>> (still tcpdump sees them).
>>>>
>>>
>>> Are you saying that the server sent to 192.168.3.1 with source ip of
>>> 192.168.6.5 and the client did not see it?
>>>
>>>> The second problem is that if the server uses the broadcast address as
>>>> its sender address (255.255.255.255), the packets get always discarded
>>>> (again, tcpdump sees them).
>>>
>>> Again, what was the destination IP address?
>>>
>>>> Now if the server fakes its sender address to be in the client's subnet,
>>>> every packet arrives again.
>>>
>>> So the only thing you change is the sender address?
>>>
>>> What tools are you using to read the packets, and how do you know it is
>>> dropped?
>>
>>
>> I have seen the same thing. I have syslog servers on one subnet without
>> a default route. If I configure a server on another subnet to send it
>> logs I can see the packets with tcpdump, but syslogd will not record them.
>>
>> If I configure a route on the recieving box that makes it think that it
>> can get to the sender (note that the route can be completely bogus,
>> pointing at a wrong or non-existing gateway) the kernel is happy and the
>> packets show up to syslogd
>>
>> the systems I am running do _not_ have selinux on them.
>>
>> I have seen this as far back as 2.6.12 so it's not a recent change.
>>
>> if you need examples with IP addresses
>>
>> box 1
>> IP 10.1.1.2
>>
>> router
>> IP 10.1.1.1
>> IP 192.168.1.1
>>
>> box 2
>> IP 192.168.1.2
>>
>> If I configure box 2 to have a route to box1, but do not configure box 1
>> to have any route (including not having a default route) that would get
>> it to a 192.168.1.x subnet tcpdump on box 1 will show the syslog
>> packets, but syslog (and any non-pcap tool) will not see the packets)
>>
>> if I configure a route on box 1 to have a default route of 10.1.1.3
>> (which does not exist, so cannot possibly route packets anywhere) then
>> everything works.
>
> I guess you need to change rp_filter settings
>
> Documentation/networking/ip-sysctl.txt
>
> rp_filter - INTEGER
>
>        0 - No source validation.
>        1 - Strict mode as defined in RFC3704 Strict Reverse Path
>            Each incoming packet is tested against the FIB and if the interface
>            is not the best reverse path the packet check will fail.
>            By default failed packets are discarded.
>        2 - Loose mode as defined in RFC3704 Loose Reverse Path
>            Each incoming packet's source address is also tested against the FIB
>            and if the source address is not reachable via any interface
>            the packet check will fail.
>
>        Current recommended practice in RFC3704 is to enable strict mode
>        to prevent IP spoofing from DDos attacks. If using asymmetric routing
>        or other complicated routing, then loose mode is recommended.
>
>        conf/all/rp_filter must also be set to non-zero to do source validation
>        on the interface
>
>        Default value is 0. Note that some distributions enable it
>        in startup scripts.

thanks, On my Debian based systems I have commented this out of the 
sysctl.conf file, but apparently there is some other script that is 
setting it anyway. I'll have to track down what it's doing.

David Lang

>
>>
>>>> So my real question is:
>>>> When does Linux discard packets and how can I prevent it from doing
>>>> that?
>>
>> for this problem, set a default route that points at a non-existing
>> gateway and I believe that your problem will go away.
>
>
>

Re: When does Linux drop UDP packets?

[Nifty niftylinkern Mitch]

On Thu, Jun 04, 2009 at 11:57:41AM -0400, Steven Rostedt wrote:
> On Thu, Jun 04, 2009 at 04:53:47PM +0200, Philipp Reh wrote:
> > Dear list,
> > 
> > I have the following setting in which a client that resides on the same
> > physical network as a server wants to receive any UDP packet that
> > arrives on any of its interfaces sent by that server.
> > 
> > The code sets the broadcast flag, calls bind to INADDR_ANY and
> > uses recvfrom from there on.
> > 
> > Let's say the server resides in the subnet 192.168.6.255 and the
> > client in 192.168.3.255. The server uses its real IP as the packet's
> > sender ip (192.168.6.5).
> 
> You don't say what the client IP is. Let's assume that it is 192.168.3.1
> for simplicity.
> 
> > 
> > Now the first problem I've encountered is the following:
> > If the client removes its default route and doesn't have any route
> > pointing into the subnet the server is in, the packets get discarded
> > (still tcpdump sees them).
> > 
> 
> Are you saying that the server sent to 192.168.3.1 with source ip of
> 192.168.6.5 and the client did not see it?
> 
> > The second problem is that if the server uses the broadcast address as
> > its sender address (255.255.255.255), the packets get always discarded
> > (again, tcpdump sees them).
> 
> Again, what was the destination IP address?
> 
> > Now if the server fakes its sender address to be in the client's subnet,
> > every packet arrives again.
> 
> So the only thing you change is the sender address?
> 
> What tools are you using to read the packets, and how do you know it is
> dropped?
> 
> -- Steve
> 
> > 
> > So my real question is:
> > When does Linux discard packets and how can I prevent it from doing
> > that?


What subnet masks?

If two mutually exclusive TCP/IP subnets are on the same physical network
they will be all but invisible to each other unless there is routing
between them.    With modern switches this is very much.   With modern
smart router/switches interesting things can be done.

The server can have a single MAC configured to send
and receive data on two subnets.

If the server is faking its sender address then other things are happening
(switch, arp, zeroconfig, bogus broadcast address...) so why fake it
set it up to be live on both nets.... make both real.

  eth0:0 192.168.6.5/24 
  eth0:1 192.168.3.5/24

  http://www.faqs.org/docs/Linux-mini/IP-Alias.html

Zeroconfig may also make things work in unexpected ways.
  http://www.zeroconf.org/

# the almost obvious... 
#     10.0.0.0        -   10.255.255.255  (10/8 prefix)
#     172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
#     192.168.0.0     -   192.168.255.255 (192.168/16 prefix)
#     169.254.0.0/16  -   169.254.255.255 (link-local 169.254.0.0/16 prefix)


-- 
	T o m  M i t c h e l l 
	Found me a new hat, now what?

Re: When does Linux drop UDP packets?

[Alexander Clouter]

Philipp Reh <sefi@s-e-f-i.de> wrote:
> 
> I have the following setting in which a client that resides on the same
> physical network as a server wants to receive any UDP packet that
> arrives on any of its interfaces sent by that server.
> 
Read up about multicasting, it will do what you want, does not depend on
the IP address of the destination workstation and will also cross 
subnets if you want it to.

It's dead easy to transmit and receive multicast traffic, broadcasting 
network traffic is so 1980's :)

> As I'm not yet subscribed to the list, please CC me directly.
> 
Have a look at GMANE for following large volumn mailing lists.

Cheers

-- 
Alexander Clouter
.sigmonster says: Familiarity breeds attempt.

Re: When does Linux drop UDP packets?

[david]

On Thu, 4 Jun 2009, Alexander Clouter wrote:

> Philipp Reh <sefi@s-e-f-i.de> wrote:
>>
>> I have the following setting in which a client that resides on the same
>> physical network as a server wants to receive any UDP packet that
>> arrives on any of its interfaces sent by that server.
>>
> Read up about multicasting, it will do what you want, does not depend on
> the IP address of the destination workstation and will also cross
> subnets if you want it to.
>
> It's dead easy to transmit and receive multicast traffic, broadcasting
> network traffic is so 1980's :)

there is only a difference between multicast and broadcast traffic if you 
are spanning subnets.

but the issue here is the rp_filter, and that would also filter out 
multicast packets from sources that you don't have routes to.

David Lang

Re: When does Linux drop UDP packets?

[Alexander Clouter]

Hi,

* david@lang.hm <david@lang.hm> [2009-06-04 16:19:56-0700]:
> 
> On Thu, 4 Jun 2009, Alexander Clouter wrote:
> 
> > Philipp Reh <sefi@s-e-f-i.de> wrote:
> > > 
> > > I have the following setting in which a client that resides on the same
> > > physical network as a server wants to receive any UDP packet that
> > > arrives on any of its interfaces sent by that server.
> > > 
> > Read up about multicasting, it will do what you want, does not depend on
> > the IP address of the destination workstation and will also cross
> > subnets if you want it to.
> > 
> > It's dead easy to transmit and receive multicast traffic, broadcasting
> > network traffic is so 1980's :)
> 
> there is only a difference between multicast and broadcast traffic if you  
> are spanning subnets.
>
Well yes and no.  Broadcast traffic is *always* handled by the kernel as 
only the kernel can tell if it is interested in it or not.  With 
multicast the NIC is configured to only pass particular 
Ethernet multicast packets up to the kernel.

By using broadcast traffic the load (okay, hardly a big problem 
now-a-days) hits *all* the workstations on the subnet, with multicast, 
only those interested in the traffic receive it.

Cheers

-- 
Alexander Clouter
.sigmonster says: You were s'posed to laugh!

Re: When does Linux drop UDP packets?

[david]

On Fri, 5 Jun 2009, Alexander Clouter wrote:

> Hi,
>
> * david@lang.hm <david@lang.hm> [2009-06-04 16:19:56-0700]:
>>
>> On Thu, 4 Jun 2009, Alexander Clouter wrote:
>>
>>> Philipp Reh <sefi@s-e-f-i.de> wrote:
>>>>
>>>> I have the following setting in which a client that resides on the same
>>>> physical network as a server wants to receive any UDP packet that
>>>> arrives on any of its interfaces sent by that server.
>>>>
>>> Read up about multicasting, it will do what you want, does not depend on
>>> the IP address of the destination workstation and will also cross
>>> subnets if you want it to.
>>>
>>> It's dead easy to transmit and receive multicast traffic, broadcasting
>>> network traffic is so 1980's :)
>>
>> there is only a difference between multicast and broadcast traffic if you
>> are spanning subnets.
>>
> Well yes and no.  Broadcast traffic is *always* handled by the kernel as
> only the kernel can tell if it is interested in it or not.  With
> multicast the NIC is configured to only pass particular
> Ethernet multicast packets up to the kernel.
>
> By using broadcast traffic the load (okay, hardly a big problem
> now-a-days) hits *all* the workstations on the subnet, with multicast,
> only those interested in the traffic receive it.

true, but only for some NICs, and even those tend to have a fairly small 
number of slots for the filters. past these limits the OS handles it all 
just like broadcasts.

David Lang

Re: When does Linux drop UDP packets?

[Alexander Clouter]

Hi,

* david@lang.hm <david@lang.hm> [2009-06-05 12:15:27-0700]:
> 
> On Fri, 5 Jun 2009, Alexander Clouter wrote:
> 
> > * david@lang.hm <david@lang.hm> [2009-06-04 16:19:56-0700]:
> > > 
> > > On Thu, 4 Jun 2009, Alexander Clouter wrote:
> > > >
> > > > It's dead easy to transmit and receive multicast traffic, broadcasting
> > > > network traffic is so 1980's :)
> > > 
> > > there is only a difference between multicast and broadcast traffic if you
> > > are spanning subnets.
> > > 
> > Well yes and no.  Broadcast traffic is *always* handled by the kernel as
> > only the kernel can tell if it is interested in it or not.  With
> > multicast the NIC is configured to only pass particular
> > Ethernet multicast packets up to the kernel.
> > 
> > By using broadcast traffic the load (okay, hardly a big problem
> > now-a-days) hits *all* the workstations on the subnet, with multicast,
> > only those interested in the traffic receive it.
> 
> true, but only for some NICs, and even those tend to have a fairly small  
> number of slots for the filters. past these limits the OS handles it all  
> just like broadcasts.
> 
I *think* only the early ones have a naff non-hashing based to filter 
multicast flows, could be wrong though.

Either way, as a packet pusher by day, I dream of the venduh's 
discovering that multicast can be used for device discovery rather than 
expecting everything to be on the same subnet :-/

In this day and age, using broadcast to do a job is just plain lazy and 
braindead.

Cheers

-- 
Alexander Clouter
.sigmonster says: Misuse may cause suffocation.

Re: When does Linux drop UDP packets?

[Herbert Xu]

david@lang.hm wrote:
>
> there is only a difference between multicast and broadcast traffic if you 
> are spanning subnets.

Which is always the case if you invest in some intelligent switches.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: When does Linux drop UDP packets?

[david]

On Wed, 24 Jun 2009, Herbert Xu wrote:

> david@lang.hm wrote:
>>
>> there is only a difference between multicast and broadcast traffic if you
>> are spanning subnets.
>
> Which is always the case if you invest in some intelligent switches.

given that each subnet will be a minimum of 4 IP addresses (the network 
address, two useable, and thr broadcast address), putting each machine on 
it's own subnet and routing between them on the switch would be very 
wasteful of addresses.

if you use larger subnets, your switch still has the ability to filter 
things out when they move from port to port, but broadcasts (unless you 
filter them) still cover the entire subnet.

so No, buying intelligent switches doesn't mean that you are always 
spanning subnets.

David Lang

Re: When does Linux drop UDP packets?

[Herbert Xu]

david@lang.hm wrote:
>
> given that each subnet will be a minimum of 4 IP addresses (the network 
> address, two useable, and thr broadcast address), putting each machine on 
> it's own subnet and routing between them on the switch would be very 
> wasteful of addresses.

What I mean is that if you have snooping switches then multicasts
and broadcasts are not the same even when you're on the same subnet.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: When does Linux drop UDP packets?

[david]

On Thu, 25 Jun 2009, Herbert Xu wrote:

> david@lang.hm wrote:
>>
>> given that each subnet will be a minimum of 4 IP addresses (the network
>> address, two useable, and thr broadcast address), putting each machine on
>> it's own subnet and routing between them on the switch would be very
>> wasteful of addresses.
>
> What I mean is that if you have snooping switches then multicasts
> and broadcasts are not the same even when you're on the same subnet.

please explain more? how do they differ?

David Lang

Re: When does Linux drop UDP packets?

[Herbert Xu]

On Wed, Jun 24, 2009 at 10:37:14PM -0700, david@lang.hm wrote:
>
> please explain more? how do they differ?

An IGMP-snooping switch will only forward multicast traffic to
ports that have subscribed to that group.  Broadcast traffic
on the otherhand is forwarded to all ports.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: When does Linux drop UDP packets?

[Alexander Clouter]

Hi,

* Herbert Xu <herbert@gondor.apana.org.au> [2009-06-25 14:13:48+0800]:
> 
> On Wed, Jun 24, 2009 at 10:37:14PM -0700, david@lang.hm wrote:
> >
> > please explain more? how do they differ?
> 
> An IGMP-snooping switch will only forward multicast traffic to
> ports that have subscribed to that group.  Broadcast traffic
> on the otherhand is forwarded to all ports.
>
[directing over to David...]

The more intelligent switches actually peek at L3/L4 (even if it's just 
a L2 switch, like a Cisco 2950) to decode IGMP packets as they come out 
from the hosts.  The switch uses that to build up an Ethernet multicast 
routing table, in addition to it's usual unicast based one.

If you bought a managed switch in the past five years (ours from 8 years 
ago that we have just binned also supported it) it should support 
IGMP snooping.  Any one buying switches now needs to make sure they 
support IPv6 and MLD snooping...bearing in mind you are going to be 
lumbered with those switches for at least five years.

In addition and mentioned before, the NIC in hardware will also filter 
any multicast traffic that is un-needed if you are using el-cheapo 
switches; crime and punishment.  Broadcast traffic *always* spans the 
whole VLAN and *always* gets passed up to the OS to make decisions on 
whether to process the packet or not.

Now, when you roll back in the 'automaticness' of service discovery and 
other such things on the network...multicast is a very powerful tool.  
Just because it can be many<->many or one<->many does not mean it cannot 
be just as efficiently used to bootstrap one<->one communications.

Cheers

-- 
Alexander Clouter
.sigmonster says: Don't take life seriously, you'll never get out alive.