Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

[Moderator note: This thread has been created by merging two separate threads on the same topic.]

I have finally somehow managed to get access to the web admin interface of one of my three DLink PPPoE modems ‘through’ my firebrick router.

I can't exactly remember what I did. I created an additional interface object mapped to one of the ethernet interfaces that goes to one of the modems. Then I created a subnet object associated with it. I set the subnet address range to 192.168.1.0/24 and then I don't remember what else I did so the secret has now been once again lost for the time being.

== Latency and LLC screw-up ===

An interesting thing happened. I noticed that due to my stupid mistake, one of the modems was set to use LLC instead of VC-MUX with PPPoEoA. MTU is 1500 and if you do the arithmetic you see that the total including all headers is 4 bytes over the limit for what will fit into an ATM cell, so a very unfortunate extra 53 bytes transmitted on every full length packet. This has just been discussed in another thread as it so happens, only in the last few days.

Anyway, that mistake means that modem #1 is running 3% slower than it should be. So I fixed it and saved the result.

I noticed ages ago that modem 1 was showing nearly 40% higher latency (ppp lcp ping time) as shown by the AA constant quality monitoring graphs when compared with the other two. So this must be the answer, which had baffled AA staff and me. That modem was working too hard, sending too much data, since on full length packets it always included one junk extra ATM cell compared with correctly set-up modems.

=== Stuffing the Firebrick ===

Anyway returning to the subject of the router. I fiddled about further and somehow managed to lock myself out of the Firebrick altogether. I have no idea what exactly I did to screw things up. I should have used the 'test' function which is designed to prevent exactly this by rolling back the configuration after 5 minutes if you do nothing and in this way it always saves you. I had to beg Mrs Weaver to reset the factory-reset Firebrick for me. Once it has been reset, one of the immediate options presented to you is to load a saved XML config file, which is what I did and recovered things in no time flat.

=== Three modems ===

I am left with the unsolved problem of how to deal with three modems at the same time. This was discussed in an earlier thread iirc. All three modems have web admin interfaces on 192.168.1.1 (I think). I have not seen an option anywhere within the modems’ settings to change this address, so I don't even know if it's possible. If it can't be changed then I would need to get the Firebrick to do NAT-style header rewriting, replacing destination IPs from within one of three defined ranges to 192.168.1.1 and re-routing onto a particular interface based on the original, pre-rewrite destination IP. perhaps it would be necessary to route it to an interface selectively first and then apply address translation after that.

I have absolutely no idea at all if a Firebrick can even do such a thing. Would I just define a subnet for a completely bogus but unique address range and then do something involving turning the NAT facility on for that subnet? Not sure exactly how NAT works, or what the definition of it is on the Firebrick, although of course I am familiar with it in practice as I used to use NAT many years ago with a Netgear router.

But I can't see everything I need to set to control the operation of NAT, unless I am failing to understand. The 'subnet object' has an address range defined for it. I can't see any setting anywhere which corresponds to the src ip address value that is overwritten into the headers when packets emerge from the NATed subnet into the ‘real world’, in the familiar NAT case this would be the CPE's WAN IP address, the address that is visible to all users on the internet and which all LAN hosts hide behind. That value gets put into the NAT translator by some sort of black magic normally. It might come from PPP IPCP iirc. But I can't see any such thing in the Firebrick's config, maybe I have just missed it.

Another thing about NAT. Presumably without ‘port forwarding’ rules inside the NAT translator, you can't access a ‘server’ in the NATed subnet from outside. The conversation, if I am understanding correctly, has to be started off by a ‘client’-like machine inside the NATed subnet which accesses some machine outside, this sets up a translation table entry and a corresponding reverse entry to handle the response. But there is no mechanism for communicating starting from outside the NAT zone because no translation table entries have been set up yet.

So unless I have missed something or failed to understand things, getting monitoring of three modems to work simultaneously is impossible without extra hardware.

[burakkucat]

I really don't know if what I am about to type make sense and is do-able. 

Each of the three modems will have a unique MAC. Surely the Firebrick just requires the information that maps each to modem from the unique MACs?

(I have trouble when attempting to configure my second generation Firebrick (a FB105) to do anything more complex than "simple".    )

[Weaver]

Anyway it explained the long standing mystery of why modem 1 had 50% worse latency figures than the other two modems. It was the 3% extra wasteful traffic involved in sending 33 ATM cells instead of 32 for 1500 byte long IP packets - 1540 bytes ATM payload with LLC instead of 1532 with VC-MUX.

In the wasteful LLC case, I make it 32 bytes of headers in the first cell, then 4 bytes of padding in the penultimate cell and then 40 bytes of padding plus the final 8-byte AAL5 CPCS trailer in the final entirely wasteful cell.

I have asked AA if they would consider sending out the DLink DSL-320B-Z1 modems with the settings set for full efficiency with VC-MUX not with DLink’s cautious factory defaults. If users are still on 20CN, then VC-MUX doesn't work and the modems do not correct iirc. Since BT doesn't support MTU 1500 on 20CN then you will have to be on MTU 1492, and there is no issues as there is no advantage to using VC-MUX because MTU 1492 IP packets will fit into 32 ATM cells even with LLC's 44 byte (with FCS) or 40 byte (no FCS) overhead. 20CN is perhaps the reason why they would not do it. I didn't know about the ‘20CN doesn't work with VC-MUX’ thing at the time, or I had forgotten, when I asked AA to cghange the settings.

Now 20CN may be almost extinct? It would be good if AA would look at the defaults at some future point anyway or at least check what the customer’s line is before sending them out.

AA is also guilty of sending the DLink modems out with bitswap turned off (the stupid default) which I have complained about.

[Weaver]

I am thinking about revisiting the business of accessing the web admin interfaces of my DLink DSL-320B-Z1 modems that are hidden from my main LAN behind my Firebrick FB2700.

I did recently manage to access one of them from the main LAN. I can't remember what I did exactly and I haven't been able to recreate it.

My main LAN lives in the IPv4 range 81.187.x.y/26. Each modem lives at 192.168.1.1 by default on its private ‘LAN’ which is solely confined to the link to one of the Firebrick’s ethernet ports.

To be clear a modem's L2 broadcast domain is just the inside of the one piece of straight wire linking that modem to the Firebrick, and the same is true for each modem. None can see each other nor can they see the main LAN. They are all on separate independent ports that are not configured as part of one switch. The Firebrick is currently not set up to route IP packets to and from those ethernet links. (But it sends IP packets to PPP interfaces obviously, and that means generated PPP frames go to those modems, since that it what internet access is in my case.) The Firebrick ends of the ethernet links have no IP addresses assigned to them.

I got the router to route packets in the 192.168.*.*/16 (or something) range to the link to modem #1, and somehow it all worked in that I could access the modem’s web admin interface via http.

If I can somehow manage to recreate the recipe, the question remains though: how would I map the various identical modems admin interfaces which are all at clashing IP addresses 192.168.1.1 to distinct addresses so that I can access them at the same time? It isn't going to be a workable setup without this.

If I could reconfigure the modems themselves to have a different IP address for their admin interface then that would be problem solved. I had a brief look round but I didn't notice a method of doing so. I think the manual mentions that it can be done though.

[Weaver]

I tried absolutely everything I could think of this morning but didn't get anywhere at all.

[burakkucat]

. . . how would I map the various identical modems admin interfaces which are all at clashing IP addresses 192.168.1.1 to distinct addresses so that I can access them at the same time? It isn't going to be a workable setup without this.

If I could reconfigure the modems themselves to have a different IP address for their admin interface then that would be problem solved. I had a brief look round but I didn't notice a method of doing so. I think the manual mentions that it can be done though.

To me, with no knowledge of a FB2700, that appears to be the key. If the three modems can be configured to use one each of the private 192.168.1.[1-3] IPv4 addresses. 

[Weaver]

I found out how to change the admin IP address of the modem. It was just right there under my nose, but I had overlooked it, thinking it was something to do with a DHCP server function.

So the nasty problem of uniqueness is now solved. But I am not sure how to confirm that the routing table is being set up correctly. I also am not sure about replies from the modem. It may be that the modem is failing to send the responses back because of ARP not working at the modem’s end or forty things. The modem doesn't know about a default gateway either on its own ‘LAN’, that is, on the modem to Firebrick link. When it ARPs for the source address that it gets in an incoming request from my machine, who knows what is going to happen ? I need some logging or wireshark or something on that side.

[burakkucat]

I found out how to change the admin IP address of the modem.

That's good progress. It would have to be either a very dumb modem or a severely locked down, ISP provided, device not to have some means of configuring its own address.

But I am not sure how to confirm that the routing table is being set up correctly. I also am not sure about replies from the modem. It may be that the modem is failing to send the responses back because of ARP not working at the modem’s end or forty things. The modem doesn't know about a default gateway either on its own ‘LAN’, that is, on the modem to Firebrick link. When it ARPs for the source address that it gets in an incoming request from my machine, who knows what is going to happen ?

As that is really FB2700 related, I'm not sure what to suggest.

I need some logging or wireshark or something on that side.

With my FB105, I can configure one port to be for use of the system running wireshark (no normal I/O between the monitoring system and the Firebrick) and mirror any of the other four ports to the "monitoring" port. I would expect the FB2700 to have something similar . . .

[Ixel]

If and when DLM is eventually reset on my first line then I'll most likely swap off the locked down ECI /r back to the DrayTek 2860Vac and Fritz!Box 7490 as 'bridged modems' so I can get statistics on my lines again. When I do this I'll be in a similar situation to you, so unless something has been figured out by that time then I might be able to figure it out (as I also have a Firebrick, although it's an FB2900). I'm currently waiting to hear further news about TTB becoming part of the trial (at least I understand that to be the case). AAISP are on top of it at the moment .

[Weaver]

It's so stupid, because I had it working, with one modem, at 192.168.1.1, and then didn't record the config. I then stuffed the Firebrick config up somehow and lost admin access to it so I had to reset the brick and reload the current config from an up-to-date backup. (Every config version in all of history is version numbered and kept. And diff’ed. Changes are always normally made off the Firebrick, not on it, by editing the XML in your favourite proper editor.)

Things I have tried on the Firebrick:

1. tried to find a display of the routing table - can't find it (equivalent of 'route print').

2. tried a traceroute and ping to the modem admin i/f from the brick itself, as opposed to from my own machine using the brick’s diagnostic tools.

3. checking the route to the modem using the routing function in the brick’s diagnostic tools. That seemed to suggest that the routing was doing the right thing as it mentioned the correct egress interface for talking to the modem. Doesn't help me with the question about ability of the modem to get packets back to me though and its likely luck with ARP.

I can't see anywhere on the modem to set a default gateway for the LAN side of things. Hardly surprising, seeing as they assume that the modem assumes it is itself the default gateway I should think. I can set an IP address for the admin i/f by hand and a netmask.

I had success using 192.168.1.1. But when I tried again it was with a (global, as it happens) 81.187.x.y/26 address in the same range as the current LAN. Realise that that was probably making things worse as I had a subnet within a subnet. But I hoped that longest-prefix-matches would win out and route successfully to a /31 subnet. The brick wouldn't let me specify /32, perhaps /31 is death though? (Because the only addresses are ‘zero’ and ‘broadcast’. As it happens, I had specified an odd address for the modem (.249), so that would be ‘broadcast’, if my brain is working.) The netmask set on the modem was /26, and I couldn't set up the address of the brick itself on that link to be the gateway on that link, as there isn't anywhere to specify it, as I mentioned before.

Perhaps it's just a horrible idea using a real address for the modems as opposed to an rfc1918 address? Any thoughts?

[burakkucat]

Perhaps it's just a horrible idea using a real address for the modems as opposed to an rfc1918 address? Any thoughts?

I think using a real IPv4 address would be a big "no". An RFC1918 address would be a "yes".

Perhaps Ixel could make a few suggestions? (His Firebrick is one generation newer than your one, whereas my Firebrick is two generations older. (And I find its configuration very un-intuitive.))

[vic0239]

Does this help? Subnet added to the FB WAN definition to allow access to the modem over that interface.

Code: [Select]

<interface name="WAN1"
            port="WAN1"
            graph="WAN1"
            ra-client="false"
            comment="WAN interface 1">
  <subnet name="VMG1312-1"
          ip="192.168.2.2/24"
          gateway="192.168.2.1"/>

[Weaver]

Vic, what does the gateway entry do? The manual on the web implies that it sets a default route in the routing table, if I have understood correctly, ie a route to the internet via that ip address.

[Weaver]

SUCCESS

I have managed to recreate what I did. Somehow.

My brain wasn't working properly, it was because of this malfunction that I succeeded. Because I did something that on reflection did not seem to make a lot of sense.

I had already set up a subnet on a new interface attached to WAN ethernet phys port 2, which was being used to talk to modem 1 on PPPoE interface 1. Just as vic shows. But I changed my mind and decided following advice that it was definitely better to go back to having an RFC1918 subnet range for talking to that modem’s admin i/f. So I defined the subnet as 192.168.1.0/24 with ip address for the brick on that link set to 192.168.1.254. The next modem will be in a subnet on another new interface mapped to the next WAN ethernet port, phys 3, and that subnet will be 192.168.2.0/24 and so on with 192.168.3.0/24. And nothing worked.

I revisited the issue that the modem was useless because it knows nothing about gateways on that LAN because it has no gateway setting option, so all IP addresses outside the subnet are either a mystery and it doesn't know what to do with ARP, or those packets mishandled by it. So I assumed that it simply didn't know how to reply even assuming it was getting my packets, or else it was directing the responses who knows where.

The trick it turned out was me trying setting the source IP on packets bound for the modem’s admin i/f by force using a Firebrick ‘firewall’ facility that lets you rewrite IP headers and I simply ordered it to rewrite the source IP address by force to be the address of the brick on that link (chosen to be 192.168.1.254). This is inoffensive, it's in the subnet range, so the modem will not be frightened and its ARPs will succeed.

And it all worked. So now the issue is completely solved. I can just configure the other modems themselves to be on distinct addresses so there is no confusion.

But when I thought about it later I decided that it shouldn't have worked. How were the response packets getting back to my own machine, my iPad? As the brick was rewriting the src IP in the inbound packets to the modems then the responses should just have been sent by the modem to the brick, not to me. Clearly the brick is far too damn clever for that. It must be doing NAT and I never realised it would, because I wasn't thinking straight. It must decide that what you want is the sensible thing, obviously you want response to get back to you, not to go off somewhere else and get lost, so it presumably makes a reverse rewriting NAT rule to redirect responses back to me in a dynamic NAT table of the usual type. So this is address-to-address rewriting and presumably not of quite the type that home users are familiar with where the client machine sees a packet coming in from the internet with the real IP address of the sender, it's only the upstream messages that have rewritten src addresses in them, the client it not made to see the whole of the internet as being inside its own LAN IP range.


 

[Weaver]

Stats, in case anyone is interested. Finally.

Modem 1

Mode:      ADSL2
Type:      ANNEX_A
Status:      Showtime
      
   Downstream   Upstream
Rate (kbps):   2827 kbps   553 kbps
      
SNR Margin (dB):   1.8   6.0
Attenuation (dB):   65.1   42.1
Output Power (dBm):   18.1   12.2
      
Super Frames:   61706   61714
RS Correctable Errors:   5404   332
RS Uncorrectable Errors:   83   0
      
HEC Errors:   51   0
Total Cells:   24980   24506
Data Cells:   24967   24506
Bit Errors:   0   0

Modem 2

Mode:      ADSL2
Type:      ANNEX_A
Status:      Showtime
   
   Downstream   Upstream
Rate (kbps):   2752 kbps   439 kbps
      
SNR Margin (dB):   3.0   5.8
Attenuation (dB):   65.6   42.3
Output Power (dBm):   18.0   12.2
      
Super Frames:   139305   139313
RS Correctable Errors:   271   562
RS Uncorrectable Errors:   0   0
      
HEC Errors:   0   0
Total Cells:   57672   16757
Data Cells:   29093   7732
Bit Errors:   0   0

Modem 3

Mode:      ADSL2
Type:      ANNEX_A
Status:      Showtime
      
   Downstream   Upstream
Rate (kbps):   2838 kbps   496 kbps
      
SNR Margin (dB):   2.5   5.9
Attenuation (dB):   65.6   42.5
Output Power (dBm):   18.1   12.2
      
Super Frames:   71992   72000
RS Correctable Errors:   1999   958
RS Uncorrectable Errors:   1   4
      
HEC Errors:   7   0
Total Cells:   34296   28231
Data Cells:   34296   28231
Bit Errors:   0   0