Is it possible for Hijack to set home/work mode based on whether it's being used in a dock with the fake-AC hack (such as mlord's creations)? I need a different IP address at home to that at work (and no, I can't use DHCP, for various reasons), and I thought that auto-selection would be a neat solution, as I have one of Mark's docks at home and one of my own (with a real power jack) at work.

If you're not using DHCP, can you simply add a second TCP subnet to the network control panel on one of the PCs? (As described here.) Then you wouldn't need to have the player do anything special, it could stay on one fixed IP that was the same for home and work.

I don't have control of either network, so I can't go around adding subnets to the routers.

Also, I'd like to avoid running ntpdate on the home network (or perhaps - one day - run it, but against different servers than I do at work).

No, you're missing the point. You don't need to add anything to the routers or have any control over your work network at all. You merely need to add an entry on your local work PC.

Here's how it works.

Let's say your home network is 192.168.0.xxx with a subnet mask of 255.255.255.0.
Let's say your work network is 10.134.75.xxx with a subnet mask of 255.255.255.0.

You set the player address to be fixed 192.168.0.42 with a subnet mask of 255.255.255.0. It works on your home network.

On your work PC, you go Start/Settings/Control Panel/Network.

It's already got one TCP/IP protocol entry that's set to 10.134.75.yyy with a subnet mask of 255.255.255.0.

You merely need to add another TCP/IP protocol entry that's set to 192.168.0.zzz with a subnet mask of 255.255.255.0. Right there on your PC. Then your PC will correctly talk to the player.

See? The trick is understanding that a subnet is merely an arbitrary address mask and that your PC can talk on any subnets you tell it to, even multiple ones.

You could also do this the other way around if need be. Once you understand the concept, it's really easy.

You're talking about ifconfig on a real computer, right?

That's very well, but what about the other machines on the network? I don't see how I can take a private address I've been assigned for my home network and legitimately use it on our work network. Doesn't it defeat the point of address allocation if people effectively make up addresses? I think I'd be in trouble if I caused a conflict. (Did I ever mention the guy who mistyped an IP address when configuring his new machine, so that it stole traffic for the router and then dropped it all? Not very popular!)

Anyway, my real aim was the one about ntpdate; I thought I was making my question simpler by asking about addresses - now I've learnt a lesson!

I don't see how I can take a private address I've been assigned for my home network and legitimately use it on our work network.

Right, that's the point I'm trying to make. You're under the illusion that the addresses are something special when they're not. You can legitimately do what I'm talking about, and it's no big deal at all and no one will notice and there will be no conflicts. I'll try to explain how it works in my next post...

Okay, here's how subnets work. It's not magic or rocket science, it's real simple.

Let's assume that you have a bunch of PCs all plugged in to a hub, or even a group of hubs and switches.

The PCs have to agree on an addressing scheme.

So you say "10.134.75.1" for the first computer, and "10.134.75.2" for the second computer, etc.

The subnet mask is the key. It says "listen to messages from all addresses with the bitmask of...", and of course you put in a bitmask of 255.255.255.0, which means that the computers all listen to messages from your address binary-ANDed with 255.255.255.0, which works out to: it listens to all addresses starting with 10.134.75.xxx.

There's nothing special about your local lan that says you can't have a thousand different little ad-hoc addressing schemes. The trick is that if you have a different address (say, 10.135.75.xxx), then no one on the 134 subnet can ping or communicate with your computer at all. But if they changed their address to be 135 then they could.

There's no special hardware or anything that says "traffic is only allowed on the 135 subnet. All other subnets are illegal." That's not how it works. You could have tons of traffic on other subnets and (here's the key) your PC merely doesn't bother listening to it. That's what a subnet is for, to filter the traffic. And the filtering is done at the PC, with the settings in the network control panel.

See, most people think of subnets as something physical involving hardware and cables. They're not. Subnets are just arbitrary choices of numbered addresses.

Now, I'm avoiding a discussion of how things like routers and gateways work. Because those don't apply to just "you and an empeg" plugged into the same hub/switch. Since that's what you're doing, we don't need to talk about how a router/gateway scheme allows multiple subnets to communicate with each other. But just know that if you have routers and gateways, they need to be specifically programmed to deal with certain subnets, and if you have a private little subnet you made for yourself, it will be completely ignored by any routers/gateways.

Anyway, back to what I was saying...

When you create another TCP entry in Windows, you're not messing up the network. You're simply saying "Hey, computer. I want you to listen for traffic coming from these addresses, too."

The only way it could be an issue is if someone else had also created an ad-hoc address group that matched yours, and then only if the individual addresses conflicted. And that's highly unlikely. And even if it did, you'd know instantly because you'd get an error message and then you could just pick a different digit.

Is the light beginning to turn on?

You missed a key point -- the 10.x.x.x and the 192.168.x.x addresses are reserved explicitly for this. If you use some other set of numbers, you will be stepping on someones toes, but this won't affect them, it'll only make it so you can't talk to the real computers in that subnet.

So, what Tony's reccomending is to create two networks, one the "real" network, and one that consists of You And Your Empeg only. Both of these networks can live on the same network card(*). As long as you don't specify a gateway for your private network, any traffic for the outside world will go over your network with the usual gateway.

Of course, none of this helps you to run or not run ntp.

Matthew

(*)Assuming you're using a Real OS or a recent Microsoft attempt at one.

Your description is not really very accurate. It's a model that effectively emulates the result, but it's not very representative of what's going on. Especially the "your PC merely doesn't bother listening to it" and "the computers all listen to messages from your address binary-ANDed with [the subnet mask]" parts. Just so you know in case you think that's how it really works.

Oh?

The thing that your computer really filters on is ethernet/MAC address. Every packet destined for your computer is explicitly addressed to your ethernet card (or is a broadcast packet). In a switched environment, this means that, mostly, it never sees any packets that are not for it. But let's say that you're just using simple hubs. The ethernet card will throw away any packets that aren't addressed to the card. (I believe this happens at a firmware level, but I'm not 100% on that.) Any packets that make it through that filter are passed to the IP stack. However, even if a packet was mis-MAC-addressed to your computer and the IP address was in the computer's subnet, the IP stack would throw it away. It's explicitly not listening to the entire subnet. In fact, the receiving end has no concept of subnets.

Where subnets come into play is on the sending end. When you're sending a packet, the first thing the computer needs to figure out is where to send the packet: to a router or "broadcast" on the ethernet segment. When your networking was configured, the system put some entries in a routing table. It put in the fact that your locally configured network is locally attached and that anything other than on that network is to go through a router that you configured. These two routes are the basic ones on any computer. They can be more complex than that, with multiple interfaces or static routes to other networks that don't go through your default router, but the algorithm used is always the same. Compare the destination address of the outgoing packet to the destinations in the routing table, find the one that most closely matches (that is, 10.134.75.0/255.255.255.0 before 10.134.0.0/255.255.0.0, for example) and use its gateway. If it's on a local network, it also needs to figure out the MAC address of the computer it's sending to. This information is kept cached in a table, the ARP table, in the OS. This is handled almost always 100% behind the scenes. When a computer comes up, it usually broadcasts its MAC address on the network with its IP address so that the other computers on the network know the correlation, but if that data has expired from the cache, the sending computer can send out a broadcast request to find an IP address's MAC address. Anyway, it bundles up the IP packet within an ethernet packet and shoots it out onto the segment. When the IP packet is destined for a computer outside its network, it budles up the same IP packet within an ethernet packet with the router's MAC address and shoots it out on the network. The router will receive it and pass it along in a very similar manner based on its routing table. In fact, the end router these days works more along the lines of your "listen to messages from your [subnet]" notion, but only as a result of some added security to prevent spoofing. It used to be that they just listened for absolutely everything and passed it along, regardless of source.

The issue is that there's nothing in the network that has any preconceived notions of network topology until you get to a router. Which just goes to reinforce your initial point even more. Essentially, there are just wires and repeaters. Anything that you send out on the wire will be sent along, even if it doesn't jibe with your netadmin's notions of the network. So if you set up a new IP addresses on systems on the same ethernet segment (which isn't really the right term here), as long as the addresses aren't currently being used globally or locally and both new nodes have netmasks that match well enough, they should be able to talk. There are ways that this might not be the case with some advanced switches, but if the network in question was brought to its knees by a node who took the router's IP address, I'm guessing they're not there.

I hope that's cleared some stuff up, and I hope I haven't made too many mistakes. (Someone jump in if I have.) Also, this is obviously specific to ethernet to some extent, but ethernet and close relatives (that is, mostly CSMA/CD) make up probably 99% of LANs these days, so that shouldn't be a real issue. Besides, I'm not good with token-based LANs anyway.

Oh and a couple of little ancillary things.

One, networks these days are written in the style of (to use examples from above) 10.134.75.0/24 and 10.134.0.0/16 or even 10.134.75/24 and 10.134/16. The number after the slash indicates the number of leading ones in the binary representation of the subnet mask. Subnet masks can be other than /8, /16, and /24, too, if you weren't aware of that.

Two, because of the way I've described them working before, subnet masks between two computers on the same segment can be mismatched and still work as long as both of their addresses are within the subnet of the more restrictive one. That is a computer configured as 10.134.75.4/24 and another as 10.134.75.5/16 can still communicate, but ones configured as 10.134.75.4/24 and 10.134.64.5/16 cannot. In fact, in the second case, the latter can talk to the former, but the former cannot talk back correctly, as it would be sending its response to its router. Now, its router might actually figure it out and pass it along or it might not, depending on configuration, and I've encountered this before and it couses quite the netowrk slowdown. In most cases, the default configuration will not allow the response to work at all, though. But simplex communication will work. Keep in mind that all TCP connections require duplex communication, though.

Thanks very much for the clarifications. Yeah, I see what you mean about the filtering onus being on the sending machine as opposed to the receiving machine.

Um....

Ummm....

[backing out of the Programming forum]

How 'bout them tube socks?

Hijack v392 sometime soon.

;@LOOPBACK command...
;@NOLOOPBACK command...

Cheers

Darn, a perfectly good discussion of networking tricks, made moot by a hijack feature. Shouldn't you be out scaling everest or something this time of year?

(Cool feature, by the way, Mark. )

Thanks, Mark.

Do these combine with ;@AC, or do they imply it?

In other words, if I have ;@NOLOOPBACK for my work dock, will the command also be executed in the car (which is DC and - obviously - no loopback) or not?

In reply to:

---

The only way it could be an issue is if someone else had also created an ad-hoc address group that matched yours, and then only if the individual addresses conflicted. And that's highly unlikely. And even if it did, you'd know instantly because you'd get an error message and then you could just pick a different digit.

---

This is the bit that causes me problems - suppose the address I've been allocated at home is the same as one allocated to somebody else at work. If we weren't on private addresses, this wouldn't happen, as normal addresses are assigned uniquely. But private addresses are allocated independently on each network; that's fine as long as long as the two networks don't come into direct contact. Moving a machine with a configured (non-DHCP) address from one net to the other in effect brings parts of the two networks together - there's a risk of conflicting with someone else's assigned address. Not that unlikely on a network like ours with thousands of private addresses, many of them DHCP allocated (so what happens to work today could fail unexpectedly later).

I know I would probably not notice if somebody else were assigned the address I was using - well, not until I tried to upload tunes or read the serial log, which could be several days. In the meantime, the other user would be giving lots of grief to IT Support. And they aren't the type to take abuse and hold onto it...

Anyway, this issue is solved (thanks, Mark!), so I'll set it up and forget it for a while.

Couple of things... 1. Since you're DHCP at work, why don't you just do DHCP at home, then you wouldn't need to change network configurations. 2. You could go the other way around and set your player to a fixed IP that fits into the work scheme and then add that address range to your home computer.

1. I'm not actually DHCP at work - since the leases were short enough to make uploading a pain (start JEmplode, wait for it to not find the player, get player address from About screen, type into JEmplode's dialog), I requested a fixed IP address (actually, I took it from a former machine of mine).

2. Yes, the address assigned at work is unlikely to clash at home - and my housemates are probably more accommodating than my colleagues in getting it right!

Anyway, @LOOPBACK/@NOLOOPBACK solves my wish much more effectively.

Excellent - one small question: which pins are used for the loopback? I tried hooking 6 and 7 (I think that was it) together for the dock identifier a while back and it never worked, so I ended up just setting it run httpd etc all the time, as it thinks it is in the car even when in the dock.

I've now read the code (and checked experimentally).

;@(NO)LOOPBACK can be used with ;@AC/;@DC and/or ;@WORK/;@HOME, and it must come first.

Loren, can you update the FAQ entry? While you're there, could you change the notes on the HTTP access control to match the new Hijack options? Thanks.

Hi Toby,

Yes, you've got it right (of course!). I may eventually tidy up the coding so that the order doesn't matter, but for now the sequence you posted is The Way.

Cheers

One idea I thought of (whilst trying - unsuccessfully - to understand how the ;@ stuff actually works) is simply to overwrite those characters in the in-memory copy with spaces. Would that work?

/me goes back to idly thinking of adding font-lock for the ;@ tokens into ini-generic-mode...

i believe that the Hijack faq is loren's baby...

Currently, Hijack only recognizes the macros when they are at the beginning of a line. When it sees one that applies, it simply replaces the trailing space (after the macro name) with a newline, thereby placing the rest of the macro line onto a line by itself where the player/hijack will recognize it.

But the code that does this is not iterative at present. Instead, it just does the LOOPBACK lines, then the AC/DC lines, then the HOME/WORK lines. Once. So they can combine in a specific order, but that's it.

If I just put a loop around it, either 3 times max or more intelligent.. then the order becomes insignificant.

Cheers

Okay, Hijack v393 is now available.

New in this version:

-- DRAM memory size replaces temperature on Vitals Screen (temperature is available from High Temperature Warning menu).

-- (one of) My email address(es) is now compiled into the kernel instead of "root@ibbm" or other random internal root@various_machines names.

-- The macro sequence in config.ini is no longer important. One can freely (and multiply) nest ;@NOLOOPBACK ;@LOOPBACK ;@AC ;@DC ;@HOME and ;@WORK on the same lines without regard to which follows which.

Cheers