On Aug 7, 2011, at 11:00 PM, Stig Bjørlykke wrote: > On Fri, Aug 5, 2011 at 11:05 PM, Michael Tuexen > <[email protected]> wrote: >> thank you... Comments are really welcome. > > The easiest part is to report the bugs :) > > >>> * Multiple IP addresses should be separated with comma in the "Edit >>> Interfaces Settings" window, I think. >> Need to see how this haves with a lot of addresses. > > If not separated by comma I think we should align the addresses below > each other. Right now they are aligned with "Interface:" and "IP > address". Agreed. > > >>> * Should we use only one line in headings used in the interface list? >>> This to save space for more interfaces in the list. >> I wanted to see all IP-addresses, but showing only one line would save >> space. Not sure. > > I was thinking about the headers, not the entries. Shorten the > heading names and adding tooltips could be a solution. Ahh, yes, that makes sense. > > >>> * The "Wireless Settings" button is not always enabled for my AirPcap >>> device, and is sometimes enabled for my Ethernet device. >> We don't have AirPcap devices and that support is most likely broken. > > I can have a look at the code changes. > > >>> And something not related to this: >>> * My AirPcap device lists "unknown" as IP address. Should this simply >>> be removed? Do we know if devices don't have an IP address? >> Not sure. Maybe not showing unknown is the same as showing no addresses. > > I think we should not show anything if we know the device has no IP > address, but I don't know if we know. The current behavior is as in 1.6. But not showing unknown saves space. So it is a good idea, I think. > > >>> * "Capture packets in monitor mode" is enabled for devices not supporting >>> this. >> If there is a way to figure out if it is supported, we should handle that >> correctly, >> I agree. > > The old code used to work. While looking at the new code I find > something which makes me think something is obvious broken: > > row.monitor_mode = caps->can_set_rfmon; > > row.monitor_mode is true if monitor mode is turned on. > caps->can_set_rfmon is true if the interface supports monitor mode. Yes, that looks wrong. > > >>> * When manually selecting all interfaces in the list, should the >>> checkbox "Capture on all interfaces" be automatically checked? >> Hmm. Not sure. Does this help? This would required counting. But it >> could be done. > > It would be more user friendly, as it leads to an inconsistent state. Not sure if it is inconsistent... I guess the name is wrong: It was supposed to be a way to simply enable all interfaces or disable all interfaces, no matter what the current state is.
Maybe there is a better way to do this? Any suggestions? > > >>> * I get wrong link-layer for some of my remote (rpcap) devices. This >>> used to work before. >> Hmm. This needs to be fixed. Can you provide some hints what is going >> wrong? We haven't seen this in our testing. > > I'm starting rpcapd on the same machine and use 'localhost' as host. > I'll have a closer look to see if I can find more clues. Thanks. > > > And I have some more issues: > * The welcome page is not refreshed after change in interface options > preferences (changing description etc.) I think it is only changed when an interface is added... OK, this is a bug. I'll add it to the ToDo list. > * The "Start" button is sometimes disabled even when selected an > interface, and sometimes enabled even when no interfaces are selected. > Try this to observe the issue: Select "Capture Options" from the > welcome page, turn on "Capture on all interfaces" and turn off > "Capture on all interfaces" again, then select capture for a simple > interface. > * "Capture all in promiscuous mode" can be checked even if not all > interfaces have this. The checkbox should be un-toggled. Well, this is a question of semantics: The intention is to switch it on or off on all interfaces, no matter what the current state is. > * Tooltips for ok button in "Edit Interfaces Settings" is wrong, it > does not start a capture process. Yepp, that is a bug. Thanks again for the feedback! All issues will be addressed, although it may take some time... Best regards Michael > > > -- > Stig Bjørlykke > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe > ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
