[Wireshark-dev] how to capture loop back traffic in wireshark
Hi, Is there any way by which Wireshark can capture packets for loopback traffic (when the source and destination ip are same)on windows or linux machine. Regards Rahul Rohit === Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. === ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] how to capture loop back traffic in wireshark
On 20 March 2014 11:21, Rahul Rohit wrote: > Hi, > > Is there any way by which Wireshark can capture packets for loopback > traffic (when the source and destination ip are same)on windows or linux > machine. > > > > > See the loopback capture page on the Wiki: http://wiki.wireshark.org/CaptureSetup/Loopback ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Infiniband dissector not showing payload
In trying to look at some IB captures, I noticed that any payload data
included was never displayed in the packet details (tree) pane. It
obviously appears in the bytes pane - but nothing in the details pane.
This is with both 1.10.6 and the latest git master.
I did some poking around and debugging, and it appears that the "data"
dissector is always called with a NULL tree.
Now, I'm not that familiar with IB. However, I was able to get the
payload data displayed by making a change in
epan/dissectors/packet-infiniband.c, in dissect_infiniband_common(),
changing
/* Get the parent tree from the ERF dissector. We don't want to
nest under ERF */
if (tree && tree->parent)
{
/* Set the normal tree outside of ERF */
tree = tree->parent;
/* Set a global reference for nested protocols */
top_tree = tree;
}
to
/* Get the parent tree from the ERF dissector. We don't want to
nest under ERF */
if (tree && tree->parent)
{
/* Set the normal tree outside of ERF */
tree = tree->parent;
/* Set a global reference for nested protocols */
top_tree = tree;
}
else
{
top_tree = tree;
}
Debugging showed that tree->parent was always NULL. Making this change
caused the Data to be displayed at the same tree level as Frame,
Extensible Record Format, and Infiniband. Not sure this is correct,
since the data is actually within the Infiniband subtree.
I can provide more details, but I don't know what other impact the above
change might have. I was hoping someone more familiar with the IB
dissector might determine what the proper fix is.
--
David Ameiss
netsh...@ameissnet.com
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Gerrit versus Buildbot
Just had the unpleasant experience of having a patch submitted to gerrit where it sat for nearly one month, just got merged after a code review, then got reverted when buildbot revealed issues. When I have submitted to other gerrit-based projects like OpenOCD, they have an automated build system connected (IIRC it's a standard thing called Jenkins) that provides a +1/-1 to trap build-related issues immediately after submission. Any reason why wireshark doesn't do this? Alternately, is there a way for submitters to access build-bot so we can proof changes prior to merge (or better yet, prior to submission)? Chris Kilgour ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Gerrit versus Buildbot
On 3/20/14 11:40 AM, Chris Kilgour wrote: > Just had the unpleasant experience of having a patch submitted to gerrit > where it sat for nearly one month, just got merged after a code review, then > got reverted when buildbot revealed issues. > > When I have submitted to other gerrit-based projects like OpenOCD, they have > an automated build system connected (IIRC it's a standard thing called > Jenkins) that provides a +1/-1 to trap build-related issues immediately after > submission. Any reason why wireshark doesn't do this? That was the plan when I installed Gerrit, unfortunately: Buildbot's GerritStatusPush doesn't work with our version of Gerrit (2.8.3): http://trac.buildbot.net/ticket/2550 Jenkins seems very nice and I'm not opposed to migrating to it, however migrating from Buildbot to Jenkins would be nontrivial and Jenkins appears to have the same lack of support for Gerrit > 2.6 as Buildbot: https://issues.jenkins-ci.org/browse/JENKINS-21564 > Alternately, is there a way for submitters to access build-bot so we can > proof changes prior to merge (or better yet, prior to submission)? If the build system had open access what would keep someone from uploading a shell script containing a box full of weasels wearing clown shoes? ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Gerrit versus Buildbot
On 03/20/2014 01:07 PM, Gerald Combs wrote: > > If the build system had open access what would keep someone from > uploading a shell script containing a box full of weasels wearing clown > shoes? Isn't the same thing true for Jenkins/buildbot spawned from gerrit? Surely the build machines must be limited/sandboxed to prevent the circus from taking over the town. Any other suggestions to reduce the 30-day latency in checking submissions against build issues, short of assembling my own build farm? ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Buildbot crash bugs
Howdy, What's the protocol (for lack of a better term) for how the Buildbot crash bugs get handled? Are there specific core developers who handle them, or is it whomever wants to fix it please do so? I ask because there've been a bunch of them lately which look like dups of bug 9909 (it wasn't the first in the series, but it's the first I easily reproduced). So I submitted a change to at least stop the crashing, to stop the bug-generation. But I can't change the status of such bugs to in-progress, so I'm hesitant to actually dig into what the code should really do, other than not crash. It's in packet-ieee80211.c, which is impressively big. (>25k lines!) So I don't want to duplicate work if someone else's already digging into it. -hadriel ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Gerrit versus Buildbot
Fyi, the current Version of Jenkins works just fine with gerrit 2.8.2 on my setup. Regards, Roland Am Donnerstag, 20. März 2014 schrieb Gerald Combs : > On 3/20/14 11:40 AM, Chris Kilgour wrote: > > Just had the unpleasant experience of having a patch submitted to gerrit > where it sat for nearly one month, just got merged after a code review, > then got reverted when buildbot revealed issues. > > > > When I have submitted to other gerrit-based projects like OpenOCD, they > have an automated build system connected (IIRC it's a standard thing called > Jenkins) that provides a +1/-1 to trap build-related issues immediately > after submission. Any reason why wireshark doesn't do this? > > That was the plan when I installed Gerrit, unfortunately: > > Buildbot's GerritStatusPush doesn't work with our version of Gerrit > (2.8.3): > > http://trac.buildbot.net/ticket/2550 > > Jenkins seems very nice and I'm not opposed to migrating to it, however > migrating from Buildbot to Jenkins would be nontrivial and Jenkins > appears to have the same lack of support for Gerrit > 2.6 as Buildbot: > > https://issues.jenkins-ci.org/browse/JENKINS-21564 > > > > Alternately, is there a way for submitters to access build-bot so we can > proof changes prior to merge (or better yet, prior to submission)? > > If the build system had open access what would keep someone from > uploading a shell script containing a box full of weasels wearing clown > shoes? > ___ > Sent via:Wireshark-dev mailing list > > > > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Buildbot crash bugs
On Mar 20, 2014, at 3:20 PM, Hadriel Kaplan wrote:
> What's the protocol (for lack of a better term) for how the Buildbot crash
> bugs get handled?
>
> Are there specific core developers who handle them, or is it whomever wants
> to fix it please do so?
The latter. The only difference between buildbot crash bugs and other bugs is
that robots don't generally do as good a job at figuring out where the problem
is, so rather than looking at the bug title to see which dissector is broken,
you have to look at a stack trace (which means you have to reproduce the bug -
it might be nice if, when a core is dumped in the buildbot tests, gdb could be
used to produce a stack trace and put it into the bug), so there's an extra
step involved in going after the bug.
> It's in packet-ieee80211.c, which is impressively big. (>25k lines!)
So is IEEE Std 802.11-2012. (>2k pages!) :-)
To be fair, IEEE Std 802.3-2012 is 634+780+358+732+844+400 = 3748 pages, so
it's about 1000 more pages (">2k" is 2793), but:
$ wc -l epan/dissectors/packet-eth.c epan/dissectors/packet-ieee8023.c
epan/dissectors/packet-ethertype.c
970 epan/dissectors/packet-eth.c
137 epan/dissectors/packet-ieee8023.c
410 epan/dissectors/packet-ethertype.c
1517 total
However, I think a lot of those 3748 pages describe various PHYs (more than I
think 802.11 has), and the different PHYs have *no* effect on the dissectors,
whereas the different PHYs for 802.11 add in some extra management frame crap
and the like.
But I digress. :-)
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Gerrit versus Buildbot
On Mar 20, 2014, at 2:24 PM, Chris Kilgour wrote: > On 03/20/2014 01:07 PM, Gerald Combs wrote: >> >> If the build system had open access what would keep someone from >> uploading a shell script containing a box full of weasels wearing clown >> shoes? > > Isn't the same thing true for Jenkins/buildbot spawned from gerrit? Surely > the build machines must be limited/sandboxed to prevent the circus from > taking over the town. Currently, it's limited to building stuff to which at least one core developer is willing to give +2. That requires human judgement, so it's not as rigid as a hardware/software-implemented sandbox. Yes, a very tight sandbox, so that filling up Makefile.am with weasels will only allow them to eliminate in a limited enclosed space, might do the job. Probably something like a VM, created afresh for every build, would do the trick. If the creation is done by cloning, that might even be fast enough. Most buildbots run on OSes capable of running as guests for various virtualization programs (OS X, Windows, Ubuntu Linux), and maybe the Solaris buildbot could run in a zone, so that might be doable. But I've never managed a build farm, so I might be missing something. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Buildbot crash bugs
On Mar 20, 2014, at 8:02 PM, Guy Harris wrote:
>> It's in packet-ieee80211.c, which is impressively big. (>25k lines!)
>
> So is IEEE Std 802.11-2012. (>2k pages!) :-)
>
> To be fair, IEEE Std 802.3-2012 is 634+780+358+732+844+400 = 3748 pages, so
> it's about 1000 more pages (">2k" is 2793), but:
Yeah but I know the 802.3 ones (well, the spec back in around 2009), whereas
the 802.11 spec just reminds me how much I hate IEEE specs. :)
(though they're better than 3GPP's by a few orders of magnitude, but I
digress...)
-hadriel
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
