AES.p4app - h2 doesn't receive the msg sent by h1
ramonfontes opened this issue · comments
Hello,
Is there something else I should care about the communication between h1 and h2? S1 gets receive the message sent by h1 but it doesn't forward the msg to its 2nd port that is connected to h2.
Hi,
The P4 code does not have routing table, and it only "reflects" the packet back to its sender. However, it should be easy to add a table such that the packet is routed.
Okay. I thought I could reproduce the scenario with the information provided within the README file. Can I consider only the port and mac address in the P4 rule?
Yes, that should be enough. You can also use only port number, to forward anything coming from port 1 into port 2, and vice versa.
Yes, I see. However, I think I may need change the P4 fie in order to achieve that. Or not?
In the usage section you have written:
Please send a packet with etherType 0x9999 with at least 128+16bit payload, ending with 0xffff. The P4 switch should reply a packet with the 128 bit plaintext replaced by its encrypted ciphertext. The switch will drop all other packets
I agree with The switch will drop all other packets. So I was wondering whether I create a new table with new instructions, would the frame sent via scapy be recognized by the original P4 file? If I use only the port number to forward anything coming from port 1 into port 2, and vice versa, I think I wouldn't be able to reproduce the network scenario as expected.
If _drop() was called anywhere in the pipeline, the packet will get dropped, no matter what other processing or routing is performed.
So, you can still add your own routing table (by writing into standard_metadata.egress_spec), and the packet with other etyerType will still get dropped.