Page 1 of 1
Feature request for 5.0 final.
Posted: Sun Jan 02, 2011 12:00 am
by FIPTech
SNMPSET and SNMPGET : to manage switches ports from Router OS scripts.
TCPDUMP : To allow for faster IP debuging. Torch does not allow to see some important things like DSCP.
Re: Feature request for 5.0 final.
Posted: Sun Jan 02, 2011 12:02 am
by mrz
TCPDUMP : To allow for faster IP debuging. Torch does not allow to see some important things like DSCP.
Packet Sniffer
Re: Feature request for 5.0 final.
Posted: Sun Jan 02, 2011 2:01 pm
by FIPTech
The main problem with Packet Sniffer is that it is not realtime. You need to stop it to get the result. If you watch for a problem, most often you don't know when it will happen. So basically, non realtime sniffers are most of the time useless.
Sending a stream through TZSP encapsulation to Wireshark is an option but not always possible because it does take bandwith. Most of the time using TZSP is complicated.
Another better option would be to be able to connect Wireshark through remote connection to Router OS. But this would need to implement WinPcap deamon inside Router OS.
The advantage of this is that you can define what you want to dump directly from Wireshark. All interfaces are available.
But the simplest and more efficient is certainly TCPDUMP.
Re: Feature request for 5.0 final.
Posted: Sun Jan 02, 2011 11:38 pm
by dolphinik1
CoA/PoD for PPTP/PPPOE/L2TP/OVPN/SSTP/HotSpot
Re: Feature request for 5.0 final.
Posted: Mon Jan 03, 2011 3:14 am
by sw0rdf1sh
I would like to see the ability to get the value of total connections to a hotspot , total unique users to a hotspot (probably checking different mac addresses) and total tx/rx bytes in hotspot since the beggining without reset of this value if the router reboots.
Something like a stats menu in winbox that stores the values.Or maybe embed this feature in graphing.
Is this possible?
Re: Feature request for 5.0 final.
Posted: Mon Jan 03, 2011 3:59 am
by fewi
I don't know if it would help as a workaround, but I run a script on my Hotspot routers that every five minutes logs the number of users per Hotspot. The router is set up for remote syslog. On the syslog server I use syslog-ng, which finds those specific syslog messages and writes them to a named pipe. A Perl script runs as a daemon and listens on that named pipe, parses the incoming messages, and uses rrdtool to graph them. Finally, a web interface (PHP) allows users to query usage based on a date range and the target router.
I can't just post all of that because it's part of a larger system that contains stuff my employer wouldn't want shared, but I could post more details and some code if it would be useful to you. The whole thing wasn't particularly hard to do, a colleague and I put everything together in less than a day.
It could easily be adjusted to also log rx/tx, and probably connections per Hotspot, though I am not sure what you mean by that. Any value that can be derived via router scripts can be sent to the outside world and recorded and displayed somehow.
Re: Feature request for 5.0 final.
Posted: Mon Jan 03, 2011 2:20 pm
by sw0rdf1sh
I don't know if it would help as a workaround, but I run a script on my Hotspot routers that every five minutes logs the number of users per Hotspot. The router is set up for remote syslog. On the syslog server I use syslog-ng, which finds those specific syslog messages and writes them to a named pipe. A Perl script runs as a daemon and listens on that named pipe, parses the incoming messages, and uses rrdtool to graph them. Finally, a web interface (PHP) allows users to query usage based on a date range and the target router.
I use similar workaround for now.The problem is that I have a website in shared hosting and can't use cacti or rrdtool.They instructed me to use perl for using rrdtool but I have no idea how to do that.If you can find a guide and send me a link on how to use rrdtool in a shared hosting environment (I have cpanel/whm access) I'd appriciate that.
Right now I am using fetch tool as described in the link below sending in a mysql database the active users in the hotspot.
I can't just post all of that because it's part of a larger system that contains stuff my employer wouldn't want shared, but I could post more details and some code if it would be useful to you. The whole thing wasn't particularly hard to do, a colleague and I put everything together in less than a day.
Thank you for everything.I might start a new topic about that (as this topic refers to other things) or see the link at the end of my post.
It could easily be adjusted to also log rx/tx, and probably connections per Hotspot, though I am not sure what you mean by that.
I just want to display in my webpage something like:
xxxx number of users transfered xxxxx mb of data from the beggining.
If I could get these values I could use the script below and use fetch tool calling for a php file every 5min,storing the values to a database and use php to display to website like fosben did.
Any value that can be derived via router scripts can be sent to the outside world and recorded and displayed somehow.
True.I would like to retrieve with scripting the values Tx/Rx Bytes in the last tab called "traffic" in winbox for the interface wlan1.Can you tell me how to get these values? (winbox 4.13 gets these values as a table in console so I can't send them with fetch tool-Stats command for an interface)
I have posted the workaround I am using here (Originaly fosben's script):
http://forum.mikrotik.com/viewtopic.php?f=9&t=28002
Anyway I thought it would be easier for us all (you and me) asking for this feature rather than asking for php,rrdtool,perl and other programming help.After all many people use mikrotik for free hotspots and the only thing that matters is if the router is online, statistics and health of the system.I think.(Please correct me if I'm wrong)
Also see this post I did:
http://forum.mikrotik.com/viewtopic.php?f=9&t=47647
Re: Feature request for 5.0 final.
Posted: Mon Jan 03, 2011 3:22 pm
by gustkiller
Support ECMP routes with MPLS/LDP:
In current state, a network with a lot of ecmp routes via ospf ( with multiple links) when LDP is enabled, only one of the multiple routes gets a label, so all traffic goes only to one path and doing bonding and another work arrounds like create vpls and bonding then is not an option because of over head as router OS doesnt support l2mtu in X86 routers so only 1500mpls mtu works on our isp. Wit ldp distributing and using multiple labels for the same route, we can overcame that problem.
Support BGP as route source for LDP.
The current ISP BCP ( best common pratices) is that ospf should be used only for infrastructure routes ( loopbacks and /30) and bgp for all other routes ( customer routes) because bgp works better with large routes. the current RouterOs LDP implementation doesnt support bgp as route source to assign mpls labels to the routes. So enable bgp as route source to bind labels , will be a very good option for large networks with more than thousands of customer routes.
Re: Feature request for 5.0 final.
Posted: Mon Jan 03, 2011 7:11 pm
by TKITFrank
Support ECMP routes with MPLS/LDP:
In current state, a network with a lot of ecmp routes via ospf ( with multiple links) when LDP is enabled, only one of the multiple routes gets a label, so all traffic goes only to one path and doing bonding and another work arrounds like create vpls and bonding then is not an option because of over head as router OS doesnt support l2mtu in X86 routers so only 1500mpls mtu works on our isp. Wit ldp distributing and using multiple labels for the same route, we can overcame that problem.
Support BGP as route source for LDP.
The current ISP BCP ( best common pratices) is that ospf should be used only for infrastructure routes ( loopbacks and /30) and bgp for all other routes ( customer routes) because bgp works better with large routes. the current RouterOs LDP implementation doesnt support bgp as route source to assign mpls labels to the routes. So enable bgp as route source to bind labels , will be a very good option for large networks with more than thousands of customer routes.
+1,
It's sad to see the development of the MPLS implementation stop like it has done. Come on MT let's finish it for v5 !! =)
Re: Feature request for 5.0 final.
Posted: Mon Jan 03, 2011 8:56 pm
by FIPTech
Most Router OS functions comes from the opensource world, so they need to wait for updates from other groups like OpenWRT to put them inside Router OS.
You're so funny
THE LATEST REMARK IS NOT POSTED BY ME. I WOULD BE INTERESTED TO KNOW HOW IT IS POSSIBLE TO EDIT MESSAGES FROM SOMEONE ELSE ON THIS FORUM
Re: Feature request for 5.0 final.
Posted: Tue Jan 04, 2011 1:43 am
by karlikus
UDP for OpenVPN
Re: Feature request for 5.0 final.
Posted: Fri Jan 07, 2011 2:46 pm
by erkel
+1 for UDP for OpenVPN.
Please we need this.
Re: Feature request for 5.0 final.
Posted: Sat Jan 08, 2011 4:30 am
by mjoksimovic
"ARP watch" or "Dynamic ARP Inspection" function for RoS strictly needed. ARP spoofing/poisoning is much more frequent phenomenon. ArpON solution is not possible on WAN's connected directly to fiber optic links through media convertor.
We have about 5000 ARP addresses on the list every moment, clearing ARP list doesn't help.
Re: Feature request for 5.0 final.
Posted: Sat Jan 08, 2011 12:49 pm
by FIPTech
ARP / DHCP spoofing control is more a switch function, like 802.1x.
All well known manufacturers have this function in their managed level 2 entry level switches. (just after managed smartswitches).
If you need it on a wan link, then put a fiber module in the switch, and define a VLAN for it so that you can send it to the router. You will avoid to buy an external media converter.
More you put inside the software router, more you will get lost packets. Except if you have high end XXXXXX $ routers, with hardware ASIC / FPGA acceleration for everything.
Re: Feature request for 5.0 final.
Posted: Mon Jan 10, 2011 1:04 am
by mjoksimovic
ARP / DHCP spoofing control is more a switch function, like 802.1x.
All well known manufacturers have this function in their managed level 2 entry level switches. (just after managed smartswitches).
If you need it on a wan link, then put a fiber module in the switch, and define a VLAN for it so that you can send it to the router. You will avoid to buy an external media converter.
More you put inside the software router, more you will get lost packets. Except if you have high end XXXXXX $ routers, with hardware ASIC / FPGA acceleration for everything.
Tried with this configuration but with no success, ARP list are going to be filled out to the maximum of 8192 entries so I decided to configure complete firewall-ing under Open BSD and to run ArpON on it also just between media convertor and MikroTik.
P.S. Let's not to go to off-topic. Thanks for giving advice.
Re: Feature request for 5.0 final.
Posted: Sun Jan 23, 2011 9:34 am
by Okivash
UDP support for OpenVPN !!! desperately need this to work for a new project we'd like to build.
Re: Feature request for 5.0 final.
Posted: Tue Feb 01, 2011 10:45 am
by omidkosari
Re: Feature request for 5.0 final.
Posted: Tue Feb 01, 2011 11:59 am
by FIPTech
UDP support for OpenVPN !!! desperately need this to work for a new project we'd like to build.
Perhaps Mikrotik do not want to implemented this because they think that UDP is not reliable and they could have problems like with MAC Winbox access.
But OpenVPN is reliable with UDP even if there are lost packets, because each packet is validated before passing in the engine.
If there are corrupted packets, they are simply dropped.
In the end, OpenVPN is almost transparent for tuneled data, it just add checks, dropping corrupted packets.
So i don't see any reason why it would not be implemented, except perhaps if Mikrotik needs to work on assembler code (there is assembler code inside OpenVPN needing porting for each different processor).
Re: Feature request for 5.0 final.
Posted: Tue Feb 01, 2011 12:12 pm
by normis
No, it's certainly not the reason. I have previously already explained that there were many unfixed problems in the OpenVPN itself, so we have stopped development, and concentrated on more reliable projects like SSTP. We don't plan to make UDP support in OpenVPN in near future.
Re: Feature request for 5.0 final.
Posted: Wed Feb 02, 2011 10:33 am
by nz_monkey
Why use OpenVPN when there are much better options like PPTP, SSTP, L2TP ?
I would suggest IPSEC too but Mikrotik are still missing VTI support...
Re: Feature request for 5.0 final.
Posted: Wed Feb 02, 2011 10:50 am
by FIPTech
No, it's certainly not the reason. I have previously already explained that there were many unfixed problems in the OpenVPN itself, so we have stopped development, and concentrated on more reliable projects like SSTP. We don't plan to make UDP support in OpenVPN in near future.
Wich problems ?
Is there hardware acceleration available on MT products with SSTP ?
PPTP is the only one who is able to bridge (with BCP). L2TP should be extended to L2TPv3.
Re: Feature request for 5.0 final.
Posted: Wed Feb 02, 2011 10:51 am
by normis
Re: Feature request for 5.0 final.
Posted: Wed Feb 02, 2011 11:12 am
by Beccara
Digging around all your post's on it are it's buggy (in which case why is it perfectly stable in a plain linux setup and used by multinational corp) and you're "developers almost all committed suicide trying to make it work" along with the complaint that "client and server end must match configuration 100%" which is a very WTF comment to make, I dont expect things to work unless both ends are 100% config matched!
SSTP is a Microsoft spec that claims to be open but in reality nonone outside of Microsoft is going to touch it with a 10ft barge pole for fear of a submarine patent and is unlikely to gain widespread adaption, It has no UDP option which run's into issues, OpenVPN is better since it's standards based and has backing from both Cisco and Juniper, It's used by VMware and Nokia.
So far you haven't given a single valid reason why you wont be furthering development on OpenVPN in ROS, If companies much bigger than MT can use it internally and integrate it their products then why are you're dev's "almost comming suicide"??
Re: Feature request for 5.0 final.
Posted: Wed Feb 02, 2011 11:18 am
by THG
Why use OpenVPN when there are much better options like PPTP, SSTP, L2TP ?
SSTP is only for remote client access, it does not support site-to-site VPN tunnels.
Re: Feature request for 5.0 final.
Posted: Wed Feb 02, 2011 11:30 am
by normis
client and server end must match configuration 100%" which is a very WTF comment to make
by this I meant that if you have lots of clients, and decide to change the encryption settings on the server, all clients will stop working unless you change the setting in the clients, one by one, by hand.
why is L2TP not good for you? It's UDP
Re: Feature request for 5.0 final.
Posted: Wed Feb 02, 2011 11:55 am
by Beccara
Personally I call that a feature :P but it's nothing a login script wouldn't fix for mass deployment. L2TP has it's place but OpenVPN is flexible in the ways it can be used. I haven't touched it in a good 9 months now but It's got alot of backing behind it from a number of big players, It seems silly for MT to stop work on it for reasons that basically boil down to "It's too hard for us"
Re: Feature request for 5.0 final.
Posted: Wed Feb 02, 2011 1:35 pm
by FIPTech
SSTP seems only used by Microsoft and is a very young technology. Not supported by Windows XP.
In the real world, Windows XP is still very present and this will not change soon.
L2TP neither SSTP do allow bridging ??
L2TPv3 do allow bridging but not supported by router OS.
Neither PPTP, L2TP or other PPP based tunnels do have very strong encryption. Only MPPE128. This is not recommanded to use them for secret informations like card paiements.
Re: Feature request for 5.0 final.
Posted: Wed Feb 02, 2011 2:06 pm
by mrz
Re: Feature request for 5.0 final.
Posted: Wed Feb 02, 2011 3:06 pm
by normis
L2TP neither SSTP do allow bridging ??
Not true. We support BCP on PPP for a very long time. There is an EoIP option
as well.
L2TPv3 do allow bridging but not supported by router OS.
This will be implemented, but known when.
Neither PPTP, L2TP or other PPP based tunnels do have very strong encryption. Only MPPE128. This is not recommanded to use them for secret informations like card paiements.
That's why people use L2TP with IPsec.
Re: Feature request for 5.0 final.
Posted: Wed Feb 02, 2011 7:40 pm
by Sob
That's why people use L2TP with IPsec.
And they
fail miserably when they try to use ROS as server for clients behind NAT. But to be fair, it's probably fixed in ROS >= 5.0rc2 (I didn't do full testing yet).
Re: Feature request for 5.0 final.
Posted: Thu Feb 03, 2011 1:40 am
by mikroguf
Unfortunately, 5.0rc2 didn't completely solve all IPSec-behind-NAT issues. See
http://forum.mikrotik.com/viewtopic.php?f=1&t=47207
Re: Feature request for 5.0 final.
Posted: Fri Feb 04, 2011 7:14 pm
by THG
This page looks empty.
Re: Feature request for 5.0 final.
Posted: Fri Feb 04, 2011 7:38 pm
by mrz
Re: Feature request for 5.0 final.
Posted: Fri Feb 04, 2011 10:43 pm
by nz_monkey
Mikrotik needs to add Virtual Tunnel Interfaces (VTI) and Next Hop Tunnel Binding(NHTB) to their IPSEC implementation:
"IP security (IPsec) virtual tunnel interfaces (VTIs) provide a routable interface type for terminating IPsec tunnels and an easy way to define protection between sites to form an overlay network. IPsec VTIs simplify configuration of IPsec for protection of remote links, support multicast, and simplify network management and load balancing."
"JUNOS supports multipoint secure tunnel interfaces with the Next-hop Tunnel Binding (NHTB) feature. This allows a device to bind multiple IPSec SAs to a single secure tunnel interface. you can bind multiple IPSec VPN tunnels to a single st0 interface unit.
To link a specific destination to a specific IPSec tunnel bound to the same st0 interface, the J Series or SRX Series device uses two tables: the inet.0 route table and the next-hop tunnel binding (NHTB) table."
If these existed, we could sell significantly more Mikrotik hardware as it would allow us to run dynamic routing protocols across IPSEC easily, scale our IPSEC WAN's easily, and allow better vendor inter-op with Cisco, Juniper and Fortinet.
Re: Feature request for 5.0 final.
Posted: Sat Feb 05, 2011 1:33 am
by FIPTech
Why not use GRE instead ?
VTI seems only to give 4 bytes less than GRE headers, but it is proprietary ?
Re: Feature request for 5.0 final.
Posted: Sat Feb 05, 2011 4:56 am
by nz_monkey
Hi FIPTech,
Configuring GRE to run over the top of IPSEC is a PITA, and from my experience is never as reliable as VTI's
VTI is not proprietary, it is just the most common name for it. Juniper call it "Secure Tunnel Interface", Fortinet call it "Interface mode IPSEC". They are all the same thing, and are all compatible with each other.
It's best thought of as an IPSEC Virtual Interface, you can assign an IP to it, and static route. Or you can assign an IP and dynamically route.
It is very flexible, and you can even use it if only one end supports it, this is done by not assigning an IP to the VTI, and adding a destination route to the interface. The remote end just needs the relevant proxy-id's in the policy and it will work (although using this hack configuration you obviously cannot use OSPF or other dynamic protocols)
An example of using VTI/NHTB is the following:
Site 1, IPSEC peer to site 2,3, VTI on peers set to be tunnel.1, tunnel.1 configured a 10.99.1.1/24, OSPF configured on tunnel.1
Site 2, IPSEC peer to site 1,3, VTI on peers set to be tunnel.1, tunnel.1 configured as 10.99.1.2/24 , OSPF configured on tunnel.1
Site 3, IPSEC peer to site 1,2, VTI on peers set to be tunnel.1, tunnel.1 configured at 10.99.1.3/24, OSPF configured on tunnel.1
So, basically you only have to create 1 tunnel interface on each router, and then bind the IPSEC peers to this, NHTB sends broadcast traffic to all peers, and unicast traffic to the correct peer. This allows OSPF to work in broadcast mode, but traffic to pass via the most efficient path.
Using these technologies, it is easy to create fully meshed IPSEC configurations, which is very useful for VoIP traffic as it then does not have to pass up to the IPSEC hub then back down to the spoke.
You could also obviously have a different tunnel interface bound to each ipsec peer, but you would have to configure an IP on each tunnel interface and this could become tedious if you had a whole bunch of sites.
Re: Feature request for 5.0 final.
Posted: Sat Feb 05, 2011 1:23 pm
by FIPTech
VTI seems unsupported in the Linux world. I don't remember i've seen this in the OpenSwan documentation.
Something that is supported inside Openswan is opportunistic encryption, with it you can share keys on a DNS server, so that each peer can connect to another one looking for the public keys on the DNS server.
It seems that since a couple years, Linux does not get the new functions it should have for Ethernet / IP / IPv6 access networks.
This limit the use of Linux routers for SMB market and very small providers use.
Instead of seing Linux developping network functions, we see Ubuntu and similar GUI distributions rising the kernel size for Desktop computing use. Something that Linux is not good at all : 90 % of the market is Windows.
This is a terrible situation, for example all the 802.1ah and 802.1Qay stuff (Provider Backbone Bridge and Provider Backbone transport) is not implemented yet inside Linux. This stuff would be very beneficial for small providers.
This situation should change, but unfortunately it is certainly very profitable to big names companies in the routing world, so almost every major actor in the industry will continue to support the developement of Ubuntu like distributions to keep Linux far from the high $ professional routing markets.
Perhaps Mikrotik and similar router distributions like Pfsense and Vyatta could start together a new Linux project, with specific routing kernel extensions.
The main goal would be to keep compatibility with the normal Linux kernel, for drivers and applications support, but adding routing and protocols extensions for example as kernel modules.
One thing is sure : Linux is more and more missing important network functions supported by usual big names companies in the routing world.
Re: Feature request for 5.0 final.
Posted: Sun Feb 06, 2011 10:04 am
by nz_monkey
FIPTech, a lot of commercial vendors base their Network Operating Systems on Linux, they just develop closed source modules and user-space applications to add the required functionality and make them unique.
Extreme Networks XOS, Allied Telesis's AlliedWare Plus, Cisco's NX-OS, Fortinet's FortiOS, Palo Alto Networks PAN-OS, are all Linux based, and to get the required performance all use hardware based acceleration.
You are right that there is no open-source VTI implementation, but there is plenty of documentation on how VTI/STI works, Juniper even have a detailed whitepaper. Mikrotik could if they had time develop this feature. Or they could do what they have with their dynamic routing, proxy and MPLS implementations and write their own.. IPSEC is the industry standard for site-to-site VPN's, and with it's inclusion as part of the IPv6 specification is not going to disappear any time in the near future, in fact I would bet it will be around long after SSTP and OpenVPN are forgotten.
If it is a question of profitability for Mikrotik, I would be happy to pay a premium for a L7 "Enterprise feature set" licence that included features like IPSEC with VTI/NHTB and stateful High Availability.
Re: Feature request for 5.0 final.
Posted: Sun Feb 06, 2011 12:07 pm
by bda
CoA/PoD for PPTP/PPPOE/L2TP/OVPN/SSTP/HotSpot
Yes! But mostly for PPPoE/PPTP.
Re: Feature request for 5.0 final.
Posted: Sun Feb 06, 2011 7:47 pm
by FIPTech
FIPTech, a lot of commercial vendors base their Network Operating Systems on Linux, they just develop closed source modules and user-space applications to add the required functionality and make them unique.
...........
If it is a question of profitability for Mikrotik, I would be happy to pay a premium for a L7 "Enterprise feature set" licence that included features like IPSEC with VTI/NHTB and stateful High Availability.
Even if you could pay for this (like me and others) i doubt Mikrotik can find the developpment time to do advanced things like this in a raisonnable amount of time.
That's why i say that those smaller companies and some opensource groups should collapse to design new kernel routing extensions to Linux, instead of reinventing the wheel each one in front of their own desks.
For example Provider Backbone Bridge, PPB-TE and GMPLS compatibility is a big work. Can't be done by a single entity.
Smaller clients do needs those functions in a raisonnable delay after they have been implemented by big companies, so that they can stay in the competition.
If you need to wait 5 or 10 years to get those functions and you can't pay for $$$$$ or €€€€€ routers, then you can't catch opening markets.
I think there is a market for harware accelerated routers, 1 to 10 times the power of a RB1100 (and 1 to 10 times the price), with support for PBB, PBB-TE and other missing functions often discussed in this forum.
X86 multi core is not the solution. This is power hungry, expensive, often unreliable because of untested hardware and drivers.
The solution is mixed MIPS (or other risc arhitecture processors) combined with FPGA based logic processing hardware, so that L3 packet processing is done by accelerated circuits at wire speed.
RB2000 to RB10000 products with a level 7 licence could be very interesting products, for small to small-medium Internet and networks providers.
Extracting C++ Linux kernel code to recode it inside VHDL logic code for FPGA use is not a simple task.This kind of mixed programming is often done inside products of very big companies like HP, Sony, Cisco, EXFO to give only a few of them... But the amount of knowledge and developement time is certainly difficult to support for smaller sized companies, but not impossible...
The advantages of hardware logic acceleration is :
- lower production cost
- lower power consumption
- garanteed wire speed capabilities with lower clock speeds than serial processing
The main disadvantage is the cost of development, spliting Linux code and proprietary extensions to mixed VHDL programming.
Mikrotik know how to program FPGA circuits. I've seen they are using small ones in their RB products. It would be fine if they could use them for routing acceleration so that their high end products could be considered carrier class.
Yes i said carrier class. Because even if you are a small or very small provider, or even selling routers to final clients, you can't loose packets or add excessive amount of jitter or gaps in the streams.
This is because today VoIP and Video is more and more transported on IP or MPLS networks where latency and packet delivery is not garanteed - because of the asynchronous nature of Ethernet, and because of the large used packet size.
So the only way to have good quality on non SDH / ATM based networks is to use carrier class Ethernet routers, as soon as you are pushing more than a few 10 Mbps or 100 Mbps of trafic.
Perhaps i'm wrong, but i feel that Mikrotik has the required smartness to manufacture very nice small carier class products if they can find the necessary help from other groups / manufacturers, or perhaps from their bank :=)
The new RouterBoard SXT with NV2 support seems to prouve this. Very smart product.
Re: Feature request for 5.0 final.
Posted: Mon Feb 21, 2011 8:58 pm
by nhickman
Please update the Sierra Wireless kernel drivers to support the AT&T Shockwave USB modem. These are the only modems that AT&T is currently handing out so being able to support them ASAP would be nice.
link to drivers
Without the updated sierra.c, the Shockwave (AT&T's 308 model) will not enumerate ttyUSB devices with the serial driver. The sierra_net.c additionally allows the wwan0 direct IP interface, but to connect you still need access to ttyUSB2. Throughput is the same using pppd or the direct IP interface.
Once the drivers are updated you can connect through pppd with
these scripts. Modify gsm_chat to use ttyUSB2 instead of ttyUSB0 then dial using 'pppd call gsm'.
Or connect with wwan0 ip interface like so:
Tell modem to connect:
ubuntu@ubuntu:/home/ubuntu# sudo screen /dev/ttyUSB2 115200
AT+CGDCONT=1,"IP","ISP.CINGULAR"
OK
AT!SCACT=1,1
OK
AT!SCACT=0,1 closes the connection.
Then bring up interface
ubuntu@ubuntu:/home/ubuntu# sudo ipconfig wwan0 up
ubuntu@ubuntu:/home/ubuntu# sudo dhclient wwan0
Listening on LPF/wwan0/46:40:97:23:03:07
Sending on LPF/wwan0/46:40:97:23:03:07
Sending on Socket/fallback
DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 3
DHCPOFFER of 166.217.196.242 from 255.255.255.255
DHCPREQUEST of 166.217.196.242 on wwan0 to 255.255.255.255 port 67
DHCPACK of 166.217.196.242 from 255.255.255.255
bound to 166.217.196.242 -- renewal in 849179012 seconds.
Either way you want to handle the connection would be fine. Just exclude the sierra_net driver to not use wwan0 and we could just stick to using the current ppp way of doing things.