Re: [nox-dev] Type Error Question

2011-03-06 Thread Aaron Rosen
Sorry, I was incorrect I am getting packet_out's. Aaron On Sat, Mar 5, 2011 at 10:50 PM, Aaron Rosen aro...@clemson.edu wrote: I've also tried this which yields the same results: if packet.next.protocol == 0x4: print UNENCAPED1 packet.next = packet.next.next

Re: [nox-dev] Type Error Question

2011-03-05 Thread Aaron Rosen
Hey Guys I have one more question: I'm receiving IPIP packets and I want to unencapsulate them. I'm receiving these packets as packet_ins and I have the follow code to handle this: if packet.next.protocol == 0x4: print UNENCAPED1 packet.next = packet.next.next

Re: [nox-dev] Type Error Question

2011-03-05 Thread Aaron Rosen
I've also tried this which yields the same results: if packet.next.protocol == 0x4: print UNENCAPED1 packet.next = packet.next.next self.send_openflow_packet(dpid, packet.arr,openflow.OFPP_FLOOD , inport) self.send_openflow_packet(dpid,

Re: [nox-dev] Type Error Question

2011-03-01 Thread James Murphy McCauley
You're not doing anything wrong here. You seem to be doing something wrong elsewhere. Specifically, you seem to have constructed an MSS TCP option with a tuple as its value, when the value should be some sort of integer. -- Murphy On Tue, 2011-03-01 at 15:22 -0500, Aaron Rosen wrote: Hello I

Re: [nox-dev] Type Error Question

2011-03-01 Thread Aaron Rosen
Hi Murphy, I'm just trying to connect to a computer using ssh so when I do ssh 130.127.39.235 I see these typeerror messages. I do not to anything with the packet when it gets to the controller except tell it to flood. The MSS of these packets are 1460 in the packet_in event. Any idea?

Re: [nox-dev] Type Error Question

2011-03-01 Thread James Murphy McCauley
Looks like the problem is in the parsing. Here's a patch: --- a/src/nox/lib/packet/tcp.py +++ b/src/nox/lib/packet/tcp.py @@ -150,7 +150,7 @@ class tcp(packet_base): elif arr[i] == tcp_opt.MSS: if arr[i+1] != 4: raise Exception() -

Re: [nox-dev] Type Error Question

2011-03-01 Thread Aaron Rosen
Oh Nox is also telling me this: Traceback (most recent call last): File ./nox/lib/util.py, line 113, in f event.total_len, buffer_id, packet) File ./nox/coreapps/examples/aaronswitch.py, line 182, in packet_in_callback self.forward(dpid, inport, packet, packet.arr, bufid) File

Re: [nox-dev] Type Error Question

2011-03-01 Thread James Murphy McCauley
Yeah, that's a bug too. Change line 78 in tcp.py to like... print '(tcp_opt to_bytes) warning, unknown option type ' + str(self.type) .. I'd actually be interested in knowing which option it is, because maybe we should be handling it. You could also probably pass packet.arr instead of

Re: [nox-dev] Type Error Question

2011-03-01 Thread Aaron Rosen
If I pass packet.arr that still doesn't work. I don't get an Error message but tcpdump says: 19:16:26.829891 IP truncated-ip - 730 bytes missing! 130.127.39.173.58832 130.127.39.235.ssh: P 2569410772:2569411564(792) ack 3106665167 win 12 nop,nop,timestamp 10172901 47037426 Also adding that

Re: [nox-dev] Type Error Question

2011-03-01 Thread James Murphy McCauley
I didn't just add the + str(self.type). I also switched it to a print from a call to self.msg() (which doesn't exist because the TCP option class isn't a subclass of the main packet class). You should do this. BUT... now I am suspicious. How are you getting these packets? Are they from

Re: [nox-dev] Type Error Question

2011-03-01 Thread Aaron Rosen
These packets are from non-matches. So I guess I'm only getting 128Bytes of the packet from this? I guess I should install a rule that sends this packets to the controller if I want the full packet. Thanks, Aaron On Tue, Mar 1, 2011 at 7:28 PM, James Murphy McCauley jam...@nau.eduwrote: I

Re: [nox-dev] Type Error Question

2011-03-01 Thread James Murphy McCauley
You CAN change how much of the packet gets forwarded from a miss, but this is done in the switch negotiation and there's no really clean way to change it (it's a macro in one of the openflow headers). You're better off installing a flow. In that case, if you're not manipulating the packets at