Huawei E173s

USB_ModeSwitch • View topic - Huawei E3231 - new model

Command to make it appears as /dev/ttyUSB0


So according to that comment we should consider this (and probably also the 2 endpoint variants) as "vendor-specific modem interfaces". I wonder if you get any ttyUSBx port responding to AT commands if you do:

Code:

modprobe option
echo 12d1 1c05  >/sys/bus/usb-serial/drivers/option1/new_id

Some minicom commands that can help you changing the settings of the modem

minicom -s (configure, change here the option "Serial port setup" -> "A -    Serial Device      :" to /dev/ttyUSB0

exit

type in your commands
example: AT^U2DIAG?

example2: AT^U2DIAG=276

Commands supported

Huawei AT-commands

note: Some devices like the Huawei K3715 seem to require AT-commands to be typed in capital letters!

There are a couple of options for disabling and re-enabling the following USB-components of Huawei USB-modems:

• modem (M)
• NAND-flashmemory drive (CD)
• microSD-drive (SD)
• PC UI interface (UI)
• network adaptor (N)
• smartcard (SC)

To disable or re-enable those components run the following AT-command, where n is one of the numbers from the table below:

AT^U2DIAG=n

On some models it is possible to read the present value of the parameter n by sending command:
AT^U2DIAG?

n	M	CD	SD	UI	N	SC	remarks	supported by	not supported by
0	+			+				E160, E1750
1	+	+
3	+			+		+	won't work on devices without SC*
5		+		+	+		won't work on devices without N*
9		+			+	+	won't work on devices without N & SC*
10	+	+				+	won't work on devices without SC*
12		+		+	+		won't work on devices without N*
255	+	+	+	+	?	?	reset to factory defaults	E160, E160E, K3565, K3715	E176, E1762, E1750, E173
256	+		+	+			for most devices: everything enabled except the flashmemory; microSD-drive will be available under Windows even without drivers installed	E160, E160E, E173, E1750, E1762, K3565, K3715	E176
257	+	+	+
259	+		+	+		+	won't work on devices without SC*	E173u-2, E176
261		+	+		+	+	won't work on devices without N & SC*
265		+	+		+	+	won't work on devices without N & SC*
266	+	+	+			+	won't work on devices without SC*
267		+	+		+		won't work on devices without N*
268	+	+	+	+			won't work on devices without N*	E1750, K3565, E173
276	+	+	+	+	+	?	reset to factory defaults	E1762, K3565, K3765, E173, E1750

*) note: Smartcard (SC) and network adaptor (N) are not present in many Huawei devices. Using an AT-command that activates SC or N on a device without these components, will result in errors and so will be noneffective.


Modems supporting AT^U2DIAG? command: E173, E1750 ,E160E Modems not supporting AT^U2DIAG? command: E160, K3565

Also on some models it is possible to display a list of devices present in a USB-stick, by sending a command:
AT^GETPORTMODE

alex's coding playground » USB Image Tool

alex's coding playground » USB Image Tool

USB Image Tool


Overview

USB Image Tool can create images of USB flash drives and MP3 players, that are mounted as USB drives. It allows you switch between images with different music styles on your MP3 Player or to make an exact backup image of your USB Stick.

Features
create image files of USB flash drives
restore images of USB flash drives
compressed image file format
show USB device information
manage favorite USB images
command line utility

ISO Image to usb

Why can't I access forwarded ports on my WAN IP from my LAN/OPTx networks? - PFSenseDocs

Why can't I access forwarded ports on my WAN IP from my LAN/OPTx networks? - PFSenseDocs

y default, pfSense does not allow LAN/OPTx connected PCs to reach forwarded ports on the WAN interface. This is a technical limitation of how the underlying PF functions, it cannot "reflect" in and out the same Interface; it only works when passing "through" the router. NAT Reflection employs some simple bouncing daemons to redirect the connections, which works but isn't always desirable, or even functional for some scenarios. Usually, split DNS is the better way if it is possible on your network. Both are explained here.

Method 1: NAT Reflection

In order to access ports forwarded on your WAN interface from internal networks, you need to enable NAT reflection.

In order to do this, you must go to System > Advanced, and from there uncheck "Disable NAT Reflection". Click save, and it should work. This will only work with single port forwards or ranges of less than 500 ports. If you're using 1:1 NAT, you can only use NAT Reflection with version 2.0 and newer.

Example of system with NAT Reflection enabled. (Disable choice is unchecked).

Method 2: Split DNS

The more elegant solution to this problem involves using Split DNS. Basically this means that internal and external clients resolve your hostnames differently.

Your internal clients would access your resources by hostname, not IP, and clients on your local network would resolve that hostname to your LAN IP, and not the WAN IP as others outside your network would see.

In order for this to work using the DNS forwarder in pfSense, your clients will need to have the IP Address of the pfSense router as their primary DNS server.

Example:

• www.example.com resolves to public IP 1.2.3.4, which is your WAN IP
• You forward port 80 on 1.2.3.4 to port 80 on 192.168.1.5
• You override www.example.com using System > DNS Forwarder and point www.example.com to 192.168.1.5
  • You could also override this with some other internal DNS mechanism.

Some screenshots that show the above in practice:

Split DNS Example, adding DNS Override

Split DNS Example, what your screen should look like with www.example.com overridden as 192.168.1.5

Method 3: Experimental Routing Tricks

This should be considered experimental, and could possibly cause bad things to happen!

If you're using 1:1 NAT, you can't use NAT Reflection. If you're a service provider (a web host, say), you may not have all relevant DNS entries under your control, so "Method 2: Split DNS" may be difficult to implement.

If you have a CIDR network block allocated to you which is all behind your pfSense firewall, you might be better off using public addresses on your internal network, or using a mix of public and private addresses.

If you have only a portion of your CIDR block behind pfSense, and you're using 1:1 NAT, you may have a difficult situation. Here's a possible approach you can consider. This may not work, or may work in only some situations. Be careful: don't try this if you're remote or don't have console access to your devices.

1. Make the external IP address an alias on your loopback interface (the interface with localhost/127.0.0.1 on it). In FreeBSD, that's something like this on the command line:

ifconfig lo0 inet 1.2.3.4 netmask 255.255.255.255 alias

Used in tags in pfSense, as described here.

2. Cause every other internal host to route traffic destined to your external IP to your internal IP. There may be 3 ways to do this:

a) Add a static route on every other host with something like route add -host 1.2.3.4 10.0.0.4 but you have to run that on every other host. This option can quickly become administratively difficult as the number of internal hosts goes up, but this can be mitigated if you have centralized administration (via something like cfagent, say).

b) Run a routing protocol - routed for example - on your internal network, and publish routes reflecting the external/internal 1:1 NAT mapping. This might be the most complicated choice, but might scale better than the other alternatives.

c) This seems to not work, presumably because pfSense already knows a route to the external network: Add static routes on the LAN interface of your pfSense firewall with a destination of the external address (1.2.3.4/32) and a gateway of the internal address (10.0.0.4/32). This alternative worries me a little bit, as I'm afraid it might confuse the firewall - I don't think so, but please be careful.