2024-10-07T13:03:03.851Z | <Matthews Jose> Hello Everyone,
I have a quick question about the V1 protocol code. In the function "CtPtr ProtocolV1::handle_client_banner(char *buffer, int r)"
ldout(cct, 20) << __func__ << " r=" << r << dendl;
if (r < 0) {
ldout(cct, 1) << __func__ << " read peer banner and addr failed" << dendl;
return _fault();
}
if (memcmp(buffer, CEPH_BANNER, strlen(CEPH_BANNER))) {
ldout(cct, 1) << __func__ << " accept peer sent bad banner '" << buffer
<< "' (should be '" << CEPH_BANNER << "')" << dendl;
return _fault();
}
ceph::buffer::list addr_bl;
entity_addr_t peer_addr;
addr_bl.append(buffer + strlen(CEPH_BANNER), sizeof(ceph_entity_addr));
try {
auto ti = addr_bl.cbegin();
decode(peer_addr, ti);
} catch (const ceph::buffer::error &e) {
lderr(cct) << __func__ << " decode peer_addr failed " << dendl;
return _fault();
}
ldout(cct, 10) << __func__ << " accept peer addr is " << peer_addr << dendl;
if (peer_addr.is_blank_ip()) {
// peer apparently doesn't know what ip they have; figure it out for them.
int port = peer_addr.get_port();
peer_addr.set_sockaddr(connection->target_addr.get_sockaddr());
peer_addr.set_port(port);
ldout(cct, 0) << __func__ << " accept peer addr is really " << peer_addr
<< " (socket is " << connection->target_addr << ")" << dendl;
}
connection->set_peer_addr(peer_addr); // so that connection_state gets set up
connection->target_addr = peer_addr;
return CONTINUE(wait_connect_message);
}" |
2024-10-07T13:07:07.047Z | <Matthews Jose> Hello everyone,
I have a quick question about the V1 protocol code in CEPH. In the function "CtPtr ProtocolV1::handle_client_banner(char *buffer, int r)" I noticed that after memcpy on the BANNER message, they do a
"int port = peer_addr.get_port();
peer_addr.set_sockaddr(connection->target_addr.get_sockaddr());
peer_addr.set_port(port);"
but when sending the client banner from the client in the function "CtPtr ProtocolV1::send_client_banner() {" we only send the following:
"bl.append(CEPH_BANNER, strlen(CEPH_BANNER));"
so why is it trying to get the IP address and the port on the server side? Thank you for the help. |
2024-10-07T13:09:56.697Z | <Matthews Jose> Hello everyone,
I have a quick question about the V1 protocol code in CEPH. In the function "CtPtr ProtocolV1::handle_client_banner(char *buffer, int r)" I noticed that after memcpy on the BANNER message, they do a
```"int port = peer_addr.get_port();
peer_addr.set_sockaddr(connection->target_addr.get_sockaddr());
peer_addr.set_port(port);"```
but when sending the client banner from the client in the function "CtPtr ProtocolV1::send_client_banner() {" we only send the following:
```"bl.append(CEPH_BANNER, strlen(CEPH_BANNER));"```
so why is it trying to get the IP address and the port on the server side? Thank you for the help. |
2024-10-07T13:10:12.994Z | <Matthews Jose> Hello everyone,
I have a quick question about the V1 protocol code in CEPH. In the function "CtPtr ProtocolV1::handle_client_banner(char *buffer, int r)" I noticed that after memcpy on the BANNER message, they do a
```int port = peer_addr.get_port();
peer_addr.set_sockaddr(connection->target_addr.get_sockaddr());
peer_addr.set_port(port);```
but when sending the client banner from the client in the function "CtPtr ProtocolV1::send_client_banner() {" we only send the following:
```bl.append(CEPH_BANNER, strlen(CEPH_BANNER));```
so why is it trying to get the IP address and the port on the server side? Thank you for the help. |
2024-10-07T15:02:13.420Z | <gregsfortytwo> I don’t remember the details of this any more (and the implementation in AsyncMessenger v the SimpleMessenger I worked with is different anyway), but I believe that data is being filled in by a different piece of the pipeline along the way. Clients frequently don’t know their own IP/port so this is actually the server identifying it and telling them for other purposes |
2024-10-07T15:04:37.826Z | <aflox> Hi everyone. Not sure if this is the channel to post this to.
I'm trying to hunt down an issue with `radosgw-admin ratelimit` and I stumbled upon a place in the Ceph codebase that looks odd to me, so maybe someone can tell me if I'm seeing ghosts .
In `RGWPutBucketTags::execute` the `attrs` array is [initialized as an empty array](https://github.com/ceph/ceph/blob/main/src/rgw/rgw_rest_ratelimit.cc#L268) with the rate limit being stored into it.
That array is then passed to `DBBucket::merge_and_store_attrs` which uses the `&new_attrs` to update `&attrs` , **but** then passes `&new_attrs` to `store->getDB()->update_bucket` : <https://github.com/ceph/ceph/blob/86227c0f9c9749601dbae234ecb27bf3325ab76c/src/rgw/rgw_sal_dbstore.cc#L274C12-L274C40>
From my understanding, `update_bucket` does not perform any merger, so this code path effectively erases all `attrs` from a bucket and replaces them with just a rate limit attr.
Is that understanding correct? It would match what we are seeing when using the `radosgw-admin ratelimit` command |
2024-10-07T15:06:24.715Z | <Matthews Jose> Thanks for your reply, would you happened to know where to look, to know who populates the ip and port data. Thanks |
2024-10-07T15:20:30.054Z | <gregsfortytwo> I looked briefly and the code is just different enough I have no idea, sorry |
2024-10-07T15:23:44.186Z | <Matthews Jose> ahh nvm thanks anyways |
2024-10-07T16:24:18.185Z | <khayyam> is this channel in-use? |
2024-10-07T16:26:41.095Z | <Khayyam Saleem> ouuu the IRC just streams into here?! |
2024-10-07T16:39:52.522Z | <Casey Bodley> there is a bridge, so slack messages show up in IRC too |
2024-10-07T16:40:36.820Z | <Khayyam Saleem> ah nice, just saw those, guess it only works if you identify with the nickserv first, i sent some loose accidental messages yday |
2024-10-07T18:32:23.877Z | <Joseph Mundackal> is <http://tracker.ceph.com|tracker.ceph.com> down for anyone else?: https://files.slack.com/files-pri/T1HG3J90S-F07QPEHLFRB/download/image.png |
2024-10-07T18:49:43.180Z | <gregsfortytwo> I just refreshed it and it seems fine? |
2024-10-07T19:03:21.615Z | <Joseph Mundackal> seems to be working now - 🤷 (thanks for confirming) |