I have a set of computers that share data using UDP broadcast. The
computers ‘collection’ is a mix of Linux, Windows and QNX machines.
On QNX, my problem is that i can not broadcast (-> 192.168.0.255)
any data blocks bigger than the MTU of the network: ~1500 bytes. If i
try to do that, the QNX TCP stack issues an error of the ‘sendto’
system call, with an errno that indicates that it cannot (IP…)
fragment the data block. When i inspect the packets on the network, i
indeed see that QNX sets the ‘DF’ (don’t fragment) flag of any smaller
(UPD/) IP packets it broadcasts.
My problem is that i do need to be able to broadcast bigger packets,
and i do not object if the QNX TCP/IP stack should decide to perform
IP fragmentation of the data. I just do not know how to ‘tell’ that
to the QNX TCP/IP stack. The QNX TCP/IP stack has no problems
receiving and re-assembling UPD/IP fragments that come from any of
the Linux/Windows systems. These systems too broadcast similar data,
and do perform this fragmentation. This indicates that the stack
does ‘understand’ UDP → IP fragmentation/re-assembling, but is
somehow told not to fragment UDP packets for transmissions.
How could i get QNX to also fragment on transmission?
There’s currently no way to have broadcast packets
fragmented. They must fit into the mtu of the sending
iface. This is a BSD’ism: NetBSD, FreeBSD, OpenBSD.
Regards,
-seanb
prfaasse <faasse@nlr-dot-nl.no-spam.invalid> wrote:
I have a set of computers that share data using UDP broadcast. The
computers ‘collection’ is a mix of Linux, Windows and QNX machines.
On QNX, my problem is that i can not broadcast (-> 192.168.0.255)
any data blocks bigger than the MTU of the network: ~1500 bytes. If i
try to do that, the QNX TCP stack issues an error of the ‘sendto’
system call, with an errno that indicates that it cannot (IP…)
fragment the data block. When i inspect the packets on the network, i
indeed see that QNX sets the ‘DF’ (don’t fragment) flag of any smaller
(UPD/) IP packets it broadcasts.
My problem is that i do need to be able to broadcast bigger packets,
and i do not object if the QNX TCP/IP stack should decide to perform
IP fragmentation of the data. I just do not know how to ‘tell’ that
to the QNX TCP/IP stack. The QNX TCP/IP stack has no problems
receiving and re-assembling UPD/IP fragments that come from any of
the Linux/Windows systems. These systems too broadcast similar data,
and do perform this fragmentation. This indicates that the stack
does ‘understand’ UDP → IP fragmentation/re-assembling, but is
somehow told not to fragment UDP packets for transmissions.
How could i get QNX to also fragment on transmission?
Thanks for the answer… Thus endeth all ideas to port the thing to
FreeBSD… :-/
Is there any prospect that this limitation will be lifted? Is the
limitation of UDP broadcast to one MTU a design choise or an
implementation effect?
I have yet to find any adverse effects of big UDP broadcasts on Linux
and/or Win32…
prfaasse <faasse@nlr-dot-nl.no-spam.invalid> wrote:
Thanks for the answer… Thus endeth all ideas to port the thing to
FreeBSD… :-/
Is there any prospect that this limitation will be lifted? Is the
limitation of UDP broadcast to one MTU a design choise or an
implementation effect?
I have yet to find any adverse effects of big UDP broadcasts on Linux
and/or Win32…
It’s a design decision. If it’s not fragmented it’s more likely all
receivers will get the entire packet.
I’m not aware of any plans to change this but anything’s possible…
Regards,
-seanb
I have thought about this, but can not quite follow the reasoning:
- i want to broadcast a ‘big’(> MTU) data packet
- this is refused by the stack because fragementing could result in
that the receiver
does not receive all fragments → the receiver would not receive
all data
- the netto result is that the receiver does not receive anything at
all… :-/
No offence intended, but for now i fail to see how not fragmenting at
all would make it more likely that a receiver gets any more data. For
‘small’ broadcast packets, there is no need to fragment, so permitting
fragmentation makes no difference, it’s; For ‘big’ packets,
fragmenting does increase the number of IP fragements, thus the
probability that one of them goes ‘lost’, but not fragmenting (aka.
not transmitting) drops the probability of receiving any data to zero
in one easy go…
Setting the DF flag in each IP fragment (meaning: don’t fragment these
IP fragments any more) I could understand, but not fragmenting at all
eludes me.
prfaasse <faasse@nlr-dot-nl.no-spam.invalid> wrote:
I have thought about this, but can not quite follow the reasoning:
- i want to broadcast a ‘big’(> MTU) data packet
- this is refused by the stack because fragementing could result in
that the receiver
does not receive all fragments → the receiver would not receive
all data
- the netto result is that the receiver does not receive anything at
all… :-/
… if you absolutely need fragmentation. If this encourages you
to rethink and avoid fragmentation, you’ve at least doubled the
chances everyone receives all packets.
There are a number of reasons why broadcast and fragmentation should
be minimized; however I’m not the network police on your subnet. All
I can currently suggest is to perhaps look at multicast as a workaround
or to contact your sales rep if you absolutely need this feature as
there’s no way enable it currently.
No offence intended, but for now i fail to see how not fragmenting at
all would make it more likely that a receiver gets any more data. For
‘small’ broadcast packets, there is no need to fragment, so permitting
fragmentation makes no difference, it’s; For ‘big’ packets,
fragmenting does increase the number of IP fragements, thus the
probability that one of them goes ‘lost’, but not fragmenting (aka.
not transmitting) drops the probability of receiving any data to zero
in one easy go…
Setting the DF flag in each IP fragment (meaning: don’t fragment these
IP fragments any more) I could understand, but not fragmenting at all
eludes me.