On Aug 7, 2011, at 11:00 PM, Stig Bjørlykke wrote:
> On Fri, Aug 5, 2011 at 11:05 PM, Michael Tuexen
> <Michael.Tuexen@xxxxxxxxxxxxxxxxx> 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 <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>