Skip to content

Conversation

timriker
Copy link
Member

@timriker timriker commented Mar 2, 2023

This should be ready to merge. Sources and plugins build. one.bzflag.org:5154 and one.bzflag.org:5155 both running my fork.

  • Address now contains sockaddr_in6.
  • Server starts listening on ipv6 :: by default.
  • if -i 0.0.0.0 is given, server starts in ipv4 only mode.
  • I have ONLY compiled on Linux. I did clear IPV6_V6ONLY which, in theory, allows Windows to use one tcp listen for both ipv4 and ipv6
  • bzadmin now starts up udp which I've used for testing
  • ServerId is gone
  • Address(text) blocks on DNS. This could use fixing.
  • udp socket follows tcp socket family
  • server cache file has nameport only once per entry
  • list server no longer returns ipaddr for BZFS0225 and newer. You will need to use my list server, or apply the pull request for bzfls.php.
  • UDEBUGMSG uses logDebugMessage at level 5
  • a number of fixes for logDebugMessages calls that tried to be on one line. With datestamp, that's broken
  • work around no bundle for debug logging in bzfs and bzadmin
  • deleted internal "name:port ; description". Now description is just description.
  • wildcard IP bans are NO LONGER SUPPORTED. They need to be converted to cidr format.

@timriker timriker self-assigned this Mar 2, 2023
@timriker timriker changed the title IPv6 work in progress IPv6 Mar 2, 2023
@timriker timriker requested review from blast007 and atupone April 10, 2023 05:40
@blast007
Copy link
Member

There's still remaining build errors and warnings with Visual Studio.

In Address::getIPVersion(), sin6_family is of type ADDRESS_FAMILY, which is typedef'ed to be an unsigned short with Winsock, so there's a warning about a loss of data converting it to an uint8_t. There's the same warning in Address::pack(...) for buf = (unsigned char*)nboPackUByte(_buf, addr.sin6_family);. We probably want to have our own defines for this anyway since the value for AF_INET6 on Windows is 23 but it is 10 on Linux.

Then there's a bunch of errors about __in6_u not being a member of in6_addr (which is the type of sin6_addr used in quite a number of places). With Winsock, the in6_addr type only has a u member with further has unsigned char Byte[16] and unsigned short Word[8] members, so it doesn't look like Winsock exposes 32-bit chunks of an IPv6 address.

@timriker
Copy link
Member Author

I've been busy with other projects, sorry. I want to get windows builds working for me locally. If port is being cast to a uint8 someplace, that's a bug. Ports should be 16 bit.

@blast007
Copy link
Member

It was the address family being cast to uint8_t, not the port.

timriker and others added 25 commits July 25, 2023 23:19
I created defines for the protocol family so we'd have consistent
numbering across platforms. I made use of macros such as
IN6_IS_ADDR_V4MAPPED which is available at least on Windows and Linux.

I fixed the non-Windows check for NAT64 addressing.

This still needs more testing and some of the #ifdef'ed parts could
possibly be simplified into something cross-platform.
…orms

On Linux there are s6_addr and s6_addr16 (in addition to s6_addr32, but
Winsock doesn't have an equivalent) aliases for __in6_u.__u6_add8 and
__in6_u.__u6_addr16. Winsock already had s6_addr, so I added s6_addr16
if it isn't defined. This allows common syntax between the platforms. I
replaced uses of 32-bit address chunks with 16-bit.
timriker and others added 3 commits July 25, 2023 23:47
Set the macOS deployment target to 10.13 to match the dependencies.
Add CoreHaptics and GameController frameworks to the bzflag client.
@timriker timriker marked this pull request as ready for review July 26, 2023 22:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

2 participants