Opened 5 years ago

Closed 4 years ago

#1334 closed defect (fixed)

RAW Datagram Handling of SAM Broken

Reported by: ExtraBattery Owned by: mkvore
Priority: minor Milestone: 0.9.16
Component: apps/SAM Version: 0.9.13
Keywords: Cc:
Parent Tickets:


I recently tried to send a non-repliable datagram to a destination registered for repliable datagrams (using SAM). I wanted to know if the datagram is delivered. I then realized that I'm unable to send a non-repliable datagram at all.

If I first create a raw datagram session in SAM "SESSION CREATE STYLE=RAW ..." and then try to send a datagram using "RAW SEND DESTINATION=... SIZE=...", I receive nothing even though I listen using another raw session. With repliable datagrams this procedure works.

So "RAW" datagram handling of SAM seems to be broken.

I also realized that the SAM documentation doesn't mention how to send a datagram without port forwarding. So it would be helpful to add some info concerning the two SAM commands for sending repliable and non-repliable datagrams using the SAM client connection:


I used I2P 0.9.13-0 for testing this. No experimental SAM was used.


Attachments (1)

Checks.txt (76 bytes) - added by ExtraBattery 5 years ago.
Ignore this attachment, it was uploaded by mistake.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 5 years ago by zzz

  • Status changed from new to infoneeded_new

Unable to reproduce. I just tried sending a raw datagram to myself using SAM v1, and it worked.

Please provide additional details and/or code for a test case.

re: docs, where do you think that info is missing? It's on the v1 docs http://i2p-projekt.i2p/en/docs/api/sam

comment:2 Changed 5 years ago by ExtraBattery

  • Status changed from infoneeded_new to new

I used SAM v3.0 for the findings posted in the OP.

I'm unable to reproduce your results with SAM v1.0. That is, using SAM (of I2P 0.9.13-0) v1.0 I'm unable to successfully send and receive a repliable datagram. Same with non-repliable datagrams. So the only thing that works for me is SAM v3.0 with repliable datagrams.

My test code is not in Java. Basically I create to sessions (mouth and ear):

Mouth in: HELLO VERSION MIN=3.0 MAX=3.0
Mouth in: SESSION CREATE STYLE=RAW DESTINATION=[518 chars/mouth] ID=abc1 nickname=mouth

Ear in: SESSION CREATE STYLE=RAW DESTINATION=[518 chars/ear] ID=abc2 nickname=ear

Each of the input is followed by the expected output of SAM (like "SESSION STATUS RESULT=OK ..."). Then I wait for one second to be on the safe side. Finally I send the datagram:

Mouth in: RAW SEND DESTINATION=[518 chars/ear] SIZE=1

Followed by one byte (I use a 0x01).

Then I listen on the "ear" session. Nothing ever happens. As I've said above, if I use "DATAGRAM" instead of "RAW", things work. So my procedure seems to be fine in general.

The SAM v1 documentation is good, I just didn't see it. I previously looked at the SAM v3 documentation (because that's the one you get when you use that css-menu on the I2P website). The v3 doc doesn't mention "RAW SEND" and "DATAGRAM SEND".

Last edited 5 years ago by ExtraBattery (previous) (diff)

comment:3 Changed 5 years ago by zzz

My v1 tests were with a recent 0.9.13-x dev build.


(here I had to patch I2P so I could log the destination so I could find out what it is and send something to myself. v1 doesn't tell you what your destination is, and you can't pass a b64 destination to it)


... and I got the 4 bytes back

comment:4 Changed 5 years ago by zzz

In SAMv3Handler.handle(), "RAW" is not recognized as a command. Looking through the history, it's never been there.

Clearly, from the code and the docs, v3 was intended to handle RAW. Presumably both in one-socket and separate-socket mode.

I only tested one-socket mode (which it appears is what you tested above since there's no PORT parameter. It's not easy for me to test separate-socket mode without writing some code or playing with netcat UDP mode.

I'll add RAW handling and see if it works.

comment:5 Changed 5 years ago by zzz

It's clear that v3 datagram handling is primarily intended to be via the datagram socket 7655. Inline (single socket) support in v3 mode is not documented. The ID parameter is not supported... it uses the most recently open raw or datagram session, as appropriate. And, of course, the OP issue that it doesn't recognize RAW at all.

To be documented.

comment:6 Changed 5 years ago by zzz

  • Milestone set to 0.9.16
  • Priority changed from major to minor

RAW support tested, in 0.9.13-17 03bde2aad36b000a71a8b8ab729b474c230517e4

Docs updated in a56cc4f45cc2c0585bf5d7c7574317e87892c221

Leaving ticket open for ID support.

comment:7 Changed 5 years ago by ExtraBattery

Good to hear that "RAW" sessions will be another feature of the upcoming SAM v3.1. I didn't test port forwarding so far, as you assumed already.

Reading comment 3... SAM v1 does not accept a base64 destination? I didn't know that. This brings me to another potential bug:

In my tests (on I2P 0.9.13-0.) I passed a base64 destination to SAM v1 and it said "SESSION STATUS RESULT=OK DESTINATION=...", repeating the destination I passed. Maybe it had an internal error that it didn't reveal at that point and that's why my further operations (sending and receiving a datagram) failed.

Can you confirm that it is possible to pass a 516 char long base64 destination to SAM v1 in the "SESSION CREATE STYLE=RAW ..." message and get a "RESULT=OK" back?

About comment 5: I assume SAM v3 ignored the ID parameter for "DATAGRAM" sessions all along and just used a random ID instead. It would be great to have this fixed too. In 0.9.16...

I realized my nickname syntax in comment 2 was incorrect. It must be "inbound.nickname=mouth". And there is potential minor bug: The router console shows the first letter of the nickname in a different casing than provided. If I use "mouth", it displays "Mouth". Is this intended?

Last edited 5 years ago by ExtraBattery (previous) (diff)

comment:8 Changed 5 years ago by zzz

v1 does not accept a base 64 destination. It treats it as a name, doesn't find it in sam.keys, and makes a transient destination. See comment 3 above, and the mods to the docs checked in as referenced in comment 6 above. It returns the identifier you gave it. It confused me too, that's why I mentioned it in comment 3 and added a warning in the docs.

the capitalization is a CSS thing in the UI.

Changed 5 years ago by ExtraBattery

Ignore this attachment, it was uploaded by mistake.

comment:9 Changed 5 years ago by ExtraBattery

I can confirm that "RAW SEND" works with the experimental SAM v3.1. I'm really grateful for that.

How can I view the diffs of the documentation?

Okay, I realize it's well documented that SAM v1 treats an unknown name the same as it would treat "TRANSIENT". Very tricky though. But I fail to see the note in the SAM v1 documentation that it always returns the passed identifier in the result message regardless of if it created a new destination or not (this behavior is really crazy in my opinion).

In the section "V1/V2 Compatible Datagram Handling" of the SAM v3 documentation, there are two bad links to the SAM v2 documentation.

comment:10 Changed 5 years ago by ExtraBattery

I did some testing. SAM (v3) does not discriminate between non-repliable and repliable datagrams when receiving. Can one tell them apart during transport or are they just a message and it depends on the receiver how to look at them?

A repliable datagram can be received as non-repliable datagram in SAM v3. If you send a repliable datagram with a payload of one byte to a destination that is registered for non-repliable datagrams, SAM will receive it as a raw datagram with a 428 (387 + 40 + 1) bytes payload.

It's also possible to receive a non-repliable datagram using a destination that is registered for repliable datagrams, if it starts with the correct 427+ bytes. The public key and signature will then be stripped away and the rest treated as payload.

comment:11 Changed 5 years ago by zzz

Links fixed in 39a27fb362aae17afa390e66b2e99d107fce1d71 thank you. I also attempted to clarify the v1/v2 DESTINATION response.

The website is in the i2p.www branch and you may view diffs with the usual tools, eepsites, websites - mtn, git, viewmtn, github.

comment:12 Changed 5 years ago by ExtraBattery

I looked at the diffs and think the docs are much easier to understand now. Can it be that the website ( isn't showing the latest version yet?

comment:13 Changed 4 years ago by zzz

  • Resolution set to fixed
  • Status changed from new to closed

I believe from comment 9 above that everything in this ticket is resolved. If there's anything left, please open a new ticket.

Note: See TracTickets for help on using tickets.