Hello,
io_net chrashes immediately if a multicast packet is send out with a
sento() call.
( call parameters are checked and are correct …)
It’s happen with a SOCK_DGRAM socket. Options used are:
SOL_SOCKET, SO_REUSADDR, SO_REUSEPORT, IP_ADD_MEMBERSHIP,
IP_MULTICAST_LOOP, IP_MULTICAST_TTL
Is it a known problem? Any workarounds ?
Armin
Armin,
Known issue - any mcast packet > ~128 bytes will kill the stack
if you have the same address/port open to listen for them. Apparently
there was a problem in the copy… if you have con0 open when
this happens you will see something like ‘mcopy’ show up then
it dies.
Good news - http://developers.qnx.com/fixes and look for the
tcpip-mcast fix for 6.1. I slammed into while working on
some UPnP code. The fix works.
Jay
Armin wrote in message <3BBF4857.1000901@web.de>…
Hello,
io_net chrashes immediately if a multicast packet is send out with a
sento() call.
( call parameters are checked and are correct …)It’s happen with a SOCK_DGRAM socket. Options used are:
SOL_SOCKET, SO_REUSADDR, SO_REUSEPORT, IP_ADD_MEMBERSHIP,
IP_MULTICAST_LOOP, IP_MULTICAST_TTLIs it a known problem? Any workarounds ?
Armin
Jay,
many thanks for your hint!
Armin
Jay Hogg wrote:
Armin,
Known issue - any mcast packet > ~128 bytes will kill the stack
if you have the same address/port open to listen for them. Apparently
there was a problem in the copy… if you have con0 open when
this happens you will see something like ‘mcopy’ show up then
it dies.Good news - > http://developers.qnx.com/fixes > and look for the
tcpip-mcast fix for 6.1. I slammed into while working on
some UPnP code. The fix works.Jay
Armin wrote in message <> 3BBF4857.1000901@web.de> >…
Hello,
io_net chrashes immediately if a multicast packet is send out with a
sento() call.
( call parameters are checked and are correct …)It’s happen with a SOCK_DGRAM socket. Options used are:
SOL_SOCKET, SO_REUSADDR, SO_REUSEPORT, IP_ADD_MEMBERSHIP,
IP_MULTICAST_LOOP, IP_MULTICAST_TTLIs it a known problem? Any workarounds ?
Armin
Hello,
I have a strange problem with multicasting using the full TCPIP stack
and the speedo device driver. I can receive multicast packets on the
QNX box. However, I cant seem to be able to send them out.
The send program sends out a few packets and then exits with the
error “Host is down”. If I run tcpdump on another machine, I can see
the QNX host sending out arp who-has packets !
The pair of programs used for testing is really very simple and I have
tested them on a combination of Linux/Solaris/LynxOS boxes.
I have also installed the tcpip_multicast patch available from the
QNX web-site.
Any pointers would be much appreciated - this problem is preventing us
from using QNX RTP as multicasting is an important requirement for
our applications.
-Pavan
–
Pavan Sikka
CSIRO Manufacturing Science and Technology Telephone: +61 7 3327 4652
Qld Centre for Advanced Technologies Facsimile: +61 7 3327 4455
Technology Court, Pullenvale QLD 4069 Email:
pavan.sikka@csiro.au
Postal: P O Box 883, Kenmore QLD 4069 Web: www.cat.csiro.au/cmst
Can you post some source?
-seanb
Pavan Sikka <pavan.sikka@csiro.au> wrote:
: Hello,
: I have a strange problem with multicasting using the full TCPIP stack
: and the speedo device driver. I can receive multicast packets on the
: QNX box. However, I cant seem to be able to send them out.
: The send program sends out a few packets and then exits with the
: error “Host is down”. If I run tcpdump on another machine, I can see
: the QNX host sending out arp who-has packets !
: The pair of programs used for testing is really very simple and I have
: tested them on a combination of Linux/Solaris/LynxOS boxes.
: I have also installed the tcpip_multicast patch available from the
: QNX web-site.
: Any pointers would be much appreciated - this problem is preventing us
: from using QNX RTP as multicasting is an important requirement for
: our applications.
: -Pavan
: –
: Pavan Sikka
: CSIRO Manufacturing Science and Technology Telephone: +61 7 3327 4652
: Qld Centre for Advanced Technologies Facsimile: +61 7 3327 4455
: Technology Court, Pullenvale QLD 4069 Email:
: pavan.sikka@csiro.au
: Postal: P O Box 883, Kenmore QLD 4069 Web: www.cat.csiro.au/cmst
OK, here goes. Its possible this code might not be doing
the right thing but Linux is more tolerant …
First, the screen-dumps:
Recv on Linux m/c:
elbonia.cat.csiro.au{sik057}52:%./recv-linux
16909060, 1014158736, 650746000
16909060, 1014158737, 659588000
16909060, 1014158738, 669584000
16909060, 1014158739, 679588000
16909060, 1014158740, 689584000
elbonia.cat.csiro.au{sik057}53:%
Send on Linux m/c:
elbonia.cat.csiro.au{sik057}52:%./send-linux
16909060, 1014158736, 650746000
16909060, 1014158737, 659588000
16909060, 1014158738, 669584000
16909060, 1014158739, 679588000
16909060, 1014158740, 689584000
elbonia.cat.csiro.au{sik057}53:%
Recv on QNX m/c:
larry{sik057}52:%./recv-qnx
16909060, 1014158736, 650746000
16909060, 1014158737, 659588000
16909060, 1014158738, 669584000
16909060, 1014158739, 679588000
16909060, 1014158740, 689584000
16909060, 1014158772, 611686758
16909060, 1014158773, 615533146
16909060, 1014158774, 618379687
16909060, 1014158775, 621226228
16909060, 1014158776, 624072769
16909060, 1014158777, 626919310
larry{sik057}53:%
Send on QNX m/c:
larry{sik057}53:%./send-qnx
16909060, 1014158772, 611686758
16909060, 1014158773, 615533146
16909060, 1014158774, 618379687
16909060, 1014158775, 621226228
16909060, 1014158776, 624072769
sendto: Host is down
larry{sik057}54:%
I have attached the programs.
If you have some working code that demonstrates
multicasting and you could post/email it, that
would be just great. Thanks,
-Pavan
Sean Boudreau wrote:
Can you post some source?
-seanb
Pavan Sikka <pavan.sikka@csiro.au> wrote:
: This is a multi-part message in MIME format.
: --------------193541AB5AFA5F01434DBC18
: Content-Type: text/plain; charset=us-ascii
: Content-Transfer-Encoding: 7bit
: OK, here goes. Its possible this code might not be doing
: the right thing but Linux is more tolerant …
: First, the screen-dumps:
The problem is that fragments after the first are
not inheriting the MCAST / BCAST flags corectly.
The only workaround is to only send packets <= to the
mtu.
This is fixed for 6.2.
-seanb
Many thanks for that, Sean. It should get us going.
Any idea when 6.2 might be out ?
Regards,
-Pavan
Sean Boudreau wrote:
Pavan Sikka <> pavan.sikka@csiro.au> > wrote:
: This is a multi-part message in MIME format.
: --------------193541AB5AFA5F01434DBC18
: Content-Type: text/plain; charset=us-ascii
: Content-Transfer-Encoding: 7bit: OK, here goes. Its possible this code might not be doing
: the right thing but Linux is more tolerant …: First, the screen-dumps:
The problem is that fragments after the first are
not inheriting the MCAST / BCAST flags corectly.
The only workaround is to only send packets <= to the
mtu.This is fixed for 6.2.
-seanb
I have a rough idea but probably better to get in touch
with your sales rep.
-seanb
Pavan Sikka <pavan.sikka@csiro.au> wrote:
: Many thanks for that, Sean. It should get us going.
: Any idea when 6.2 might be out ?
: Regards,
: -Pavan
: Sean Boudreau wrote:
:>
:> Pavan Sikka <pavan.sikka@csiro.au> wrote:
:> : This is a multi-part message in MIME format.
:> : --------------193541AB5AFA5F01434DBC18
:> : Content-Type: text/plain; charset=us-ascii
:> : Content-Transfer-Encoding: 7bit
:>
:> : OK, here goes. Its possible this code might not be doing
:> : the right thing but Linux is more tolerant …
:>
:> : First, the screen-dumps:
:>
:> The problem is that fragments after the first are
:> not inheriting the MCAST / BCAST flags corectly.
:> The only workaround is to only send packets <= to the
:> mtu.
:>
:> This is fixed for 6.2.
:>
:> -seanb