Fix windows packet creation #5
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Windows packets were being generated with the wrong address. Packats leaving the machine were using the address as 0.0.0.0 on the source, which was then not propagated by any network stack. This was caused by the in_pktinfo on Windows not using the interface address if the socket ipi_ifindex is defined. On Linux, the in_pktinfo structure has an extra field, the ipi_spec_dst, which is used as the first source of information, then the ipi_ifindex next. On windows, if we set the ipi_ifindex, the ipi_addr will be used regardless of what is the interface ip. Given that we were only filling the field with a value if the interface passed was a Interface::Address, the field would go out as mem::zeroed, so 0.0.0.0 To avoid producing invalid packets, during the windows socket startup, we investigate all the addresses and build a hashmap of ifindex -> address. So, when we use the information, we lookup the table and also fill the address part of the request. To avoid erros when sending packets with Interface::Default, the CMSGHDR for control is not being created, and instead is added as an empty buffer. This was enough to have a system using multicast-socket to start listening to packets once again and finding each-other with win x win communicaiton. It also fixed the win x linux communication producing things as 0.0.0.0 when listening to the messages.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Windows packets were being generated with the wrong address. Packats
leaving the machine were using the address as 0.0.0.0 on the source,
which was then not propagated by any network stack.
This was caused by the in_pktinfo on Windows not using the interface
address if the socket ipi_ifindex is defined.
On Linux, the in_pktinfo structure has an extra field, the ipi_spec_dst,
which is used as the first source of information, then the ipi_ifindex
next.
On windows, if we set the ipi_ifindex, the ipi_addr will be used
regardless of what is the interface ip.
Given that we were only filling the field with a value if the interface
passed was a Interface::Address, the field would go out as mem::zeroed,
so 0.0.0.0
To avoid producing invalid packets, during the windows socket startup,
we investigate all the addresses and build a hashmap of ifindex ->
address.
So, when we use the information, we lookup the table and also fill the
address part of the request.
To avoid erros when sending packets with Interface::Default, the CMSGHDR
for control is not being created, and instead is added as an empty
buffer.
This was enough to have a system using multicast-socket to start
listening to packets once again and finding each-other with win x win
communicaiton.
It also fixed the win x linux communication producing things as 0.0.0.0
when listening to the messages.