[pox-dev] Requesting port statistics (problem with connection)

Tmusic Tmusic987 at gmail.com
Mon Oct 8 12:24:24 PDT 2012


Hi Murphy,

Port stats are working now (with the new version of libopenflow).

Thank you for all your help!!

Regards,

Tim


2012/10/6 Murphy McCauley <murphy.mccauley at gmail.com>

> Weird, not sure how that happened.  I think you can just change the "n"
> argument to "part", but that code is actually right around some other work
> I've been doing in betta's libopenflow, so I've just pushed my latest
> libopenflow which also addresses this.
>
> -- Murphy
>
> On Oct 6, 2012, at 10:47 AM, Tmusic wrote:
>
> Hi,
>
> Thank you very much!!
> Topology and discovery are working.
> Flow stats are working.
>
> Port stats still give errors:
> Request goes well and the switch responds (checked with wireshark).
> I think it happens while parsing the received packet.
>
> Traceback (most recent call last):
>   File "/home/openflow/pox_workspace/OFcontroller/pox/openflow/of_01.py",
> line 835, in run
>     if con.read() is False:
>   File "/home/openflow/pox_workspace/OFcontroller/pox/openflow/of_01.py",
> line 700, in read
>     msg.unpack(self.buf)
>   File
> "/home/openflow/pox_workspace/OFcontroller/pox/openflow/libopenflow_01.py",
> line 2332, in unpack
>     self.body.append(n)
> NameError: global name 'n' is not defined
>
>
> This the wireshark analysis of the port stats response:
>
> Frame 4515: 496 bytes on wire (3968 bits), 496 bytes captured (3968 bits)
> Linux cooked capture
> Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
> Transmission Control Protocol, Src Port: 53590 (53590), Dst Port: 6633
> (6633), Seq: 269, Ack: 353, Len: 428
> OpenFlow Protocol
>     Header
>         Version: 0x01
>         Type: Stats Reply (CSM) (17)
>         Length: 428
>         Transaction ID: 14
>     Stats Reply
>         Type: Physical port statistics (0x0004)
>         Flags: 0
>         Port Stats
>             Port #: 3
>             # Received packets: 6
>             # Transmitted packets: 88
>             # Received bytes: 468
>             # Transmitted bytes: 3608
>             # RX dropped: 0
>             # TX dropped: 0
>             # RX errors: 0
>             # TX errors: 0
>             # RX frame errors: 0
>             # RX overrun errors: 0
>             # RX CRC errors: 0
>             # Collisions: 0
>         Port Stats
>             Port #: 2
>             # Received packets: 6
>             # Transmitted packets: 79
>             # Received bytes: 468
>             # Transmitted bytes: 3239
>             # RX dropped: 0
>             # TX dropped: 0
>             # RX errors: 0
>             # TX errors: 0
>             # RX frame errors: 0
>             # RX overrun errors: 0
>             # RX CRC errors: 0
>             # Collisions: 0
>         Port Stats
>             Port #: Local  (local openflow "port")
>             # Received packets: 0
>             # Transmitted packets: 0
>             # Received bytes: 0
>             # Transmitted bytes: 0
>             # RX dropped: 0
>             # TX dropped: 0
>             # RX errors: 0
>             # TX errors: 0
>             # RX frame errors: 0
>             # RX overrun errors: 0
>             # RX CRC errors: 0
>             # Collisions: 0
>         Port Stats
>             Port #: 1
>             # Received packets: 6
>             # Transmitted packets: 72
>             # Received bytes: 468
>             # Transmitted bytes: 2952
>             # RX dropped: 0
>             # TX dropped: 0
>             # RX errors: 0
>             # TX errors: 0
>             # RX frame errors: 0
>             # RX overrun errors: 0
>             # RX CRC errors: 0
>             # Collisions: 0
>
> Thanks,
>
> Tim
>
>
>
> 2012/10/6 Murphy McCauley <murphy.mccauley at gmail.com>
>
>> All right, yeah, openflow.topology was majorly broken.  It should be in
>> somewhat better shape now.
>>
>> (I never use it -- it's due for a major overhaul.)
>>
>> -- Murphy
>>
>> On Oct 6, 2012, at 7:03 AM, Murphy McCauley wrote:
>>
>> That method was renamed to listen_to_dependencies().  I think it's in
>> there twice.  Does renaming it fix everything?
>>
>> You'll also need to run openflow.discovery if you want topology
>> discovery, BTW.
>>
>> -- Murphy
>>
>> On Oct 6, 2012, at 5:49 AM, Tmusic wrote:
>>
>> Hi,
>>
>> Thanks!
>> I'm indeed running python 32bit in a VM.
>> Betta can run now, but topology discovery is not working.
>> When running the topology and openflow.topology components, I get
>> following error:
>>
>> Traceback (most recent call last):
>>   File "/home/openflow/pox_workspace/OFcontroller/pox/boot.py", line 447,
>> in boot
>>     if _do_launch(argv):
>>   File "/home/openflow/pox_workspace/OFcontroller/pox/boot.py", line 187,
>> in _do_launch
>>     f(**params)
>>   File
>> "/home/openflow/pox_workspace/OFcontroller/pox/openflow/topology.py", line
>> 316, in launch
>>     core.register("openflow_topology", OpenFlowTopology())
>>   File
>> "/home/openflow/pox_workspace/OFcontroller/pox/openflow/topology.py", line
>> 66, in __init__
>>     if not core.listenToDependencies(self, self._wantComponents):
>>   File "/home/openflow/pox_workspace/OFcontroller/pox/core.py", line 481,
>> in __getattr__
>>     raise AttributeError("'%s' not registered" % (name,))
>> AttributeError: 'listenToDependencies' not registered
>>
>> Topology seems to be ok, but PyDev indicates an unresolved import in
>> openflow.topology (xid_generator).
>>
>> Any ideas?
>>
>> Thanks,
>>
>> Tim
>>
>>
>> 2012/10/5 Murphy McCauley <murphy.mccauley at gmail.com>
>>
>>> On Oct 5, 2012, at 1:34 PM, Murphy McCauley wrote:
>>> >> Betta (0ca0a8b5b5726195aa2c69337af98a146308dab9) always gives
>>> following error (no matter which components are loaded):
>>> > ...
>>> >>  File
>>> "/home/openflow/temp_repo/poxrefbetta/pox/openflow/libopenflow_01.py", line
>>> 51, in xid_generator
>>> >>    return chain.from_iterable(repeat(xrange(start,stop+1))).next
>>> >> OverflowError: Python int too large to convert to C long
>>> >
>>> > Oh, weird.  I guess you're running a 32 bit Python?  Try knocking the
>>> +1 off the second arg to xrange and seeing if that fixes it.
>>>
>>> Yeah, I confirmed this was a 32 bit issue.  I've pushed a fix.  Thanks
>>> for the report.
>>>
>>> -- Murphy
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noxrepo.org/pipermail/pox-dev-noxrepo.org/attachments/20121008/0e489cda/attachment-0001.htm>


More information about the pox-dev mailing list