iBGP eBGP

1. IBGP (hosts in the same AS) does not require
the multihop option. IBGP is multihop by default.
2. Do the IBGP peers have a route(s) to the next hop(s)
learned by the EBGP peer? If they don't, the
IBGP peers will discard the routes from EBGP as invalid.
Based on your description, it sounds like the IBGP
peers don't have routes the next hop.
The next hop is not automatically changed when
advertised to IBGP peers, but it is changed when
advertised to EBGP or confederation peers.
If your IBGP peers don't have a route the next hop
learned by BGP, you will need to do one of the following:
1. Add static routes to the next hop(s) learned from EBGP
on all the IBGP peers
2. Run an internal routing protocol such as OSPF to between
the IBGP peers that advertises the next hop(s) learned from
EBGP
3. Use route maps to change the next hop when advertising
the routes learned from EBGP to the IBGP peers
4. Use a confederation for you IBGP routers. Another benefit
of confederations, is that they don't require full mesh.
Also, if there are multihops between the IBGP peers,
the IBGP peers will need routes to each other through the
intermediate nodes. Routes through intermediate nodes in a
multihop configurations are required for IBGP, EBGP, and
confederations. These routes can either be static or carried
in an internal routing protocol so as OSPF.

Below is a short summary of IBGP and the route reflector concept.
When running IBGP, all neighbors must be fully meshed in order to learn each
other's routes. The fully meshed topology is necessary because of the BGP
Split Horizon rule, which states that a route learned from one IBGP neighbor
will not be advertised to another IBGP neighbor. (The BGP Split Horizon rule
is more strict than the Conventional Split Horizon rule in that it prevents
routing updates from being sent to any other IBGP neighbor and not only to
the originator of the update). Therefore, IBGP updates about connected
networks can only be sent to immediate neighbors; every router in the AS
must have any other router in the same AS as an immediate neighbor, which is
a fully meshed topology. This is why route reflectors come into play. Route
reflectors are capable of ignoring the BGP Split Horizon rule and forward
routing updates from one IBGP neighbor to another IBGP neighbor. Therefore,
when route reflectors are configured, the fully meshed topology among the
route reflector's clients is no longer required. However, the Conventional
Split Horizon rule is still enforced; when a route reflector (router A)
receives an update about a network from route reflector client B, it
forwards it to every route reflector client EXCEPT router A.
Peer groups contain BGP routers that have common update policies. An update
sent to a peer group must be sent to every member. Therefore, if route
reflector clients are members of a peer group, the route reflector must send
an update received from Router A to every route reflector client (every
member of the peer group), INCLUDING router A. As you can see, this behavior
contravenes the Conventional Split Horizon Rule. Therefore, peer groups are
not compatible with route reflectors.

iwconfig configuration

You can configure your NIC's IP settings as if the NIC were a regular Ethernet device. After you use the ifup command the NIC becomes active, but it will not function correctly as its wireless settings haven't been configured yet.

The most commonly used command in Wireless Tools is iwconfig, which you can use to configure most of the wireless parameters, including the SSID and the wireless mode. For the wireless mode, Managed means that there is a wireless access point (WAP) on the network and Ad-hoc signifies that there is none.

For example, if your wireless NIC is named eth0 and your managed network's ESSID is homenet, then the commands would be.

iwconfig eth0 mode Managed
iwconfig eth0 essid homenet

Your NIC should now become fully functional. You will need to run these iwconfig commands each time you use the ifup command, however; forgetting to do so can be problematic. The next section shows how to make these iwconfig changes permanent.

to put the original MAC address back, you need to flash 1D, 1E, 1F (first location) and A5, A6, A7 (second location). The second location will have the opossite order of the hex numbers. Here is an example of MAC address structure and location.

When I got this message it was because I had forgotten to set my TFTP server to use 192.168.3.1 as it's address so it was not seeing the TFTP request coming from the GW2348. I changed the setting and then the reply coming from the GW2348 looked like this:

The message repeats twice since this is when you are actually overwriting the original version of linux installed on the board. They really want you to be sure and it is wise to reread your command line to be sure that you aren't doing something stupid… but forge ahead… The GW2348 will respond:

Programming this block of the flash memory takes quite a while because it is a very large file. You will now do two more similar commands that will execute in exactly the same way but will finish much faster. They are:

Resetting to Factory Defaults
Deliberant products have the capability of being reset to defaults by pinging the device with a certain packet size when the radio is booting.
During the startup of the device, when the drivers of the ethernet interfaces are loaded, the discovery daemon is started. The daemon suspends
startup process for 3 seconds and waits for ICMP "echo request" packet of length 369 bytes. If the packet received, the discovery resets the
device to default configuration.
Steps to reset to default settings:
Step 1. Power off the device.
Step 2. Obtain the device MAC address.
Step 3. Connect a PC to the same physical subnet as the device.
Step 4. Execute 'arp -s' command to assign the IP address (IP address should be from the same subnet as PC) to the device MAC address:
arp -s <IP address to assign> <device MAC address>
Step 5. Start pinging the device:
ping <IP address> -s 369
Step 6. Power up device and wait about 30sec or more (depends from device hardware).

bits & bytes

Regarding rom. The first 4 bytes is a signature, then 4 byte checksum if changed to 0, the information is not checked.
with the displacement of 0x10 repeated 2 times the code device, for example, np27g 0xf6, 0x11, 0x78, 0x0. replacing it
could sews firmware from other devices in this series (while noting the reset counter. amount). 0x50 shift - 4 bytes mean
size of the kernel and that starts with rootfs 0x10100 + 8 bytes (which contain the lenght of kernel + rootfs and presumably
kontrolnyya amount).

If retain Reset button during power, it is possible to fill the firmware on tftp directly via email 192.168.168.1/24 loader.

0x100fc shift - 4 bytes certain checksum modification time taking into account the contents of the archive linux.img
(runtime gzip th with a maximum compression), with the changing values in the field of Linux NE STARTUET although
without passport problems

there is a crc32 of gzipped image (from the 0x10100 to the end) on offset 0x100fc on my wp54ag, setting it and disabling
first crc on 0x4 allows me to boot my modified firmware. I bet it will be same for np27g... I bet it will be same for np27g ...

BTW: do you know how to compute first crc (is it really crc32?) on 0x4, it will be better to have it corectly set instead of
disabled (00000000) BTW: do you know how to compute first crc (is it really crc32?) On 0x4, it will be better to have it
correctly set instead of disabled (00000000)

quick howto

* I managed to quickly brick this device.
* I got the required files from Compex for the jtag recovery.
* I am not sure if they are the correct ones for the hardware I have.
* Don't ask me for the files. Please contact Compex support instead.
* The flash chip is a 4MB labeled MX 64621, 29LV320CBTC-70G
* I used a self build unbuffered jtag cable
* the pinouts for the wp54 device are here
* I had to convert the OCD macro file to a script file for the openwince-jtag ←- (this step is not necessary)

step by step

The .mac init macro for OCD Commander can be made into a script for jtag tools.
You need to change the "word 0x...... = 0x....." commands to "poke 0x... 0x..." commands.

For instance, the command in the .mac file: "word 0xb20000bc = 0x0" would become "poke 0x520000bc 0x0" in a jtag tools script.
The command in the .mac file: "word 0xb20000bc" would become "peek 0xb20000bc"
The 0x5 at the start is in the range of 32-bit memory access which is what you need for writing to the ADM5120 registers.

Following these instructions I was able to get some respond from the bricked box.
These are the steps from inside the jtag program:

The binding didn't change, but bugs were fixed in the parsing code so
that what was common practice (but wrong) in 2.6.23 doesn't work anymore.
Your tsi108 node only provides a ranges translation for its own
registers, but you have a PCI child node with ranges outside of that.
It's a bit awkward, but what we currently tend to do is move the PCI
node out to the root level (make sure to change the reg property to be
the full address rather than the tsi108 offset).

DD-wrt

push the reset button. plugin the power cord. hold the button for 10 seconds
then do tftp -i 192.168.1.20 put RS.dd-wrt.bin
your local computer ip must be staticly configured to 192.168.1.100
thats all

Ubiquity

* There is a performance and stability issue concearning RAM speed and LAN stability with early RouterStation devices. Upgrading to this ubiquiti image resolves these issues. Details of this image:

Known Issues

* Some early RouterStation devices (first two quarters of 2009) have a very poor or non working LAN port attached on the eth1 (the one near to the corner).

* Official support for the RouterStation line of products just froze only a few months after their official release. It looks like as ubiquity used OpenWrt hype as a promotion campaign for their products while never returned any actual support to the open source community.

OpenWrt OZOnet images

OZOnet images are bleeding edge openwrt images trimmed down to minimum for stability and performance. They are targeted just for wifi long range links. All builds are tested on real hardware and production setups. You may find those images here. Details of these images:

brcm47xx

The bridge is created due to lan_ifname being set to br0 .. any time any of the *_ifname variables is a br* the script will create a bridge and parse the corresponding *_ifnames variable.
So, you could do the following:
lan_ifname=vlan0
wan_ifname=vlan1
wifi_ifname=eth1
(assumes a v2 or above)

Bullet M5

J10 serial pins

firmware tftp

just bumped into this. A fairly new Bullet M5 would not respond on the classic 192.168.1.20. Searching the net found the following. Don't get tricked though, your Bullet will not respond to regular pings (icmp). You need to use arping. Best way to figure out the IP of the unit is to put it on tftp ready and use tcpdump on the network cable that connects it to your linux workstation.

My Bullet M5 happened to listen to IP 192.168.1.33. This is only for the tftp state.

Devices manufactured using any v5.0-RC (pre-productionFW) are configured with the following IP in TFTP rescue mode:
192.168.1.30
192.168.1.31
192.168.1.32
192.168.1.33
192.168.1.34
192.168.1.145
These IPs are set in u-boot configuration.
ICMP ping to these IPs are not allowed. Correct IP you can find only uploading firmware through TFTP, when device is in TFTP rescue mode.
Devices manufactured using v5.0 final release and newer firmware versions, will use default IP set to 192.168.1.20.

*** Another silly issue that I recently bumped on is that some times is better to start the tftp transfer before getting the Bullet-M on tftp ready status, otherwise the tftp transfer may fail.

A few issues as of May 2017 with lede/openwrt

1). the on-board ethernet wrongly identifies the network connection as Gbit. I believe the device does not support Gbit, just fast ethernet. Thereof prior to flashing, an off/on is recommended just on the ethernet port @ the poe or switch.

2). After the above procedure, it's recommended to first start the tftp on the server before starting the tftp transfer procedure at the bullet-m.

Further annoying issues as of October 2017

1). to avoid any networking locking issues it's better to connect the device on a fast 100Mbit switch.

2). start the tftp (I use atftp)

3). cold reboot the Bullet-M

4). either hold the reset for 10 seconds and then release it or start the urescue from the U-boot menu on the serial console.

ZTE ZXHN H108NS unlocking howto

It's annoying to have anyone pocking any settings on your network setup. At some point my second adsl started having problems with packet loss on the LAN. It was that bad that I had to switch to a backup standby adsl device that I always keep for such occasions. I never used to worry about my adsl setup as long as it's stable with decent bandwidth, decent low latency and 0% packet loss.

The latest firmware for this box provided by otenet that has changed couple of names and I think lately goes by cosmote is called: H108NSV1.0.7u_ZRD_GR2_A68_20150720

it has a royal disabled web functionality with most menus locked down, telnet/ssh is also disabled and nmap/scan show couple of “unfriendly” ports listening.

Searching the web I bumped on vasvir page, a kind soul that had similar experiences and feelings about this device. His work and documentation helped me greatly in order to extract, modify and create a decent new firmware that unlocks and restores total control to the device. I will document here the steps that I followed in order to do this: