Re: usb/149039: [uhso] Binding problem with uhso
The following reply was made to PR usb/149039; it has been noted by GNATS. From: Fredrik Lindberg To: bug-follo...@freebsd.org, pilzablei...@web.de Cc: Hans Petter Selasky Subject: Re: usb/149039: [uhso] Binding problem with uhso Date: Sat, 31 Jul 2010 15:00:07 +0200 This is a multi-part message in MIME format. --060404010006010801030805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I apparently missed some interface flags (that really doesn't make sense for this device, it's configured with a /32 mask so broadcast etc can only be to itself) that the network stack wants to work properly. With the following patch I'm able bind ssh etc and able to connect to the machine through it. The patch is for -current so I'm not sure if it applies cleanly on 8-release/stable, but it should be trivial to merge it manually if it doesn't apply. Fredrik Lindberg --060404010006010801030805 Content-Type: text/plain; name="uhso.c-binding.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="uhso.c-binding.patch" Index: sys/dev/usb/net/uhso.c === --- sys/dev/usb/net/uhso.c (revision 210676) +++ sys/dev/usb/net/uhso.c (working copy) @@ -1561,7 +1561,7 @@ ifp->if_init = uhso_if_init; ifp->if_start = uhso_if_start; ifp->if_output = uhso_if_output; - ifp->if_flags = 0; + ifp->if_flags = IFF_BROADCAST | IFF_MULTICAST | IFF_NOARP; ifp->if_softc = sc; IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); ifp->if_snd.ifq_drv_maxlen = ifqmaxlen; --060404010006010801030805-- ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/149039: [uhso] Binding problem with uhso
On 08/01/2010 04:37 AM, per...@pluto.rain.com wrote: The following reply was made to PR usb/149039; it has been noted by GNATS. From: Fredrik Lindberg To: bug-follo...@freebsd.org, pilzablei...@web.de Cc: Hans Petter Selasky Subject: Re: usb/149039: [uhso] Binding problem with uhso Date: Sat, 31 Jul 2010 15:00:07 +0200 I apparently missed some interface flags (that really doesn't make sense for this device, it's configured with a /32 mask so broadcast etc can only be to itself) that the network stack wants to work properly. Is a /32 mask even legal? Unless there's a special case involved, it ought to mean that there are no interfaces on the subnet other than this one, thus this interface has no peer to communicate with and might as well not exist. Adding net@ in hopes someone there knows what should happen. Yes, technically a /32 mask defines only one single address, but it's the only mask that really makes sense for this device. /32 masks are "legal" and commonly used for the loopback address of routers. But this is is indeed a very special case. The device has a USB interface that accepts raw IP-packets (with no other encapsulation). Once you have told the device to connect, it will tell you what IP-address you have and what DNS-servers to use, but that's it. My best guess is that the devices does PPP internally in firmware and abstracts the point-to-point link with a IP-packet interface. But since none of these details are available the only (as far as I know) viable thing is to set a /32 mask and set 0.0.0.0 (default route) to be directly reachable through the interface (route add -interface). Fredrik Lindberg ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/149039: [uhso] Binding problem with uhso
The following reply was made to PR usb/149039; it has been noted by GNATS. From: Fredrik Lindberg To: per...@pluto.rain.com Cc: pilzablei...@web.de, bug-follo...@freebsd.org, freebsd-...@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/149039: [uhso] Binding problem with uhso Date: Mon, 02 Aug 2010 08:54:12 +0200 On 08/01/2010 04:37 AM, per...@pluto.rain.com wrote: >> The following reply was made to PR usb/149039; it has been noted >> by GNATS. >> >> From: Fredrik Lindberg >> To: bug-follo...@freebsd.org, pilzablei...@web.de >> Cc: Hans Petter Selasky >> Subject: Re: usb/149039: [uhso] Binding problem with uhso >> Date: Sat, 31 Jul 2010 15:00:07 +0200 >> >> I apparently missed some interface flags (that really doesn't make >> sense for this device, it's configured with a /32 mask so broadcast >> etc can only be to itself) that the network stack wants to work >> properly. > > Is a /32 mask even legal? Unless there's a special case involved, > it ought to mean that there are no interfaces on the subnet other > than this one, thus this interface has no peer to communicate with > and might as well not exist. > > Adding net@ in hopes someone there knows what should happen. > Yes, technically a /32 mask defines only one single address, but it's the only mask that really makes sense for this device. /32 masks are "legal" and commonly used for the loopback address of routers. But this is is indeed a very special case. The device has a USB interface that accepts raw IP-packets (with no other encapsulation). Once you have told the device to connect, it will tell you what IP-address you have and what DNS-servers to use, but that's it. My best guess is that the devices does PPP internally in firmware and abstracts the point-to-point link with a IP-packet interface. But since none of these details are available the only (as far as I know) viable thing is to set a /32 mask and set 0.0.0.0 (default route) to be directly reachable through the interface (route add -interface). Fredrik Lindberg ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Fw: Re: USB modem driver needed
On 08/07/10 21:46, Hans Petter Selasky wrote: On Saturday 07 August 2010 20:08:43 Adrie wrote: Hi, More info for getting this device running under Ubuntu from a forum: I think the driver is called uhso.c, see /sys/dev/usb/net/uhso.c . Maybe there is a missing VID+PID in the table there if it does not get detected under FreeBSD 8+. I don't recognize the device name nor the IDs. If it's a standard plain serial modem for use with ppp then u3g is most likely the correct driver. Fredrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: u3g support for Option Icon 031 modem
On 09/14/2010 02:53 PM, Piotr Isajew wrote: Hi, I made some tests and it appears to work (AT commands as well as PPP connections), but patching u3g.c (at least on 8.1-STABLE) is required for it to work. Regards, Piotr Did you try the uhso driver? I think 031 is an older device with only plain serial ports so I guess it doesn't matter really. Fredrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: uhso hangs on incoming call
On 09/22/2010 07:55 AM, Piotr Isajew wrote: Hello, I'm experimenting with uhso driver and Option Icon 031 modem. Modem responds to AT commands in minicom but it hangs as soon as there is any incoming call to the modem (it may or may not output one RING indication - depending on luck). Is this a common problem or am I the first to encounter it? Regards, Piotr uhso hasn't received much testing in this area, mainly because it was designed for newer Option devices that have their raw IP packet interface. We could work to fix this, but if u3g worked for you I suggest using that driver instead. Fredrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: New uhso(4) device: Globetrotter HSUPA Modem Option N.V.
On 02/18/2011 01:58 AM, Brandon Gooch wrote: I've recently got my hands on an Option N.V. Globetrotter HSUPA Modem, rev 2.00/0.00, addr 2. [...] Also, I tried doing something like this (as per the uhso(4) man page): brandon@x300:~$ sudo cu -l /dev/cuaU2 Connected uhso2: failed to set ctrl line state to 0x01: USB_ERR_TIMEOUT uhso2: failed to set ctrl line state to 0x03: USB_ERR_TIMEOUT ޭ���T+CGDCONT=1,, OK uhso1: failed to set ctrl line state to 0x01: USB_ERR_TIMEOUT uhso1: failed to set ctrl line state to 0x03: USB_ERR_TIMEOUT _OWANCALL: 1, 1 aޭ��aޭ��Aޭ��Aޭ��Aޭ��Aޭ��Aޭ��Aޭ�ޭ��Aޭ�ޭ�� That's where I'm stuck. -Brandon Hmm. Not sure whats going on here. Could you try the other serial ports (except the diagnostic one) with cu or minicom and see if you get the same result with those? Fredrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: New uhso(4) device: Globetrotter HSUPA Modem Option N.V.
On 02/21/2011 07:28 PM, Brandon Gooch wrote: On Mon, Feb 21, 2011 at 11:30 AM, Fredrik Lindberg wrote: On 02/18/2011 01:58 AM, Brandon Gooch wrote: I've recently got my hands on an Option N.V. Globetrotter HSUPA Modem, rev 2.00/0.00, addr 2. [...] Also, I tried doing something like this (as per the uhso(4) man page): brandon@x300:~$ sudo cu -l /dev/cuaU2 Connected uhso2: failed to set ctrl line state to 0x01: USB_ERR_TIMEOUT uhso2: failed to set ctrl line state to 0x03: USB_ERR_TIMEOUT ޭ���T+CGDCONT=1,, OK uhso1: failed to set ctrl line state to 0x01: USB_ERR_TIMEOUT uhso1: failed to set ctrl line state to 0x03: USB_ERR_TIMEOUT _OWANCALL: 1, 1 aޭ��aޭ��Aޭ��Aޭ��Aޭ��Aޭ��Aޭ��Aޭ�ޭ��Aޭ�ޭ�� That's where I'm stuck. Hmm. Not sure whats going on here. Could you try the other serial ports (except the diagnostic one) with cu or minicom and see if you get the same result with those? I did, but seemed to get no response at all from the others, or couldn't connect. I sent an updated message with debugging turned on, not sure if you got it, I can re-send if needed. Thanks for helping out with this, the device in question is the model we are now getting here at the university for our AT&T mobile broadband accounts. I may be able to try out a recent Ubuntu or Fedora to see what's happening there, but it could be a couple of days... Yeah, I got that message. Not connecting and not getting an serial console is a bit different. From the output above it looks like random garbage on the serial port. Try connecting to all different serial ports (without uhsoctl running) with minicom or cu and try typing AT. (The diagnostic port doesn't work, so skip that one). Fredrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: sierra wireless compass 597 aircard (Was: Documentation)
Marcin Cieslak wrote: It maybe a good idea to add 0xFFF to the usbdevs. Does the "umass" driver attach to the 0xFFF device? I would recommend adding this as a quirk to umass.c then. There are patches attached (ubsa.c_patch, umass_c.patch, usbdevs.patch) I am using to kill the "zeroconf" CD on the UMTS. They do not always work - i.e. umass_attach does not wait until the device is really detached. But setting USB_DEBUG helps :-) Since your patches deals with Option cards I'll just let you know that all(?) Option based devices can be switched perfectly safe from user land, without patching ubsa, using camcontrol. The command to switch Option devices is a SCSI REZERO command. This should be enough to switch the device, given that pass0 is the modem (use camcontrol devlist) camcontrol cmd pass0 -c “01 00 00 00 00 00″ -i 1 i1 camcontrol might give you an error but the device will be switched. Note that this is ONLY for Option based devices, I don't know about the Sierra ones but the linux usb_modeswitch tool might be a good start. Fredrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sierra wireless compass 597 aircard (Was: Documentation)
Steve Clark wrote: Fredrik Lindberg wrote: Marcin Cieslak wrote: It maybe a good idea to add 0xFFF to the usbdevs. Does the "umass" driver attach to the 0xFFF device? I would recommend adding this as a quirk to umass.c then. There are patches attached (ubsa.c_patch, umass_c.patch, usbdevs.patch) I am using to kill the "zeroconf" CD on the UMTS. They do not always work - i.e. umass_attach does not wait until the device is really detached. But setting USB_DEBUG helps :-) Since your patches deals with Option cards I'll just let you know that all(?) Option based devices can be switched perfectly safe from user land, without patching ubsa, using camcontrol. The command to switch Option devices is a SCSI REZERO command. This should be enough to switch the device, given that pass0 is the modem (use camcontrol devlist) camcontrol cmd pass0 -c “01 00 00 00 00 00″ -i 1 i1 camcontrol might give you an error but the device will be switched. Note that this is ONLY for Option based devices, I don't know about the Sierra ones but the linux usb_modeswitch tool might be a good start. Fredrik Hi Fredrik, This does not seem to work for me with the sierra usb device. No, as I said it's for devices from Option (www.option.com). My comment was actually more directed to Marcin since his patches dealt with Option devices. Sorry for the semi thread hijacking. I personally think it's a bad idea to put the code for "switching" these kind of devices inside the kernel. Drivers will become cluttered with switching code for different kinds of devices and it will prevent anybody from actually reading was on the "Zero-CD" device. Besides, I'm quite sure all devices can be switched from user land, one way or another. In my opinion, what's really needed is some sort of generic dynamic black listing which can prevent drivers from attaching to devices. For usb devices one can then simply send the magic switch sequences through a ugen device. The usb_modeswitch tool does exactly that. Fredrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GPS ports in uhso
On 13.01.2014 03:28, Lundberg, Johannes wrote: Hi I've been playing around getting GPS working with my GTM661W and the uhso driver. The ports are defined in uhso.c but in the method uhso_probe_iface_auto the GPS and GPSCTL ports are not in the switch(port) case. Is there a reason for this? The only reason is that I didn't have a modem with a GPS port to test with when I wrote it, so I never added it since I didn't know if anything else was needed to get it working. I tried simply adding like this 823 case UHSO_PORT_TYPE_MODEM: 824 return (UHSO_IFACE_SPEC(UHSO_IF_BULK, 825 UHSO_PORT_SERIAL, port)); 826 case UHSO_PORT_TYPE_MSD: to 823 case UHSO_PORT_TYPE_GPS: 824 case UHSO_PORT_TYPE_GPSCTL: 825 case UHSO_PORT_TYPE_MODEM: 826 return (UHSO_IFACE_SPEC(UHSO_IF_BULK, 827 UHSO_PORT_SERIAL, port)); 828 case UHSO_PORT_TYPE_MSD: Sorry for the manual patch. I can send a patch file later if needed. I don't have an antenna at the moment so I can't confirm that the data is accurate but I'm getting output similar to what I expect in the GPS port and I can control it via the GPSCTL port. If you get GPS data and are able to use the port, then just add it :) Fredrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
