MikroTik

Posted: **Tue Aug 20, 2019 9:06 pm**

We have a job coming up in a warehouse with some long Ethernet runs for access points. We will be using CAT6 cabling.

If we use standard 802.3af POE switches and access points that are powered 802.3af, my understanding is that the GPER can go in between and the switch should power the GPER and the access point.

Is that correct?

Do they pass VLANs?

Any reason not to use them?

Thanks
Jason

Posted: **Wed Aug 21, 2019 10:18 am**

Yes, it will effectively extend your cable and will pass any data you transmit and also will power the device at the other end. It's like putting a switch in between. There will be a minimal voltage drop, below one Volt, see table at the second page of this file; https://i.mt.lv/cdn/rb_files/GPeR-1565848659.pdf

Posted: **Mon Aug 26, 2019 1:48 am**

Does it learn MAC addresses (SVL or IVL?), drop bad frames and add some delay (store and forward), auto-negotiate (possibly different speeds to both ends) like a switch? Or is it a true layer 1 repeater, nothing more?
Also, does it allow 802.3af/at PoE detection/classification with the device at the other end? For this you must draw almost no current at low voltages, so that 25k resistance is still correctly measured.

Posted: **Wed Sep 11, 2019 12:34 am**

It's like putting a switch in between

mmh, thats a delphi-oracle term ...
a switch learns mac-adresses ... a switch ages mac-adresses !?
so question is: is this a switch, like a two-port-bridge or is it just like patch-port in OVS which says "<->" ?

Posted: **Wed Sep 11, 2019 1:27 am**

Does it learn MAC addresses (SVL or IVL?), drop bad frames and add some delay (store and forward), auto-negotiate (possibly different speeds to both ends) like a switch? Or is it a true layer 1 repeater, nothing more?
Also, does it allow 802.3af/at PoE detection/classification with the device at the other end? For this you must draw almost no current at low voltages, so that 25k resistance is still correctly measured.

Good questions...
Also what about MTU it can do?

Posted: **Wed Sep 11, 2019 2:11 am**

It's like putting a switch in between
a switch learns mac-adresses ... a switch ages mac-adresses !?

a switch with 2 ports doesn't need to learn no MAC addresses and henceforth not responsible for any aging procedures. it neither runs no loop prevention algorythm. whatever is received from port A will be sent out to port B. it is basically a more expensive piece of wire that is manageable

if it would support different speeds on both ports, it sould then also have buffering to mitigate drops from congestions due to different bitrate frames arrive and leave.

Posted: **Wed Sep 11, 2019 2:57 am**

i think its a 2port switch with Poe in to power it and Poe pass-through

a great device

gper1.jpg

gper2.jpg

Posted: **Fri Sep 13, 2019 12:57 am**

a switch with 2 ports doesn't need to learn no MAC addresses

of cause there would be no need, neither would be a need for that in a linux-bridge which contains two logical interfaces by my command or a 24-port switch where I only plugged two cables in ...
... but they do ! ... threrefore my question.
There are Access-Points in the field which communicates power-requirements over LLDP-MED ... more questions ... !? How would a GPER behave ?

Expecting a pair of GPER ... (what is it ... ... kleine racker : ) ? ... tomorrow.
... or how Gertrud would say:
" a field-test is a field-test is a field-test"

Posted: **Fri Sep 13, 2019 1:21 am**

"Yes, it will effectively extend your cable and will pass any data you transmit"

data ... yep, data is a lot ...

so let us concatenate which questions:

- ether-speed negotiation bursts (and the results ... we all now: it's standard ... but it's not golden in functionality ... nowhere )
- lldp-behaviour (lldp-med ...etc. ... etc.)
- mtu (max_es ? no max_es ?
- multicast

studied "https://i.mt.lv/cdn/rb_files/GPeR-1565848659.pdf" thoughtfully ... but ... I've ... still ... some questions left
... so let's fill the voids
\Yii

Posted: **Fri Sep 13, 2019 2:01 am**

What chip is that? Marvell 88e8041? It's hard to read from the image...
But that's a huge chip for such simple device, probably have like 4 ports or even MII interface...

If it does have more ports, maybe there could be GPER version with more than two connectors? So you could branch off cable to the device, like AP... just like you did in the old days of coaxial cable with the T...

Posted: **Tue Sep 17, 2019 10:06 pm**

most fun is always testing new stuff

... guess we can skip the 'unboxing part', because this is obviously the wysiwyg-approach ... no knives ... no scissors ... no violence needed ... and I aggree 100% with it
.

1st.png

.
first test ... brute force !
the big buddy in the foreground is a wireless-ap with two 5GHz-ac- and one 2.4GHz-radios ... and it's eating PoE-power ... like ... hell
the grey box with yellow patch in the back is a PoE+ Switch ... and it's feeding PoE-power ... like ... ... accordingly
.

wuhan-sw# show poe interface GigabitEthernet 1/1
Interface               PD Class  Port Status                               Power Used [W]   Current Used [mA]  
----------------------  --------  ----------------------------------------  ---------------  -----------------  
GigabitEthernet 1/1     4         PoE turned ON                             11.9             225                 
wuhan-sw#

.

2nd.png

.
when a GPER is plugged inbetween ... in a world of plug'n'play ... nothing would change ?!
.

3rd.png

.
... the first test ?! ... a "PASS" !
all radios up, pnp ... nice and easy
.

wuhan-sw# show poe interface GigabitEthernet 1/1           
Interface               PD Class  Port Status                               Power Used [W]   Current Used [mA]  
----------------------  --------  ----------------------------------------  ---------------  -----------------  
GigabitEthernet 1/1     4         PoE turned ON                             14.4             256                 
wuhan-sw#

.
little more power is used ... thats it

wuhan-sw# show lldp neighbors interface GigabitEthernet 1/1
Local Interface     : GigabitEthernet 1/1
Chassis ID          : DC-08-56-03-22-A0
Port ID             : DC-08-56-03-22-A0
Port Description    : Alcatel-Lucent Enterprise OAW-AP1231 eth0
System Name         : OmniAccess Stellar OAW-AP1231
System Description  : Alcatel-Lucent Enterprise OAW-AP1231 3.0.6.28
System Capabilities : Bridge(+), WLAN Access Point(+), Router(-), Station Only(-)
PoE Type            : 

PoE Source          : 
PoE Power           : 
PoE Priority        : 

wuhan-sw#

.
and we learn two things:
- GPER is transparent for LLDP-frames
- and my band-aid was a goofy idea
.
adding one more GPER and a little bit more power ...
.

4th.png

.
... expected results
.

wuhan-sw# show poe interface GigabitEthernet 1/1
Interface               PD Class  Port Status                               Power Used [W]   Current Used [mA]  
----------------------  --------  ----------------------------------------  ---------------  -----------------  
GigabitEthernet 1/1     4         PoE turned ON                             16.1             299                 
wuhan-sw#

.

5th.png

.
... still fine, when we replace the PoE-Client with a PoE-2-passive-converter and a map-lite
.

wuhan-sw# show poe interface GigabitEthernet 1/1           
Interface               PD Class  Port Status                               Power Used [W]   Current Used [mA]  
----------------------  --------  ----------------------------------------  ---------------  -----------------  
GigabitEthernet 1/1     4         PoE turned ON                             3.6              70                  
wuhan-sw#

.
less power ! (like out of hell : )
... and very enlightening:
.

wuhan-sw# show interface GigabitEthernet 1/1 capabilities 

GigabitEthernet 1/1 Capabilities:
  Model:                 8G-2GF
  Type:                  10/100/1000BaseT
  Speed:                 10,100,1000,auto
  Duplex:                half,full,auto
  Trunk encap. type:     802.1Q
  Trunk mode:            access,hybrid,trunk
  Channel:               yes
  Broadcast suppression: no
  Flowcontrol:           yes
  Fast Start:            no
  QoS scheduling:        tx-(8q)
  CoS rewrite:           yes
  ToS rewrite:           yes
  UDLD:                  no
  Inline power:          yes
  RMirror:               no
  PortSecure:            yes
  Dot1x:                 yes

.

wuhan-sw#
wuhan-sw# show interface GigabitEthernet 1/1 status 
Interface               Mode     Speed & Duplex  Flow Control  Max Frame  Excessive  Link      
----------------------  -------  --------------  ------------  ---------  ---------  --------  
GigabitEthernet 1/1     enabled  Auto            disabled      9600       Discard    1Gfdx      
wuhan-sw#

.
.
lldp = transparent, link-speed = per segment
.

6th.PNG

.
from map-lite's point of view ...
.

7th.PNG

...
at this point more ether-speed tests and some pcaps were planned ... (but homeland-administration decided other...wisely) ... so we postpone that to the next episode ...

Posted: **Tue Sep 17, 2019 10:21 pm**

Thx for the info

Posted: **Tue Sep 17, 2019 11:24 pm**

good stuff floaty, thx

Still would be good to identify the switch chip used so we can find the datasheet for it with exact specs...

Posted: **Tue Sep 17, 2019 11:27 pm**

oncho.png

.
... yepp ... I thought so ... ... guess I was to hasty to shoot a bundle

Posted: **Wed Sep 18, 2019 12:03 am**

would be good to identify the switch chip

.
Yeah I know ... but this reminds of christmas, when I was a child ... my sister got a new watch ... and I got lot of trouble ... and she would not accept 'my fireforce-truck' ! as compensation.
To be honest ... I already tried, but my little iPhone-crowbar is not the sharpest anymore ( ... cause I'm a box-burglar since when I still believed in Santa).
... and what is more ... I bought this from company-budget ... yepp nobody would screw me over a GPER ... but in summary

?!

Maybe someone from the MTik-family here in the forum, can ask R&D what chip is involved and we learn without cracking it open ?!
It's published for every router-board what chip is soldered ... so I couldn't figure any lyzeums-behaviour ?!

... and when it comes to blackbox-analyzing ... you learn about how sharp (or not) your (mental-)tools are ...
so:
1st: social engineering (if someone would a decent question call it like that)
2nd: old school (if you put something in and comes more than nothing out, you may be able to figure what's going on inside)
3rd:

alle_neune.png

.

Posted: **Wed Sep 18, 2019 12:10 am**

see also viewtopic.php?f=3&t=150611 ...

Posted: **Wed Sep 18, 2019 1:35 am**

1) at what OSI layer this device work? at L1 like hub, or at L2 like switch?
2) what delay does this device add?
3) why distance is limited to 1500 m?

.

1) ... the DEVICE (aka GPeR [thats from the birth-certificate] acts obviously like a switch
... different ether-speeds ... with full-duplex on both sides of the box ... that I've learned from my 'network-potty-class-tests' ( no offense ... of cause you neeed a potty for potty-class ... )
... MTik is printing two mac-adressess on the type-shield ( broad broad hint ! ... no need on a hub for that ... and yes ... you couldn't know without a potty)

2) ... also a good question ... maybe the lowest, which the soldered 'switching'-chip would allow ... guess the delay is like any other mainstream store-and-forward-switching-chip you find on the market
... cause when you have different speeds on your ether-segments ... which is obviously possible ... you're a store-and-forward-switch ... by the needs !

main score of the product seems to be: enhance GBit/s-connectivity without the fiber-constraints ( workmanship-like ... and of cause powering devices, where you don't wanna have to distribute electrical-power too ) ... I wouldn't expect Usain-Bolt-Perfs

3) ... we have delay on every medium ... and we have MAC-layer defined which expects minimum-response-times to fit the protocol
... we add the 'natural' delay of the medium with the delay of our (signal-regenerating) switches ... and yet we have a boundary ...

... that's our life Jacky Brown

[ ... and also the fiber-man coping with the problem ... https://en.wikipedia.org/wiki/Fiber-optic_communication ]

Posted: **Wed Sep 18, 2019 1:54 am**

https://en.wikipedia.org/wiki/Shannon_limit
.
interesting article indeed ... and crazy numbers:
.

tönn.PNG

Posted: **Wed Sep 18, 2019 6:37 pm**

I didn't say I agree with all comments there

Posted: **Fri Sep 20, 2019 1:42 pm**

... yepp ... the discourse had a little drift

... so ... STP, 802.1q:
Setup: PoE-Switch<-->GPER<-->passivePoEconv<-->mapLite
.

802.##1.png

.
.

wuhan-sw# show spanning-tree active 
CIST Bridge STP Status
Bridge ID    : 32768.9A-86-03-28-05-01
Root ID      : 32768.9A-86-03-28-05-01
Root Port    : -
Root PathCost: 0
Regional Root: 32768.9A-86-03-28-05-01
Int. PathCost: 0
Max Hops     : 20
TC Flag      : Steady
TC Count     : 4
TC Last      :   0d 00:01:30
Port       Port Role       State       Pri  PathCost  Edge  P2P  Uptime       
---------  --------------  ----------  ---  --------  ----  ---  -------------
Gi 1/1     DesignatedPort  Forwarding  128     20000  No    Yes  0d 00:01:32
wuhan-sw#

.
.

802.##2.PNG

.
wuhan-sw is the choosen root-bridge ... so I guess the auditorium would diagnose by the 100% ... GPER is transparent for Bridge-PDUs

Posted: **Fri Sep 20, 2019 1:59 pm**

and not so surprising anymore:
.

wuhan-sw# show run
--- snip ---
!
interface GigabitEthernet 1/1
 switchport mode trunk                             
 poe mode plus
 poe power limit 30.0
!
--- snip ---
wuhan-sw# show vlan
VLAN  Name                              Interfaces
----  --------------------------------  ----------
1     default                           Gi 1/1,3-10
11    nubecula                          Gi 1/1-2,9

wuhan-sw# 
wuhan-sw# show ip interface  brief 
Interface        Address              Method   Status
---------------- -------------------- -------- ------
VLAN 1           192.168.222.177/24   DHCP     UP    
VLAN 11          1.1.1.1/24           Manual   UP    
wuhan-sw# 
wuhan-sw# ping ip 1.1.1.2
PING server 1.1.1.2, 56 bytes of data.
64 bytes from 1.1.1.2: icmp_seq=0, time=0ms
64 bytes from 1.1.1.2: icmp_seq=1, time=0ms
64 bytes from 1.1.1.2: icmp_seq=2, time=0ms
64 bytes from 1.1.1.2: icmp_seq=3, time=0ms
64 bytes from 1.1.1.2: icmp_seq=4, time=0ms
Sent 5 packets, received 5 OK, 0 bad
wuhan-sw#

.
.

802.##3.PNG

.
.
transparency for 802.1q-tagged frames

Posted: **Fri Sep 20, 2019 2:29 pm**

since we were able to add an OSPF-Router in Vlan11 on a "wuhan-sw"-port ... we can mark tickbox "multicast" as 'checked'
.

802.##4.PNG

.

802.##5.png

Posted: **Fri Sep 20, 2019 3:04 pm**

side-note:

when plugging in a GPER into my PoE-switch like that:
.

#1.png

.
... and than add a PoE-Client behind the GPER, like that:
.

#2.png

.
... or that:
.

#3.png

.
.
... the PoE-Client is not powered up ... I had to disconnect and reconnect the cable at PoE-Switch before power is delivered
( I thought this is remarkable ... for instance in case your PoE-Client resides on a 500-feet-tower ... and you wondering up there ?! [ I know ... 500feet is kinda melodramatic, but I had to construct the need for a GPER

])
.
guess this behaviour is related to PoE-detection in the switch ... no passive PoE-adapter in the arsenal to verify ... so check, before climb !

Posted: **Fri Sep 20, 2019 5:42 pm**

guess this behaviour is related to PoE-detection in the switch ... no passive PoE-adapter in the arsenal to verify ... so check, before climb !

Normis explained that 802.3af/at powering only works when there's a compliant device down the line ... if there isn't one, passive PoE injector should be used.

Posted: **Fri Sep 20, 2019 6:59 pm**

because it is my responsability to keep the readers tight and greedy ...
now ... at very last ... the gretchen-question:
? MTU ?

for starters: it was not so easy to find the proper equipment for the mtu-tests here at homeland-labs

While the "wuhan-sw" supports a max. frame-size of 9600 bytes (guess this is the whole frame), it's test-utility ends at 1452 (seems this is payload).
The most capable SBC I've found here reaches it's flag-pole-end at 4000 bytes.
So I did it with a chromebook with USB3-EtherNIC [9194byte] and the win10-laptop on which I'm just typing these words [9014byte].
The MTU-size I was able to transfer over the GPER was 9014byte (... for today ... )
Good news is: we can call this a jumbo

.
.

wuhan-sw(config-if)# interface GigabitEthernet 1/1
wuhan-sw(config-if)# mtu ?
    1518-9600    Maximum frame size in bytes.
wuhan-sw(config-if)# mtu 9600
wuhan-sw(config-if)# 
!
interface GigabitEthernet 1/1
 switchport mode trunk                             
 poe mode plus                                     
 poe power limit 30.0                              
!       
wuhan-sw# show ip interface brief 
Interface        Address              Method   Status
---------------- -------------------- -------- ------
VLAN 1           192.168.222.177/24   DHCP     UP    
VLAN 11          1.1.1.1/24           Manual   UP    
wuhan-sw# 
wuhan-sw# ping ip 192.168.222.165 size ?   
    <2-1452>    2-1452; Default is 56 (excluding MAC, IP and ICMP headers)
wuhan-sw#

.
chromebook:

localhost / # ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet 192.168.222.166  netmask 255.255.255.0  broadcast 192.168.222.255
        inet6 fe80::2e0:4cff:fe68:248  prefixlen 64  scopeid 0x20<link>
        ether 00:e0:4c:68:02:48  txqueuelen 1000  (Ethernet)
        RX packets 20107  bytes 28433065 (27.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9678  bytes 995227 (971.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

localhost / # ifconfig eth0 mtu 9200
SIOCSIFMTU: Invalid argument
localhost / # ifconfig eth0 mtu 9100
localhost / # ifconfig eth0 mtu 9150
localhost / # ifconfig eth0 mtu 9160
localhost / # ifconfig eth0 mtu 9170
localhost / # ifconfig eth0 mtu 9180
localhost / # ifconfig eth0 mtu 9190
localhost / # ifconfig eth0 mtu 9200
SIOCSIFMTU: Invalid argument
localhost / # ifconfig eth0 mtu 9196
SIOCSIFMTU: Invalid argument
localhost / # ifconfig eth0 mtu 9194
localhost / # ifconfig eth0 mtu 9195
SIOCSIFMTU: Invalid argument
localhost / # ifconfig eth0 | grep mtu
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9194
localhost / #

.
.

_1.PNG

.
.

_3.png

.
.

_4.png

.
.

_5.png

Posted: **Fri Sep 20, 2019 7:25 pm**

sooo ... hopefully without being to much over the railing, we can say:
.
GPER is 802.1at-PoE-powered two-port switch, which is capable to deliver 802.1at-PoE-power to a client-device and it is transparent for every Layer2-protocol*), while it supports a mtu-size of at least 9014 bytes ?!

*) in a more formal way:
when GPER=br666
then
ovs-ofctl add-flow br666 "in_port=1, actions=2"
ovs-ofctl add-flow br666 "in_port=2, actions=1"

... and there is a IP67-housing for it

Posted: **Fri Sep 20, 2019 11:22 pm**

I think its a 2port switch with Poe in to power it and Poe pass-through

.
@chechito
seems you were right by first best-guess-attempt ...
btw. ... ... were you able to exactly identify, whether the marvell-chip is a 88E8040 or a 88E8042 ??

even when it is a:
Marvell® Yukon 88E8040 Gigabit Ethernet Controller-Chip ?!

... no-one can NOT stroll into the marvell-website and study in all sangfroid some specs ! ... this is Eddy-Snowdon-Age ! ... you need to have a NDA-agreement.with these marvelous silicon-cooks

... before you do.

And maybe the exact max-supported-mtu-size of the device/chip is irrelevant for the most use-cases, where the deployment-parms of the environment are more crucial ?!

So we expect "real-field-notes" for real "use-cases" (I like the instagram-style tower-stories in the forum !!

).
.

chippy-yie-hey.PNG

Posted: **Sat Sep 21, 2019 12:46 am**

I think its a 2port switch with Poe in to power it and Poe pass-through
.
@chechito
seems you were right by first best-guess-attempt ...
btw. ... ... were you able to exactly identify, whether the marvell-chip is a 88E8040 or a 88E8042 ??

the photo shows almost what i see in real life

i try it with different light angles and a magnifier glass but the number are very tiny and ink looks half erased

Posted: **Sun Sep 22, 2019 12:47 am**

when I got my 'security cleareance' ... I will find a way, to leak in between the lines, while telling noomp

.

Dear floaty,

We have received your registration request for use of the Marvell Extranet.

You indicated on the registration form that you either don't have a Marvell Non-Disclosure Agreement (NDA) on file with us, or that you were unsure. Because of the confidential nature of the information you can access from the Extranet, you do need to be under an NDA to use the site. You'll be contacted shortly by a Marvell Sales Representative to confirm your NDA status. If you don't have an NDA on file, you will be provided with one to complete.

If you have any questions, please contact your Marvell sales representative or distributor or click here to locate a sales representative in your area.

Thank you for your interest in Marvell.

Regards,
The Marvell Extranet Sales Administrator

Visit us online at www.marvell.com.

Posted: **Wed Oct 02, 2019 11:48 pm**

... so far ... my request for clearance at marvell ... stuck in spam ?! ... ignored ?! ... I don't give a schattenriss
... we proceed !
... todays setup is able to escalate things to mtu-size 9216 byte ... and is able to do a perf-test too

I added a PoE-injector and removed the GPER-jumper on PoE-out (just to be shure ... ... I ruined some hardware at homeland.labs ... yes ... but this server is not my property;
... so let's keep insurance-rates at reasonable rates : )
... and I added two namespaces in the server-setup to xmit from one to the other.
.

9216-setup.png

.
to keep things simple (and avoid scrolling in a code-window: plain screenshots ... and to forestall the results 9216bytes ? -> yes ... perf-test -> nothing to carp about)
... guess higher mtu-sizes would require a custom kernel ... my opinion: I'm good with 9216

mtu-test:
.

ping1.png

.

ping2.png

.
perf-test:
.
.

perf1.png

.

perf2.png

.

Posted: **Thu Oct 03, 2019 12:38 am**

guess this behaviour is related to PoE-detection in the switch ... no passive PoE-adapter in the arsenal to verify ... so check, before climb !

Normis explained that 802.3af/at powering only works when there's a compliant device down the line ... if there isn't one, passive PoE injector should be used.

.
positive ... the issue isn't happening with a "dump" injector ... so link-detection and PoE-detection in combination inside a PoE-switch could possibly cause a problem while setup and/or operation ... not a big one, with a managable switch ... ... and who would ... ? but again: reconsider.

Posted: **Thu Oct 03, 2019 2:58 am**

last advise !
while editing your posting ... and going lazy ...
... don't become sloppy with your GPER-jumpers ...

(stock your tools ... and keep hoover and cat away

)
.

jumper.png

Posted: **Fri Oct 25, 2019 11:21 pm**

and in most of the cases a GPeR would make sense
... adding a proper housing for it [GPeR IP67 Case] , would be sensefull too:
installation is straight forward ... ... when using ready-made cables you have possibly to shorten the bend relief of the cable
.

1_1.jpg

.

2_2.jpg

.

3_3.jpg

.

4_4.jpg

.

5_5.jpg

.

6_6.jpg

Posted: **Sat Oct 26, 2019 2:47 pm**

6_6.jpg

Nice pics ... but this one is not gonna work

Posted: **Sat Oct 26, 2019 6:07 pm**

yepp, when I got this setup to fly, caribean retirement is on schedule

MikroTik

GPER usage questions

GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions

Re: GPER usage questions