I've not seen this specific behavior before. I'm not sure why it would do that.
To be clear, org.apache.activemq.artemis.spi.core.protocol.RemotingConnection#getRemoteAddress is basically just a wrapper around io.netty.channel.Channel#remoteAddress [1] so the exact behavior here will be determined by Netty. It may be worth reaching out to the Netty community for insight. Is the client connecting via IPv6? Is the relevant acceptor listening on an IPv6 address? Justin [1] https://github.com/netty/netty/blob/0503b50a32ebdb576e3064f67b01081665f0f15e/transport/src/main/java/io/netty/channel/Channel.java#L147 On Mon, Jun 2, 2025 at 10:26 AM William Crowell <wcrow...@perforce.com.invalid> wrote: > Is there any reason why the following code would return the IPv6 loopback > address and not the actual physical IPv4 address of the client? > > import io.netty.handler.codec.mqtt.MqttMessage; > import org.apache.activemq.artemis.core.protocol.mqtt.MQTTInterceptor; > import org.apache.activemq.artemis.spi.core.protocol.RemotingConnection; > > public class MyInterceptor implements MQTTInterceptor { > @Override > public boolean intercept(final MqttMessage mqttMessage, final > RemotingConnection connection) { > System.out.println("RemotingConnection: " + > connection.getRemoteAddress()); > return true; > } > } > > This prints out: RemotingConnection: [0:0:0:0:0:0:0:1]:46682 > > Regards, > > William Crowell > > > This e-mail may contain information that is privileged or confidential. If > you are not the intended recipient, please delete the e-mail and any > attachments and notify us immediately. > >
