Hi
The problem was that "reverse-path filtering" was enabled. after
disabling reverse-path filtering I could receive broadcasts as
expected.
As a side note - interface does not need to be in promiscuous mode
cheers pieter
On 13/07/2011 10:03, Pieter wrote:
Hi
All
Im running Linux 2.6.32.14 on an embedded MPC4858.
One of the Application (CLI) must reciece a UDP broadcast packet.
The problem is that I only receive packets broadcast from within
the same subnet (192.168.0.x) even though the broadcast app
sends the broadcast to 255.255.255.255.
when i run tcpdump on the embedded machine it shows both
broadcasts from the same subnet well as different subsets: as
shown below:
SDH-0A000221> /tmp/tcpdump port 23 or port 33334
tcpdump: verbose output suppressed, use -v or -vv for full
protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size
65535 bytes
(1) 07:48:35.787826 IP 172.16.63.184.cli >
255.255.255.255.cli: UDP, length 58
(2) 07:48:43.832539 IP 192.168.0.1.cli > 255.255.255.255.cli:
UDP, length 60
(3) 07:48:43.840627 IP 192.168.0.254.cli > 192.168.0.1.cli:
UDP, length 112
The embedded machine is configured with:
ip 192.168.0.254
mask 255.255.0.0
(1) is a broadcast from a different subnet
(2) is broadcast from within same subnet
(3) the imbeded applications reply to the broadcast from same
subnet
The service has been delared in "etc/xinetd.d/cli" as follows:
service cli
{
socket_type = dgram
protocol = udp
port = 23
wait = yes
user = root
server = /usr/vastech/in.cli
disable = no
cps = 10 5
flags = IPv4
}
and the port assigned in "/etc/xinetd.d/services" as follows (port
23 for back comparability with older products)
#telnet 23/udp
cli 23/udp
cli 33334/udp
Is there something basic that I have overlooked ? should the
interface be set and left in
promiscuous mode to do what I require?
thanks pieter
--
VASTech PTY (LTD)
021 880 9807
|
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
