| Age | Commit message (Collapse) | Author |
|---|
|
Allow accepting udp "connections" using a multicast local address.
Before, it was only possible to receive multicast using the headers
option. Having a connection orirented stream can be very usefull
when receiving multicast audio data. One gets a "connection" for
every source.
Implement (optional) support for IGMPv2 and MLDv1.
This can be usefull if bridges on the network have IGMP/MLD snooping
enabled, and wont forward multicast traffic unless we report what
we excpect. This is experimental for now, so the igmp protocol
must be manually added to the kernel configuration.
|
|
This adds a new route "t"-flag that enables network address translation,
replacing the source address (and local port) of a forwarded packet to
one of the outgoing interface.
The state for a translation is kept in a new Translation structure,
which contains two Iphash entries, so it can be inserted into the
per protocol 4-tuple hash table, requiering no extra lookups.
Translations have a low overhead (~200 bytes on amd64),
so we can have many of them. They get reused after 5 minutes
of inactivity or when the per protocol limit of 1000 entries
is reached (then the one with longest inactivity is reused).
The protocol needs to export a "forward" function that is responsible
for modifying the forwarded packet, and then handle translations in
its input function for iphash hits with Iphash.trans != 0.
This patch also fixes a few minor things found during development:
- Include the Iphash in the Conv structure, avoiding estra malloc
- Fix ttl exceeded check (ttl < 1 -> ttl <= 1)
- Router should not reply with ttl exceeded for multicast flows
- Extra checks for icmp advice to avoid protocol confusions.
|
|
We used to just return the first address of the incoming
interface regardless of if the address matches the source
ip type and scope.
This change tries to find the best interface address that
will match the source ip so it can be used as a source
address when replying to the packet.
|
|
when making outgoing connections, the source ip was selected
by just iterating from the first to the last interface and
trying each local address until a route was found. the result
was kind of hard to predict as it depends on the interface
order.
this change replaces the algorithm with the route lookup algorithm
that we already have which takes more specific desination and
source prefixes into account. so the order of interfaces does
not matter anymore.
|
|
|
|
we did not apply the special case to store 0xFFFF (-0)
in the checksum field when the checksum calculation
returned zero. we survived this for v4 as RFC768 states:
> If the computed checksum is zero, it is transmitted as
> all ones (the equivalent in one's complement arithmetic).
>
> An all zero transmitted checksum value means that the
> transmitter generated no checksum (for debuging or for
> higher level protocols that don't care).
for ipv6 however, the checksum is not optional and receivers
would drop packets with a zero checksum.
|
|
|
|
address for icmpttlexceeded, cleanup
|
|
ipv4local() and ipv6local() now take remote address argument,
returning the closest local address to the source. this
implements the standartized source address selection rules
instead of just returning the first local v4 or v6 address.
the source address selection was broken for esp, rudp an udp,
blindly assuming ifc->lifc->local being a valid v4 address.
use ipv6local() instead.
the v6 routing code used to lookup source address route to
decide to drop the packet instead of checking the interface
on the destination route.
factor out the route hint from Conv and put it in Routehint
structure. avoiding stack bloat in v4 routing. implement the
same trick for v6 avoiding second route lookup in ipoput6.
fix memory leak in icmpv6 router solicitation handling.
remove old unfinished handling of multiple v6 routers. should
implement source specific routes instead.
avoid duplication, use common convipvers() function.
use isv4() instead of memcmp v4prefix.
|
|
|
|
|
|
/n/bugs/open/multicasts_and_udp_buffers
http://bugs.9front.org/open/multicasts_and_udp_buffers/readme
michal@Lnet.pl
I have ported my small MPEG-TS analisis tool to Plan9.
To allow this application working I had to fix a bug in the kernel IPv4 code and increase UDP input buffer.
Bug is related to listening for IPv4 multicast traffic. There is no problem if you listen for only one group or multiple groups with different UDP ports. This works:
Write to UDP ctl:
anounce PORT
addmulti INTERFACE_ADDR MULTICAST_ADDR
headers
and you can read packets from data file.
You need to set headers option because otherwise every UDP packet for MULTICAST_ADDR!PORT is treat as separate connection. This is a bug and should be fixed too, but I didn't tried it.
There is a problem when you need to receive packets for multiple multicast groups. Usually the same destination port is used by multiple streams and above sequence of commands fails for second group because the port is the same.
Simple and probably non-intrusive fix is adding "|| ipismulticast(addr)" to if statement at /sys/src/9/ip/devip.c:861 line:
if(ipforme(c->p->f, addr) || ipismulticast(addr))
This fixes the problem and now you can use the following sequence to listen for multiple multicast groups even if they all have the same destination port:
announce MULTICAST_ADDR!PORT
addmulti INTERFACE_ADDR MULTICAST_ADDR
headers
After that my application started working but signals packet drops at >2 Mb/s input rate. The same is reported by kernel netlog. Increase capacity of UDP connection input queue fixes this problem /sys/src/9/ip/udp.c:153
c->rq = qopen(512*1024, Qmsg, 0, 0);
--
Michał Derkacz
|
|
|
|
|
|
|
